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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 19 September 2013 16:47 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 34E1321F95DD for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 09:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.51
X-Spam-Level:
X-Spam-Status: No, score=-101.51 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, 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 ftUu52VaiHGe for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 09:47:03 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8272C21F9951 for <stox@ietf.org>; Thu, 19 Sep 2013 09:47:01 -0700 (PDT)
Received: from sjc-vpn6-839.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 798CB206F1; Thu, 19 Sep 2013 10:51:55 -0600 (MDT)
Message-ID: <523B2A83.7080302@stpeter.im>
Date: Thu, 19 Sep 2013 10:46:59 -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: stox@ietf.org
References: <5203E484.4050902@goodadvice.pages.de> <523A7520.70002@stpeter.im>
In-Reply-To: <523A7520.70002@stpeter.im>
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-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: Thu, 19 Sep 2013 16:47:20 -0000

-----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-----