From nobody Thu Jun 9 15:37:16 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 834D312D568; Thu, 9 Jun 2016 15:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 1JLimOdMY3LU; Thu, 9 Jun 2016 15:37:11 -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 9E63912D580; Thu, 9 Jun 2016 15:37:11 -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 u59MbAl6000841 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2016 17:37:10 -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: Thu, 09 Jun 2016 17:37:19 -0500 Message-ID: <4BE36129-280C-475C-9C5A-6E9D0D770D90@nostrum.com> In-Reply-To: <57460522.4030600@stpeter.im> 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> 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: Thu, 09 Jun 2016 22:37:14 -0000 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? If the SIP contact has a reciprocal subscription back to the xmpp contact’s presence, is that impacted by this unsubscribe action? Or is the SIP user expected to remove the authorization for the xmpp user to see her presence info? - in 5.3.1, I _think_ the flow creates both an authorization and a notification dialog. If the SIP user unsubscribes, and resubscribes (that is, tears down the notification dialog and creates a new one), 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?) Nits: - 1, 5th paragraph: s/specfic/specific/ - 5.2.2, first paragraph, last sentence: I suspect "whenever" should be "... sufficiently in advance of when..." On 25 May 2016, at 15:03, Peter Saint-Andre wrote: > Yes, I think it's ready to go. I can give it a once-over consistency > check first if you'd like, though. > > Thanks! > > Peter > > On 5/25/16 1:55 PM, Ben Campbell wrote: >> Hi Peter, >> >> I'm catching up on some backlog. Is this version ready to go in your >> opinion, or was there more work to do? >> >> Thanks! >> >> Ben. >> >> On 28 Apr 2016, at 13:47, Peter Saint-Andre wrote: >> >>> I just submitted -08 to address this issue (and clean up some >>> related >>> text and examples). >>> >>> On 4/28/16 10:00 AM, Peter Saint-Andre wrote: >>>> Good point. I think "notification dialog" sounds right. I'm trying >>>> to >>>> avoid the term "subscription"... >>>> >>>> Sent from mobile, might be terse >>>> >>>>> On Apr 28, 2016, at 8:19 AM, Ben Campbell wrote: >>>>> >>>>>> On 28 Apr 2016, at 9:13, Peter Saint-Andre wrote: >>>>>> >>>>>>> On 3/20/16 4:45 PM, Peter Saint-Andre wrote: >>>>>>> A further thought... >>>>>>> >>>>>>> On 09/28/2015 09:32 PM, Ben Campbell wrote: >>>>>>>>> On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote: >>>>>>>>> >>>>>>>>> On 9/24/15 11:55 AM, Ben Campbell wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> Also, how does this violate the SIP semantic? >>>>>>>>>>> >>>>>>>>>>> There's a mismatch in the meaning of subscribe. Treating a >>>>>>>>>>> SIP >>>>>>>>>>> subscription as if it were long-lived means the gateway >>>>>>>>>>> follows the >>>>>>>>>>> XMPP subscription model, not the SIP subscription model. A >>>>>>>>>>> gateway >>>>>>>>>>> implementer needs to choose which model to honor, and if it >>>>>>>>>>> chooses >>>>>>>>>>> the XMPP model then it's not honoring the SIP model (and >>>>>>>>>>> vice-versa). >>>>>>>>>> >>>>>>>>>> I think this depends on the resolution to the previous >>>>>>>>>> comment, >>>>>>>>>> but I >>>>>>>>>> would say that if the protoocl behavior expectations of the >>>>>>>>>> SIP >>>>>>>>>> subscriber are met, the semantic has not been violated. >>>>>>>>> >>>>>>>>> Maybe. :-) >>>>>>>>> >>>>>>>>> It still seems to me that the gateway is enforcing one model >>>>>>>>> or the >>>>>>>>> other. Perhaps "violate" is a strong word in this context, >>>>>>>>> though. >>>>>>>> >>>>>>>> I think we may be reading too much into the "ephemeral" >>>>>>>> subscription >>>>>>>> model, while still trying to think of an xmpp subscription and >>>>>>>> a SIP >>>>>>>> subscription of modeling the same thing. Both XMPP and SIP have >>>>>>>> an >>>>>>>> ephemeral component and a long-lived component. In XMPP, the >>>>>>>> subscription is long lived, and the presence session is >>>>>>>> relatively >>>>>>>> ephemeral. In SIP, the authorization policy, and the presence >>>>>>>> of an >>>>>>>> entity on a contact list are long lived, and the subscription >>>>>>>> is >>>>>>>> ephemeral. >>>>>>>> >>>>>>>> So if we think of an XMPP subscription as equivalent to SIP >>>>>>>> subscriber >>>>>>>> authorization, and an XMPP presence session as equivalent to a >>>>>>>> SIP >>>>>>>> subscription, I think we can avoid violence to the assumptions >>>>>>>> of >>>>>>>> either >>>>>>>> side. >>>>>>> >>>>>>> That too is helpful toward a better description of the mismatch >>>>>>> in >>>>>>> models. >>>>>> >>>>>> I propose to add the following paragraph to the introduction: >>>>>> >>>>>> Although specifications for both SIP and XMPP use the term >>>>>> "subscription", the term is employed in different ways. In >>>>>> SIP, a >>>>>> "subscription" is the mechanism whereby a subscriber requests >>>>>> presence notifications from the contact over a relatively >>>>>> short >>>>>> period of time, renewed as necessary to keep receiving >>>>>> presence >>>>>> notifications. By contrast, in XMPP a "subscription" is >>>>>> essentially >>>>>> shorthand for a long-lived presence authorization. To prevent >>>>>> confusion, this document uses the term "notification request" >>>>>> for >>>>>> SIP subscriptions and the term "presence authorization" for >>>>>> XMPP >>>>>> subscriptions. >>>>> >>>>> Hi Peter, >>>>> >>>>> I think this is on the right track. But I'm afraid SIP people >>>>> might >>>>> confuse "notification request" with "NOTIFY request", i.e. the >>>>> NOTIFY message itself. >>>>> >>>>> To put things is SIP terms, would "subscription dialog" or >>>>> "notification dialog" work? (Or maybe just "dialog"?) >>>>> >>>>>> Then modify the rest of the document accordingly. >>>>>> >>>>>> I started making these changes last night and will post a revised >>>>>> I-D either today or tomorrow. >>>>>> >>>>>> Peter > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From nobody Fri Jun 17 15:07:53 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 57FC812DB7F; Fri, 17 Jun 2016 15:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 YJSVuu1Yc_N9; Fri, 17 Jun 2016 15:07:50 -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 6168712DB7B; Fri, 17 Jun 2016 15:07:50 -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 u5HM7mM6091573 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2016 17:07:49 -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, 17 Jun 2016 17:07:50 -0500 Message-ID: <7BC0C622-6892-484F-9550-09281AF8C237@nostrum.com> In-Reply-To: <4BE36129-280C-475C-9C5A-6E9D0D770D90@nostrum.com> 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, 17 Jun 2016 22:07:52 -0000 Any thoughts? On 9 Jun 2016, at 17:37, 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? If the SIP contact has > a reciprocal subscription back to the xmpp contact’s presence, is > that impacted by this unsubscribe action? Or is the SIP user expected > to remove the authorization for the xmpp user to see her presence > info? > > - in 5.3.1, I _think_ the flow creates both an authorization and a > notification dialog. If the SIP user unsubscribes, and resubscribes > (that is, tears down the notification dialog and creates a new one), > 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?) > > > Nits: > > - 1, 5th paragraph: s/specfic/specific/ > > - 5.2.2, first paragraph, last sentence: I suspect "whenever" should > be "... sufficiently in advance of when..." > > > > > > > > > On 25 May 2016, at 15:03, Peter Saint-Andre wrote: > >> Yes, I think it's ready to go. I can give it a once-over consistency >> check first if you'd like, though. >> >> Thanks! >> >> Peter >> >> On 5/25/16 1:55 PM, Ben Campbell wrote: >>> Hi Peter, >>> >>> I'm catching up on some backlog. Is this version ready to go in your >>> opinion, or was there more work to do? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 28 Apr 2016, at 13:47, Peter Saint-Andre wrote: >>> >>>> I just submitted -08 to address this issue (and clean up some >>>> related >>>> text and examples). >>>> >>>> On 4/28/16 10:00 AM, Peter Saint-Andre wrote: >>>>> Good point. I think "notification dialog" sounds right. I'm trying >>>>> to >>>>> avoid the term "subscription"... >>>>> >>>>> Sent from mobile, might be terse >>>>> >>>>>> On Apr 28, 2016, at 8:19 AM, Ben Campbell >>>>>> wrote: >>>>>> >>>>>>> On 28 Apr 2016, at 9:13, Peter Saint-Andre wrote: >>>>>>> >>>>>>>> On 3/20/16 4:45 PM, Peter Saint-Andre wrote: >>>>>>>> A further thought... >>>>>>>> >>>>>>>> On 09/28/2015 09:32 PM, Ben Campbell wrote: >>>>>>>>>> On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote: >>>>>>>>>> >>>>>>>>>> On 9/24/15 11:55 AM, Ben Campbell wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> Also, how does this violate the SIP semantic? >>>>>>>>>>>> >>>>>>>>>>>> There's a mismatch in the meaning of subscribe. Treating a >>>>>>>>>>>> SIP >>>>>>>>>>>> subscription as if it were long-lived means the gateway >>>>>>>>>>>> follows the >>>>>>>>>>>> XMPP subscription model, not the SIP subscription model. A >>>>>>>>>>>> gateway >>>>>>>>>>>> implementer needs to choose which model to honor, and if it >>>>>>>>>>>> chooses >>>>>>>>>>>> the XMPP model then it's not honoring the SIP model (and >>>>>>>>>>>> vice-versa). >>>>>>>>>>> >>>>>>>>>>> I think this depends on the resolution to the previous >>>>>>>>>>> comment, >>>>>>>>>>> but I >>>>>>>>>>> would say that if the protoocl behavior expectations of the >>>>>>>>>>> SIP >>>>>>>>>>> subscriber are met, the semantic has not been violated. >>>>>>>>>> >>>>>>>>>> Maybe. :-) >>>>>>>>>> >>>>>>>>>> It still seems to me that the gateway is enforcing one model >>>>>>>>>> or the >>>>>>>>>> other. Perhaps "violate" is a strong word in this context, >>>>>>>>>> though. >>>>>>>>> >>>>>>>>> I think we may be reading too much into the "ephemeral" >>>>>>>>> subscription >>>>>>>>> model, while still trying to think of an xmpp subscription and >>>>>>>>> a SIP >>>>>>>>> subscription of modeling the same thing. Both XMPP and SIP >>>>>>>>> have an >>>>>>>>> ephemeral component and a long-lived component. In XMPP, the >>>>>>>>> subscription is long lived, and the presence session is >>>>>>>>> relatively >>>>>>>>> ephemeral. In SIP, the authorization policy, and the presence >>>>>>>>> of an >>>>>>>>> entity on a contact list are long lived, and the subscription >>>>>>>>> is >>>>>>>>> ephemeral. >>>>>>>>> >>>>>>>>> So if we think of an XMPP subscription as equivalent to SIP >>>>>>>>> subscriber >>>>>>>>> authorization, and an XMPP presence session as equivalent to a >>>>>>>>> SIP >>>>>>>>> subscription, I think we can avoid violence to the assumptions >>>>>>>>> of >>>>>>>>> either >>>>>>>>> side. >>>>>>>> >>>>>>>> That too is helpful toward a better description of the mismatch >>>>>>>> in >>>>>>>> models. >>>>>>> >>>>>>> I propose to add the following paragraph to the introduction: >>>>>>> >>>>>>> Although specifications for both SIP and XMPP use the term >>>>>>> "subscription", the term is employed in different ways. In >>>>>>> SIP, a >>>>>>> "subscription" is the mechanism whereby a subscriber requests >>>>>>> presence notifications from the contact over a relatively >>>>>>> short >>>>>>> period of time, renewed as necessary to keep receiving >>>>>>> presence >>>>>>> notifications. By contrast, in XMPP a "subscription" is >>>>>>> essentially >>>>>>> shorthand for a long-lived presence authorization. To >>>>>>> prevent >>>>>>> confusion, this document uses the term "notification request" >>>>>>> for >>>>>>> SIP subscriptions and the term "presence authorization" for >>>>>>> XMPP >>>>>>> subscriptions. >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> I think this is on the right track. But I'm afraid SIP people >>>>>> might >>>>>> confuse "notification request" with "NOTIFY request", i.e. the >>>>>> NOTIFY message itself. >>>>>> >>>>>> To put things is SIP terms, would "subscription dialog" or >>>>>> "notification dialog" work? (Or maybe just "dialog"?) >>>>>> >>>>>>> Then modify the rest of the document accordingly. >>>>>>> >>>>>>> I started making these changes last night and will post a >>>>>>> revised >>>>>>> I-D either today or tomorrow. >>>>>>> >>>>>>> Peter >> >> _______________________________________________ >> 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 Tue Jun 21 19:44:26 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 B27E412D89F; Tue, 21 Jun 2016 19:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 iwpWyPm3oi-S; Tue, 21 Jun 2016 19:44:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDF12D896; Tue, 21 Jun 2016 19:44:23 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C7524E8288; Tue, 21 Jun 2016 20:57:19 -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: Date: Tue, 21 Jun 2016 20:44:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4BE36129-280C-475C-9C5A-6E9D0D770D90@nostrum.com> 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: Wed, 22 Jun 2016 02:44:25 -0000 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. > 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. > 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. > - 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. (Yes, I know, presence state machines are horribly complicated!) > 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? > 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. > Nits: > > - 1, 5th paragraph: s/specfic/specific/ > > - 5.2.2, first paragraph, last sentence: I suspect "whenever" should be > "... sufficiently in advance of when..." Good catch. After we settle on a common understanding of the foregoing points, I'll submit -09 so that we have clean text ready for IETF Last Call. Thanks again, Peter