From nobody Thu May  1 15:24:14 2014
Return-Path: <waqas20@gmail.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7F41A7032 for <stox@ietfa.amsl.com>; Thu,  1 May 2014 14:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkXR94t65son for <stox@ietfa.amsl.com>; Thu,  1 May 2014 14:02:06 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id E26621A0971 for <stox@ietf.org>; Thu,  1 May 2014 14:02:05 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id w7so2469067lbi.39 for <stox@ietf.org>; Thu, 01 May 2014 14:02:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=sEVwVad+yfN1DfZutficGCErIvB9U6BfVUJf68xVjS0=; b=QX6CuqpfRbMPlU6LR8ohizbiTHAesl7sO64rmuToCdMJU+hYHwRuULA8ubHz151nCB vutN3LfEoxH4sfr/ep3avGFCIEr5rBs5P7r4gbz+ki+JmyDu1yMI1MLEZmHpftPzojiB 7tacax53nv55FKHnx3HL0PipQqpCOEUs809qrhL95RKntE0/ZTOFaP4H78ii1wSTGxtI gUJT50xjRe1q23RBzsv6jTmTM0v/ozuo1St9dc7gKzFnA1WC451JHXGILT6ooE+Q7ipf 9aFdLnG10AapQCqVjsOq/4bbDhOq1FeUKBulHzKwFxjmmmHRhvy9I6GtxZZ5uLL7KUEW caGg==
X-Received: by 10.152.3.72 with SMTP id a8mr3538880laa.33.1398978123272; Thu, 01 May 2014 14:02:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.115.4.162 with HTTP; Thu, 1 May 2014 14:01:42 -0700 (PDT)
From: Waqas Hussain <waqas20@gmail.com>
Date: Thu, 1 May 2014 17:01:42 -0400
Message-ID: <CALm9TZ_--rtZyWu3k4WjNd1Oo=ZuYUuwyhySRQkD7aEPi5cJdQ@mail.gmail.com>
To: stox@ietf.org
Content-Type: multipart/alternative; boundary=089e01419f3416141704f85cfae2
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/tjeEqUF-0M1CeO4uMTsBFY1wr0w
X-Mailman-Approved-At: Thu, 01 May 2014 15:24:05 -0700
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 21:02:07 -0000

--089e01419f3416141704f85cfae2
Content-Type: text/plain; charset=UTF-8

On Apr 24, 2014, at 6:12 PM, Yana Stamcheva wrote:


Hello all,

Only one review has been received on this list during the WGLC
(Thanks Philipp!) and in order to be able to proceed we would need
more people to express their support for this document!

Therefore, we hereby would like to extend the WGLC period with 2
more weeks and end it on May 5, 2014.

Please, if you'd like this document to go forward, send your
reviews, comments or support notes to the list before May 5, 2014!

If you're willing to review the document but for some reason you
won't be able to do it before the above deadline, please contact
the chairs.



The mapping looks sane. I have not implemented it though.

--
Waqas Hussain

--089e01419f3416141704f85cfae2
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><pre style="color:rgb(0,0,0);margin:0em">On Apr 24, 2014, at 6:12 PM, Yana Stamcheva wrote:

</pre><blockquote style="color:rgb(0,0,0);font-family:Times;font-size:medium;border-left-color:rgb(85,85,238);border-left-style:solid;border-left-width:0.2em;margin:0em;padding-left:0.85em"><pre style="margin:0em">Hello all,

Only one review has been received on this list during the WGLC
(Thanks Philipp!) and in order to be able to proceed we would need
more people to express their support for this document!

Therefore, we hereby would like to extend the WGLC period with 2
more weeks and end it on May 5, 2014.

Please, if you&#39;d like this document to go forward, send your
reviews, comments or support notes to the list before May 5, 2014!

If you&#39;re willing to review the document but for some reason you
won&#39;t be able to do it before the above deadline, please contact
the chairs.

</pre></blockquote><div><br></div><div>The mapping looks sane. I have not implemented it though.<br></div><div><br></div><div>--</div><div>Waqas Hussain</div><div><br></div><div><br></div></div>

--089e01419f3416141704f85cfae2--


From nobody Fri May  2 13:16:24 2014
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2F1A091A for <stox@ietfa.amsl.com>; Fri,  2 May 2014 13:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.664
X-Spam-Level: 
X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7vK0AjajqR6 for <stox@ietfa.amsl.com>; Fri,  2 May 2014 13:16:22 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 037A11A0913 for <stox@ietf.org>; Fri,  2 May 2014 13:16:21 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta01.westchester.pa.mail.comcast.net with comcast id x7PM1n0030cZkys518GKyT; Fri, 02 May 2014 20:16:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id x8GK1n0093ZTu2S3W8GKAG; Fri, 02 May 2014 20:16:19 +0000
Message-ID: <5363FD13.5020106@alum.mit.edu>
Date: Fri, 02 May 2014 16:16:19 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: stox@ietf.org
References: <CALm9TZ_--rtZyWu3k4WjNd1Oo=ZuYUuwyhySRQkD7aEPi5cJdQ@mail.gmail.com>
In-Reply-To: <CALm9TZ_--rtZyWu3k4WjNd1Oo=ZuYUuwyhySRQkD7aEPi5cJdQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399061779; bh=bWmGWkFAgZsC0QLXzR+9k/jBiej41mTH+RYbNq21mk8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=etSPd3Gg2pARyTwoGbX4814sL9j6N9FPb1p63nvMEnRmgFhsce1dHT35MYZVZrgtO 5+4eBiVz+Y15qowmLGlGiGpzPW29R+1R5/eZoMHvzenoq0q5YCeo5/23elcxZnE7NW S1R8q33dkLcj3eg+u0fdfHq1tQ3aj7lb/+Mpb5fHYjUAUr52zSvIGPZJfTZl4Mp++o FQi6hfhJ8AWt0gHapYWyM+p2gXqYy29sZNVqCLUE8W2qQoEsTe3zMJRaaq5hQMe+yK 7GzVaq9fXmiFk5WT17SVlw5RmS4XGxlvO/y8ekf5KuCDLyw4uFMeW1+YC5CNBJwjze n0CdwQJkn5WlA==
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/dthdAz07glqlZUw_ZdKXdOAjW3E
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 20:16:22 -0000

I took a look at this. Disclaimer: It's been a long time since the 
simple-chat work was done and I haven't been involved with it since. So 
maybe I have forgotten or missed something.

Section 4:

Both F4 and F5 are 200 OK messages! It appears that F5 is unintended - 
it doesn't seem to be referenced anywhere.

In a variety of places in the MSRP examples:

The "gr=" URI parameter is used with sip URIs. It seems to be carrying 
nicknames. I don't know where that usage is coming from - it doesn't 
seem to come from draft-ietf-simple-chat-18. Should probably check with 
one of the authors of simple-chat about this.

	Thanks,
	Paul



From nobody Fri May  2 13:44:31 2014
Return-Path: <ben@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703B01A0939 for <stox@ietfa.amsl.com>; Fri,  2 May 2014 13:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level: 
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kh6luDdMgwx for <stox@ietfa.amsl.com>; Fri,  2 May 2014 13:44:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B111A091A for <stox@ietf.org>; Fri,  2 May 2014 13:44:28 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s42KiNdO009298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 May 2014 15:44:24 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org>
Date: Fri, 2 May 2014 15:44:23 -0500
X-Mao-Original-Outgoing-Id: 420756262.978313-0c5c2bcf68ff14c216551f43eba12cc2
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com>
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org>
To: Yana Stamcheva <yana@jitsi.org>, draft-ietf-stox-groupchat.all@tools.ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/2oqdjknM0DE-RtsCMb7xGHCm5cE
Cc: stox@ietf.org
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 20:44:30 -0000

Hi,=20

Here's some belated comments:

General:

I strongly suggest this be reviewed by one or both of the authors of =
draft-ietf-simple-chat, if it hasn't been already.

Conceptually it looks good. But I see some issues with the SIP =
interaction. It may be that I am confused by the two-gateway model, but =
you have a number of transactions where the SIP responses do not go back =
to the same entity that sent the SIP request. I suspect the intent was =
that one gateway or the other would handle things depending on which =
side initiated communication, but you've got dialogs (even individual =
transactions) split across them. If this is intended, then they would =
need to share SIP dialog and transaction state somehow.


Details:

-- Section 4:=20

It would be helpful to show a network diagram before jumping directly =
into the call flows.  (Same for the later scenario where the conference =
is an XMPP MUC).

- F3 is left hanging. If the xmpp-msrp gateway sends the INVITE, it =
needs to receive the response and also send an ACK. Also, it appears to =
skip the MSRP-XMPP gateway, but the rest of the transaction terminates =
there.  Effectively, the MSRP-XMPP gateway receives an unsolicited SIP =
response. This won't work.

- F4 and F5 appear to be duplicates.

- F7 indicates the MSRP session is between the MSRP-to-XMPP gateway and =
the conference server. But the MSRP-XMPP gateway never saw the XMPP user =
enter the room. Also, there should be a initial MSRP SEND request prior =
to the nick.

F8: Technically, the "OK" in the MSRP response is just a comment. I =
suggest showing MSRP responses by just the response code in the diagram. =
The comment has no semantic effect (and is even optional).

F18: This assumes the MSRP default reporting model was selected. This =
draft should probably consider how the MSRP REPORT method fits into the =
picture. (Along those lines, does anything change if MSRP relays are =
present?)

Also, F19 needs to land on the same device that sent F18.

F20: What triggered the msrp-xmpp gateway to send the XMPP groupchat =
message?

-- Section 4.1, example 2:

The a=3Dchatroom attribute does not include support for private =
messaging or nicknames. Since the flow uses these later, they should =
probably be included. (Repeats in 5.1)

-- Section 4.2, Example 6:

I suggest putting something more informative than "OK" in the MSRP 200 =
response. (e.g. "Nickname-Accepted").


-- Section 5:

What is the SIP Server? Is this a SIP Proxy, or something else? What =
value does it add to the flow?=20

F46: Need an initial MSRP SEND prior to the nickname request. Also, MSRP =
requests should not traverse a SIP server (unless it is also an MSRP =
relay.)

F47: I suggest moving F47 to after F45. As is, it looks like it take the =
SIP server a long time to proxy the ACK.

F56 and F57:

This shows the XMPP-MSRP gateway receiving the XMPP presence message, =
and sending the SIP NOTIFY. But that device never saw the SIP SUBSCRIBE. =
Either the SUBSCRIBE should have gone to it, or F56 and F57 should have =
crossed the other gateway.

Thanks!

/Ben


On Apr 24, 2014, at 11:12 AM, Yana Stamcheva <yana@jitsi.org> wrote:

> Hello all,
>=20
> Only one review has been received on this list during the WGLC (Thanks =
Philipp!) and in order to be able to proceed we would need more people =
to express their support for this document!
>=20
> Therefore, we hereby would like to extend the WGLC period with 2 more =
weeks and end it on May 5, 2014.
>=20
> Please, if you'd like this document to go forward, send your reviews, =
comments or support notes to the list before May 5, 2014!
>=20
> If you're willing to review the document but for some reason you won't =
be able to do it before the above deadline, please contact the chairs.
>=20
> Thanks!
> Yana Stamcheva & Markus Isomaki
>=20
> On 06 Apr 2014, at 20:20, Yana Stamcheva <yana@jitsi.org> wrote:
>=20
>> The editors and the chairs believe that the following draft is now =
ready and hereby start a 2-week Working Group Last Call for:
>>=20
>> draft-ietf-stox-groupchat-04 : =
http://tools.ietf.org/html/draft-ietf-stox-groupchat-04 (Last updated on =
2014-03-25)
>>=20
>> The WGLC ends on April 21, 2014.
>>=20
>> Please review the document and bring any remaining issues, or issues =
whose resolution is not satisfactory, to the attention of the Working =
Group on this list before April 21.
>>=20
>> If after reviewing the document you find it complete and do not have =
any comments, please send a note to that effect as well!
>>=20
>> Regards,
>> Yana Stamcheva & Markus Isomaki
>=20
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox


From nobody Mon May 12 07:08:27 2014
Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4691A0328 for <stox@ietfa.amsl.com>; Mon, 12 May 2014 07:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ldsdmLe226K for <stox@ietfa.amsl.com>; Mon, 12 May 2014 07:08:22 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6AC1A029C for <stox@ietf.org>; Mon, 12 May 2014 07:08:21 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id at1so3684572iec.19 for <stox@ietf.org>; Mon, 12 May 2014 07:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZSkHiTYLiE9eKtCwxyxQQ8FKP7avMpvpnAQ/thlwSYk=; b=hyBrG4DIaFkj0cDfVBHS3Ov4z70i7qsg8rS22V84KRjNZTQ3+KdPdY27gjuV5qrQH4 DrJPkRyxE1Jo5IgCjB3DMPJn2OnM6VSBvg7Grjfr7jEhYbXoZ0GXYehhtbPBvcyidlVD i4X8egDKgs/uYYYkrBmLquaGFP9txdWTxjwHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=ZSkHiTYLiE9eKtCwxyxQQ8FKP7avMpvpnAQ/thlwSYk=; b=OOIxKttIiOKj1VSIMIBN8Z0DlykSBd+b5ZqrB2ifsZAn0I3ydgPr8d5VkudTS/LXlq Q1rAvMtVDntb2FmCQ+1lcr9IBFxGP9QWU81z83dZdqiOPgQ3WdJgLkZVhGiLW25K2rF2 QyNqPe3V4Z3clm6+r0CimnvCj1qrmWFhCCRjxMbodrg+6jiQ3eCTyGQhloL0EDgl2xiy L5PbKVFFc2dp8oT9aNqCwa/wQdoUA6uszvhepn/a6aqEvEElGawVGg1rNqz2h5LKlLgc IEazXJSjRBOMpk4+pS3kXvfMkjaW1GnI51WyD463v2B30iyB58riTV+SUbr/igiAhCAh EjxQ==
X-Gm-Message-State: ALoCoQl9dvmHYRBafATKxipyYova1GHxVkgYoniyWK9Gowa32St8lVhVsPK5aC6inNOFH+WI1FJl
X-Received: by 10.50.111.138 with SMTP id ii10mr43763883igb.34.1399903695425;  Mon, 12 May 2014 07:08:15 -0700 (PDT)
Received: from [192.168.1.134] (32.251.sfcn.org. [160.7.251.32]) by mx.google.com with ESMTPSA id q2sm5630944ign.2.2014.05.12.07.08.14 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 07:08:14 -0700 (PDT)
Message-ID: <5370D5CD.4010800@getjive.com>
Date: Mon, 12 May 2014 08:08:13 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: stox@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/BUnXfnBIo1lqkHW0dzq29klQj9w
Subject: [Stox] Review - draft-ietf.stox-chat-06
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 14:08:26 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Review of draft-ietf-stox-chat-06:

1. I suggest labeling the state diagrams in Section 4 and Section 5
describing XMPP to MSRP order of events and MSRP to XMPP order of
events, respectively, e.g. "Figure 1", "Figure 2".

2. I suggest that both the state diagram in Section 4 and the state
diagram in Section 5 should enumerate all of the SIP messages that are
sent in the establishment of the session.
  a. In the state diagram in Section 4, after event F3 but before
event F4, the SIP Server sends SIP 100 TRYING back to the
XMPP-to-Server Gateway.
  b. In the state diagram in Section 4, after event F4 but before
event F5, the SIP user sends SIP 100 TRYING back to the SIP server.
  c. In the state diagram in Section 5, after event F19 but before
event F20, the SIP Server sends SIP 100 TRYING back to the SIP User.
  d. In the state diagram in Section 5, after event F20 but before
event F21, the SIP-to-XMPP Gateway sends SIP 100 TRYING back to the
SIP Server.

2. Considering the first state diagram in Section 4, the first portion
of this diagram from event F1 through event F10 inclusive:
  a. The SIP Server should complete the establishment of the SIP
Session with the XMPP-to-SIP Gateway; the SIP-to-XMPP Gateway should
not be involved in this interaction.  This is more consistent with
[I-D.ietf-stox-core] Section 4 which indicates, "If the XMPP user
initiates the interaction, then the XMPP server would invoke its
XMPP-to-SIP gateway and thus the communication would occur over SIP",
and with Figure 1 of that same section.  Until the XMPP-to-SIP Gateway
receives confirmation that the session originated by event F3 is
established, the interaction started by the XMPP User (event F1) is
incomplete.  In other words:
    i. Event F6 should be sent from the SIP Server to the XMPP-to-SIP
