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

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Aug 2016 15:18:16 -0500

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Aug 2016 12:25:19 -0600

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:
>>> I have a couple of questions about the implications of the new "presence
>>> 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
>> §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.
>

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

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

>> these sentences to clarify matters.

Will do.

> user to receive the XMPP user's presence"?

Yes, that's what my clunky phrasing was intended to capture.

>>> authorization state for the SIP user? (Would F29 and F30 still happen?)
>>

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

Peter