Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt

Ben Campbell <ben@nostrum.com> Mon, 23 June 2014 14:15 UTC

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: Saúl Ibarra Corretgé <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ú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.

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

> 
> 
> Cheers,
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
>