Gateway instead of the SIP-to-XMPP Gateway.
    ii. Events F7 and F8 should be sent to the SIP Server from the
XMPP-to-SIP Gateway instead of the SIP-to-XMPP Gateway.

3. Considering the first state diagram in Section 4, the last portion
of this diagram from event F15 through event F18 inclusive:
  a. Because the original SIP session should be established between
the XMPP-to-SIP Gateway and the SIP Server as I mentioned above in
2.a., event F16 should be sent from the SIP Server to the XMPP-to-SIP
Gateway instead of the SIP-to-XMPP Gateway; likewise, event F17 should
be sent to the SIP Server from the XMPP-to-SIP Gateway instead of the
SIP-to-XMPP Gateway.

4. The state diagrams in Sections 4 and 5 identify events representing
SIP ACK messages and subsequent MSRP SEND, e.g. the event groupings
numbered F7 and F8, F9 and F10, F23 and F24, and F25 and F26.
Grouping these messages in this way suggests that they must be
transferred in lockstep.  For example, consider the event sequence F7,
F8, F9, and F10.  The diagram seems to suggest that the SIP Server
would receive the SIP ACK (event F7) and then wait for the MSRP SEND
(event F8) before forwarding the SIP ACK to the SIP User (event F9).
However, the SIP Server should forward the SIP ACK immediately.

5. At the end of Section 4, Examples 8 and 9 describe how the SIP User
may terminate the session.  Similar examples are given in Section 5,
Examples 17 and 18.  I suggest that a mention is made in both sections
recognizing the lack of a corresponding sequence of events from the
XMPP User, due to the fact that XMPP does not establish sessions like
SIP does, along with a reference to Section 6 where this is discussed
in the context of the "gone" XMPP chat state.  Further, I suggest
labeling that portion of Section 6 to facilitate it being referenced
from Sections 4 and 5.

6. In the discussion of the "gone" XMPP chat state:
  a. I suggest referencing [XEP-0085] which describes this state.
  b. I suggest that an XMPP-to-SIP Gateway MUST support the "gone"
XMPP chat state.  This is a change from the support requirements for
the "gone" XMPP chat state as outlined in [XEP-0085] Section 5.2 Table
2 which indicate that XMPP agents SHOULD support the "gone" state.
  c. I suggest we recommend that the XMPP-to-SIP Gateway implement a
timeout as described in [XEP-0085] Section 2 Table 1, such that if the
XMPP User has not sent a message for a previously created XMPP-to-SIP
chat session for some period of time, and no SIP BYE has been received
to terminate the session from the SIP User, that a message with the
"gone" XMPP chat state be generated from the XMPP-to-SIP Gateway to
the SIP Server to end the session.  Should the XMPP User choose to
continue the conversation at a later date, a new SIP session can be
established.  Further, we should suggest a timeout value but indicate
that such a value is implementation dependent, as is done by
[XEP-0085] Section 2 Table 1.


- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan@getjive.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTcNXKAAoJEPyFiw1u4O0cYO0H/0K0ar7cWL6leMPAaoZIVAIz
2arUoJf3mB8zNfUqSTjknwizzBkxL+AwXqyD/hP0d6LCf/a5qo3A0Xr7xApBrRxJ
rYmoQcZN/r9e8MdJ8h6/1ngm4EjdqnsDFuqxKs95Cyl1D9dO9Kth06zH+gSt8jYp
m4+TzXAL9iVA7VbEbCsRtuuTltHV3Chn5u37kBuVb/NK/KMB6hR6zjZYDZ8bsFuw
rKEYjRdAM5ghZ1Sr6d/AoHGoXrp3MfnTsd1F7Z7TdHMm8MfVCVy75ivkeGXNAzDd
U+pIg1hGerC9Nh3fDvWulQArwMbgtgyXAfEXRcoeAniifNenG3kuZ6OjBPtd89k=
=d2SP
-----END PGP SIGNATURE-----


From nobody Mon May 19 19:36:23 2014
Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898DF1A047A for <stox@ietfa.amsl.com>; Mon, 19 May 2014 19:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeYhgvkS5CSd for <stox@ietfa.amsl.com>; Mon, 19 May 2014 19:36:19 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C91A0469 for <stox@ietf.org>; Mon, 19 May 2014 19:36:19 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id lx4so3224927iec.32 for <stox@ietf.org>; Mon, 19 May 2014 19:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=/HwCoZnoG+h9gpIGY0e+4XzS9ZybCF2BMm0O5gWSVLU=; b=TrEh8JmluNlAzxNEeB90vSMwjTEB7JzaMhPC6ewblVcE6pGNWl0RRpgK5F4NxhHhqB IDx+QyPkmlgfVHGbWTVrF0eECj00s87dnddu4/ZG3IRvX9jKTXqV8RRaWEiza/qkF1Ds yTMJkL8Al5lZM/efN90/j9lnVcNiPEzK7rrOo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=/HwCoZnoG+h9gpIGY0e+4XzS9ZybCF2BMm0O5gWSVLU=; b=bBWxzPd0woR//vhl8xPB5XPOuSMi2F9ud2mVaVtOO5oloaHKnGg+Jh049KFZ3+mQZi rCAqdWZb3trJbZlpunKjGlCLjuzt/76JvvSvZCyrbWNQ7qET9w4ZswsS3xUj7veq2niu raXsDwjfM7Bb3ePiWbOjRqfW1iDzkPdmeHk10xXY7yX1rmNBOryEDoRnnO5TOG2Q5ycp zp6I+s2XXkUrh2F3huS9XbMxzL0yBDsfUKRHHtIeuh21CEiAcyJQsEXeJadKRDNly3i0 097hDBWfICL8kX3SaWL0PpqJCB1EyqQZwjxj7kniovjvwNx6s2JarMDEG3cZcJNvzfb8 FQWw==
X-Gm-Message-State: ALoCoQlDS6hvAwgT2BSw3Lr7tipcII0d2srbVVsknlL20kLyc/fAKY2OO2NU2FDIXkCflOowVBc+
X-Received: by 10.42.168.6 with SMTP id u6mr36473459icy.41.1400553378961; Mon, 19 May 2014 19:36:18 -0700 (PDT)
Received: from [192.168.1.134] (32.251.sfcn.org. [160.7.251.32]) by mx.google.com with ESMTPSA id rt10sm25502102igb.15.2014.05.19.19.36.18 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 19:36:18 -0700 (PDT)
Message-ID: <537ABFA1.2080606@getjive.com>
Date: Mon, 19 May 2014 20:36:17 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: stox@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/JEDs2wqL8tlxkYEsgK1kCNKKwsU
Subject: [Stox] Communication between STOX-capable and non-STOX-capable entities
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 02:36:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Should a STOX-capable server be able to communicate with a
non-STOX-capable server, so long as the communication is started by
the STOX-capable server?  Is this among the current goals of the WG?

Sorry if this has been covered - but this particular point remains
unclear to me despite numerous readings through draft-ietf-stox-core
and some of the other supporting drafts.


Let me provide a simple example to explain what I mean.

Suppose an XMPP client initiates a chat to a user that happens to be a
SIP client user.  Per draft-ietf-stox-chat, this request flows through
the XMPP Server which determines that the message is targeted to a SIP
user, and then invokes its own XMPP-to-SIP Gateway to translate the
request to a SIP request and send that request on to the appropriate
SIP server.

So far, the XMPP Server knows that the target user is a SIP user, but
does not know anything about the SIP Server capabilities other than
that it is (presumably) a SIP server.  Importantly, the XMPP Server
does not know whether the SIP Server also supports a SIP-to-XMPP gateway.


This is where my question comes.  Given the described XMPP Server with
a corresponding XMPP-to-SIP gateway, is it meant to be the case that
this XMPP Server should be able to communicate with any valid SIP
server, so long as the conversation is initiated by the XMPP Server?


This is an important point because it has direct impact on several of
our current drafts.


- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan@getjive.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTer+bAAoJEPyFiw1u4O0c7Z0IALJSPkDrVBaLEOi2SB3xFg8B
8q0EFNodnF8v+u2Rwxf2Q4KTVVoufLY/GOxgaMcUzZPpAz99uK0n50w4o7+yMO6+
hyLql9tlkD6vaZ1I07JmuxA46PYEgfFU+xM4Oin3y2UP7CUerVJ0sxOU5w7vYMS0
rTEfTVenyj+w/vqXtzUvAIpXdlOOO0tyxDIXQc55KoK+yVCwpxn1oThBP0U339y1
cesEYMoQ2oFMRr49UiFGT1YAnjrcpt0FMHJ+90wh5qm54/N98JVBJ9kMhWFgn2/G
HthM4CV98ifiqSWDkvRKQtzimu73TJxSt9f5PCveQTrLQ51udTHOkTs3AtdAz6o=
=auEo
-----END PGP SIGNATURE-----


From nobody Wed May 21 18:30:59 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6906F1A005A; Wed, 21 May 2014 18:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5bzqoyBVlqi; Wed, 21 May 2014 18:30:45 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAC21A0059; Wed, 21 May 2014 18:30:45 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0D4A118000D; Wed, 21 May 2014 18:30:31 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140522013031.0D4A118000D@rfc-editor.org>
Date: Wed, 21 May 2014 18:30:31 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/W7HayFROrFfbR0mPwKznuiPNFAg
Cc: drafts-update-ref@iana.org, stox@ietf.org, rfc-editor@rfc-editor.org
Subject: [Stox] RFC 7247 on Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 01:30:51 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7247

        Title:      Interworking between the Session Initiation 
                    Protocol (SIP) and the Extensible Messaging 
                    and Presence Protocol (XMPP): Architecture, 
                    Addresses, and Error Handling 
        Author:     P. Saint-Andre, A. Houri, J. Hildebrand
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    ietf@stpeter.im, 
                    avshalom@il.ibm.com, 
                    jhildebr@cisco.com
        Pages:      24
        Characters: 57218
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-stox-core-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7247.txt

As a foundation for the definition of bidirectional protocol mappings
between the Session Initiation Protocol (SIP) and the Extensible
Messaging and Presence Protocol (XMPP), this document specifies the
architectural assumptions underlying such mappings as well as the
mapping of addresses and error conditions.

This document is a product of the SIP-TO-XMPP Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed May 21 18:31:19 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2C1A0061; Wed, 21 May 2014 18:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpzqC4n8V1a7; Wed, 21 May 2014 18:31:04 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8B8B1A005B; Wed, 21 May 2014 18:31:00 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7B2C218A9A0; Wed, 21 May 2014 18:30:46 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140522013046.7B2C218A9A0@rfc-editor.org>
Date: Wed, 21 May 2014 18:30:46 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/cs-KyxaU2ePWEs9sZZu92CZ1wSI
Cc: drafts-update-ref@iana.org, stox@ietf.org, rfc-editor@rfc-editor.org
Subject: [Stox] RFC 7248 on Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 01:31:06 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7248

        Title:      Interworking between the Session Initiation 
                    Protocol (SIP) and the Extensible Messaging 
                    and Presence Protocol (XMPP): Presence 
        Author:     P. Saint-Andre, A. Houri, J. Hildebrand
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    ietf@stpeter.im, 
                    avshalom@il.ibm.com, 
                    jhildebr@cisco.com
        Pages:      30
        Characters: 60875
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-stox-presence-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7248.txt

This document defines a bidirectional protocol mapping for the
exchange of presence information between the Session Initiation
Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP).

This document is a product of the SIP-TO-XMPP Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Tue May 27 07:51:52 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169131A0424 for <stox@ietfa.amsl.com>; Tue, 27 May 2014 07:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kX048esj7SH for <stox@ietfa.amsl.com>; Tue, 27 May 2014 07:51:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 944781A0158 for <stox@ietf.org>; Tue, 27 May 2014 07:51:43 -0700 (PDT)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DBD9540C58; Tue, 27 May 2014 08:51:39 -0600 (MDT)
Message-ID: <5384A67A.6050302@stpeter.im>
Date: Tue, 27 May 2014 08:51:38 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, stox@ietf.org
References: <CALm9TZ_--rtZyWu3k4WjNd1Oo=ZuYUuwyhySRQkD7aEPi5cJdQ@mail.gmail.com> <5363FD13.5020106@alum.mit.edu>
In-Reply-To: <5363FD13.5020106@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/e5oh3KvQg_n7UTkvnpIFEA0gd0I
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 14:51:45 -0000

On 5/2/14, 2:16 PM, Paul Kyzivat wrote:
> I took a look at this. Disclaimer: It's been a long time since the
> simple-chat work was done and I haven't been involved with it since. So
> maybe I have forgotten or missed something.
>
> Section 4:
>
> Both F4 and F5 are 200 OK messages! It appears that F5 is unintended -
> it doesn't seem to be referenced anywhere.

Yes, that's an extraneous line.

> In a variety of places in the MSRP examples:
>
> The "gr=" URI parameter is used with sip URIs. It seems to be carrying
> nicknames. I don't know where that usage is coming from - it doesn't
> seem to come from draft-ietf-simple-chat-18. Should probably check with
> one of the authors of simple-chat about this.

We do talk about the GRUU mapping in the stox-core spec (now RFC 7247). 
Here the GRUU valies (MUC) are mapping resourceparts of full JIDs, which 
in XMPP Multi-User Chat also serve as nicknames.

So, for instance, this is a mere resourcepart for a user's connected device:

    Contact: <sip:juliet@example.com>;gr=balcony

Whereas this is a resourcepart functioning as a MUC nickname:

    sip:verona@chat.example.org;gr=Romeo

Preserving this information from the XMPP side of the gateway seems like 
a good idea (or at least not a bad idea), but I am not sure if a 
standard MSRP implementation would make use of the information. Checking 
with the authors of draft-ietf-simple-chat seems like a reasonable thing 
to do.

Saúl, what does your implementation do with the GRUU in both cases (mere 
resourcepart and MUC nickname)?

Peter


From nobody Tue May 27 16:47:24 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76091A07C7 for <stox@ietfa.amsl.com>; Tue, 27 May 2014 16:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Ovp2GWCPFS for <stox@ietfa.amsl.com>; Tue, 27 May 2014 16:47:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6A931A0309 for <stox@ietf.org>; Tue, 27 May 2014 16:47:20 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 447B740C58; Tue, 27 May 2014 17:47:13 -0600 (MDT)
Message-ID: <53852400.2070704@stpeter.im>
Date: Tue, 27 May 2014 17:47:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Yana Stamcheva <yana@jitsi.org>,  draft-ietf-stox-groupchat.all@tools.ietf.org
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org> <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com>
In-Reply-To: <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/lg4RfrhWZlBWEmYwkTpviM-ITbQ
Cc: stox@ietf.org
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 23:47:23 -0000

Hi Ben, thanks for the feedback! Comments inline.

On 5/2/14, 2:44 PM, Ben Campbell wrote:
> Hi,
>
> Here's some belated comments:
>
> General:
>
> I strongly suggest this be reviewed by one or both of the authors of
> draft-ietf-simple-chat, if it hasn't been already.

Agreed. I've asked both Geir and Aki to take a look, and I've pinged Sal 
about asking Miguel since they work together.

> Conceptually it looks good. But I see some issues with the SIP
> interaction. It may be that I am confused by the two-gateway model,
> but you have a number of transactions where the SIP responses do not
> go back to the same entity that sent the SIP request. I suspect the
> intent was that one gateway or the other would handle things
> depending on which side initiated communication, but you've got
> dialogs (even individual transactions) split across them. If this is
> intended, then they would need to share SIP dialog and transaction
> state somehow.

Hmmmmmm.

You make a good point. The diagrams here are not consistent with the 
architectural assumptions we described in the stox-core spec (now RFC 
7247)...

         #########################################################
         #                                                       #
         #                 +-----+                               #
         #                 | S2X |                               #
         #   +-------------+ GW  |<...........>+-------------+   #
         #   | SIP Server  +-----+             | XMPP Server |   #
         #   | example.net |             +-----+ example.com |   #
         #   +-------------+<***********>| X2S +-------------+   #
         #         *                     | GW  |  :              #
         #         *                     +-----+  :              #
         #         *                              :              #
         #    romeo@example.net             juliet@example.com   #
         #                                                       #
         #########################################################

             Legend:
               XMPP = ... or :
                SIP = *

             Figure 1: Possible Gateway Deployment Architecture

    Note that bidirectional communication between the SIP server and the
    XMPP server can be established over either SIP or XMPP.  If the XMPP
    user initiates the interaction, then the XMPP server would invoke its
    XMPP-to-SIP gateway; thus, the communication would occur over SIP.
    If the SIP user initiates the interaction, then the SIP server would
    invoke its SIP-to-XMPP gateway; thus, the communication would occur
    over XMPP.

