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

Ben Campbell <> Fri, 06 June 2014 20:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B0D41A0268 for <>; Fri, 6 Jun 2014 13:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PrP9rCh8J8nu for <>; Fri, 6 Jun 2014 13:23:32 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FE381A027C for <>; Fri, 6 Jun 2014 13:23:32 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Fri, 6 Jun 2014 15:23:22 -0500
X-Mao-Original-Outgoing-Id: 423779002.182674-0e6e4facaeaf9be3471465399be8ec30
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Peter Saint-Andre <>
X-Mailer: Apple Mail (2.1878.2)
Cc:, Yana Stamcheva <>,
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jun 2014 20:23:34 -0000


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