Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]

Ben Campbell <ben@nostrum.com> Fri, 06 June 2014 20:23 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 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.
> 
> On 5/2/14, 2:44 PM, Ben Campbell wrote:
> 

[...]

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

[...]

> That is, the MSRP-to-XMPP gateway doesn't belong as an entity in the protocol flow for XMPP MUC to MSRP Multi-party Messaging Session (Section 4), and the XMPP-to-MSRP gateway doesn't belong in the protocol flow for MSRP Multi-party Messaging Session to XMPP MUC (Section 5). If we correct this error, I think most of the feedback you provide below can be easily addressed. For ease of reference, I refer to it from here on as the Fundamental Architectural Inconsistency Lameness, a.k.a. "FAIL".
> 
> Unfortunately, the diagrams in the stox-presence spec (now RFC 7248) make the FAIL, too! How I hate submitting errata on brand-new RFCs. :(
> 

My apologies for not catching it there :-(

>> Details:
>> 
>> -- Section 4:
>> 
>> It would be helpful to show a network diagram before jumping directly
>> into the call flows.  (Same for the later scenario where the
>> conference is an XMPP MUC).
> 
> Something like figure 1 in RFC 7247? We probably need a separate one here, because the entities are different.

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.

[...]


> 
>> F8: Technically, the "OK" in the MSRP response is just a comment. I
>> suggest showing MSRP responses by just the response code in the
>> diagram. The comment has no semantic effect (and is even optional).
> 
> Would you recommend removing such things for SIP responses, too?
> 

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

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:
> 
> http://tools.ietf.org/html/draft-ietf-stox-chat-06#section-7
> 
> I haven't thought much about how (or if) that applies to groupchat scenarios (in XMPP it's used mainly for one-to-one chat sessions, although it could be used for groupchat, too).

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.

[...]

> 
>> -- Section 5:
> 
> The FAIL applies here, too (i.e., remove the XMPP-to-MSRP gateway from the picture).
> 
>> What is the SIP Server? Is this a SIP Proxy, or something else? What
>> value does it add to the flow?
> 
> I've assumed that a SIP client wouldn't send data directly to a gateway, but that a SIP Proxy would likely act as an intermediary and initial router.
> 

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

[...]