Re: [Stox] Review on -presence

[Peter Saint-Andre <[e-mail]>]

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.

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/