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

Philipp Hancke <> Thu, 19 September 2013 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B78E021F9433 for <>; Thu, 19 Sep 2013 10:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fWjC3838Neq0 for <>; Thu, 19 Sep 2013 10:13:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5727B21F94FF for <>; Thu, 19 Sep 2013 10:13:38 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8JHDZPi013046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Thu, 19 Sep 2013 19:13:36 +0200
Message-ID: <>
Date: Thu, 19 Sep 2013 19:13:29 +0200
From: Philipp Hancke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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 17:13:46 -0000

Am 19.09.2013 18:46, schrieb Peter Saint-Andre:
> Hash: SHA1
> Philipp, thanks for the review. Comments inline.

Stuff that is done removed. Thanks for addressing the issues.

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

I think what I mean was "the call id should be something along the lines 
of". The intent was the same however.

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

What I meant (and i needed to parse this again, too) was that I think 
the gateway acknowledges on behalf of Juliet, not Romeo as the text 
says. The example itself is ok.