From nobody Mon Jun  2 10:06:04 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 6E13A1A024D for <stox@ietfa.amsl.com>; Mon,  2 Jun 2014 10:06:03 -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 rKoMUBiOxZJv for <stox@ietfa.amsl.com>; Mon,  2 Jun 2014 10:05:59 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE4D1A023A for <stox@ietf.org>; Mon,  2 Jun 2014 10:05:59 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id tp5so4743014ieb.17 for <stox@ietf.org>; Mon, 02 Jun 2014 10:05:54 -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=paVYerg5pw7VolUFTPJ9ntq6RqAp33L6fxF/gZ8yD7o=; b=Vu4CG+VciIR7BryQq0GOSm0qdHO5g0HN9/4Yj0m/Aq0DInR5Pw+65fvWXWD2ExjtwU P/f19UlpnIlU/sxLPc5fLMzDK/xmBftf3xGlKH86yrouFo1/ChUmuiw61uaEk2r2lAgH g3KVeu2O8gP08y0yevp5vqtPj8eTaoHmPVnI4=
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=paVYerg5pw7VolUFTPJ9ntq6RqAp33L6fxF/gZ8yD7o=; b=GfAZUiJbP3MblReKZ4m+dPmCRSvkYnPkSNsa7VX45XYHlqQQS5+G36wV3lPH+OD70k ym8989h9aI8i5hE2dMXhXJ/cvLT9+wrSzM/AdlNuO53lJKCcnQiz2wZf4r9BX7IZDlpH 8QdwLzRfdAUQ74QiBnd28fgaxOfohrJ+U00T427pXA7+JiH0mqeZ3axQWupKlHbehrtM XGT6TXI+8qQboPi3pNuOCqqS1YFxB5oNN+ik70O75e90ApOBYRVm348KGMrYFRnF+E0Q i6t60vBwd/cYDHThrAxTgJzoitKbma4pJLQdyfIPKrP3RbOWulWZ3hM0sJpR4wAPqBqA 2xMQ==
X-Gm-Message-State: ALoCoQljzS7JVEY6Xuoh2HSC84/BH9IzIpQohJ0sxFbQK+rOUp2wEVgzGrSOb1WZZqjNEINfk3sS
X-Received: by 10.50.131.136 with SMTP id om8mr9675163igb.49.1401728753943; Mon, 02 Jun 2014 10:05:53 -0700 (PDT)
Received: from [10.20.200.236] ([199.87.120.126]) by mx.google.com with ESMTPSA id q2sm6887143ign.2.2014.06.02.10.05.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 10:05:53 -0700 (PDT)
Message-ID: <538CAEF0.8060305@getjive.com>
Date: Mon, 02 Jun 2014 11:05:52 -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> <538748BE.1050608@getjive.com>
In-Reply-To: <538748BE.1050608@getjive.com>
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/oKRLLsxn7IqaW4IZAJOo0Yn1Ix0
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: Mon, 02 Jun 2014 17:06:03 -0000

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

Further comments in line.


On 5/29/14, 8:48 AM, Matt Ryan wrote:
> 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.

For simplicity's sake let me just enumerate my general suggestion
instead of separate review emails for each pertinent draft.  My
apologies for being indecisive.


I suggest the drafts contain some formal language indicating the
assumptions that should be followed on each side in order to emphasize
the interoperability point.

For example:
- - Given a server sending a message to another server with a different
protocol, the sending server doesn't know whether the receiving server
supports STOX, and interoperability is a goal, so there should be
language indicating that the server SHOULD (MUST?) support sender-side
translation of messages from one protocol to the other.
- - Because a receiving server might be receiving messages from a sender
that does not support STOX, the receiving server SHOULD support
destination-side translation of messages from one protocol to the other.

I believe this is in harmony both with RFC 7247 and the clarification
I received in answer to my question, and that such language would both
support and emphasize these two important points.


> 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.

I believe the discussion in a separate thread addresses this concern
for me, wherein we've talked about reworking the examples in the
drafts to not show the receiving-side gateway in the diagrams.



> 
> 
> 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 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/

iQEcBAEBCgAGBQJTjK7sAAoJEPyFiw1u4O0cT3oH+gPsBVdEARpG8S81LMInTAzT
vPmJMySq0T9fdCm5F0CLudEp9+tfZgGDg1DRCtBYRZWn8AhxK3GCUdlkT0OjO1a7
v4Ordp8dtJNcVLsHsQw7WJX5gkfJGgNrmJ2q1mIsNy1m2YtmGRvTQ6qY1duMUvQu
UuIJEIk5eIvOYIy7VhGUsnOMJmvXnxLSO5Lg6KKQNKtumU4VLduYdDTPyr4t6pk8
MIwmbJsbxlD3x3ltBvrnCVey6NUhWac1YcKFOediYeb/7LlaPfkkA4zoD2k0pyfH
4HFuYoqnNyDp3gohzSgDo+zAITgInv4YMeP5bmiNhaeIKGFZ5jAmUsfUUus7f2Y=
=WNXx
-----END PGP SIGNATURE-----


From nobody Tue Jun  3 20:32:38 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 EB6B21A0030 for <stox@ietfa.amsl.com>; Tue,  3 Jun 2014 20:32:36 -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 brXsomMow73Y for <stox@ietfa.amsl.com>; Tue,  3 Jun 2014 20:32:34 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B01A002E for <stox@ietf.org>; Tue,  3 Jun 2014 20:32:34 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B29CE40332; Tue,  3 Jun 2014 21:32:28 -0600 (MDT)
Message-ID: <538E934C.8090205@stpeter.im>
Date: Tue, 03 Jun 2014 21:32:28 -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: <5370D5CD.4010800@getjive.com>
In-Reply-To: <5370D5CD.4010800@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/W9EDOhmla-LPFSrJH3hDUQnKI4A
Subject: Re: [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: Wed, 04 Jun 2014 03:32:37 -0000

Hi Matt, thanks for the review. Comments inline.

(As mentioned in another thread, this document also needs to be updated 
to address what I jokingly called the "FAIL" issue.)

On 5/12/14, 8:08 AM, Matt Ryan wrote:
> -----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".

Sure.

> 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.

We haven't done that in all the other specs. Are you suggesting that we 
update them all? Do you feel that this would add value? Note also that 
we don't address every possible interaction (e.g., various error flows).

> 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.

Yes, that's the FAIL issue.

> 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.

More FAIL-ure.

> 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.

I haven't found a good way in these "swim-lane" diagrams to notate that 
things don't need to be sent in lockstep. We could at least add some 
text along those lines.

> 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.

Good point, will do.

> 6. In the discussion of the "gone" XMPP chat state:
>    a. I suggest referencing [XEP-0085] which describes this state.

Where do you suggest referencing this? It's already mentioned in 
paragraph 2 of Section 6.

>    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.

That seems sensible in this context.

>    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

(or has not sent a "gone" chat state, I suppose)

> , 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.

Would you also suggest that the gateway send a gone event to the XMPP 
user, indicating that the session is ended?

> Should the XMPP User choose to
> continue the conversation at a later date, a new SIP session can be
> established.

For sure.

> 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.

Simply citing XEP-0085 might be reasonable, unless MSRP has explicit 
recommendations about timeout values (I don't see anything in RFC 4975 
but I might be missing something).

Peter



From nobody Fri Jun  6 13:23:35 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 3B0D41A0268 for <stox@ietfa.amsl.com>; Fri,  6 Jun 2014 13:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PrP9rCh8J8nu for <stox@ietfa.amsl.com>; Fri,  6 Jun 2014 13:23:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE381A027C for <stox@ietf.org>; Fri,  6 Jun 2014 13:23:32 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s56KNMVP002961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 15:23: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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53852400.2070704@stpeter.im>
Date: Fri, 6 Jun 2014 15:23:22 -0500
X-Mao-Original-Outgoing-Id: 423779002.182674-0e6e4facaeaf9be3471465399be8ec30
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4B94AC1-B364-49E7-853A-FB7362A65DE7@nostrum.com>
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>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/-ZU7SKeE4y6WPDWga_RizMvbTKo
Cc: draft-ietf-stox-groupchat.all@tools.ietf.org, Yana Stamcheva <yana@jitsi.org>, 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, 06 Jun 2014 20:23:34 -0000

Hi,

Apologies for the delay--I just got back from vacation. Comments inline. =
I deleted sections that did not seem to need further comment.

On May 27, 2014, at 6:47 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> Hi Ben, thanks for the feedback! Comments inline.
>=20
> On 5/2/14, 2:44 PM, Ben Campbell wrote:
>=20

[...]

>> 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.
>=20
> Hmmmmmm.
>=20
> 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)...

[...]

> 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".
>=20
> Unfortunately, the diagrams in the stox-presence spec (now RFC 7248) =
make the FAIL, too! How I hate submitting errata on brand-new RFCs. :(
>=20

My apologies for not catching it there :-(

>> Details:
>>=20
>> -- 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).
>=20
> Something like figure 1 in RFC 7247? We probably need a separate one =
here, because the entities are different.

Yes. I don't think this is a show stopper, but I think it would make the =
draft easier to digest for a new reader.

[...]


>=20
>> 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).
>=20
> Would you recommend removing such things for SIP responses, too?
>=20

You had to go there, didn't you :-)

No, I don't recommend that for SIP. It's become conventional to leave =
them in for SIP. I realize that is inconsistent. The only reason I =
mention it is that inconsistent reason phrases have historically been a =
source of interop issues in SIP. We tried to make it better in MSRP by =
emphasizing that only the   error number matters, and anything that =
looks like a reason phrase is strictly a comment for humans.  But MSRP =
looks enough like SIP that the effort might have been futile.

In retrospect, I withdraw the comment. The call flows _are_ for human =
consumption, and the comments probably make them easier to understand.


>> 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?)
>=20
> Agreed, we need to make it clear that we're using the default =
reporting model.
>=20

With the MSRP defaults, we can probably get by without showing REPORTs =
if all endpoints are one hop from the switch. (That is, there are no =
MSRP relays.)


> 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:
>=20
> http://tools.ietf.org/html/draft-ietf-stox-chat-06#section-7
>=20
> 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).

It gets more complicated if someone requests success reports. You don't =
really get end-to-end success reports with simple-chat, because a =
typical MSRP client wouldn't understand getting multiple success reports =
for the same message (or message chunk) from different message =
recipients. If we need end-to-end acknowledgements, we might need =
something like RFC5438 extended for MSRP. But I doubt that's something =
STOX would want to take on.

[...]

>=20
>> -- Section 5:
>=20
> The FAIL applies here, too (i.e., remove the XMPP-to-MSRP gateway from =
the picture).
>=20
>> What is the SIP Server? Is this a SIP Proxy, or something else? What
>> value does it add to the flow?
>=20
> 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.
>=20

That's probably true for real world flows. I suggest relabeling it to =
proxy (and making sure it behaves like one.) OTOH, you can illustrate =
the flow without one if that would make things neater.

[...]

>> Also,
>> MSRP requests should not traverse a SIP server (unless it is also an
>> MSRP relay.)
>=20
> I am not familiar enough with typical MSRP deployments to know if this =
is usually the case.
>=20

While someone might co-locate them, they are separate logical functions. =
=46rom an architectural perspective we should probably not mix SIP and =
MSRP across the same "box".

[...]=


From nobody Sun Jun  8 13:27:32 2014
Return-Path: <prvs=229d99f18=markus.isomaki@nokia.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 568F91A0403 for <stox@ietfa.amsl.com>; Sun,  8 Jun 2014 13:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 yQ6P3LVvVbcx for <stox@ietfa.amsl.com>; Sun,  8 Jun 2014 13:27:29 -0700 (PDT)
Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F71F1A0175 for <stox@ietf.org>; Sun,  8 Jun 2014 13:27:28 -0700 (PDT)
Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-2.service.capgemini.fi with ESMTP; 08 Jun 2014 23:27:25 +0300
Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sun, 8 Jun 2014 23:27:25 +0300
Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.0775.031; Sun, 8 Jun 2014 23:27:06 +0300
From: <markus.isomaki@nokia.com>
To: <stox@ietf.org>
Thread-Topic: STOX WG status
Thread-Index: Ac+DUo3AQdK2vYOcREm/6H7x3tZgHw==
Date: Sun, 8 Jun 2014 20:27:06 +0000
Message-ID: <f48e141ae1854bcab5dfdc90c99eb2b1@NOKWDCFIEXCH02P.nnok.nokia.com>
Accept-Language: en-US, fi-FI
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.50.31.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/mh8QZQLESNc23Tbh56oalQBKFGQ
Subject: [Stox] STOX WG status
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: Sun, 08 Jun 2014 20:27:31 -0000

Hi all,

Below you can find the chairs' view of the current status of the STOX WG do=
cuments. Comments and questions are welcome.=20

---

  * draft-ietf-stox-core
     - Published as RFC 7247

  * draft-ietf-stox-presence
     - Published as RFC 7248
     - Will need an errata to address the FAIL [1] issue.

This documents are complete from STOX WG point of view.

---

  * draft-ietf-stox-im:
     - Initial WG last call already in December 2013
     - Latest update on March 11=20
     - No issues, ready for AD review. Wait to move it together with -chat,=
 though.
=20
  * draft-ietf-stox-chat:
      - Initial WG last call already in December 2013
     - Latest update on March 11
     - Reviews received after the last update
     - New revision needed to address the review comments including FAIL.=20

  * draft-ietf-stox-groupchat:
     - WG last call beginning of May
     - Reviews received during and after the last call
     - New version needed to address review comments including FAIL.

Target would be to get these above three documents to AD review within June=
/July timeframe. Peter, the main author in all of these, has been doing a g=
ood work with this set and has promised another round of updates in the nex=
t couple of weeks.

---

  * draft-ietf-stox-media:
    - Latest update on March 20
    - Still needs more work before considering WG last call

Target is to get this document to WG last call phase in August/September ti=
meframe. The chairs have asked the co-authors about their plans and at leas=
t Peter and Saul have promised to get busy with this again still in June.

---

[1] stox-core defines separate gateways in SIP-to-XMPP and XMPP-to-SIP dire=
ction, respectively. However, only a single gateway entity is supposed to b=
e used within one "instance" of communication: SIP-to-XMPP gateway is used =
when the communication is initiated from the SIP side, and vice versa. The =
message flow diagrams in stox-presecen, stox-chat and stox-groupchat howeve=
r mistakenly always show two gateways being involved. See http://www.ietf.o=
rg/mail-archive/web/stox/current/msg00507.html for more details.

Regards,
	Markus & Yana


From nobody Mon Jun  9 18:47:54 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 7954E1A0336 for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 18:47:53 -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 L3pNfo9AoFDY for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 18:47:51 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C87CB1A032E for <stox@ietf.org>; Mon,  9 Jun 2014 18:47:51 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A4FB540A26; Mon,  9 Jun 2014 19:47:50 -0600 (MDT)
Message-ID: <539663C6.7000508@stpeter.im>
Date: Mon, 09 Jun 2014 19:47:50 -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>
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> <C4B94AC1-B364-49E7-853A-FB7362A65DE7@nostrum.com>
In-Reply-To: <C4B94AC1-B364-49E7-853A-FB7362A65DE7@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/VQyV6W_ilNI259jH_rOJZjVurSE
Cc: stox@ietf.org, Yana Stamcheva <yana@jitsi.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, 10 Jun 2014 01:47:53 -0000

Honing in on one point for the moment...

On 6/6/14, 2:23 PM, Ben Campbell wrote:
>
> On May 27, 2014, at 6:47 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>
>> Hi Ben, thanks for the feedback! Comments inline.
>>
>> On 5/2/14, 2:44 PM, Ben Campbell wrote:

<snip/>

>>> 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.
>>
>
> While someone might co-locate them, they are separate logical functions. From an architectural perspective we should probably not mix SIP and MSRP across the same "box".

So the MSRP messages would be routed directly from the XMPP-to-MSRP 
gateway to the SIP user agent, right? And I take it that would apply to 
draft-ietf-stox-chat, too...

Peter


From nobody Mon Jun  9 19:50:43 2014
Return-Path: <internet-drafts@ietf.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 E6E511A036B; Mon,  9 Jun 2014 19:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2XcLOBC8MLfJ; Mon,  9 Jun 2014 19:50:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 990741A0347; Mon,  9 Jun 2014 19:50:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140610025037.20554.34247.idtracker@ietfa.amsl.com>
Date: Mon, 09 Jun 2014 19:50:37 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/YggBj2rips8uJVVdLAc4pskifOU
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-chat-07.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 02:50:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions
        Authors         : Peter Saint-Andre
                          Salvatore Loreto
	Filename        : draft-ietf-stox-chat-07.txt
	Pages           : 18
	Date            : 2014-06-09

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of instant messages in the context of a one-to-one chat
   session between a user of the Session Initiation Protocol (SIP) and a
   user of the Extensible Messaging and Presence Protocol (XMPP).
   Specifically for SIP text chat, this document specifies a mapping to
   the Message Session Relay Protocol (MSRP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-chat/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-chat-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jun  9 19:52:10 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 C7A931A035F for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:52:08 -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 LmretKtZ--ov for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:52:07 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 535BC1A034F for <stox@ietf.org>; Mon,  9 Jun 2014 19:52:07 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F0D040A26; Mon,  9 Jun 2014 20:52:06 -0600 (MDT)
Message-ID: <539672D6.70306@stpeter.im>
Date: Mon, 09 Jun 2014 20:52:06 -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: markus.isomaki@nokia.com, stox@ietf.org
References: <f48e141ae1854bcab5dfdc90c99eb2b1@NOKWDCFIEXCH02P.nnok.nokia.com>
In-Reply-To: <f48e141ae1854bcab5dfdc90c99eb2b1@NOKWDCFIEXCH02P.nnok.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/JZI6WpsZ1CmUSDGxAg-9xiTRNVo
Subject: Re: [Stox] STOX WG status
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, 10 Jun 2014 02:52:08 -0000

On 6/8/14, 2:27 PM, markus.isomaki@nokia.com wrote:

>    * draft-ietf-stox-chat:
>        - Initial WG last call already in December 2013
>       - Latest update on March 11
>       - Reviews received after the last update
>       - New revision needed to address the review comments including FAIL.

Done!

Peter


From nobody Mon Jun  9 19:52:26 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 0EB571A034F for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FChoctJ3LpL9 for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:52:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6441A0347 for <stox@ietf.org>; Mon,  9 Jun 2014 19:52:18 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5A2qFSO087313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jun 2014 21:52:17 -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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <539663C6.7000508@stpeter.im>
Date: Mon, 9 Jun 2014 21:52:15 -0500
X-Mao-Original-Outgoing-Id: 424061535.012964-52474b94c0b15d7bd4aa6b07eec433e6
Content-Transfer-Encoding: quoted-printable
Message-Id: <18A49A4B-5EE6-4832-B77E-6DCE345FBFD8@nostrum.com>
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> <C4B94AC1-B364-49E7-853A-FB7362A65DE7@nostrum.com> <539663C6.7000508@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/ahG09039GzYQZKqByfnJwCiI5Ic
Cc: stox@ietf.org, Yana Stamcheva <yana@jitsi.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, 10 Jun 2014 02:52:24 -0000

On Jun 9, 2014, at 8:47 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

>>>> Also,
>>>> MSRP requests should not traverse a SIP server (unless it is also =
an
>>>> MSRP relay.)
>>>=20
>>> I am not familiar enough with typical MSRP deployments to know if =
this is usually the case.
>>>=20
>>=20
>> While someone might co-locate them, they are separate logical =
functions. =46rom an architectural perspective we should probably not =
mix SIP and MSRP across the same "box".
>=20
> So the MSRP messages would be routed directly from the XMPP-to-MSRP =
gateway to the SIP user agent, right?

Assuming no MSRP relays are in play, yes. (And I think it's reasonable =
to leave them out unless you need to illustrate some MSRP relay specific =
interaction. I don't _think_ you do.)

Think of MSRP as a media session, with SIP signaling. Like RTP, but =
different :-)

> And I take it that would apply to draft-ietf-stox-chat, too...

Answering off the top of my head (as in not having stox-chat open in =
front of me), I think it probably applies there as well.

Thanks!

Ben.=


From nobody Mon Jun  9 19:53:50 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 B1C891A0347 for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:53:49 -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 ZqteA7NgjPhc for <stox@ietfa.amsl.com>; Mon,  9 Jun 2014 19:53:48 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A826D1A033C for <stox@ietf.org>; Mon,  9 Jun 2014 19:53:48 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5087B40A26; Mon,  9 Jun 2014 20:53:48 -0600 (MDT)
Message-ID: <5396733B.7060800@stpeter.im>
Date: Mon, 09 Jun 2014 20:53:47 -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>
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> <C4B94AC1-B364-49E7-853A-FB7362A65DE7@nostrum.com> <539663C6.7000508@stpeter.im> <18A49A4B-5EE6-4832-B77E-6DCE345FBFD8@nostrum.com>
In-Reply-To: <18A49A4B-5EE6-4832-B77E-6DCE345FBFD8@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/YuxadfZa5aEWwkO7yFM4ADZSnn0
Cc: stox@ietf.org, Yana Stamcheva <yana@jitsi.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, 10 Jun 2014 02:53:49 -0000

On 6/9/14, 8:52 PM, Ben Campbell wrote:
>
> On Jun 9, 2014, at 8:47 PM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
>
>>>>> 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.
>>>>
>>>
>>> While someone might co-locate them, they are separate logical
>>> functions. From an architectural perspective we should probably
>>> not mix SIP and MSRP across the same "box".
>>
>> So the MSRP messages would be routed directly from the XMPP-to-MSRP
>> gateway to the SIP user agent, right?
>
> Assuming no MSRP relays are in play, yes. (And I think it's
> reasonable to leave them out unless you need to illustrate some MSRP
> relay specific interaction. I don't _think_ you do.)

Agreed.

> Think of MSRP as a media session, with SIP signaling. Like RTP, but
> different :-)

Heh, yes.

>> And I take it that would apply to draft-ietf-stox-chat, too...
>
> Answering off the top of my head (as in not having stox-chat open in
> front of me), I think it probably applies there as well.

Well I assumed as much since it seemed sensible, so the latest version
(just posted) fixes that for 1:1 chat, too.

Thanks!

Peter



From nobody Tue Jun 10 16:40:33 2014
Return-Path: <internet-drafts@ietf.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 BFF991A0330; Tue, 10 Jun 2014 16:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yOtU28iqKuP0; Tue, 10 Jun 2014 16:40:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 867D11A00FD; Tue, 10 Jun 2014 16:40:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140610234030.21637.69436.idtracker@ietfa.amsl.com>
Date: Tue, 10 Jun 2014 16:40:30 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/Ol31eKRLVTczDkWesBc4d5LY95s
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-im-09.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 23:40:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
        Authors         : Peter Saint-Andre
                          Avshalom Houri
                          Joe Hildebrand
	Filename        : draft-ietf-stox-im-09.txt
	Pages           : 12
	Date            : 2014-06-10

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of single instant messages between the Session Initiation
   Protocol (SIP) and the Extensible Messaging and Presence Protocol
   (XMPP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-im/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-im-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jun 10 16:41:21 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 E4DB41A0264 for <stox@ietfa.amsl.com>; Tue, 10 Jun 2014 16:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.532
X-Spam-Level: 
X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 Nyuj82gZXDpr for <stox@ietfa.amsl.com>; Tue, 10 Jun 2014 16:41:19 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5BE1A0195 for <stox@ietf.org>; Tue, 10 Jun 2014 16:41:19 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DBBCB4032A; Tue, 10 Jun 2014 17:41:18 -0600 (MDT)
Message-ID: <5397979E.4000200@stpeter.im>
Date: Tue, 10 Jun 2014 17:41:18 -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
CC: stox@ietf.org
References: <20140610234030.21637.69436.idtracker@ietfa.amsl.com>
In-Reply-To: <20140610234030.21637.69436.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/TdeRW6nTr0lpOC-IEwqF5L3QqHU
Subject: Re: [Stox] I-D Action: draft-ietf-stox-im-09.txt
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, 10 Jun 2014 23:41:21 -0000

A few small edits for consistency with the other documents.

On 6/10/14, 5:40 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
>          Authors         : Peter Saint-Andre
>                            Avshalom Houri
>                            Joe Hildebrand
> 	Filename        : draft-ietf-stox-im-09.txt
> 	Pages           : 12
> 	Date            : 2014-06-10
>
> Abstract:
>     This document defines a bidirectional protocol mapping for the
>     exchange of single instant messages between the Session Initiation
>     Protocol (SIP) and the Extensible Messaging and Presence Protocol
>     (XMPP).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-stox-im/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-stox-im-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-09
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>


From nobody Tue Jun 10 20:44:56 2014
Return-Path: <internet-drafts@ietf.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 9B5481A0358; Tue, 10 Jun 2014 20:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Sbqt3z7T1J_i; Tue, 10 Jun 2014 20:44:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5271A033C; Tue, 10 Jun 2014 20:44:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140611034449.8863.29452.idtracker@ietfa.amsl.com>
Date: Tue, 10 Jun 2014 20:44:49 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/-0SPCw24evpYtuBEM5VKopnSp7s
Cc: stox@ietf.org
Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Jun 2014 03:44:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
        Authors         : Peter Saint-Andre
                          Saul Ibarra
                          Salvatore Loreto
	Filename        : draft-ietf-stox-groupchat-05.txt
	Pages           : 40
	Date            : 2014-06-10

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of instant messages in the context of a multiparty chat
   session among users of the Session Initiation Protocol (SIP) and
   users of the Extensible Messaging and Presence Protocol (XMPP).
   Specifically, this document defines a mapping between the SIP-based
   Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
   (MUC) extension.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-groupchat-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jun 10 20:46:26 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 DF0711A035E for <stox@ietfa.amsl.com>; Tue, 10 Jun 2014 20:46:22 -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 2m0ylvoTjUar for <stox@ietfa.amsl.com>; Tue, 10 Jun 2014 20:46:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E0D761A035D for <stox@ietf.org>; Tue, 10 Jun 2014 20:46:20 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 80D2040332; Tue, 10 Jun 2014 21:46:20 -0600 (MDT)
Message-ID: <5397D10B.3060806@stpeter.im>
Date: Tue, 10 Jun 2014 21:46:19 -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: stox@ietf.org
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com>
In-Reply-To: <20140611034449.8863.29452.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/H-kp0cGLMq97uWc_n62k6Pr39ko
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 11 Jun 2014 03:46:23 -0000

An attempt to address feedback received recently, as well as the "FAIL" 
issue...

On 6/10/14, 9:44 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.
>
>          Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
>          Authors         : Peter Saint-Andre
>                            Saul Ibarra
>                            Salvatore Loreto
> 	Filename        : draft-ietf-stox-groupchat-05.txt
> 	Pages           : 40
> 	Date            : 2014-06-10
>
> Abstract:
>     This document defines a bidirectional protocol mapping for the
>     exchange of instant messages in the context of a multiparty chat
>     session among users of the Session Initiation Protocol (SIP) and
>     users of the Extensible Messaging and Presence Protocol (XMPP).
>     Specifically, this document defines a mapping between the SIP-based
>     Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
>     (MUC) extension.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-stox-groupchat-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-05
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>


From nobody Wed Jun 11 09:57:11 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 E6A611A0207 for <stox@ietfa.amsl.com>; Wed, 11 Jun 2014 09:57:03 -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 jM3SdWt2iTzL for <stox@ietfa.amsl.com>; Wed, 11 Jun 2014 09:56:58 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB861A01E1 for <stox@ietf.org>; Wed, 11 Jun 2014 09:56:56 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id at1so19485iec.14 for <stox@ietf.org>; Wed, 11 Jun 2014 09:56:56 -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=L6/InTF+CW9hf5XZIXjhCWLZlvx/rCAkjxIwbPEhItE=; b=Pp79BAiN13oj6P4q7OLvOqxX3xsZ5iRXUJVLwDtpLFWv/K986YUQHr6onkbYtazVzK 6h2vTIf63VAgHLP3GOmY3XJztCFrF92ykgJtWmfshl93jOfJt+4m3/iT2h31o0GehKz2 onYftY4ZKRxfh6ixJ0uTfotL4iHs8I2It/4RE=
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=L6/InTF+CW9hf5XZIXjhCWLZlvx/rCAkjxIwbPEhItE=; b=OFEJvuSYPWk4TwW2jllbjhaBKrEaIVZyUEFP0LQC4sL/y7qZrljviDT6zf8D5H5FAc dZd5a0OhJrYEXvxCPlVrJJIJgzlnC7PAQTFH56bBNe1YzwGwwzhKqfcRfzzTrtzq+/h8 GqYwo6iTE3dt+dR4LQZWkXhGgh3Kppa1MA0hRNjS4fJAY3VXa47dnMO8XnGA0hm46nEn /onT6r+SBUIrLbKBc+iBKcbUZxq/bUrSRfitAO+lY0qDJYx3YecXNcok5p2GoVD5SjuL ZrRmSafxceB1gegGiFmlKv6brVz1NPc48zT02tYD5tufZwM8HA8CCwsowb/114d37guu S5Pg==
X-Gm-Message-State: ALoCoQnFheqMToMSpNg+z0Li91mwG4tfDXswX0eim7hbTCdAftxrJzCQuNBj2iIqG/V8Zs8ZAA4l
X-Received: by 10.42.83.6 with SMTP id f6mr47494412icl.11.1402505816288; Wed, 11 Jun 2014 09:56:56 -0700 (PDT)
Received: from [10.20.200.236] ([199.87.120.126]) by mx.google.com with ESMTPSA id ci7sm46513490igb.11.2014.06.11.09.56.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 09:56:55 -0700 (PDT)
Message-ID: <53988A57.9060700@getjive.com>
Date: Wed, 11 Jun 2014 10:56:55 -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: Peter Saint-Andre <stpeter@stpeter.im>, stox@ietf.org
References: <5370D5CD.4010800@getjive.com> <538E934C.8090205@stpeter.im>
In-Reply-To: <538E934C.8090205@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/ejCFB5z7rO706kJEX3fPGUKvvvU
Subject: Re: [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: Wed, 11 Jun 2014 16:57:04 -0000

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

Thank you for considering my review. I have reviewed
draft-ietf-stox-chat-07 and feel that it addresses the issues I raised
in my review.

I do have a couple of comments inline below.


On 6/3/14, 9:32 PM, Peter Saint-Andre wrote:
> Hi Matt, thanks for the review. Comments inline.
> 
> (As mentioned in another thread, this document also needs to be
> updated to address what I jokingly called the "FAIL" issue.)

It is simultaneously a clever acronym and too harsh a criticism. :)

> 
> On 5/12/14, 8:08 AM, Matt Ryan wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> Review of draft-ietf-stox-chat-06:
>> 

(snip)

>> 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.
> 
> We haven't done that in all the other specs. Are you suggesting
> that we update them all? Do you feel that this would add value?
> Note also that we don't address every possible interaction (e.g.,
> various error flows).
> 

That's fair.

My argument to include them is that RFC 3261 Section 17.2.1 indicates
this is a requirement for the SIP Server in this case, so it is
essential to the session establishment flow, which makes this case
different from error flows.  However, relevant diagrams are examples
and presumably not normative, and since leaving them out eliminates
clutter from the diagram making it easier to understand, I am okay
with leaving them out.

The new diagrams look great, by the way, much easier to understand now
that the receiving-side gateway is not in the picture anymore.




- -- 
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/

iQEcBAEBCgAGBQJTmIpVAAoJEPyFiw1u4O0cP/sH+wZkRte2F7p/RDaxYvE+9xUi
DQ7UtcvGIQqrhdnDOIMPwFiL47M+juJJKqX09YXNgLgsvAMEul8boamfadqLvyB5
nzbLO2kOYDwJeZp+hGDBFExy1syExmBfMTmEbibErYMQc/0EiBFSskasN7Qt9lks
WXUzxIjR4RRaGuo5fUwFrbtVAiiwPuf60wO4TBf/IPzVepZXGH0dcmuDCAyLUsxA
VILRtWhUFgy+atwLC18SfXA+bMx2IErJswncAFUu52lc96zXiihTnREUBmKoZsu8
9+tsy9UxrAjTY3XNrkszwEvku6tRkXeU6y84oBqp02xN+KHU/8neFGZCG/czToU=
=KvTA
-----END PGP SIGNATURE-----


From nobody Thu Jun 19 14:49:37 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 A78CF1A031A for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 14:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Tbr7a_jyAy2K for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 14:49:34 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7026A1A045B for <stox@ietf.org>; Thu, 19 Jun 2014 14:49:34 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5JLnUbm072572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2014 16:49:32 -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.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5397D10B.3060806@stpeter.im>
Date: Thu, 19 Jun 2014 16:49:31 -0500
X-Mao-Original-Outgoing-Id: 424907370.96806-1f8a04705138d6a60ea86fdecce8610d
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/H8fqKm4cXZ3_GUb5z8aA3aaKD6s
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 19 Jun 2014 21:49:36 -0000

Hi Peter,

[Disclaimer: this was a higher level review than for the previous =
version--I mainly looked to see how the previous discussions about the =
architecture rendered into the draft. ]

This version is much improved. I think you've gotten the "FAIL" off of =
it. But of course, cleaning up the architecture reveals a few things :-)

