Subject: [Stox] Review on -presence

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Jul 2013 17:33:18 +0200

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.

- 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…" ?

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

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

- 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. Also, the priority in PIDF is a float between 0 and 1, is it the same for XMPP?

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

* Editorial nits:

- Many example requests lack a To header
- Sec 3.2.3: "gateway SHOULD a presence stanza" -> "gateway SHOULD send a presence stanza"

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Aug 2013 00:32:03 +0200

On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote:
> - 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.

Agreed.

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

-- 
Peter Saint-Andre
https://stpeter.im/