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

"Ben Campbell" <ben@nostrum.com> Wed, 07 September 2016 20:39 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8E12B029 for <stox@ietfa.amsl.com>; Wed, 7 Sep 2016 13:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level:
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 549FD7e05eP9 for <stox@ietfa.amsl.com>; Wed, 7 Sep 2016 13:39:47 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD2712B213 for <stox@ietf.org>; Wed, 7 Sep 2016 13:39:47 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u87KdiuE000224 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Sep 2016 15:39:46 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre" <stpeter@stpeter.im>
Date: Wed, 07 Sep 2016 15:39:44 -0500
Message-ID: <B197ACCC-5DB0-4C8F-8C54-1159A89B1796@nostrum.com>
In-Reply-To: <512b8d52-68e1-2bdd-d153-20e24fbb73de@stpeter.im>
References: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> <a139f13c-9745-0d86-853b-d5d6b8c9124c@stpeter.im> <E1C65C7E-CDFF-40BC-AF01-B2F029B64E6E@nostrum.com> <931fcd90-11c8-0b58-b3ad-eb6e7be2557e@stpeter.im> <f12534a1-bdce-925f-3358-c22975dd3bbe@stpeter.im> <512b8d52-68e1-2bdd-d153-20e24fbb73de@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.5r5260)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/nMsrCDBxHR6qUaDsU9uwHGQ4ApU>
Cc: stox@ietf.org
Subject: Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2016 20:39:49 -0000

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