Section 4:

I think the addition of section 4 helps a lot in general.

The architecture treats the MSRP Conference server to be a monolithic =
thing. The result of this is, in the examples, all the SIP and MSRP =
traffic go to the sample place. That doesn't match the architecture from =
RFC 4975 and simple-chat, where the signaling (SIP) is separate from =
media (MSRP).  simple-chat talks in terms of a conference focus that =
handles the signaling side, and an MSRP switch that handles the media =
(MSRP) side.

Now, it's perfectly okay to collocate those services into an MSRP =
Conference Server in real deployments, and okay to show it that way in =
this draft for the sake of simplicity. But it would be worth mentioning =
that in section 4, and maybe also mentioning that any interaction =
between the conference focus and MSRP switch are out of scope (and =
irrelevant) for this draft.

Along the same line, I assume the public "SIP side" interface of the X2M =
gateway looks like a conference focus plus an MSRP switch to the outside =
world. Again, these could be logically separate, but co-located.

Section 5 (and subsections)

The diagram does not show the transport (e.g. TCP) connection =
establishment for MSRP. I think it would be useful to do so. Also, the =
active endpoint (the one opening the transport connection) has to send =
an immediate MSRP SEND request once the connection is established. (I =
don't _think_ simple-chat extended that to allow an initial NICKNAME to =
replace that--but I may have missed it.)

Section 6 (and subsections)

The diagram in section 6 still has a "SIP Server". It's still not clear =
to me what that represents. It _could_ be a SIP Proxy, in which the MSRP =
session would skip it. I guess it could be an MSRP aware b2bua, in which =
case the MSRP session might also traverse it. It could be a combo of a =
SIP proxy and an RFC 4976 MSRP relay, but that would require additional =
MSRP signaling.

I would suggest promoting it to some sort of SIP "service" or "service =
provider", which is more of a cloud than a box, and having the MSRP =
traffic skip it entirely. Or removing it entirely--there's no _protocol_ =
reason that a SIP user needs an outbound service provider (even though =
there might be perfectly good _deployment_ reasons.)

I also think section 6 needs to show the same sort of MSRP connection =
establishment and initial SEND request as mentioned for 5.

Thanks!

Ben.


On Jun 10, 2014, at 10:46 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> An attempt to address feedback received recently, as well as the =
"FAIL" issue...
>=20
> On 6/10/14, 9:44 PM, internet-drafts@ietf.org wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>  This draft is a work item of the SIP-TO-XMPP Working Group of the =
IETF.
>>=20
>>         Title           : Interworking between the Session Initiation =
Protocol (SIP) and the Extensible Messaging and Presence Protocol =
(XMPP): Groupchat
>>         Authors         : Peter Saint-Andre
>>                           Saul Ibarra
>>                           Salvatore Loreto
>> 	Filename        : draft-ietf-stox-groupchat-05.txt
>> 	Pages           : 40
>> 	Date            : 2014-06-10
>>=20
>> Abstract:
>>    This document defines a bidirectional protocol mapping for the
>>    exchange of instant messages in the context of a multiparty chat
>>    session among users of the Session Initiation Protocol (SIP) and
>>    users of the Extensible Messaging and Presence Protocol (XMPP).
>>    Specifically, this document defines a mapping between the =
SIP-based
>>    Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
>>    (MUC) extension.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-stox-groupchat-05
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-groupchat-05
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> stox mailing list
>> stox@ietf.org
>> https://www.ietf.org/mailman/listinfo/stox
>>=20
>=20
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox


From nobody Thu Jun 19 15:01:32 2014
Return-Path: <ag@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 CDF441A044F for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 15:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611] 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 cycnV45iIa6f for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 15:01:29 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE41A0320 for <stox@ietf.org>; Thu, 19 Jun 2014 15:01:28 -0700 (PDT)
Received: from [192.168.156.100] (r186-48-252-8.dialup.adsl.anteldata.net.uy [186.48.252.8]) by mail.sipthor.net (Postfix) with ESMTPSA id C495716DC724; Fri, 20 Jun 2014 00:01:24 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: ag@ag-projects.com
In-Reply-To: <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com>
Date: Thu, 19 Jun 2014 19:01:18 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <70C779B3-81E3-4E72-8CEA-44F97CF7436F@ag-projects.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/YQULtJ7kAvhui4CX-ZBA6o_VhIQ
Cc: stox@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 19 Jun 2014 22:01:31 -0000

On 19 Jun 2014, at 18:49, Ben Campbell <ben@nostrum.com> wrote:

> Hi Peter,
>=20
> [Disclaimer: this was a higher level review than for the previous =
version--I mainly looked to see how the previous discussions about the =
architecture rendered into the draft. ]
>=20
> This version is much improved. I think you've gotten the "FAIL" off of =
it. But of course, cleaning up the architecture reveals a few things :-)
>=20
> Section 4:
>=20
> I think the addition of section 4 helps a lot in general.
>=20
> The architecture treats the MSRP Conference server to be a monolithic =
thing. The result of this is, in the examples, all the SIP and MSRP =
traffic go to the sample place. That doesn't match the architecture from =
RFC 4975 and simple-chat, where the signaling (SIP) is separate from =
media (MSRP).  simple-chat talks in terms of a conference focus that =
handles the signaling side, and an MSRP switch that handles the media =
(MSRP) side.

For all practical reasons, they do end up in the same place. Otherwise, =
how would the MSRP switch communicate with the SIP server in order to =
share the information it knows about the participants or add/remove the =
media plane slots? Do we need another protocol or mechanism between the =
two? Even speculating about this possibility would introduce some =
unnecessary uncertainty for those contemplating implementing this =
specification.

> Now, it's perfectly okay to collocate those services into an MSRP =
Conference Server in real deployments, and okay to show it that way in =
this draft for the sake of simplicity.
> But it would be worth mentioning that in section 4, and maybe also =
mentioning that any interaction between the conference focus and MSRP =
switch are out of scope (and irrelevant) for this draft.

I would skip mentioning this this, based on the argument I made above. =
It sounds as scary as "there is something we don=92t know how it has to =
be done but is not our problem=94.=20

> Along the same line, I assume the public "SIP side" interface of the =
X2M gateway looks like a conference focus plus an MSRP switch to the =
outside world. Again, these could be logically separate, but co-located.
> Section 5 (and subsections)
>=20
> The diagram does not show the transport (e.g. TCP) connection =
establishment for MSRP. I think it would be useful to do so. Also, the =
active endpoint (the one opening the transport connection) has to send =
an immediate MSRP SEND request once the connection is established. (I =
don't _think_ simple-chat extended that to allow an initial NICKNAME to =
replace that--but I may have missed it.)
>=20
> Section 6 (and subsections)
>=20
> The diagram in section 6 still has a "SIP Server". It's still not =
clear to me what that represents. It _could_ be a SIP Proxy, in which =
the MSRP session would skip it. I guess it could be an MSRP aware b2bua, =
in which case the MSRP session might also traverse it. It could be a =
combo of a SIP proxy and an RFC 4976 MSRP relay, but that would require =
additional MSRP signaling.
>=20
> I would suggest promoting it to some sort of SIP "service" or "service =
provider", which is more of a cloud than a box, and having the MSRP =
traffic skip it entirely. Or removing it entirely--there's no _protocol_ =
reason that a SIP user needs an outbound service provider (even though =
there might be perfectly good _deployment_ reasons.)
>=20
> I also think section 6 needs to show the same sort of MSRP connection =
establishment and initial SEND request as mentioned for 5.
>=20
> Thanks!
>=20
> Ben.
>=20
>=20
> On Jun 10, 2014, at 10:46 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:
>=20
>> An attempt to address feedback received recently, as well as the =
"FAIL" issue...
>>=20
>> On 6/10/14, 9:44 PM, internet-drafts@ietf.org wrote:
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>> This draft is a work item of the SIP-TO-XMPP Working Group of the =
IETF.
>>>=20
>>>        Title           : Interworking between the Session Initiation =
Protocol (SIP) and the Extensible Messaging and Presence Protocol =
(XMPP): Groupchat
>>>        Authors         : Peter Saint-Andre
>>>                          Saul Ibarra
>>>                          Salvatore Loreto
>>> 	Filename        : draft-ietf-stox-groupchat-05.txt
>>> 	Pages           : 40
>>> 	Date            : 2014-06-10
>>>=20
>>> Abstract:
>>>   This document defines a bidirectional protocol mapping for the
>>>   exchange of instant messages in the context of a multiparty chat
>>>   session among users of the Session Initiation Protocol (SIP) and
>>>   users of the Extensible Messaging and Presence Protocol (XMPP).
>>>   Specifically, this document defines a mapping between the =
SIP-based
>>>   Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
>>>   (MUC) extension.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-stox-groupchat-05
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stox-groupchat-05
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> stox mailing list
>>> stox@ietf.org
>>> https://www.ietf.org/mailman/listinfo/stox
>>>=20
>>=20
>> _______________________________________________
>> stox mailing list
>> stox@ietf.org
>> https://www.ietf.org/mailman/listinfo/stox
>=20
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>=20


From nobody Thu Jun 19 15:25:12 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 6E9D81A016C for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 15:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kTndgXg8AObc for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 15:25:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78B11A0183 for <stox@ietf.org>; Thu, 19 Jun 2014 15:25:09 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5JMP3fk075517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2014 17:25:05 -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.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <70C779B3-81E3-4E72-8CEA-44F97CF7436F@ag-projects.com>
Date: Thu, 19 Jun 2014 17:25:03 -0500
X-Mao-Original-Outgoing-Id: 424909503.366751-d500017e6c3f4b9d3d5f9c8d0ef96866
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CA0EC6D-5955-42A4-89D2-9460436564B3@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <70C779B3-81E3-4E72-8CEA-44F97CF7436F@ag-projects.com>
To: ag@ag-projects.com
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/aCYGNoTkH8mFXDa0_K0FgqxAQgY
Cc: stox@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 19 Jun 2014 22:25:11 -0000

On Jun 19, 2014, at 5:01 PM, ag@ag-projects.com wrote:

>> The architecture treats the MSRP Conference server to be a monolithic =
thing. The result of this is, in the examples, all the SIP and MSRP =
traffic go to the sample place. That doesn't match the architecture from =
RFC 4975 and simple-chat, where the signaling (SIP) is separate from =
media (MSRP).  simple-chat talks in terms of a conference focus that =
handles the signaling side, and an MSRP switch that handles the media =
(MSRP) side.
>=20
> For all practical reasons, they do end up in the same place. =
Otherwise, how would the MSRP switch communicate with the SIP server in =
order to share the information it knows about the participants or =
add/remove the media plane slots? Do we need another protocol or =
mechanism between the two? Even speculating about this possibility would =
introduce some unnecessary uncertainty for those contemplating =
implementing this specification.

MSRP and simple-chat allow them to be separate. If people implement =
stox-groupchat to assume that the focus and switch are always =
co-located, then they could not interop with a decomposed MSRP =
conference service. If you think that MSRP conference services should =
not be decomposed in practice, that might be worth a separate draft :-) =
(Note that "should not be decomposed in practice" is a very different =
thing than "have not been decomposed in currently available services.)

As far "unnecessary uncertainty" goes, all it needs is guidance to avoid =
any assumption that the focus and switch are at the same address. =
Implementing stox-groupchat with a non-monolithic msrp conference =
service does not require solving the "how does the focus talk to the =
switch" problem. I'm not suggesting anything more complex than saying =
"We are showing these co-located to keep the diagrams simple--but =
remember that the SDP may point to a different location for the MSRP =
service."=


From nobody Thu Jun 19 20:36:30 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 1A2661A00B5 for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 20:36:27 -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 lr5W7bQUE8CE for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 20:36:25 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 288F81A01B6 for <stox@ietf.org>; Thu, 19 Jun 2014 20:36:25 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8338340DBF; Thu, 19 Jun 2014 21:36:24 -0600 (MDT)
Message-ID: <53A3AC37.30507@stpeter.im>
Date: Thu, 19 Jun 2014 21:36:23 -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.6.0
MIME-Version: 1.0
To: Matt Ryan <mryan@getjive.com>, stox@ietf.org
References: <5370D5CD.4010800@getjive.com> <538E934C.8090205@stpeter.im> <53988A57.9060700@getjive.com>
In-Reply-To: <53988A57.9060700@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/oo4MOrtXUDQCIeGZk6DJ32f8RTc
Subject: Re: [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: Fri, 20 Jun 2014 03:36:27 -0000

On 6/11/14, 10:56 AM, Matt Ryan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Thank you for considering my review. I have reviewed
> draft-ietf-stox-chat-07 and feel that it addresses the issues I raised
> in my review.
>
> I do have a couple of comments inline below.
>
>
> On 6/3/14, 9:32 PM, Peter Saint-Andre wrote:
>> Hi Matt, thanks for the review. Comments inline.
>>
>> (As mentioned in another thread, this document also needs to be
>> updated to address what I jokingly called the "FAIL" issue.)
>
> It is simultaneously a clever acronym and too harsh a criticism. :)
>
>>
>> On 5/12/14, 8:08 AM, Matt Ryan wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>>
>>> Review of draft-ietf-stox-chat-06:
>>>
>
> (snip)
>
>>> 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.
>>
>> We haven't done that in all the other specs. Are you suggesting
>> that we update them all? Do you feel that this would add value?
>> Note also that we don't address every possible interaction (e.g.,
>> various error flows).
>>
>
> That's fair.
>
> My argument to include them is that RFC 3261 Section 17.2.1 indicates
> this is a requirement for the SIP Server in this case, so it is
> essential to the session establishment flow, which makes this case
> different from error flows.  However, relevant diagrams are examples
> and presumably not normative, and since leaving them out eliminates
> clutter from the diagram making it easier to understand, I am okay
> with leaving them out.