That is, the MSRP-to-XMPP gateway doesn't belong as an entity in the 
protocol flow for XMPP MUC to MSRP Multi-party Messaging Session 
(Section 4), and the XMPP-to-MSRP gateway doesn't belong in the protocol 
flow for MSRP Multi-party Messaging Session to XMPP MUC (Section 5). If 
we correct this error, I think most of the feedback you provide below 
can be easily addressed. For ease of reference, I refer to it from here 
on as the Fundamental Architectural Inconsistency Lameness, a.k.a. "FAIL".

Unfortunately, the diagrams in the stox-presence spec (now RFC 7248) 
make the FAIL, too! How I hate submitting errata on brand-new RFCs. :(

> Details:
>
> -- Section 4:
>
> It would be helpful to show a network diagram before jumping directly
> into the call flows.  (Same for the later scenario where the
> conference is an XMPP MUC).

Something like figure 1 in RFC 7247? We probably need a separate one 
here, because the entities are different.

> - F3 is left hanging. If the xmpp-msrp gateway sends the INVITE, it
> needs to receive the response and also send an ACK.  Also, it appears
> to skip the MSRP-XMPP gateway, but the rest of the transaction
> terminates there.  Effectively, the MSRP-XMPP gateway receives an
> unsolicited SIP response. This won't work.

Yes, the responses need to be sent back to the XMPP-to-MSRP gateway.

> - F4 and F5 appear to be duplicates.

Correct.

> - F7 indicates the MSRP session is between the MSRP-to-XMPP gateway
> and the conference server. But the MSRP-XMPP gateway never saw the
> XMPP user enter the room.

Right. This will get fixed by addressing the FAIL.

> Also, there should be a initial MSRP SEND
> request prior to the nick.

OK.

> F8: Technically, the "OK" in the MSRP response is just a comment. I
> suggest showing MSRP responses by just the response code in the
> diagram. The comment has no semantic effect (and is even optional).

Would you recommend removing such things for SIP responses, too?

> F18: This assumes the MSRP default reporting model was selected. This
> draft should probably consider how the MSRP REPORT method fits into
> the picture. (Along those lines, does anything change if MSRP relays
> are present?)

Agreed, we need to make it clear that we're using the default reporting 
model.

As I understand it, the MSRP REPORT method provides functionality 
similar to Message Delivery Receipts (XEP-0184) in XMPP. This is 
discussed in the stox-im spec:

http://tools.ietf.org/html/draft-ietf-stox-chat-06#section-7

I haven't thought much about how (or if) that applies to groupchat 
scenarios (in XMPP it's used mainly for one-to-one chat sessions, 
although it could be used for groupchat, too).

> Also, F19 needs to land on the same device that sent F18.

FAIL.

> F20: What triggered the msrp-xmpp gateway to send the XMPP groupchat
> message?

FAIL.

> -- Section 4.1, example 2:
>
> The a=chatroom attribute does not include support for private
> messaging or nicknames. Since the flow uses these later, they should
> probably be included. (Repeats in 5.1)

Good catch.

> -- Section 4.2, Example 6:
>
> I suggest putting something more informative than "OK" in the MSRP
> 200 response. (e.g. "Nickname-Accepted").

WFM.

> -- Section 5:

The FAIL applies here, too (i.e., remove the XMPP-to-MSRP gateway from 
the picture).

> What is the SIP Server? Is this a SIP Proxy, or something else? What
> value does it add to the flow?

I've assumed that a SIP client wouldn't send data directly to a gateway, 
but that a SIP Proxy would likely act as an intermediary and initial router.

> F46: Need an initial MSRP SEND prior to the nickname request.

Yes, as above.

> Also,
> MSRP requests should not traverse a SIP server (unless it is also an
> MSRP relay.)

I am not familiar enough with typical MSRP deployments to know if this 
is usually the case.

> F47: I suggest moving F47 to after F45. As is, it looks like it take
> the SIP server a long time to proxy the ACK.

Sure.

> F56 and F57:
>
> This shows the XMPP-MSRP gateway receiving the XMPP presence message,
> and sending the SIP NOTIFY. But that device never saw the SIP
> SUBSCRIBE. Either the SUBSCRIBE should have gone to it, or F56 and
> F57 should have crossed the other gateway.

The FAIL strikes again.

> Thanks!

No, thank you for the feedback!

Peter


From nobody Wed May 28 05:37:47 2014
Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0B01A00EA for <stox@ietfa.amsl.com>; Wed, 28 May 2014 05:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.989
X-Spam-Level: 
X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2nStxpJakZ1 for <stox@ietfa.amsl.com>; Wed, 28 May 2014 05:37:42 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA71A0064 for <stox@ietf.org>; Wed, 28 May 2014 05:37:42 -0700 (PDT)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E547614AC001; Wed, 28 May 2014 14:37:37 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <537ABFA1.2080606@getjive.com>
Date: Wed, 28 May 2014 14:37:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com>
References: <537ABFA1.2080606@getjive.com>
To: Matt Ryan <mryan@getjive.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/q-APs80A3Uroxq_EUhCtt8rSn2g
Cc: stox@ietf.org
Subject: Re: [Stox] Communication between STOX-capable and non-STOX-capable entities
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2014 12:37:43 -0000

Hi Matt,

On May 20, 2014, at 4:36 AM, Matt Ryan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> Should a STOX-capable server be able to communicate with a
> non-STOX-capable server, so long as the communication is started by
> the STOX-capable server?  Is this among the current goals of the WG?
>=20
> Sorry if this has been covered - but this particular point remains
> unclear to me despite numerous readings through draft-ietf-stox-core
> and some of the other supporting drafts.
>=20
>=20
> Let me provide a simple example to explain what I mean.
>=20
> Suppose an XMPP client initiates a chat to a user that happens to be a
> SIP client user.  Per draft-ietf-stox-chat, this request flows through
> the XMPP Server which determines that the message is targeted to a SIP
> user, and then invokes its own XMPP-to-SIP Gateway to translate the
> request to a SIP request and send that request on to the appropriate
> SIP server.
>=20
> So far, the XMPP Server knows that the target user is a SIP user, but
> does not know anything about the SIP Server capabilities other than
> that it is (presumably) a SIP server.  Importantly, the XMPP Server
> does not know whether the SIP Server also supports a SIP-to-XMPP =
gateway.
>=20
>=20
> This is where my question comes.  Given the described XMPP Server with
> a corresponding XMPP-to-SIP gateway, is it meant to be the case that
> this XMPP Server should be able to communicate with any valid SIP
> server, so long as the conversation is initiated by the XMPP Server?
>=20
>=20
> This is an important point because it has direct impact on several of
> our current drafts.
>=20

The idea is that a STOX capable infrastructure is transparent to others. =
To the eyes of the world,  given domain, say example.com has SRV records =
for SIP and XMPP. The fact that there is an actual gateway handling the =
traffic and doing some translations is a detail of that infrastructure. =
So a non-STOX server should be able to communicate with a STOX server =
just fine.


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From nobody Wed May 28 05:52:06 2014
Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220481A037D for <stox@ietfa.amsl.com>; Wed, 28 May 2014 05:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.989
X-Spam-Level: 
X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M84dpux0ddf for <stox@ietfa.amsl.com>; Wed, 28 May 2014 05:52:04 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id F2BC61A0151 for <stox@ietf.org>; Wed, 28 May 2014 05:52:03 -0700 (PDT)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D862314AC001; Wed, 28 May 2014 14:51:59 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <5384A67A.6050302@stpeter.im>
Date: Wed, 28 May 2014 14:51:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <35FABB91-8C3A-41A7-BD95-4C6FAD148BD5@ag-projects.com>
References: <CALm9TZ_--rtZyWu3k4WjNd1Oo=ZuYUuwyhySRQkD7aEPi5cJdQ@mail.gmail.com> <5363FD13.5020106@alum.mit.edu> <5384A67A.6050302@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/539py5H3_7Ga3AQpYcoVEz_9et8
Cc: stox@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2014 12:52:05 -0000

On May 27, 2014, at 4:51 PM, Peter Saint-Andre wrote:

> On 5/2/14, 2:16 PM, Paul Kyzivat wrote:
>> I took a look at this. Disclaimer: It's been a long time since the
>> simple-chat work was done and I haven't been involved with it since. =
So
>> maybe I have forgotten or missed something.
>>=20
>> Section 4:
>>=20
>> Both F4 and F5 are 200 OK messages! It appears that F5 is unintended =
-
>> it doesn't seem to be referenced anywhere.
>=20
> Yes, that's an extraneous line.
>=20
>> In a variety of places in the MSRP examples:
>>=20
>> The "gr=3D" URI parameter is used with sip URIs. It seems to be =
carrying
>> nicknames. I don't know where that usage is coming from - it doesn't
>> seem to come from draft-ietf-simple-chat-18. Should probably check =
with
>> one of the authors of simple-chat about this.
>=20
> We do talk about the GRUU mapping in the stox-core spec (now RFC =
7247). Here the GRUU valies (MUC) are mapping resourceparts of full =
JIDs, which in XMPP Multi-User Chat also serve as nicknames.
>=20
> So, for instance, this is a mere resourcepart for a user's connected =
device:
>=20
>   Contact: <sip:juliet@example.com>;gr=3Dbalcony
>=20
> Whereas this is a resourcepart functioning as a MUC nickname:
>=20
>   sip:verona@chat.example.org;gr=3DRomeo
>=20
> Preserving this information from the XMPP side of the gateway seems =
like a good idea (or at least not a bad idea), but I am not sure if a =
standard MSRP implementation would make use of the information. Checking =
with the authors of draft-ietf-simple-chat seems like a reasonable thing =
to do.
>=20
> Sa=FAl, what does your implementation do with the GRUU in both cases =
(mere resourcepart and MUC nickname)?
>=20

Hi,

Mere resourcepart is translated to a full JID. When using MUC, 2 things =
happen: the address is translated to a bare JID and a NICKNAME chunk is =
sent over MSRP in order to join the groupchat. The occupant JID is =
translated to a GRUU, which can be used for private messaging.

Hope that helps!

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From nobody Thu May 29 05:47:00 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2981A08DF for <stox@ietfa.amsl.com>; Thu, 29 May 2014 05:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level: 
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO55g1HAxyaj for <stox@ietfa.amsl.com>; Thu, 29 May 2014 05:46:58 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0A1A00AF for <stox@ietf.org>; Thu, 29 May 2014 05:46:58 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3484240332; Thu, 29 May 2014 06:46:52 -0600 (MDT)
Message-ID: <53872C3C.7000007@stpeter.im>
Date: Thu, 29 May 2014 06:46:52 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>,  Matt Ryan <mryan@getjive.com>
References: <537ABFA1.2080606@getjive.com> <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com>
In-Reply-To: <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/uFiahrqmTMxPk5vLdwLdTgWPe18
Cc: stox@ietf.org
Subject: Re: [Stox] Communication between STOX-capable and non-STOX-capable entities
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2014 12:46:59 -0000

On 5/28/14, 6:37 AM, Saúl Ibarra Corretgé wrote:
> Hi Matt,
>
> On May 20, 2014, at 4:36 AM, Matt Ryan wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Should a STOX-capable server be able to communicate with a
>> non-STOX-capable server, so long as the communication is started by
>> the STOX-capable server?  Is this among the current goals of the WG?
>>
>> Sorry if this has been covered - but this particular point remains
>> unclear to me despite numerous readings through draft-ietf-stox-core
>> and some of the other supporting drafts.
>>
>>
>> Let me provide a simple example to explain what I mean.
>>
>> Suppose an XMPP client initiates a chat to a user that happens to be a
>> SIP client user.  Per draft-ietf-stox-chat, this request flows through
>> the XMPP Server which determines that the message is targeted to a SIP
>> user, and then invokes its own XMPP-to-SIP Gateway to translate the
>> request to a SIP request and send that request on to the appropriate
>> SIP server.
>>
>> So far, the XMPP Server knows that the target user is a SIP user, but
>> does not know anything about the SIP Server capabilities other than
>> that it is (presumably) a SIP server.  Importantly, the XMPP Server
>> does not know whether the SIP Server also supports a SIP-to-XMPP gateway.
>>
>>
>> This is where my question comes.  Given the described XMPP Server with
>> a corresponding XMPP-to-SIP gateway, is it meant to be the case that
>> this XMPP Server should be able to communicate with any valid SIP
>> server, so long as the conversation is initiated by the XMPP Server?
>>
>>
>> This is an important point because it has direct impact on several of
>> our current drafts.
>>
>
> The idea is that a STOX capable infrastructure is transparent to others. To the eyes of the world,  given domain, say example.com has SRV records for SIP and XMPP. The fact that there is an actual gateway handling the traffic and doing some translations is a detail of that infrastructure. So a non-STOX server should be able to communicate with a STOX server just fine.

+1

Peter



From nobody Thu May 29 07:48:40 2014
Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04541A034F for <stox@ietfa.amsl.com>; Thu, 29 May 2014 07:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx0jsRbvzbyn for <stox@ietfa.amsl.com>; Thu, 29 May 2014 07:48:37 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15851A6F04 for <stox@ietf.org>; Thu, 29 May 2014 07:48:35 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id hl10so439565igb.17 for <stox@ietf.org>; Thu, 29 May 2014 07:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XriMQaDjjAYD8CjYd9hIVaXhwlM7p0nPW9VbFGfLKPw=; b=qY7Ynk0LXdsDZZZbw76GEV2QsbUt5NIsX/8Yg0x0wVmts4Zuo9coN1TxOo19fOQrL/ xoizodhBzWuRMpbr96PQP0Nh+GHvjv74lRHZuJKYzBHnytecmvtoh220A7HuNKx5Q7Fb G87U00hXtbeFrs36RoMjMT14WA+pJoxCFSqvc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XriMQaDjjAYD8CjYd9hIVaXhwlM7p0nPW9VbFGfLKPw=; b=hlywKODVmJyXbR1UKm871mR1PXY/lNDCW+q3SmSMgFfm95I+v2VaWonEJTtuVblxoU MZaS7wm7WoePiq4huCnFOyJBrDxJK7R/WlNWM9XCUw/DOg8LdRrsTJakhWd5aKQBvsBL JSTtk4fXRAr1djzOZc5rzoRI/ahKp/2sJiId3JUbForjs+dE1J8QAPypwPcOyCa0+VEt xyXDFO/0PB71j2A2XKLQilFEDTI6WQ1lU1oCnPs/UULUZIB6srZWbKh1ymIaYk264oe1 n4Pw7fPMCSBPLJ1SyGzHp1AEnwdgw5UevpY6dj2PGRD9/8e2wO9brzHf4VoB2VtPUONM c3GQ==
X-Gm-Message-State: ALoCoQlFjIuANQTGkQFh+rfeyI9XM1kBixH+HGkjPPFRmpAugy/v9/kijGtG3g0tEZKb55RbQHw5
X-Received: by 10.42.204.19 with SMTP id fk19mr8116488icb.68.1401374911641; Thu, 29 May 2014 07:48:31 -0700 (PDT)
Received: from [10.20.200.236] ([199.87.120.126]) by mx.google.com with ESMTPSA id vm1sm14634792igc.3.2014.05.29.07.48.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 07:48:31 -0700 (PDT)
Message-ID: <538748BE.1050608@getjive.com>
Date: Thu, 29 May 2014 08:48:30 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: stox@ietf.org
References: <537ABFA1.2080606@getjive.com> <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com> <53872C3C.7000007@stpeter.im>
In-Reply-To: <53872C3C.7000007@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/Mkd5VXsTnWrBfR24-fUt-XaDE7U
Cc: =?ISO-8859-1?Q?Sa=FAl_Ibarr?= =?ISO-8859-1?Q?a_Corretg=E9?= <saul@ag-projects.com>, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] Communication between STOX-capable and non-STOX-capable entities
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2014 14:48:39 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Saúl and Peter, thanks for your input on my question.

I agree that this is the approach we should take.  This direction is
supported by RFC 7427 (previously draft-ietf-stox-core) where the
responsibility for determining the format for communication and
translating if required is put upon the sending server and it's
accompanying gateway, and not upon the receiving server.

Because of this, I have further concerns with draft-ietf-stox-chat-06
as well as with draft-ietf-stox-groupchat-04.  I will enumerate these
each separately in their own review emails.  But in summary, the
concerns are that the examples given in these drafts show the gateways
on both sides of communication as being involved in exchanges where
they should not be required, and that showing the involvement of both
gateways gives the impression that both ARE required.

In other words, it does not emphasize the point that STOX-capable
servers must be able to communicate effectively with non-STOX-capable
servers, which it seems we agree is important.


On 5/29/14, 6:46 AM, Peter Saint-Andre wrote:
> On 5/28/14, 6:37 AM, Saúl Ibarra Corretgé wrote:
>> Hi Matt,
>> 
>> On May 20, 2014, at 4:36 AM, Matt Ryan wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>> 
>>> Should a STOX-capable server be able to communicate with a 
>>> non-STOX-capable server, so long as the communication is 
>>> started by the STOX-capable server?  Is this among the current
>>>  goals of the WG?
>>> 
>>> Sorry if this has been covered - but this particular point 
>>> remains unclear to me despite numerous readings through 
>>> draft-ietf-stox-core and some of the other supporting drafts.
>>> 
>>> 
>>> Let me provide a simple example to explain what I mean.
>>> 
>>> Suppose an XMPP client initiates a chat to a user that happens
>>>  to be a SIP client user.  Per draft-ietf-stox-chat, this 
>>> request flows through the XMPP Server which determines that the
>>> message is targeted to a SIP user, and then invokes its own
>>> XMPP-to-SIP Gateway to translate the request to a SIP request
>>> and send that request on to the appropriate SIP server.
>>> 
>>> So far, the XMPP Server knows that the target user is a SIP 
>>> user, but does not know anything about the SIP Server 
>>> capabilities other than that it is (presumably) a SIP server. 
>>> Importantly, the XMPP Server does not know whether the SIP 
>>> Server also supports a SIP-to-XMPP gateway.
>>> 
>>> 
>>> This is where my question comes.  Given the described XMPP 
>>> Server with a corresponding XMPP-to-SIP gateway, is it meant to
>>> be the case that this XMPP Server should be able to communicate
>>> with any valid SIP server, so long as the conversation is
>>> initiated by the XMPP Server?
>>> 
>>> 
>>> This is an important point because it has direct impact on 
>>> several of our current drafts.
>>> 
>> 
>> The idea is that a STOX capable infrastructure is transparent to 
>> others. To the eyes of the world,  given domain, say example.com
>> has SRV records for SIP and XMPP. The fact that there is an
>> actual gateway handling the traffic and doing some translations
>> is a detail of that infrastructure. So a non-STOX server should
>> be able to communicate with a STOX server just fine.
> 
> +1
> 
> Peter
> 
> 

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan@getjive.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTh0i5AAoJEPyFiw1u4O0cEKEIAIwOqkOX1Rv2OmYkPlaR1+iY
aX6I8FNVifLvLH8ejei0hSTZoPqLFIbuZwkrJCnNyBo2bV4xMFoL91nQnKNe4dFX
xbKzLEPuV++A2YswEA6kklpJOlxHvqJEaAaiixci4Z24ZYR1deyW0ZQzXGKvE8Kr
Fycvqyz/eGPEM+FuY4UQSRnqnjVVHXAGvUvl86C+XEqNdxY68EYBDSHf6VTxGczI
MdVRErTmgYgGB2vQvouALrq6DB6JccWEz8cVf1QAFkXwYe4yH/Z7Rz1l/dkgUXrb
5Mfn7MCIKFAFHNGJQPPNLp1wJziGZonMMYpaDC/dFiHVy+qRSD5dNLFajtgbzUE=
=fi5u
-----END PGP SIGNATURE-----


