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

[Peter Saint-Andre <[e-mail]>]

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

Philipp, thanks for the review. Comments inline.

On 9/18/13 9:53 PM, Peter Saint-Andre wrote:
> On 8/8/13 12:33 PM, Philipp Hancke wrote:
> 
>> chat: example f2: call-id: contain jid? how about uniqueness?.

Yes, RFC 3261 says they need to be unique:

   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.

I was unthinkingly following the examples in specs like RFC 4975. I'll
change them to be UUIDs.

>> Is there any text on the use of <thread/>?

There is text about this in draft-ietf-stox-im, which says to map
Call-ID to <thread/> and vice-versa. However, that probably belongs in
the -chat document, since thread isn't really used in pager-mode
single messages.

>> in -im @example.com callid is used

As mentioned, I'll make them UUIDs.

>> a=lang could be taken xml:lang?

In the -im I-D we map xml:lang to the Content-Language header. I think
that's more appropriate than a=lang, which has some subtleties I'd
prefer to avoid -- see draft-gellens-mmusic-negotiating-human-language
for some related considerations.

>> before example F4: the gateway acknowledges on behalf of juliet?

Yours was a very brief comment and I'm not sure I understand the force
of your question. Are you wondering why there's an ACK at this point
in the negotiation? That's what I see in RFC 4975:

           Alice                     Bob
             |                        |
             |                        |
             |(1) (SIP) INVITE        |
             |----------------------->|
             |(2) (SIP) 200 OK        |
             |<-----------------------|
             |(3) (SIP) ACK           |
             |----------------------->|
             |(4) (MSRP) SEND         |
             |----------------------->|

>> example f5: the initial message in F1 should have an id
>> attribute

Agreed.

>> which gets mapped in f5. Does a786hjs2 map to thread/call id?

That's an MSRP transaction identifier, which IMHO maps to a stanza
'id' attribute in XMPP. This too needs to be documented in the -chat I-D.

>> example f6: shouldn't message-id should be different from f5?

Yes, I think so, because that's a different transaction.

>> mapping of message-id to id attribute, should be randomly
>> generated if not present

Hmm. In MSRP, the message-id can be used to identify an overall
message, which might be chunked into separate transactions. XMPP
doesn't have the concept of a message in the MSRP sense when we're
talking about IM. In XMPP, In-Band Bytestreams (XEP-0047) enables you
to chunk a large piece of data into smaller pieces, but that's used
only for file transfer, not for IM. We could add a note about this in
the -chat I-D, but for IM purposes I think we don't want to map the
MSRP message-id to anything on the XMPP side.

>> section 4: sessinos -> sessions;

Yes, my fingers often make that mistake while typing. :-)

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/

iQIcBAEBAgAGBQJSOyqDAAoJEOoGpJErxa2pLcoQAK6DaWqEMjTVA5rDHwP2ilpc
hO7YCUOU9tig4y1F/75ySwg+zqERkotmj6o3PVl108LgUnCKYXThqr0qOyQ2ic4z
k0/cVe4/dCqq4V0/HoKri2CEMpL1hoc5LK+Kwy1v8jnr/JtuCyoQ7tW/zXBK+VyR
KRxoSaokmoZ/HAITLd2sVc0s90u0La73dggdy1xqp8uPXWEv12rnJ1cEdm0Vjdlk
2mS6Tn5XEx2yM5/C2/liJOcN7ntAcqRZ9P+4JLOkSHuJx++wKYrsu8gx7V3wET5A
buxQcJUXQWCz7z628QC2rt30bo5BcDtow+MaEX5hyKi8Olmzo4062Bpc5sEijVHM
TU43Dbk2BjusvtyYeVq44yOHhHnRFPeRqv5LhaGMaGpT6IcJNfm7PS/TZ/F94EZS
+kMjIbGBbm4vW7CKQ98J9T9w4+qQG61TodgLs3pG53r0yYnsYpOD6Lq+5gJlUvcS
t0cGezv2aEkgNRlr449JxOjihMqK4OyCsN4hL9wLbnNfxSXYCwiEJ8hCYaMEN6L7
KmI04FMVX70etWlV8LndYBeRBFDJGYQOCtPxhp71F+Q0Nkue4rFo+ebLwj9ywbVK
7KanGtPvrilPo6tqldGAH0VjB/HFEO9cOB/eZ9JBBTNrP/OI9HgazLITQmWv69bV
qxrHafVj3/Fq/xk73RIv
=0b1p
-----END PGP SIGNATURE-----