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

Peter Saint-Andre <> Thu, 19 September 2013 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34E1321F95DD for <>; Thu, 19 Sep 2013 09:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.51
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ftUu52VaiHGe for <>; Thu, 19 Sep 2013 09:47:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8272C21F9951 for <>; Thu, 19 Sep 2013 09:47:01 -0700 (PDT)
Received: from (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 798CB206F1; Thu, 19 Sep 2013 10:51:55 -0600 (MDT)
Message-ID: <>
Date: Thu, 19 Sep 2013 10:46:59 -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
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: Thu, 19 Sep 2013 16:47:20 -0000

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


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

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