I see the SIP 100 TRYING messages as analogous to XEP-0198 stream 
acknowledgements - we could include them (if XEP-0198 were part of RFC 
6120, if you will), but they would indeed clutter up the diagrams and 
IMHO what we're trying to do in the diagrams is help developers 
understand the overall flows.

But perhaps a note to that effect would be helpful.

> The new diagrams look great, by the way, much easier to understand now
> that the receiving-side gateway is not in the picture anymore.

Great, thanks for reviewing the document again!

Peter



From nobody Thu Jun 19 20:53: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 A01121A01C8 for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 20:52:57 -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 h2YMuZV18Ze2 for <stox@ietfa.amsl.com>; Thu, 19 Jun 2014 20:52:55 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD4EC1A01C4 for <stox@ietf.org>; Thu, 19 Jun 2014 20:52:55 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7091F40DBF; Thu, 19 Jun 2014 21:52:55 -0600 (MDT)
Message-ID: <53A3B016.6060202@stpeter.im>
Date: Thu, 19 Jun 2014 21:52:54 -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.6.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com>
In-Reply-To: <FAD8D3C3-9976-4813-86BF-64CE9247F63C@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/ipje2Ku2JUV1Ej59bs7uD75kSyY
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 20 Jun 2014 03:52:57 -0000

On 6/19/14, 3:49 PM, Ben Campbell wrote:
> Hi Peter,
>
> [Disclaimer: this was a higher level review than for the previous
> version--I mainly looked to see how the previous discussions about
> the architecture rendered into the draft. ]
>
> This version is much improved. I think you've gotten the "FAIL" off
> of it. But of course, cleaning up the architecture reveals a few
> things :-)
>
> Section 4:
>
> I think the addition of section 4 helps a lot in general.
>
> The architecture treats the MSRP Conference server to be a monolithic
> thing.

As you pointed out later in this thread, this is a simplifying 
assumption to make the diagrams and explanations easier to follow.

> The result of this is, in the examples, all the SIP and MSRP
> traffic go to the sample place. That doesn't match the architecture
> from RFC 4975 and simple-chat, where the signaling (SIP) is separate
> from media (MSRP).  simple-chat talks in terms of a conference focus
> that handles the signaling side, and an MSRP switch that handles the
> media (MSRP) side.
>
> Now, it's perfectly okay to collocate those services into an MSRP
> Conference Server in real deployments, and okay to show it that way
> in this draft for the sake of simplicity. But it would be worth
> mentioning that in section 4, and maybe also mentioning that any
> interaction between the conference focus and MSRP switch are out of
> scope (and irrelevant) for this draft.
>
> Along the same line, I assume the public "SIP side" interface of the
> X2M gateway looks like a conference focus plus an MSRP switch to the
> outside world. Again, these could be logically separate, but
> co-located.

Exactly.

> Section 5 (and subsections)
>
> The diagram does not show the transport (e.g. TCP) connection
> establishment for MSRP. I think it would be useful to do so.

Agreed.

(It would also be useful to mention that we're assuming that an MSRP 
client uses the SIP "binding" to communicate with the MSRP conference 
server, see Section 6...)

> Also,
> the active endpoint (the one opening the transport connection) has to
> send an immediate MSRP SEND request once the connection is
> established. (I don't _think_ simple-chat extended that to allow an
> initial NICKNAME to replace that--but I may have missed it.)

Good catch.

> Section 6 (and subsections)
>
> The diagram in section 6 still has a "SIP Server".

I have to admit that I was pretty sleepy when I was editing that part of 
the document. :-)

> It's still not
> clear to me what that represents. It _could_ be a SIP Proxy, in which
> the MSRP session would skip it. I guess it could be an MSRP aware
> b2bua, in which case the MSRP session might also traverse it. It
> could be a combo of a SIP proxy and an RFC 4976 MSRP relay, but that
> would require additional MSRP signaling.
>
> I would suggest promoting it to some sort of SIP "service" or
> "service provider", which is more of a cloud than a box, and having
> the MSRP traffic skip it entirely. Or removing it entirely--there's
> no _protocol_ reason that a SIP user needs an outbound service
> provider (even though there might be perfectly good _deployment_
> reasons.)

If we remove it entirely (and I'm not opposed to that), is it safe to 
say that an MSRP client would connect directly to an MSRP-to-XMPP 
gateway? With my XMPP glasses on that doesn't make sense because in that 
world we always think of something (a "service" or "service provider" as 
you call it) acting as a network gatekeeper. However, I know that's not 
something we assume in SIP/MSRP architectures, so for our purposes here 
it's probably fine to delete the service provider from the diagrams in 
Section 6.

> I also think section 6 needs to show the same sort of MSRP connection
> establishment and initial SEND request as mentioned for 5.

Noted!

> Thanks!
>
> Ben.

Thanks for your continued reviews!

Peter


From nobody Fri Jun 20 13:31:29 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 A63FF1B2904 for <stox@ietfa.amsl.com>; Fri, 20 Jun 2014 13:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qSaNNN1kkLdT for <stox@ietfa.amsl.com>; Fri, 20 Jun 2014 13:31:25 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F71C1B28F3 for <stox@ietf.org>; Fri, 20 Jun 2014 13:31:25 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5KKVLrT068391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jun 2014 15:31: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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53A3B016.6060202@stpeter.im>
Date: Fri, 20 Jun 2014 15:31:21 -0500
X-Mao-Original-Outgoing-Id: 424989081.821871-5ad80e75b1f2482948fb06d6a795ce43
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED7FABAE-27C2-44A4-A0F9-D59130166DE2@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/b2_qlcuXgDxEJKROH0SnNzKCbpM
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 20 Jun 2014 20:31:27 -0000

On Jun 19, 2014, at 10:52 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> On 6/19/14, 3:49 PM, Ben Campbell wrote:
>> Hi Peter,
>>=20
>> [Disclaimer: this was a higher level review than for the previous
>> version--I mainly looked to see how the previous discussions about
>> the architecture rendered into the draft. ]
>>=20
>> This version is much improved. I think you've gotten the "FAIL" off
>> of it. But of course, cleaning up the architecture reveals a few
>> things :-)
>>=20
>> Section 4:
>>=20
>> I think the addition of section 4 helps a lot in general.
>>=20
>> The architecture treats the MSRP Conference server to be a monolithic
>> thing.
>=20
> As you pointed out later in this thread, this is a simplifying =
assumption to make the diagrams and explanations easier to follow.

Do you concur that that assumption should be pointed out? (Or did I miss =
some place where it is already?)

On a tangentially related note, I recall another reviewer complained =
about the lack of SIP provisional responses. It might be worth also =
putting in a disclaimer that provisional responses have been left out to =
simplify things.

>=20

[...]

>> Section 5 (and subsections)
>>=20
>> The diagram does not show the transport (e.g. TCP) connection
>> establishment for MSRP. I think it would be useful to do so.
>=20
> Agreed.
>=20
> (It would also be useful to mention that we're assuming that an MSRP =
client uses the SIP "binding" to communicate with the MSRP conference =
server, see Section 6...)

Agreed.

[...]

>> Section 6 (and subsections)
>>=20
>> The diagram in section 6 still has a "SIP Server".
>=20
> I have to admit that I was pretty sleepy when I was editing that part =
of the document. :-)
>=20
>> It's still not
>> clear to me what that represents. It _could_ be a SIP Proxy, in which
>> the MSRP session would skip it. I guess it could be an MSRP aware
>> b2bua, in which case the MSRP session might also traverse it. It
>> could be a combo of a SIP proxy and an RFC 4976 MSRP relay, but that
>> would require additional MSRP signaling.
>>=20
>> I would suggest promoting it to some sort of SIP "service" or
>> "service provider", which is more of a cloud than a box, and having
>> the MSRP traffic skip it entirely. Or removing it entirely--there's
>> no _protocol_ reason that a SIP user needs an outbound service
>> provider (even though there might be perfectly good _deployment_
>> reasons.)
>=20
> If we remove it entirely (and I'm not opposed to that), is it safe to =
say that an MSRP client would connect directly to an MSRP-to-XMPP =
gateway? With my XMPP glasses on that doesn't make sense because in that =
world we always think of something (a "service" or "service provider" as =
you call it) acting as a network gatekeeper. However, I know that's not =
something we assume in SIP/MSRP architectures, so for our purposes here =
it's probably fine to delete the service provider from the diagrams in =
Section 6.
>=20

In the SIP/MSRP world, this is sort of fuzzy.=20

There's no  SIP architectural requirement for clients to send their =
signaling through some service between themselves and the destinations. =
But in practice, they commonly do for various reasons ( NAT traversal, =
authentication, policy enforcement, control-oriented service providers, =
etc). And what sits in that box may be different for different =
deployments.=20

Similarly, MSRP might have an MSRP relay there, or you might have some =
SBC-like device that handles both signaling and media (the case that =
would look the most like the diagram.)

I would personally lean towards taking it out, perhaps with a disclaimer =
that there might be any number of SIP and/or MSRP devices between the =
client and the gateway (which btw is acting both as a SIP to XMPP and =
MSRP to XMPP gateway, even if only for chat purposes), but that they are =
not important for understanding the flow.


>> I also think section 6 needs to show the same sort of MSRP connection
>> establishment and initial SEND request as mentioned for 5.
>=20
> Noted!
>=20
>> Thanks!
>>=20
>> Ben.
>=20
> Thanks for your continued reviews!
>=20
> Peter


From nobody Mon Jun 23 00:21: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 896B41A0564 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.711
X-Spam-Level: *
X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZKay_CsGngR5 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:21:39 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79E1B29CB for <stox@ietf.org>; Mon, 23 Jun 2014 00:21:38 -0700 (PDT)
Received: from imac.saghul.lan (g154115.upc-g.chello.nl [80.57.154.115]) by mail.sipthor.net (Postfix) with ESMTPSA id 150D016DC6DE; Mon, 23 Jun 2014 09:21:35 +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: <538CAEF0.8060305@getjive.com>
Date: Mon, 23 Jun 2014 09:21:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <533D00BC-0988-4430-96ED-028381A951DF@ag-projects.com>
References: <537ABFA1.2080606@getjive.com> <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com> <53872C3C.7000007@stpeter.im> <538748BE.1050608@getjive.com> <538CAEF0.8060305@getjive.com>
To: Matt Ryan <mryan@getjive.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/GDoST1r9fX3yqE5YkhknONmWIOU
Cc: stox@ietf.org, 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: Mon, 23 Jun 2014 07:21:40 -0000

Hi Matt,

Sorry for the belated response.

On Jun 2, 2014, at 7:05 PM, Matt Ryan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> Further comments in line.
>=20
>=20
> On 5/29/14, 8:48 AM, Matt Ryan wrote:
>> Sa=FAl and Peter, thanks for your input on my question.
>>=20
>> 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.
>>=20
>> 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.
>=20
> For simplicity's sake let me just enumerate my general suggestion
> instead of separate review emails for each pertinent draft.  My
> apologies for being indecisive.
>=20
>=20
> I suggest the drafts contain some formal language indicating the
> assumptions that should be followed on each side in order to emphasize
> the interoperability point.
>=20
> For example:
> - - Given a server sending a message to another server with a =
different
> protocol, the sending server doesn't know whether the receiving server
> supports STOX, and interoperability is a goal, so there should be
> language indicating that the server SHOULD (MUST?) support sender-side
> translation of messages from one protocol to the other.
> - - Because a receiving server might be receiving messages from a =
sender
> that does not support STOX, the receiving server SHOULD support
> destination-side translation of messages from one protocol to the =
other.
>=20
> I believe this is in harmony both with RFC 7247 and the clarification
> I received in answer to my question, and that such language would both
> support and emphasize these two important points.
>=20

I need to go through the rest of the emails, but given that the heart of =
STOX is actual translation, I'm not sure if we need more working on =
that. It should be obvious since *that* is exactly what we are =
describing.


Cheers,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From nobody Mon Jun 23 00:30:31 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 F0B711B29D5 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.711
X-Spam-Level: *
X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 WrnfqcemVnp1 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:30:29 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id B2F591B29D1 for <stox@ietf.org>; Mon, 23 Jun 2014 00:30:25 -0700 (PDT)
Received: from imac.saghul.lan (g154115.upc-g.chello.nl [80.57.154.115]) by mail.sipthor.net (Postfix) with ESMTPSA id DD56616DC6DE; Mon, 23 Jun 2014 09:30:24 +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: <53A3B016.6060202@stpeter.im>
Date: Mon, 23 Jun 2014 09:30:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B47341B-67BF-4E85-804D-39A0553ECBC1@ag-projects.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/paYobgbSk_FFeDthBE_I0-OgV78
Cc: Ben Campbell <ben@nostrum.com>, stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 23 Jun 2014 07:30:30 -0000

>=20
>=20
>> Section 5 (and subsections)
>>=20
>> The diagram does not show the transport (e.g. TCP) connection
>> establishment for MSRP. I think it would be useful to do so.
>=20
> Agreed.
>=20
> (It would also be useful to mention that we're assuming that an MSRP =
client uses the SIP "binding" to communicate with the MSRP conference =
server, see Section 6...)
>=20
>> Also,
>> the active endpoint (the one opening the transport connection) has to
>> send an immediate MSRP SEND request once the connection is
>> established. (I don't _think_ simple-chat extended that to allow an
>> initial NICKNAME to replace that--but I may have missed it.)
>=20
> Good catch.
>=20

While you are right, Ben, isn't that implied? I mean, obviously there =
needs to be a TCP connection, which needs to be bound and so on, but if =
we go down that rabbit-hole we would need to also say that it could =
happen if reverse if ACM is being used... so, perhaps we can assume (or =
add a note about it) that a working MSRP connection established using =
standard mechanisms and then we send the NICKNAME over it?


Cheers,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From nobody Mon Jun 23 07:15:47 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 67E671B2B36 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 07:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.449
X-Spam-Level: 
X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, 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 oZLz-uk8aYkk for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 07:15:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C8D1B2B31 for <stox@ietf.org>; Mon, 23 Jun 2014 07:15:35 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5NEFNhL017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 09:15:25 -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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <8B47341B-67BF-4E85-804D-39A0553ECBC1@ag-projects.com>
Date: Mon, 23 Jun 2014 09:15:23 -0500
X-Mao-Original-Outgoing-Id: 425225723.622246-87a60e6ad74d586cfb97d0eeac39278f
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DD88B39-F4A9-4F89-A8ED-B967DB7EDE32@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im> <8B47341B-67BF-4E85-804D-39A0553ECBC1@ag-projects.com>
To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/WkQumJKslSL4xw0p209DjZrRH2A
Cc: stox@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 23 Jun 2014 14:15:43 -0000

On Jun 23, 2014, at 2:30 AM, Sa=FAl Ibarra Corretg=E9 =
<saul@ag-projects.com> wrote:

>>=20
>>=20
>>> Section 5 (and subsections)
>>>=20
>>> The diagram does not show the transport (e.g. TCP) connection
>>> establishment for MSRP. I think it would be useful to do so.
>>=20
>> Agreed.
>>=20
>> (It would also be useful to mention that we're assuming that an MSRP =
client uses the SIP "binding" to communicate with the MSRP conference =
server, see Section 6...)
>>=20
>>> Also,
>>> the active endpoint (the one opening the transport connection) has =
to
>>> send an immediate MSRP SEND request once the connection is
>>> established. (I don't _think_ simple-chat extended that to allow an
>>> initial NICKNAME to replace that--but I may have missed it.)
>>=20
>> Good catch.
>>=20
>=20
> While you are right, Ben, isn't that implied? I mean, obviously there =
needs to be a TCP connection, which needs to be bound and so on, but if =
we go down that rabbit-hole we would need to also say that it could =
happen if reverse if ACM is being used... so, perhaps we can assume (or =
add a note about it) that a working MSRP connection established using =
standard mechanisms and then we send the NICKNAME over it?

Explicit is better than implicit. I don't think we have to show every =
possible variation in setting up an MSRP session, just like we don't =
show every SIP variation (but a note to that effect could be helpful.) I =
think the fact that the connection setup for MSRP is handled differently =
than that for XMPP is an important concept for this draft.

Which of course makes me wonder if connection management on the XMPP =
side should be mentioned.

>=20
>=20
> Cheers,
>=20
> --
> Sa=FAl Ibarra Corretg=E9
> AG Projects
>=20
>=20
>=20


From nobody Mon Jun 23 18:36:12 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 A762F1A083D for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.654
X-Spam-Level: 
X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 jfQHxUTnwRw1 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:36:09 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5DE1A053B for <stox@ietf.org>; Mon, 23 Jun 2014 18:36:09 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A012140DE2; Mon, 23 Jun 2014 19:36:08 -0600 (MDT)
Message-ID: <53A8D607.9050609@stpeter.im>
Date: Mon, 23 Jun 2014 19:36:07 -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.6.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im>
In-Reply-To: <53A3B016.6060202@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/ALlaW0a_7dVlPGZjpaW5i7VrGYI
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 24 Jun 2014 01:36:10 -0000

On 6/19/14, 9:52 PM, Peter Saint-Andre wrote:
> On 6/19/14, 3:49 PM, Ben Campbell wrote:
>> Hi Peter,
>>
>> [Disclaimer: this was a higher level review than for the previous
>> version--I mainly looked to see how the previous discussions about
>> the architecture rendered into the draft. ]
>>
>> This version is much improved. I think you've gotten the "FAIL" off
>> of it. But of course, cleaning up the architecture reveals a few
>> things :-)
>>
>> Section 4:
>>
>> I think the addition of section 4 helps a lot in general.
>>
>> The architecture treats the MSRP Conference server to be a monolithic
>> thing.
>
> As you pointed out later in this thread, this is a simplifying
> assumption to make the diagrams and explanations easier to follow.
>
>> The result of this is, in the examples, all the SIP and MSRP
>> traffic go to the sample place. That doesn't match the architecture
>> from RFC 4975 and simple-chat, where the signaling (SIP) is separate
>> from media (MSRP).  simple-chat talks in terms of a conference focus
>> that handles the signaling side, and an MSRP switch that handles the
>> media (MSRP) side.
>>
>> Now, it's perfectly okay to collocate those services into an MSRP
>> Conference Server in real deployments, and okay to show it that way
>> in this draft for the sake of simplicity. But it would be worth
>> mentioning that in section 4, and maybe also mentioning that any
>> interaction between the conference focus and MSRP switch are out of
>> scope (and irrelevant) for this draft.
>>
>> Along the same line, I assume the public "SIP side" interface of the
>> X2M gateway looks like a conference focus plus an MSRP switch to the
>> outside world. Again, these could be logically separate, but
>> co-located.
>
> Exactly.
>
>> Section 5 (and subsections)
>>
>> The diagram does not show the transport (e.g. TCP) connection
>> establishment for MSRP. I think it would be useful to do so.
>
> Agreed.

