Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

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

Some further thoughts on presence subscriptions below...

On 09/24/2015 11:55 AM, Ben Campbell wrote:
> 
> On 23 Sep 2015, at 22:52, Peter Saint-Andre - &yet wrote:
> 
>> Hi Ben, thanks for the continued careful reviews. Comments inline.
>>
>> On 9/21/15 9:25 PM, Ben Campbell wrote:
> 

<snip/>

>>> -2nd paragraph after example 11:
>>> This also needs a NOTIFY. You mention one in the following paragraph for
>>> the declined case, but you need one in either case.
>>
>> Yes. The XMPP server will generate a presence notification in this
>> case, so that's the primary NOTIFY of interest here, I think.
> 
> I think it's still worth mentioning that it happens. And that brings up
> another question: A RFC 6665 notifier is required to send an "immediate"
> NOTIFY. Do you think the presence stanza will reliably arrive at the
> gateway in time to be considered "immediate"? If there's any likelihood
> of delay, the gateway may need to send a "pending" NOTIFY.
> 
> [...]
> 
>>
>>> - 2nd bullet:
>>> This description is confusing. You aren’t maintaining the SIP
>>> subscription, just the xmpp subscription.
>>
>> "Treat the subscription as if it were long-lived" might be clearer.
>>
> 
> WFM.
> 
>>> -- 2nd bullet, sub-item 2:
>>>
>>> Do I understand this to mean the XMPP gateway infers availability of the
>>> SIP user from the SIP user’s subscription? That should come from a
>>> reciprocal subscription. Just because a SIP user subscribes to someone
>>> else's presence doesn't mean that user is available. Just because he
>>> doesn't doesn't mean he is not.
>>
>> This flow describes what happens when the SIP user ends its presence
>> session. In that case, it seems to me that sending a presence stanza
>> of type "unavailable" to the XMPP user is appropriate (when the
>> gateway treats the subscription as if it were long-lived).
> 
> While it's probably not common in practice, it's perfectly okay
> according to the protocol for a SIP user to stop subscribing to a
> resource, while continuing to send updates to that resource on a
> reciprocal subscription. It might be reasonable to assume the user to be
> unavailable if you have no information to the contrary, but this advice
> seems to suggest overriding presence information sent explicitly by the
> SIP user with presence information inferred from the subscription.
> 
> 
>>
>>> Also, how does this violate the SIP semantic?
>>
>> There's a mismatch in the meaning of subscribe. Treating a SIP
>> subscription as if it were long-lived means the gateway follows the
>> XMPP subscription model, not the SIP subscription model. A gateway
>> implementer needs to choose which model to honor, and if it chooses
>> the XMPP model then it's not honoring the SIP model (and vice-versa).
> 
> I think this depends on the resolution to the previous comment, but I
> would say that if the protoocl behavior expectations of the SIP
> subscriber are met, the semantic has not been violated.

While attempting to improve the text, I've been thinking about this
issue some more. I see two paths.

1. We could add a paragraph such as the following to Section 5.3.2 on
refreshing a presence subscription from SIP to XMPP:

   Note: In SIP there is no necessary connection between a presence
   session and an outbound subscription to a contact's presence; for
   example, a SIP user agent could end its subscription to the contact's
   presence yet still keep sending presence notifications to the
   contact, or it could send a presence notification indicating that it
   is offline (i.e., by sending a PIDF document with a basic status of
   "closed") while still maintaining a subscription to the contact's
   presence.  However, to simplify the description of handling
   notifications and subscriptions this document assumes that if a SIP
   user goes offline it will also terminate its outbound subscriptions.

2. We could remove any mention of presence sessions (i.e., online or
offline state) from Section 5.3.2 and make it purely about presence
subscriptions and not availability.

I'm not sure which way to go. Currently Section 5.3.2 talks about
presence notifications, so removing any mention of a presence session
seems odd (after all, the whole point of presence subscriptions is to
receive presence notifications).

I will ponder this further but for now I will probably include a note
similar to the one shown above until we can determine the best path forward.

Peter