Re: [Stox] review of core, chat, groupchat and presence

Peter Saint-Andre <> Tue, 24 September 2013 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D12621F9C7B for <>; Mon, 23 Sep 2013 17:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.876
X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QILFDgQo0qpt for <>; Mon, 23 Sep 2013 17:25:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD9D521F9B21 for <>; Mon, 23 Sep 2013 17:25:32 -0700 (PDT)
Received: from ergon.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 2FCE5415F9; Mon, 23 Sep 2013 18:30:40 -0600 (MDT)
Message-ID: <>
Date: Mon, 23 Sep 2013 18:25:31 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Philipp Hancke <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] review of core, chat, groupchat and presence
X-Mailman-Version: 2.1.12
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: Tue, 24 Sep 2013 00:25:37 -0000

Hash: SHA1

On 9/22/13 11:57 PM, Philipp Hancke wrote:
>> Thanks again for the review. Comments inline.
> As before, removing items done.
> new nit: [length] looks like it should be replaced with the
> examples actual length in three places. Only seen in -groupchat.

Will fix.

> [...]
>>> example f3 is not shown
>> I don't feel that we need to show every 200 OK. Yes, we put the 
>> example in, but sometimes you really can have too
>> many examples. :-)
> Right. But then it might make sense to either add a "not shown"
> marker in the ascii art or not number them. I'll check if that
> happens often enough to make sense.

Well, maybe we'll just add the examples for the sake of completeness.

> [...]
>>> 4.4: presence broadcast before ack? must buffer until
>>> receiving 110 ack?
>> Your comment is a bit cryptic. Would you please expand it?
> Hah, that was the only comment you found cryptic? :-)

I think that I managed to decryptify the others. ;-)

> btw: it might make sense to reuse the caption from XEP-0045 (7.2.3 
> Presence Broadcast) for the caption of F7 (which is raw, unbridled
> xmpp and not translated; current text seems copy-paste from F11 in
> sect 3.5): "Service Sends Presence from Existing Occupants to New
> Occupant"


> Now the attempt to decipher my comments: First part: In MUC, the
> participant lists is sent to the new occupant (muc example 21)
> before the new occupants own presence (muc  example 24) and 
> therefore potentially before any acknowledgements that might be
> required on the MSRP side. Is that a problem?

Well, neither RFC 4975 nor draft-ietf-simple-chat really specifies the
handling of participant lists. There is a passing mention in the
latter document, but it's not very detailed:

   Typically the conference focus acts as a notifier of the conference
   event package, RFC 4575 [RFC4575].  It is RECOMMENDED that conference
   foci and endpoints support RFC 6502 [RFC6502] for providing
   information regarding the conference, and in particular, supplying
   information of the roaster of the conference.  It is also RECOMMENDED
   that conference foci and endpoints support RFC 6501 [RFC6501], which
   extends the <user> element originally specified in RFC 4575 [RFC4575]
   with a new 'nickname' attribute.  This allows endpoints to learn the
   nicknames of participants of the chat room.

However, in draft-ietf-stox-groupchat we assume that the conference
focus does support the conference-info package for the room roster.

[ Hopefully the RFC Editor will correct "roaster" to "roster" :-) ]

> Second part: In example F10, two (or more) stanzas are translated
> into a single event. Unless you can do partial updates (Emil? I
> think you mentioned such a thing for COIN) here, the gateway needs
> to know when it can dispatch example 4.4 -- upon receiving the
> participants own presence, which might come with a 110 status code.
That's all correct.

> Since I don't think all xmpp serveers do 110, i think there is some
> text required that the gateway needs to be able to recognize the
> self-presence and not mistake it as part of the participants list. 
> (should it be participant_s_ presence in the caption?)

The SIP-to-XMPP gateway will need to maintain state about the MSRP
session that the SIP user agent has requested. This implies that the
gateway will need to know the user's SIP URI and the mapping of that
URI into an XMPP address, then based on that mapping determine when it
has received a complete room roster from the MUC room (with or without
a 110 status code), i.e., when it has received the in-room presence of
the SIP user (which according to XEP-0045 is the last presence stanza
received in the initial batch sent after joining). Once that happens,
the SIP-to-XMPP gateway can construct the conference-info document
containg the complete room roster and send that to the SIP user.

And yes, we need to make that clear in the spec.

> Is that clearer?

Yes, thanks.


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -