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

["Ben Campbell" <[e-mail]>]

On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote:

> On 9/24/15 11:55 AM, Ben Campbell wrote:

[...]
>>>> -- note 7:
>>>>
>>>> Do you expect a SIP Presence UA to do something useful with the 
>>>> <show/>
>>>> element ? Most will probably ignore it.
>>>
>>> Losing that information along the way would guarantee that a 
>>> presence
>>> UA can't do something useful with it; preserving the information 
>>> seems
>>> helpful.
>>
>> Okay. It might be worth a note that the sender should not depend on 
>> the
>> receiver to render it.
>
> Actually the XMPP sender (or the sender's client) doesn't necessarily 
> know that the receiver is a SIP user. Therefore I'm not sure what we 
> can say about the sender. At most perhaps we can add a sentence like 
> this:

Of course, by "sender", I meant "gateway" :-)

>
>     However, there is no guarantee that the SIP receiver will render
>     a standard XMPP <show/> value or custom extension.
>

WFM.

[...]
>
>>>> -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.
>
> Not sure. I'll think about that some more.

It might be reasonable to punt this to the implementation to decide, 
with some guidance about what to do if you can't immediately send a 
"real" NOTIFY. And on reflection, this gets tangled up with 
authorization--the "pending" NOTIFY is more to say the authorization has 
not yet been determined. If the subscriber is known to be authorized, 
then rather than a "pending" NOTIFY it might just send a normal NOTIFY 
with some default presence state, then send the real presence when it 
gets it. (The subscriber's user experience might be a to initially see 
the entity as "closed" then quickly transition to "open".)

[...]

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

[...]