Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt
Peter Saint-Andre <stpeter@stpeter.im> Fri, 02 September 2016 22:23 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 557BF12B005 for <stox@ietfa.amsl.com>; Fri, 2 Sep 2016 15:23:56 -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 3_Nb5U1E4sE5 for <stox@ietfa.amsl.com>; Fri, 2 Sep 2016 15:23:54 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D1896127735 for <stox@ietf.org>; Fri, 2 Sep 2016 15:23:54 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 624A940FC8; Fri, 2 Sep 2016 16:23:57 -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>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <f12534a1-bdce-925f-3358-c22975dd3bbe@stpeter.im>
Date: Fri, 02 Sep 2016 16:23:53 -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: <931fcd90-11c8-0b58-b3ad-eb6e7be2557e@stpeter.im>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stox/dV4zaLfZPZ09fi0x03zunnz7Gh0>
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: Fri, 02 Sep 2016 22:23:56 -0000
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
- [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt internet-drafts
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Ben Campbell
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-7248bis-09… Saúl Ibarra Corretgé