Re: [Stox] Review on -presence

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

On 8/7/13 3:54 PM, Saúl Ibarra Corretgé wrote:
> 
> On Aug 3, 2013, at 10:48 AM, Peter Saint-Andre wrote:
> 
>> 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:
>> 
> 
> Yep, you would usually refresh the subscription.

Agreed.

>> (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").
>> 
> 
> Yep, I think we could say that you MAY send an empty NOTIFY and
> compose and offline state tuple based on the previous state.

In draft-ietf-stox-presence-01 I added the following paragraph:

   For as long as a SIP user is online and interested in receiving
   presence notifications from the XMPP users, the user's SIP user agent
   is responsible for periodically refreshing the subscription by
   sending an updated SUBSCRIBE request with an appropriate value for
   the Expires header.

However, I did not add an example, so IMHO it would be good to do that
in -02.

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

Thanks for the validation. :-)

Peter

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