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

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 20 Mar 2016 16:24:22 -0600

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 20 Mar 2016 16:45:41 -0600

A further thought...

On 09/28/2015 09:32 PM, Ben Campbell wrote:
> On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote:
> 
>> On 9/24/15 11:55 AM, Ben Campbell wrote:

<snip/>

>> Maybe. :-)
>> It still seems to me that the gateway is enforcing one model or the
>> other. Perhaps "violate" is a strong word in this context, though.
>>
> 
> I think we may be reading too much into the "ephemeral" subscription
> model, while still trying to think of an xmpp subscription and a SIP
> subscription of modeling the same thing. Both XMPP and SIP have an
> ephemeral component and a long-lived component. In XMPP, the
> subscription is long lived, and the presence session is relatively
> ephemeral. In SIP, the authorization policy, and the presence of an
> entity on a contact list are long lived, and the subscription is ephemeral.
> 
> So if we think of an XMPP subscription as equivalent to SIP subscriber
> authorization, and an XMPP presence session as equivalent to a SIP
> subscription, I think we can avoid violence to the assumptions of either
> side.

That too is helpful toward a better description of the mismatch in
models. I'm going to ruminate on the matter but first (i.e., right now)
submit a revised I-D that incorporates (I think) all of the other fixes.

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Mar 2016 15:26:35 -0500

On 20 Mar 2016, at 17:45, Peter Saint-Andre wrote:

> I'm going to ruminate on the matter but first (i.e., right now)

For my own clarity; the current version is intended to resolve all but 
this issue?

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Mar 2016 15:47:53 -0600

> For my own clarity; the current version is intended to resolve all but

Correct! However, I made the changes over a long period of time so I'm 
sure we'll need to check things over. I plan to do that on my own this 
week, but more eyes are better. :-)

Peter