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

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

On 8/29/16 9:43 PM, Peter Saint-Andre wrote:
> On 8/29/16 4:56 PM, Ben Campbell wrote:
>> Hi Peter,
>>
>> I'm going to try to be more responsive on this, and break the apology
>> loop :-)
>
> Likewise!
>
>> 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.
>
> Your description really clarified things for me, so thanks!

Looking at the I-D more closely, I think that the protocol flow diagram 
in §5.2.3 is fine, but that some clarifying text would help. I propose 
the following change to the first paragraph of that section.

OLD

    The following diagram illustrates the protocol flow by which an XMPP
    user cancels her outbound presence authorization to a SIP contact
    (i.e., indicates that she no longer wishes to be authorized to see
    the SIP contact's presence), as further explained in the text and
    examples after the diagram.

NEW

    The following diagram illustrates the protocol flow by which an XMPP
    user cancels her outbound presence authorization to a SIP contact
    (i.e., indicates that she no longer wishes to be authorized to see
    the SIP contact's presence).  As can be seen, because SIMPLE does not
    have a construct that enables a contact to cancel her presence
    authorization, this flow instead results in cancellation of the
    contact's notification dialog (with the implication on the XMPP side
    that the contact will not request a subsequent notification dialog).
    Additional details are explained in the text and examples after the
    diagram.

Similarly in §5.3.3...

OLD

    At any time, the SIP user can cancel his outbound presence
    authorization to the XMPP contact (i.e., indicate that he no longer
    wishes to be authorized to receive presence notifications from the
    XMPP contact) by sending a SUBSCRIBE message whose Expires header is
    set to a value of zero ("0"):

NEW

    SIP does not directly have a construct for cancelling an outbound
    presence authorization.  Instead, the SIP user would terminate his
    outbound notification dialog by sending a SUBSCRIBE message whose
    Expires header is set to a value of zero ("0"), and then never renew
    it:

>> 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.
>
> Yes, that seems sensible. I will work on an updated I-D along those
> lines very soon.

Given the changes proposed above, do you think we also need to modify 
§5.1? We could add a sentence or clause there, too, but I'm not sure 
it's really necessary.

Thanks!

Peter