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

Hi Peter,

I think version 10 is very close to ready. I have two minor comments; 
for the most part these don't change the interaction. I've actually 
suggested text this time :-)

-4, list item 1:

OLD:
   Instead of forwarding a SUBSCRIBE message to the SIP user, the 
Presence Server
   would act on the basis of a policy set by the SIP User Agent using 
the ’
   presence.winfo’ event package, for which the SIP user would receive 
events.
NEW:
   Instead of forwarding a SUBSCRIBE message to the SIP user, the 
Presence Server
   would inform the user of subscription activity using the 
’presence.winfo’
   event package.

-5.1, paragraph after bullet list:
OLD:
    As described in [RFC3856], SIP presence authorizations are
    effectively implicit: when a SIP user receives an initial SIP
    SUBSCRIBE event from a contact, the recipient’s SIP User Agent 
will
    prompt the user to approve or deny the request.
NEW:
    As described in [RFC3856], in SIP the subscriber does not explicitly
    request the creation or removal of presence authorizations. Rather,
    the authorizations are triggered by subscription activity. When a
    SIP user receives an initial SIP SUBSCRIBE event from a contact,
    the recipient’s SIP User Agent or presence server notifies the
    user to make an authorization policy decision.

Thanks!

Ben.

On 2 Sep 2016, at 21:19, Peter Saint-Andre wrote:

> On 9/2/16 4:23 PM, Peter Saint-Andre wrote:
>> 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.
>
> Actually I think the following changes would help to clarify matters.
>
> OLD
>
>    As described in [RFC3856], SIP notification dialogs and presence
>    authorizations are managed through the use of SIP SUBSCRIBE events
>    sent from a SIP User Agent or Presence Server to an intended
>    recipient who is most generally referenced by a Presence URI of the
>    form <pres:user@domain> but who might be referenced by a SIP or 
> SIPS
>    (Session Initiation Protocol Secure) URI of the form
>    <sip:user@domain> or <sips:user@domain>.  In practice, 'pres' URIs
>    are rarely used, which is why the examples in this document use 
> 'sip'
>    URIs.
>
> NEW
>
>    As described in [RFC3856], SIP presence authorizations are
>    effectively implicit: when a SIP user receives an initial SIP
>    SUBSCRIBE event from a contact, the recipient's SIP User Agent will
>    prompt the user to approve or deny the request.  This decision is
>    recorded in the User Agent or in a Presence Server, so that in the
>    future any notification dialogs from the contact are automatically
>    approved.  (Note that addresses for SIP users and contacts are most
>    generally referenced by a Presence URI of the form 
> <pres:user@domain>
>    but might be referenced by a SIP or SIPS (Session Initiation 
> Protocol
>    Secure) URI of the form <sip:user@domain> or <sips:user@domain>;
>    because in practice 'pres' URIs are rarely used, the examples in 
> this
>    document use 'sip' URIs.)
>
> I'm going to submit a revised I-D with these changes and we'll take it 
> from there. :-)
>
> Peter
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox