Re: [Stox] Review on -presence

Peter Saint-Andre <> Thu, 01 August 2013 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 854EC21F9D2A for <>; Wed, 31 Jul 2013 23:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.071
X-Spam-Status: No, score=-101.071 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bnwti0pkFYWA for <>; Wed, 31 Jul 2013 23:38:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5304021F89A6 for <>; Wed, 31 Jul 2013 23:38:45 -0700 (PDT)
Received: from (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 65EDFE831E; Thu, 1 Aug 2013 00:41:01 -0600 (MDT)
Message-ID: <>
Date: Thu, 01 Aug 2013 00:32:03 +0200
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Saúl Ibarra Corretgé <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [Stox] Review on -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, 01 Aug 2013 06:38:50 -0000

On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote:
> Hi,
> Here is my review of the -presence document:
> - Sec 3.3.2 suggests that if the subscription is maintained but we
> have no presence state, a PIDF would be generated with a basic status
> of closed, but what would be the tuple ID, if we don't know any
> resource for this user anymore? We could also send an empty NOTIFY,
> which would achieve the same goal.

The empty NOTIFY sounds more consistent with the spirit of SIP presence.

> - Sec 3.3.2 specifies how to handle the case when a gateway
> translated a SIP subscription into an XMPP subscription and then the
> SIP side decided to end it, but doesn't mention what to do in case
> the XMPP side decides to end it. It should send a NOTIFY with
> Subscription-State: terminated;reason=rejected.


> - Sec 4.1, "Instant Message URI of the form <pres:user@domain>" -
> shouldn't this be "Presence URI of the form…" ?

Looks like a copy-and-paste error.

> - Using ID-123kdklejd doesn't seem to work as a valid xs:ID, TID-1234
> does work though, so we could use TID- as the prefix for tuple
> identifiers in examples and such.

I will double-check that against the XML specification.

> - Table 6 suggests that the Call-ID header should be matched to the
> presence stanza id, but the called won't change throughout the whole
> dialog, so we should use something else, which changes for each SIP
> transaction, what about the Via branch? Table 7 uses CSeq, FWIW.

You're right -- Call-ID is not right here. CSeq is better, and I think
we changed it in Table 7 but not Table 6.

> - Table 6 suggests that priority is translated as the PIDF priority
> for a tuple, but that's an attribute of the contact element, which we
> don't mention, but I guess we should. 

Good catch -- we don't seem to include the contact element in any of the
examples. Will fix.

> Also, the priority in PIDF is a
> float between 0 and 1, is it the same for XMPP?

Hmm. We had text about that in RFC 3922, and I suggest we copy that to
this draft (adjusting as necessary)...

   An XMPP presence stanza MAY contain a <priority/> child element whose
   value is an integer between -128 and +127.  The value of this element
   MAY be mapped to the 'priority' attribute of the <contact/> child of
   the PIDF <tuple/> element.  If the value of the XMPP <priority/>
   element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
   range of allowable values for the PIDF 'priority' attribute is any
   decimal number from zero to one inclusive, with a maximum of three
   decimal places.  If an XMPP-CPIM gateway maps these values, it SHOULD
   treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP
   <priority>127</priority> as PIDF priority='1', mapping intermediate
   values appropriately so that they are unique (e.g., XMPP priority 1
   to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
   so on up through mapping XMPP priority 126 to PIDF priority 0.992;
   note that this is an example only, and that the exact mapping shall
   be determined by the XMPP-CPIM gateway).

That's twice in one day I have looked at RFC 3922. ;-)

> - Sec 4.3, the translated XMPP stanza contains the full JID of
> Juliet, but where did we get the resource from? Shouldn't it go to
> the bare JID?

Another copy-and-paste error, I think.


Peter Saint-Andre