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

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

My turn to apologize for the delay. This draft seem especially prone to 
falling through my task list cracks.

Some more comments and questions inline:


On 21 Jun 2016, at 21:44, Peter Saint-Andre wrote:

> Hi Ben, thanks for your comments. My apologies for the delayed reply.
>
> On 6/9/16 4:37 PM, Ben Campbell wrote:
>> Hi Peter,
>>
>>
>> I have a couple of questions about the implications of the new 
>> "presence
>> authorization" concept, and a couple of editorial nits. Otherwise, I
>> think this is ready for IETF last call. It might make sense to go 
>> ahead
>> with the last call, and address these with any last call 
>> comments--but
>> I'd like to have an initial round of conversation about the presence
>> authorization first.
>>
>> - in 5.2.3, whose "authorization" is canceled?
>
> The use cases in §5.2 originate on the XMPP side and the use cases in 
> §5.3 originate on the SIP side, so §5.2.3 describes what happens 
> when the XMPP user no longer wishes to receive presence notifications 
> from the SIP contact.

This makes me think the abstraction is still not quite right. From the 
SIP perspective, this flow does not cancel an authorization to receive 
presence. It merely stops notifications. If the XMPP were to resubscribe 
later, the SIP presence server would probably just restart 
notifications. It would consider the watcher to be authorized based on 
existing authorization policy. That policy doesn't go away just because 
the watcher unsubscribed.

Basically the state that says "Juliet is allowed to see Romeo's 
presence" is long lived. It's independent from the state that says 
"Juliet currently wants to receive notification of changes in Romeo's 
presence".  It's possible the server will expire that policy after some 
time, but that would be completely proprietary.  Otherwise, the 
authorization only goes away when and if the _SIP_ user removes it, for 
example using XCAP.

So at the risk of rehashing old coversations, I think we've got the 
following bits of state:

XMPP:
- Watcher is subscribed - long lived, means the same as "watcher is 
authorized".

- Watcher wants notifications - Short lived for duration of the 
watcher's XMPP connection to his XMPP server. Requires "watcher is 
subscribed" to be true.

SIP:
- Watcher is subscribed - Short lived (soft state). Means watcher wants 
notifications. Requires "Watcher is authorized" to be true.

- Watcher is authorized - Long lived.  Controlled by presentity. If no 
policy already exists, decision triggered by a watcher's attempt to 
subscribe.


>
>> If the SIP contact has a
>> reciprocal subscription back to the xmpp contact’s presence, is 
>> that
>> impacted by this unsubscribe action?
>
> It shouldn't be, because we're not assuming that authorization to 
> receive presence notifications needs to be bidirectional. So this flow 
> results in the XMPP user (here, Juliet) no longer receiving presence 
> notifications from the SIP contact (here, Romeo); however, Romeo can 
> still happily receive presence notifications from Juliet.

Okay, then I think we are good here.

>
>> Or is the SIP user expected to
>> remove the authorization for the xmpp user to see her presence info?
>
> Romeo would also need to inform Juliet that he no longer wishes to 
> receive presence notifications from her, i.e., he would need to 
> complete the flow in §5.3.3.
>
> I can see that the phrasing in §5.2.3 and §5.3.3 is confusing, i.e.:
>
>   5.2.3
>
>     cancelling an XMPP user's presence authorization to a SIP contact
>
>   5.3.3
>
>     cancel the presence authorization
>
> That wording doesn't make the directionality clear. I'll rephrase 
> these sentences to clarify matters.

That would help.

>
>> - in 5.3.1, I _think_ the flow creates both an authorization and a
>> notification dialog.
>
> To prevent confusion, we're now using the term "notification dialog" 
> for SIP->XMPP and "presence authorization" for XMPP->SIP. When you say 
> "authorization" here, are you referring to a presence authorization 
> from the XMPP user to the SIP user? If so, how would the notification 
> dialog from the SIP user to the XMPP trigger that? If not, then let's 
> make sure we're on the same page about what's happening here.

I'm not entirely sure what "authorization from the XMPP user to the SIP 
user means". Would it make sense to say "authorization to allow the SIP 
user to receive the XMPP user's presence"?

>
> (Yes, I know, presence state machines are horribly complicated!)

Yep. And differently shaped between the two protocols.

>
>> If the SIP user unsubscribes, and resubscribes
>> (that is, tears down the notification dialog and creates a new one),
>
> That is, completes the flow in §5.3.1, then completes the flow in 
> §5.3.3, then initiates the flow in §5.3.1 again - correct?

Yes.

>
>> is
>> there any difference in the flow due to the fact the XMPP server has
>> authorization state for the SIP user? (Would F29 and F30 still 
>> happen?)
>
> You are correct - the XMPP server would still consider the SIP user to 
> be authorized, and so it would not prompt the XMPP client for approval 
> of an authorization request. See §3.1.3, point #2, of RFC 6121.

So trying to avoid any terms we've previously used to avoid preconceived 
confusion:

It sounds like, for both directions, the bit of state that means the 
"watcher currently gets notices of presence changes" and the bit of 
state that means "the watcher is _allowed_ to get presence information" 
seem separate for both protocols.

Would it make sense to talk about a "notification session" that is short 
lived, and a "presence authorization"? Or is "session" too loaded?

[...]

Thanks!

Ben.