Re: [Stox] Review on -presence

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

On 8/1/13 12:32 AM, Peter Saint-Andre wrote:
> 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? 

Actually, in this scenario the gateway does know the status because the
XMPP user is still online -- it's just that the SIP user's subscription
to the XMPP user's status has expired.

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

I've looked into this further. Here is what I find in RFC 3856 (Section
6.6.2):

   If the resource is not in a meaningful state, RFC 3265 [2] allows the
   body of the initial NOTIFY to be empty.  In the case of presence,
   that NOTIFY MAY contain a presence document.  This document would
   indicate whatever presence state the subscriber has been authorized
   to see; it is interpreted by the subscriber as the current presence
   state of the presentity.  For pending subscriptions, the state of the
   presentity SHOULD include some kind of textual note that indicates a
   pending status.

And in RFC 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.

Everything there is about an initial NOTIFY confirming a presence
subscription. However, Section 3.3.2 of the stox-presence spec discusses
what to do if the SIP user's subscription expires:

   It is the responsibility of the SIMPLE-XMPP gateway to properly
   handle the difference between short-lived SIP presence subscriptions
   and long-lived XMPP presence subscriptions.  The gateway has two
   options when the SIP user's subscription expires...

It seems to me that there's a false assumption here, because in general
doesn't the SIP user agent initiate a refresh to maintain the
subscription (as long as it's online)? So I think there are two cases here:

(1) SIP user agent is online and generates a refresh by re-subscribing.
In this case, the empty NOTIFY might make sense (although you could
argue that it's not truly an "initial NOTIFY").

(2) SIP user agent goes offline and the subscription truly expires. In
this case, the handling we currently describe seems generally correct to me.

Peter

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