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

Peter Saint-Andre <stpeter@stpeter.im> Sat, 03 September 2016 02:19 UTC

Return-Path: <stpeter@stpeter.im>
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 B73CD12D5C9 for <stox@ietfa.amsl.com>; Fri, 2 Sep 2016 19:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 v1Zx6-t2PVqX for <stox@ietfa.amsl.com>; Fri, 2 Sep 2016 19:19:37 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8D95312D5C4 for <stox@ietf.org>; Fri, 2 Sep 2016 19:19:37 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3BFC4159F; Fri, 2 Sep 2016 20:19:39 -0600 (MDT)
To: Ben Campbell <ben@nostrum.com>
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>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <512b8d52-68e1-2bdd-d153-20e24fbb73de@stpeter.im>
Date: Fri, 2 Sep 2016 20:19:35 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <f12534a1-bdce-925f-3358-c22975dd3bbe@stpeter.im>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/AZyocGr_K2RKdDWCtCzmOfCfYz4>
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: Sat, 03 Sep 2016 02:19:38 -0000

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