From nobody Fri May 30 13:38:33 2014
Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CE21A8788 for <stox@ietfa.amsl.com>; Fri, 30 May 2014 13:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SANAlvEkUw1P for <stox@ietfa.amsl.com>; Fri, 30 May 2014 13:38:26 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E791A6FE6 for <stox@ietf.org>; Fri, 30 May 2014 13:38:25 -0700 (PDT)
Received: by mail-ig0-f180.google.com with SMTP id c1so1316611igq.7 for <stox@ietf.org>; Fri, 30 May 2014 13:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oLSruS1FL04M5cfHFe750ftTUBgFaILKXELLSi+COYo=; b=FFh9I2fYvXuW5F2HvBAHoBF+QtwnuNodQ46g+BTywMzscVQKuI4VQUiLlgG28/abzj VFQ0ahpGerCWXljDKXxl9VEUFd/bYgxHEZHshgHdFV6+04tPjmnaDcaiF9Nvj/mNZroR vIaJ+l9f9oxGub0lpSt1XhAsirC7qjgRcB1bc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oLSruS1FL04M5cfHFe750ftTUBgFaILKXELLSi+COYo=; b=XGKLnKOdYs0ToCH4eN0pivDwq22WRcv0asOoRSKYq/V4+LWm24a29BF6LeCGZUz01N tOzIpCcEtperCvUqxj6K4mqYSdMD4Vxmw//oMy+5JQFVry1j+4p10HC1VHaBpEeXi0vl Qhgv8HAhIm9P6RTpQkOGs3vlgo4gcTXhDicpJeb59nZqEwroDeWPozrEkDdH0dXcCDJ7 ZnRVphgTJKBiiQe2lp3lVKxCW0EbpHkxdJttSbgInp3SumdmC7ArhLIdLCMy1a1AFAr5 XZP85b9D3LdcnjddDc7t0G6DsHGp9V6Ko8A7LtnbdCBqWd0uQ8PvSd3MTeMvKdCORQ4+ UV3A==
X-Gm-Message-State: ALoCoQm6VcRvLmFqip2HfG5fjPt0AV8x5cVToX1lqCIMGFrc7NwueFinTD6IoRF3fqC8bmR1eJhx
X-Received: by 10.50.254.132 with SMTP id ai4mr9148469igd.30.1401482300974; Fri, 30 May 2014 13:38:20 -0700 (PDT)
Received: from [10.20.200.236] ([199.87.120.126]) by mx.google.com with ESMTPSA id h5sm7971179igi.4.2014.05.30.13.38.19 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 13:38:20 -0700 (PDT)
Message-ID: <5388EC3B.70405@getjive.com>
Date: Fri, 30 May 2014 14:38:19 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: stox@ietf.org
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org> <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com> <53852400.2070704@stpeter.im>
In-Reply-To: <53852400.2070704@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/7FM5mKMzhSK18kjK9Im2lmjQXIs
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 20:38:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Comments below.


On 5/27/14, 5:47 PM, Peter Saint-Andre wrote:
> Hi Ben, thanks for the feedback! Comments inline.
> 
> On 5/2/14, 2:44 PM, Ben Campbell wrote:
>> Hi,
>> 
>> Here's some belated comments:
>> 
(snip)
>> I see some issues with the SIP interaction. It may be that I am
>> confused by the two-gateway model, but you have a number of
>> transactions where the SIP responses do not go back to the same
>> entity that sent the SIP request. I suspect the intent was that
>> one gateway or the other would handle things depending on which
>> side initiated communication, but you've got dialogs (even
>> individual transactions) split across them. If this is intended,
>> then they would need to share SIP dialog and transaction state
>> somehow.
> 
> Hmmmmmm.
> 
> You make a good point. The diagrams here are not consistent with
> the architectural assumptions we described in the stox-core spec
> (now RFC 7247)...
> 
> ######################################################### #
> # #                 +-----+                               # #
> | S2X |                               # #   +-------------+ GW
> |<...........>+-------------+   # #   | SIP Server  +-----+
> | XMPP Server |   # #   | example.net |             +-----+
> example.com |   # #   +-------------+<***********>| X2S
> +-------------+   # #         *                     | GW  |  :
> # #         *                     +-----+  :              # #
> *                              :              # #
> romeo@example.net             juliet@example.com   # #
> # #########################################################
> 
> Legend: XMPP = ... or : SIP = *
> 
> Figure 1: Possible Gateway Deployment Architecture
> 
> Note that bidirectional communication between the SIP server and
> the XMPP server can be established over either SIP or XMPP.  If the
> XMPP user initiates the interaction, then the XMPP server would
> invoke its XMPP-to-SIP gateway; thus, the communication would occur
> over SIP. If the SIP user initiates the interaction, then the SIP
> server would invoke its SIP-to-XMPP gateway; thus, the
> communication would occur over XMPP.
> 
> That is, the MSRP-to-XMPP gateway doesn't belong as an entity in
> the protocol flow for XMPP MUC to MSRP Multi-party Messaging
> Session (Section 4), and the XMPP-to-MSRP gateway doesn't belong in
> the protocol flow for MSRP Multi-party Messaging Session to XMPP
> MUC (Section 5).If we correct this error, I think most of the
> feedback you provide below can be easily addressed.


This is one of the concerns I also raised in my review of
draft-ietf-stox-chat-06 on 5/12/14, and why I raised my subsequent
question about communication between STOX-capable and non-STOX-capable
entities.

The situation is actually a bit worse:  If the XMPP-to-SIP gateway
sends a SIP invite to the SIP server (or MSRP conference in the
groupchat case) on the receiving end, the SIP session will not get
established until the XMPP-to-SIP gateway receives a 200 OK from the
SIP server, and it will continue to retry this INVITE until the
session is established.

Keeping state on the XMPP side might help (other than you still have
the unnecessary retransmits), but as Peter pointed out, simply
removing the MSRP-to-XMPP gateway in this protocol flow would then
result in the 200 OK returning to the XMPP-to-SIP gateway, which would
complete the establishment of the session also.


- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan@getjive.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTiOw5AAoJEPyFiw1u4O0c/mIIAKDTV4SAwORIuL3GwfqfA2Vg
AKeGMgmKT9RTLhXnh3YjJxetN1XJ9spGcaVUIv4xvlDnAdqqeURiR1jc8uSkLtl5
YPdzERgPrL4tLcum2+/0cVneRvgLqHfwj9O88im9GRtuMTZ8Ny6Vb0+rHHylq7Y+
zKo88Zi3myT7MNXZioa7KTxt+xtTDQz2LxhCkuLeK+Sr/dkG+aQOjI4ZYsPSE7Ne
aatqCXqA3gUbWVe1YmUhCzkSjVTun6OWRkxDvxG9QLIQkFRZnu96FPSrJETYYYwf
QXAyX14yr9beq6NUxUDdsCZJ0URL/mHeuSVe0isG+MhBXHwfNIjEebslh3BoACY=
=bt4O
-----END PGP SIGNATURE-----


From nobody Fri May 30 17:00:56 2014
Return-Path: <mryan@getjive.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AE11A0636 for <stox@ietfa.amsl.com>; Fri, 30 May 2014 17:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-F3q-uakaRF for <stox@ietfa.amsl.com>; Fri, 30 May 2014 17:00:52 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28EE1A04A9 for <stox@ietf.org>; Fri, 30 May 2014 17:00:52 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id rd18so2365228iec.24 for <stox@ietf.org>; Fri, 30 May 2014 17:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+v/5CpA8JbD6XtdVIOKzyvRaQtDTdv1Ex1O+9Fjfj/A=; b=Y79odVMZgxadcvPdI/z57NAIUani/eFRS0rYKAINsytNlElcBqL66AnJwnrdyYBao7 svP18sXhn2QHXjV5ZayQ4uAQRwGE6AoKYTK5D53gyc//yeJh9uQrJWxOJQZOs2/nXmTM QQQfm76SeuHJxAnsw8DzTlmjLvG5icvxjEytQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+v/5CpA8JbD6XtdVIOKzyvRaQtDTdv1Ex1O+9Fjfj/A=; b=KEMNORJ1vFPMRrkHBzrh9XtlEhLWJdtUdH6XuE77V+q4kbWDG8wD0SIe/ZrI9KfQjZ vC+Ok932XUrafZQXPHapyZbsHHrhIU5YDmU0/CY5XzWEpSPX6Z2xHlzsoCZyb9yNx4Mo UxHZgkgBOqep6NEt4SbKU5f+PbDzKdlL8ScR04Ds3u9ToHS5pAAMMlwG1aArpEsDpgyZ Z0j4rue7QQn8V5IRHoAVmQ9UuxAtkFzQYTcY6HfuxRLSsvBS3GHwTI2JRnQXYRf2gfRY 6C27x8h1B2VA3sR2mjFrVYB/jP6G+h9zmXLlzUb+qYusSv4J9BQ4HSdhl6dumfUisYa9 WlYQ==
X-Gm-Message-State: ALoCoQk6bpQwN8wJsDyJ+Kef6n1d8nYtaoau5D3W4jdjSTLc8G7qSHoHspcOWeB2rESC9oIcBLqR
X-Received: by 10.50.32.70 with SMTP id g6mr1095407igi.0.1401494447774; Fri, 30 May 2014 17:00:47 -0700 (PDT)
Received: from [10.20.200.236] ([199.87.120.126]) by mx.google.com with ESMTPSA id ie13sm9109572igb.10.2014.05.30.17.00.46 for <stox@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 17:00:47 -0700 (PDT)
Message-ID: <53891BAE.9040104@getjive.com>
Date: Fri, 30 May 2014 18:00:46 -0600
From: Matt Ryan <mryan@getjive.com>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: stox@ietf.org
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org> <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com> <53852400.2070704@stpeter.im>
In-Reply-To: <53852400.2070704@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/qWu-aL4VeYWBe3e_SvIlPgvsnGw
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 00:00:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 5/27/14, 5:47 PM, Peter Saint-Andre wrote:
> 
> Unfortunately, the diagrams in the stox-presence spec (now RFC
> 7248) make the FAIL, too! How I hate submitting errata on brand-new
> RFCs. :(
> 

Unfortunately, this is true - and also true for draft-ietf-stox-chat
and draft-ietf-stox-media.

If it pleases the group, I would be happy to volunteer to rework some
of the examples based on the discussion and submit them via the list
for further discussion.  I'll assume this is okay and try to get
started this weekend. :)


- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan at getjive dot com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTiRusAAoJEPyFiw1u4O0cW08IAI3YR0DkPLaHl7EzOBulVC9h
j2vGGqKz8j4xzYbR0DZhOO9QVHM3nlz17XuwwilKd8B6Mfui+9lfu52nJB+gFsuo
aR3fyKUXB+9UZv5whveffp77VtXLWa3Gl5kLnU/FljW7UUKCFshC2fYry4eVx5AD
3N7OupGrAEXCYubnZi1vn3a+XuagIf8criQaB4pJHNFxpzpYt/bc1XjLMjSJ0yXs
ARZNdKXLDC8fJSYYgYAdsLoIPdmvJ8t/pqce3CxozPAhMEsq+yd4FUSvHeoe6Efm
n8nGMi0zO4Q95sxQKK0lfKFL5E7Bt2J9dIx3Ki5HK1HqrqHEbSc8hWy61NCZc1w=
=Pa4D
-----END PGP SIGNATURE-----


From nobody Fri May 30 17:09:45 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1541A0679 for <stox@ietfa.amsl.com>; Fri, 30 May 2014 17:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K24QvsSmY_-A for <stox@ietfa.amsl.com>; Fri, 30 May 2014 17:09:41 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF51A0636 for <stox@ietf.org>; Fri, 30 May 2014 17:09:41 -0700 (PDT)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B856A40C58; Fri, 30 May 2014 18:09:36 -0600 (MDT)
Message-ID: <53891DC0.1090007@stpeter.im>
Date: Fri, 30 May 2014 18:09:36 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Matt Ryan <mryan@getjive.com>, stox@ietf.org
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org> <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com> <53852400.2070704@stpeter.im> <53891BAE.9040104@getjive.com>
In-Reply-To: <53891BAE.9040104@getjive.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/5ytZBenvZT78Srzz6TQ6GYl-RSY
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 00:09:42 -0000

On 5/30/14, 6:00 PM, Matt Ryan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 5/27/14, 5:47 PM, Peter Saint-Andre wrote:
>>
>> Unfortunately, the diagrams in the stox-presence spec (now RFC
>> 7248) make the FAIL, too! How I hate submitting errata on brand-new
>> RFCs. :(
>>
>
> Unfortunately, this is true - and also true for draft-ietf-stox-chat
> and draft-ietf-stox-media.
>
> If it pleases the group, I would be happy to volunteer to rework some
> of the examples based on the discussion and submit them via the list
> for further discussion.  I'll assume this is okay and try to get
> started this weekend. :)

Yeah it's all the specs. I wouldn't wish ASCII art editing on anyone, 
and I think it's mostly that, so I'm happy to do that for the next 
revision. But patches are always welcome. :-)

Peter