BTW, RFC 7247 does say:

    Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from
    SIP to XMPP will need to support TCP as the underlying transport
    protocol.  By contrast, as specified in [RFC3261], either TCP or UDP
    can be used as the underlying transport for SIP messages, and a given
    SIP deployment might support only UDP; therefore, a gateway from XMPP
    to SIP might need to communicate with a SIP server using either TCP
    or UDP.

But here we're talking about MSRP, so we might need similar text.

Peter



From nobody Mon Jun 23 18:39:26 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 C30D61A063A for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:39:24 -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 N6FHJydi-WBm for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:39:23 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 15E351A053B for <stox@ietf.org>; Mon, 23 Jun 2014 18:39:23 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9004B40DE2; Mon, 23 Jun 2014 19:39:22 -0600 (MDT)
Message-ID: <53A8D6C9.7040404@stpeter.im>
Date: Mon, 23 Jun 2014 19:39:21 -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.6.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corr?= =?ISO-8859-1?Q?etg=E9?= <saul@ag-projects.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im> <8B47341B-67BF-4E85-804D-39A0553ECBC1@ag-projects.com> <2DD88B39-F4A9-4F89-A8ED-B967DB7EDE32@nostrum.com>
In-Reply-To: <2DD88B39-F4A9-4F89-A8ED-B967DB7EDE32@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/X-Xc-kt1MtbBeOUb18fnmwpwiKA
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 24 Jun 2014 01:39:24 -0000

On 6/23/14, 8:15 AM, Ben Campbell wrote:
>
> On Jun 23, 2014, at 2:30 AM, Saúl Ibarra Corretgé <saul@ag-projects.com> wrote:
>
>>>
>>>
>>>> Section 5 (and subsections)
>>>>
>>>> The diagram does not show the transport (e.g. TCP) connection
>>>> establishment for MSRP. I think it would be useful to do so.
>>>
>>> Agreed.
>>>
>>> (It would also be useful to mention that we're assuming that an MSRP client uses the SIP "binding" to communicate with the MSRP conference server, see Section 6...)
>>>
>>>> Also,
>>>> the active endpoint (the one opening the transport connection) has to
>>>> send an immediate MSRP SEND request once the connection is
>>>> established. (I don't _think_ simple-chat extended that to allow an
>>>> initial NICKNAME to replace that--but I may have missed it.)
>>>
>>> Good catch.
>>>
>>
>> While you are right, Ben, isn't that implied? I mean, obviously there needs to be a TCP connection, which needs to be bound and so on, but if we go down that rabbit-hole we would need to also say that it could happen if reverse if ACM is being used... so, perhaps we can assume (or add a note about it) that a working MSRP connection established using standard mechanisms and then we send the NICKNAME over it?
>
> Explicit is better than implicit. I don't think we have to show every possible variation in setting up an MSRP session, just like we don't show every SIP variation (but a note to that effect could be helpful.) I think the fact that the connection setup for MSRP is handled differently than that for XMPP is an important concept for this draft.

I do think it would be good to have a note somewhere to the effect that 
not every protocol interaction is mentioned here.

> Which of course makes me wonder if connection management on the XMPP side should be mentioned.

What did you have in mind for connection management? Something like 
XEP-0198?

Peter



From nobody Mon Jun 23 18:42:39 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 9D1721A063A for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2MIQ299dN0CS for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:42:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FD81A053B for <stox@ietf.org>; Mon, 23 Jun 2014 18:42:32 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5O1gRu5079842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 20:42:31 -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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53A8D607.9050609@stpeter.im>
Date: Mon, 23 Jun 2014 20:42:26 -0500
X-Mao-Original-Outgoing-Id: 425266946.909634-c55b3f127ba9f1e0601cbd1cdb77c077
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB01DA92-88E8-4F9E-8797-68F5E4108706@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im> <53A8D607.9050609@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/uMKzi5jvKXdYQk09v9rV47zSz9o
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 24 Jun 2014 01:42:36 -0000

On Jun 23, 2014, at 8:36 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> BTW, RFC 7247 does say:
>=20
>   Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from
>   SIP to XMPP will need to support TCP as the underlying transport
>   protocol.  By contrast, as specified in [RFC3261], either TCP or UDP
>   can be used as the underlying transport for SIP messages, and a =
given
>   SIP deployment might support only UDP; therefore, a gateway from =
XMPP
>   to SIP might need to communicate with a SIP server using either TCP
>   or UDP.
>=20
> But here we're talking about MSRP, so we might need similar text.

I think it's more than a matter of just supporting TCP, it's a matter of =
when connections are opened and closed, and which party is responsible.

(Do we need to worry about other transports, i.e. WebSocket?)=


From nobody Mon Jun 23 18:45:18 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 0A56A1B27B1 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bWoCeNfm51kg for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 18:45:13 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC801B27B3 for <stox@ietf.org>; Mon, 23 Jun 2014 18:45:13 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5O1j6vj080116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 20:45:07 -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.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53A8D6C9.7040404@stpeter.im>
Date: Mon, 23 Jun 2014 20:45:06 -0500
X-Mao-Original-Outgoing-Id: 425267105.973733-1268aa690014068981ddfbbe93346043
Content-Transfer-Encoding: quoted-printable
Message-Id: <874E6D33-D55D-4636-BB11-219209349B40@nostrum.com>
References: <20140611034449.8863.29452.idtracker@ietfa.amsl.com> <5397D10B.3060806@stpeter.im> <FAD8D3C3-9976-4813-86BF-64CE9247F63C@nostrum.com> <53A3B016.6060202@stpeter.im> <8B47341B-67BF-4E85-804D-39A0553ECBC1@ag-projects.com> <2DD88B39-F4A9-4F89-A8ED-B967DB7EDE32@nostrum.com> <53A8D6C9.7040404@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/oZJCHdKsgi_JNODzGeuDExNzhwM
Cc: stox@ietf.org, =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt
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, 24 Jun 2014 01:45:16 -0000

On Jun 23, 2014, at 8:39 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> On 6/23/14, 8:15 AM, Ben Campbell wrote:
>>=20
>> On Jun 23, 2014, at 2:30 AM, Sa=FAl Ibarra Corretg=E9 =
<saul@ag-projects.com> wrote:
>>=20
>>>>=20
>>>>=20
>>>>> Section 5 (and subsections)
>>>>>=20
>>>>> The diagram does not show the transport (e.g. TCP) connection
>>>>> establishment for MSRP. I think it would be useful to do so.
>>>>=20
>>>> Agreed.
>>>>=20
>>>> (It would also be useful to mention that we're assuming that an =
MSRP client uses the SIP "binding" to communicate with the MSRP =
conference server, see Section 6...)
>>>>=20
>>>>> Also,
>>>>> the active endpoint (the one opening the transport connection) has =
to
>>>>> send an immediate MSRP SEND request once the connection is
>>>>> established. (I don't _think_ simple-chat extended that to allow =
an
>>>>> initial NICKNAME to replace that--but I may have missed it.)
>>>>=20
>>>> Good catch.
>>>>=20
>>>=20
>>> While you are right, Ben, isn't that implied? I mean, obviously =
there needs to be a TCP connection, which needs to be bound and so on, =
but if we go down that rabbit-hole we would need to also say that it =
could happen if reverse if ACM is being used... so, perhaps we can =
assume (or add a note about it) that a working MSRP connection =
established using standard mechanisms and then we send the NICKNAME over =
it?
>>=20
>> Explicit is better than implicit. I don't think we have to show every =
possible variation in setting up an MSRP session, just like we don't =
show every SIP variation (but a note to that effect could be helpful.) I =
think the fact that the connection setup for MSRP is handled differently =
than that for XMPP is an important concept for this draft.
>=20
> I do think it would be good to have a note somewhere to the effect =
that not every protocol interaction is mentioned here.
>=20
>> Which of course makes me wonder if connection management on the XMPP =
side should be mentioned.
>=20
> What did you have in mind for connection management? Something like =
XEP-0198?

You give me too much credit. I had nothing in particular in mind--just =
whether it was a subject that needed discussion.

I lean towards "no", since I assume that the connections for XMPP will =
have been opened well before the flow started, and closed well =
afterwards. But in constrast, a connection for MSRP is opened as a =
_result_ of the SIP (or equivalent) messages that are part of the flow.

>=20
> Peter
>=20
>=20