Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt

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

Hi Peter,

I'm going to try to be more responsive on this, and break the apology 
loop :-)

I agree we are zeroing in on things here. I think, with this version, I 
can better clarify my remaining concern. (I think it's the only thing 
left.)

5.2.3 talks about canceling a presence authorization. But from Romeo's 
perspective, it does do that; it only cancels the notification session. 
SIP has no way for Juliet to explicitly say "I want my permission to see 
Romeo's presence info to go away". If Juliet never wants to be notified 
again, she simply doesn't subscribe again. Maybe Romeo's system has some 
policy that ages out such authorizations over time, but that's not 
really relevant to this draft. (It's also possible for Romeo to 
unilaterally cancel that authorization, but that's probably more detail 
than is needed here.) In simpler terms, Romeo's presence server asks him 
if he wants to let Juliet subscribe the first time she tries. For future 
subscriptions, it won't ask. If Romeo later decides he prefers less 
star-crossed relationships, he can withdraw that permission. Other than 
than the initial subscription request, Juliet has no say in the matter.

This is also true for _requesting_ authorization. For example, the only 
thing that makes 5.2.1 into a request for authorization (on the SIP 
side) is the fact that Juliet is subscribing for the first time. (I'm 
not saying 5.2.1 needs to change; I just mention this for background).

Likewise in 5.3.3, Romeo is not asking to be deauthorized. He's just 
asking to end the notification session. Now that may not matter, he just 
gets re-authorized next time hie sends a SUBSCRIBE request. But he might 
be surprised to find that Juliet thought he had requested to be 
deauthorized. (Not to mention, that Juliet might feel, well, 
"unfriended" :-)  )

This all goes counter to the statement in the 2nd to last paragraph of 
5.1 that SIP presence authorizations are managed with SUBSCRIBE 
requests. The real situation is that the watcher (Juliet) doesn't manage 
these authorizations at all--they are unilaterally managed by the 
presentity (Romeo). A SUBSCRIBE request from Juliet may cause Romeo to 
be notified that he needs to make an authorization decision if he has 
not previously given permission.

So, how to fix this? I'm not sure I have the answer. But one approach 
might be to extend 5.1 to be more clear about the difference in 
authorization models, then have sections 5.2.x and 5.3.x talk more about 
notification sessions than authorization, but mention authorization 
state changes in the commentary about the message detail as needed.

On 28 Aug 2016, at 19:19, Peter Saint-Andre wrote:

> Hi Ben & others,
>
> Here are a few more fixes intended to address issues raised in the 
> last few rounds of email. We're getting close...
>
> Peter
>
> On 8/28/16 2:30 PM, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the SIP-TO-XMPP of the IETF.
>>
>>         Title           : Interworking between the Session Initiation 
>> Protocol (SIP) and the Extensible Messaging and Presence Protocol 
>> (XMPP): Presence
>>         Author          : Peter Saint-Andre
>> 	Filename        : draft-ietf-stox-7248bis-09.txt
>> 	Pages           : 31
>> 	Date            : 2016-08-28
>>
>> Abstract:
>>    This document defines a bidirectional protocol mapping for the
>>    exchange of presence information between the Session Initiation
>>    Protocol (SIP) and the Extensible Messaging and Presence Protocol
>>    (XMPP).  This document obsoletes RFC 7248.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-stox-7248bis-09
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-09
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> stox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stox
>>
>
> _______________________________________________
> stox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stox