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

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

I think this thread has devolved into a long series of apologies. :-)

More comments inline to help us get this finished!

On 8/12/16 2:18 PM, Ben Campbell wrote:
> 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.

In XMPP, if the user sends <presence type='unsubscribe'/> to the contact 
then the user-as-watcher will no longer be subscribed to the contact's 
presence and the contact's server will remove the user's authorization. 
If the user wants to be authorized again, the user will have to send 
<presence type='subscribe'/> again.

So I think that the protocol flow in §5.2.3 actually does what you want 
it to do, but that my phrasing "no longer wishes to receive presence 
notifications" confused you - it actually means that the XMPP user no 
longer wishes to have an authorization to see the SIP contact's presence.

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

Shall I add a brief note clarification on this point? If you had to ask 
the question, implementers might, too.

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

Will do.

>>> - 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, that's what my clunky phrasing was intended to capture.

>> (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?

I like that terminology. Let me see if working it in clarifies the 
situation.

Peter