From nobody Fri Aug 12 13:18:23 2016 Return-Path: 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 39DB912D908; Fri, 12 Aug 2016 13:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 uN1SaNC2s7kI; Fri, 12 Aug 2016 13:18:22 -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 04EDB12D80E; Fri, 12 Aug 2016 13:18:18 -0700 (PDT) Received: from [10.0.1.4] (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 u7CKIHYo063766 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Aug 2016 15:18:18 -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.4] From: "Ben Campbell" To: "Peter Saint-Andre" Date: Fri, 12 Aug 2016 15:18:16 -0500 Message-ID: In-Reply-To: References: <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <56EF2815.8050407@stpeter.im> <57221AA1.5000609@stpeter.im> <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> <57225AAF.8060007@stpeter.im> <57460522.4030600@stpeter.im> <4BE36129-280C-475C-9C5A-6E9D0D770D90@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 20:18:23 -0000 My turn to apologize for the delay. This draft seem especially prone to falling through my task list cracks. Some more comments and questions inline: On 21 Jun 2016, at 21:44, Peter Saint-Andre wrote: > Hi Ben, thanks for your comments. My apologies for the delayed reply. > > On 6/9/16 4:37 PM, Ben Campbell wrote: >> Hi Peter, >> >> >> I have a couple of questions about the implications of the new >> "presence >> authorization" concept, and a couple of editorial nits. Otherwise, I >> think this is ready for IETF last call. It might make sense to go >> ahead >> with the last call, and address these with any last call >> comments--but >> I'd like to have an initial round of conversation about the presence >> authorization first. >> >> - in 5.2.3, whose "authorization" is canceled? > > The use cases in §5.2 originate on the XMPP side and the use cases in > §5.3 originate on the SIP side, so §5.2.3 describes what happens > when the XMPP user no longer wishes to receive presence notifications > from the SIP contact. This makes me think the abstraction is still not quite right. From the SIP perspective, this flow does not cancel an authorization to receive presence. It merely stops notifications. If the XMPP were to resubscribe later, the SIP presence server would probably just restart notifications. It would consider the watcher to be authorized based on existing authorization policy. That policy doesn't go away just because the watcher unsubscribed. Basically the state that says "Juliet is allowed to see Romeo's presence" is long lived. It's independent from the state that says "Juliet currently wants to receive notification of changes in Romeo's presence". It's possible the server will expire that policy after some time, but that would be completely proprietary. Otherwise, the authorization only goes away when and if the _SIP_ user removes it, for example using XCAP. So at the risk of rehashing old coversations, I think we've got the following bits of state: XMPP: - Watcher is subscribed - long lived, means the same as "watcher is authorized". - Watcher wants notifications - Short lived for duration of the watcher's XMPP connection to his XMPP server. Requires "watcher is subscribed" to be true. SIP: - Watcher is subscribed - Short lived (soft state). Means watcher wants notifications. Requires "Watcher is authorized" to be true. - Watcher is authorized - Long lived. Controlled by presentity. If no policy already exists, decision triggered by a watcher's attempt to subscribe. > >> If the SIP contact has a >> reciprocal subscription back to the xmpp contact’s presence, is >> that >> impacted by this unsubscribe action? > > It shouldn't be, because we're not assuming that authorization to > receive presence notifications needs to be bidirectional. So this flow > results in the XMPP user (here, Juliet) no longer receiving presence > notifications from the SIP contact (here, Romeo); however, Romeo can > still happily receive presence notifications from Juliet. Okay, then I think we are good here. > >> Or is the SIP user expected to >> remove the authorization for the xmpp user to see her presence info? > > Romeo would also need to inform Juliet that he no longer wishes to > receive presence notifications from her, i.e., he would need to > complete the flow in §5.3.3. > > I can see that the phrasing in §5.2.3 and §5.3.3 is confusing, i.e.: > > 5.2.3 > > cancelling an XMPP user's presence authorization to a SIP contact > > 5.3.3 > > cancel the presence authorization > > That wording doesn't make the directionality clear. I'll rephrase > these sentences to clarify matters. That would help. > >> - in 5.3.1, I _think_ the flow creates both an authorization and a >> notification dialog. > > To prevent confusion, we're now using the term "notification dialog" > for SIP->XMPP and "presence authorization" for XMPP->SIP. When you say > "authorization" here, are you referring to a presence authorization > from the XMPP user to the SIP user? If so, how would the notification > dialog from the SIP user to the XMPP trigger that? If not, then let's > make sure we're on the same page about what's happening here. I'm not entirely sure what "authorization from the XMPP user to the SIP user means". Would it make sense to say "authorization to allow the SIP user to receive the XMPP user's presence"? > > (Yes, I know, presence state machines are horribly complicated!) Yep. And differently shaped between the two protocols. > >> If the SIP user unsubscribes, and resubscribes >> (that is, tears down the notification dialog and creates a new one), > > That is, completes the flow in §5.3.1, then completes the flow in > §5.3.3, then initiates the flow in §5.3.1 again - correct? Yes. > >> is >> there any difference in the flow due to the fact the XMPP server has >> authorization state for the SIP user? (Would F29 and F30 still >> happen?) > > You are correct - the XMPP server would still consider the SIP user to > be authorized, and so it would not prompt the XMPP client for approval > of an authorization request. See §3.1.3, point #2, of RFC 6121. So trying to avoid any terms we've previously used to avoid preconceived confusion: It sounds like, for both directions, the bit of state that means the "watcher currently gets notices of presence changes" and the bit of state that means "the watcher is _allowed_ to get presence information" seem separate for both protocols. Would it make sense to talk about a "notification session" that is short lived, and a "presence authorization"? Or is "session" too loaded? [...] Thanks! Ben. From nobody Sun Aug 28 11:25:24 2016 Return-Path: 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 893E212B008; Sun, 28 Aug 2016 11:25:23 -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 EfAAJWFoHm_m; Sun, 28 Aug 2016 11:25:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16B12B018; Sun, 28 Aug 2016 11:25:22 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 276E7F0748; Sun, 28 Aug 2016 12:27:55 -0600 (MDT) To: Ben Campbell References: <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <56EF2815.8050407@stpeter.im> <57221AA1.5000609@stpeter.im> <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> <57225AAF.8060007@stpeter.im> <57460522.4030600@stpeter.im> <4BE36129-280C-475C-9C5A-6E9D0D770D90@nostrum.com> From: Peter Saint-Andre Message-ID: <95291a74-8f87-ea83-bdd9-d4d651f69116@stpeter.im> Date: Sun, 28 Aug 2016 12:25:19 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: stox@ietf.org, draft-ietf-stox-7248bis.all@ietf.org Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 18:25:23 -0000 I think this thread has devolved into a long series of apologies. :-) More comments inline to help us get this finished! On 8/12/16 2:18 PM, Ben Campbell wrote: > My turn to apologize for the delay. This draft seem especially prone to > falling through my task list cracks. > > Some more comments and questions inline: > > > On 21 Jun 2016, at 21:44, Peter Saint-Andre wrote: > >> Hi Ben, thanks for your comments. My apologies for the delayed reply. >> >> On 6/9/16 4:37 PM, Ben Campbell wrote: >>> Hi Peter, >>> >>> >>> I have a couple of questions about the implications of the new "presence >>> authorization" concept, and a couple of editorial nits. Otherwise, I >>> think this is ready for IETF last call. It might make sense to go ahead >>> with the last call, and address these with any last call comments--but >>> I'd like to have an initial round of conversation about the presence >>> authorization first. >>> >>> - in 5.2.3, whose "authorization" is canceled? >> >> The use cases in §5.2 originate on the XMPP side and the use cases in >> §5.3 originate on the SIP side, so §5.2.3 describes what happens when >> the XMPP user no longer wishes to receive presence notifications from >> the SIP contact. > > This makes me think the abstraction is still not quite right. From the > SIP perspective, this flow does not cancel an authorization to receive > presence. It merely stops notifications. If the XMPP were to resubscribe > later, the SIP presence server would probably just restart > notifications. It would consider the watcher to be authorized based on > existing authorization policy. That policy doesn't go away just because > the watcher unsubscribed. > > Basically the state that says "Juliet is allowed to see Romeo's > presence" is long lived. It's independent from the state that says > "Juliet currently wants to receive notification of changes in Romeo's > presence". It's possible the server will expire that policy after some > time, but that would be completely proprietary. Otherwise, the > authorization only goes away when and if the _SIP_ user removes it, for > example using XCAP. > > So at the risk of rehashing old coversations, I think we've got the > following bits of state: > > XMPP: > - Watcher is subscribed - long lived, means the same as "watcher is > authorized". > > - Watcher wants notifications - Short lived for duration of the > watcher's XMPP connection to his XMPP server. Requires "watcher is > subscribed" to be true. > > SIP: > - Watcher is subscribed - Short lived (soft state). Means watcher wants > notifications. Requires "Watcher is authorized" to be true. > > - Watcher is authorized - Long lived. Controlled by presentity. If no > policy already exists, decision triggered by a watcher's attempt to > subscribe. In XMPP, if the user sends to the contact then the user-as-watcher will no longer be subscribed to the contact's presence and the contact's server will remove the user's authorization. If the user wants to be authorized again, the user will have to send again. So I think that the protocol flow in §5.2.3 actually does what you want it to do, but that my phrasing "no longer wishes to receive presence notifications" confused you - it actually means that the XMPP user no longer wishes to have an authorization to see the SIP contact's presence. >>> If the SIP contact has a >>> reciprocal subscription back to the xmpp contact’s presence, is that >>> impacted by this unsubscribe action? >> >> It shouldn't be, because we're not assuming that authorization to >> receive presence notifications needs to be bidirectional. So this flow >> results in the XMPP user (here, Juliet) no longer receiving presence >> notifications from the SIP contact (here, Romeo); however, Romeo can >> still happily receive presence notifications from Juliet. > > Okay, then I think we are good here. Shall I add a brief note clarification on this point? If you had to ask the question, implementers might, too. >>> Or is the SIP user expected to >>> remove the authorization for the xmpp user to see her presence info? >> >> Romeo would also need to inform Juliet that he no longer wishes to >> receive presence notifications from her, i.e., he would need to >> complete the flow in §5.3.3. >> >> I can see that the phrasing in §5.2.3 and §5.3.3 is confusing, i.e.: >> >> 5.2.3 >> >> cancelling an XMPP user's presence authorization to a SIP contact >> >> 5.3.3 >> >> cancel the presence authorization >> >> That wording doesn't make the directionality clear. I'll rephrase >> these sentences to clarify matters. > > That would help. Will do. >>> - in 5.3.1, I _think_ the flow creates both an authorization and a >>> notification dialog. >> >> To prevent confusion, we're now using the term "notification dialog" >> for SIP->XMPP and "presence authorization" for XMPP->SIP. When you say >> "authorization" here, are you referring to a presence authorization >> from the XMPP user to the SIP user? If so, how would the notification >> dialog from the SIP user to the XMPP trigger that? If not, then let's >> make sure we're on the same page about what's happening here. > > I'm not entirely sure what "authorization from the XMPP user to the SIP > user means". Would it make sense to say "authorization to allow the SIP > user to receive the XMPP user's presence"? Yes, that's what my clunky phrasing was intended to capture. >> (Yes, I know, presence state machines are horribly complicated!) > > Yep. And differently shaped between the two protocols. > >> >>> If the SIP user unsubscribes, and resubscribes >>> (that is, tears down the notification dialog and creates a new one), >> >> That is, completes the flow in §5.3.1, then completes the flow in >> §5.3.3, then initiates the flow in §5.3.1 again - correct? > > Yes. > >> >>> is >>> there any difference in the flow due to the fact the XMPP server has >>> authorization state for the SIP user? (Would F29 and F30 still happen?) >> >> You are correct - the XMPP server would still consider the SIP user to >> be authorized, and so it would not prompt the XMPP client for approval >> of an authorization request. See §3.1.3, point #2, of RFC 6121. > > So trying to avoid any terms we've previously used to avoid preconceived > confusion: > > It sounds like, for both directions, the bit of state that means the > "watcher currently gets notices of presence changes" and the bit of > state that means "the watcher is _allowed_ to get presence information" > seem separate for both protocols. > > Would it make sense to talk about a "notification session" that is short > lived, and a "presence authorization"? Or is "session" too loaded? I like that terminology. Let me see if working it in clarifies the situation. Peter From nobody Sun Aug 28 13:30:54 2016 Return-Path: X-Original-To: stox@ietf.org Delivered-To: stox@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8691712B03A; Sun, 28 Aug 2016 13:30:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> Date: Sun, 28 Aug 2016 13:30:52 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-7248bis-09.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:30:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Author : Peter Saint-Andre Filename : draft-ietf-stox-7248bis-09.txt Pages : 31 Date : 2016-08-28 Abstract: This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stox-7248bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 28 17:19:46 2016 Return-Path: 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 B575812D0C2 for ; Sun, 28 Aug 2016 17:19:44 -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 FsoGNKq14WPy for ; Sun, 28 Aug 2016 17:19:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 660F112B019 for ; Sun, 28 Aug 2016 17:19:43 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D66A1F0748; Sun, 28 Aug 2016 18:22:17 -0600 (MDT) To: stox@ietf.org References: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: Date: Sun, 28 Aug 2016 18:19:41 -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: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 00:19:45 -0000 Hi Ben & others, Here are a few more fixes intended to address issues raised in the last few rounds of email. We're getting close... Peter On 8/28/16 2:30 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence > Author : Peter Saint-Andre > Filename : draft-ietf-stox-7248bis-09.txt > Pages : 31 > Date : 2016-08-28 > > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of presence information between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). This document obsoletes RFC 7248. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stox-7248bis-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From nobody Mon Aug 29 15:56:46 2016 Return-Path: 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 4189C12D11F for ; Mon, 29 Aug 2016 15:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 fla0RmOAr_RU for ; Mon, 29 Aug 2016 15:56:42 -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 7ACDD126FDC for ; Mon, 29 Aug 2016 15:56:42 -0700 (PDT) Received: from [10.0.1.9] (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 u7TMuf84045539 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Aug 2016 17:56:41 -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.9] From: "Ben Campbell" To: "Peter Saint-Andre" Date: Mon, 29 Aug 2016 17:56:41 -0500 Message-ID: In-Reply-To: References: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 22:56:45 -0000 Hi Peter, I'm going to try to be more responsive on this, and break the apology loop :-) 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. 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. On 28 Aug 2016, at 19:19, Peter Saint-Andre wrote: > Hi Ben & others, > > Here are a few more fixes intended to address issues raised in the > last few rounds of email. We're getting close... > > Peter > > On 8/28/16 2:30 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIP-TO-XMPP of the IETF. >> >> Title : Interworking between the Session Initiation >> Protocol (SIP) and the Extensible Messaging and Presence Protocol >> (XMPP): Presence >> Author : Peter Saint-Andre >> Filename : draft-ietf-stox-7248bis-09.txt >> Pages : 31 >> Date : 2016-08-28 >> >> Abstract: >> This document defines a bidirectional protocol mapping for the >> exchange of presence information between the Session Initiation >> Protocol (SIP) and the Extensible Messaging and Presence Protocol >> (XMPP). This document obsoletes RFC 7248. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stox-7248bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-stox-7248bis-09 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-09 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >> > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From nobody Mon Aug 29 20:43:23 2016 Return-Path: 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 C929E12D0E1 for ; Mon, 29 Aug 2016 20:43:22 -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 KQiOhPJW8LnH for ; Mon, 29 Aug 2016 20:43:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF88127A90 for ; Mon, 29 Aug 2016 20:43:21 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC200F075D; Mon, 29 Aug 2016 21:46:00 -0600 (MDT) To: Ben Campbell References: <147241625250.24476.13333521107304467910.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <931fcd90-11c8-0b58-b3ad-eb6e7be2557e@stpeter.im> Date: Mon, 29 Aug 2016 21:43:19 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 03:43:23 -0000 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! > 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. Peter