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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 25 September 2013 02:24 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091C011E81AB for <stox@ietfa.amsl.com>; Tue, 24 Sep 2013 19:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.825
X-Spam-Level:
X-Spam-Status: No, score=-101.825 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbXTmLxaBSH0 for <stox@ietfa.amsl.com>; Tue, 24 Sep 2013 19:23:59 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6764711E81A4 for <stox@ietf.org>; Tue, 24 Sep 2013 19:23:58 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 12D6A415F4; Tue, 24 Sep 2013 20:29:09 -0600 (MDT)
Message-ID: <5242493D.20709@stpeter.im>
Date: Tue, 24 Sep 2013 20:23:57 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
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 <fippo@goodadvice.pages.de>
References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im> <523FD85C.6010600@goodadvice.pages.de> <5240DBFB.4010607@stpeter.im>
In-Reply-To: <5240DBFB.4010607@stpeter.im>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: Re: [Stox] review of core, chat, groupchat and presence
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 02:24:04 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/23/13 6:25 PM, Peter Saint-Andre wrote:
> 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 example.com, 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"
> 
> WFM.
> 
>> 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.

Here is proposed text:

   Because the "room roster" is communicated in XMPP by means of
   multiple presence stanzas (one for each participant) whereas the
   participant list is communicated in SIP by means of a single
   conference-info document, the SIP-to-XMPP gateway will need to keep
   track of the user's SIP URI and the mapping of that URI into an XMPP
   address; then, based on that mapping, it will need to determine when
   it has received a complete room roster from the MUC room, 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 containing the complete room
   roster and send that to the SIP user.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSQkk8AAoJEOoGpJErxa2p/kIQAJd9sCq6DvXa4VgKBLKqWigZ
Cl0tTN/IFiyK/1pxsbUJ3V2gH4kKELDa2vtY3GPnuklwaFkI05e/n8VJsqWmMe+H
myKWz5RYJ3899/qOGVfzFBp6l+Tx1z1aZ/+TM3Kk/KI74/Jo8ylOMPsNUdMRIXS9
cOZGV93BVrqLWtAT/0ma2vH2o4BrBHrDpwW3jpo94PSLsJxmnYgWraGdfnrrW72W
LVVCNSfXgp1hwwQ2B8h/cam6pL67hcHzkr65dUyh2SIYNSh39sYqrnYFeoauXxnN
qMWdZ6pYRL7pf2NsTVYD/qSxeZv3X7bKcjFVrfn/dVIuma3RRBUtTT0VIqJllufM
8sd9cto3S8+8OhNgM30Uj4eGE41rReSza5lS9yKeO9bRshFg5bOa8hpVFTl9CzHP
ZbAhBtAYE7cB5Vxuh1peqwGyPCT7KJGQgu4NGmj2A8JmQTCT0BS0nDwrayBXfhmz
7xAYR11BwdNvm+Rp+02fbRnCPFLqIM1Q5Z9nlgXxS8FvtTrLJqqYfmukKN13OCjq
kqeex+OOxTXLnyaurs7cJcDFQPWIWW8r7mTascwdp1WjIHQvUwmSEO5jZXuimK6x
ux5Y9NuxXRm6e9lDinbyCJf/7/BTohc0DW/Eudel/gRU29L3LyDnNYQxLW8QknM9
5I3/g1VENOFtydUugWhI
=5mmx
-----END PGP SIGNATURE-----