From nobody Thu Apr 28 07:14:03 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 CCA0512D7A5; Thu, 28 Apr 2016 07:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 YM5j-KvUH8Lp; Thu, 28 Apr 2016 07:14:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79C12D7B5; Thu, 28 Apr 2016 07:13:55 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 47337E8206; Thu, 28 Apr 2016 08:23:07 -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> From: Peter Saint-Andre Message-ID: <57221AA1.5000609@stpeter.im> Date: Thu, 28 Apr 2016 08:13:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56EF2815.8050407@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 28 Apr 2016 14:14:02 -0000 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. 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 From nobody Thu Apr 28 07: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 A068E12D6DA; Thu, 28 Apr 2016 07:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 BvzRYAHxNifP; Thu, 28 Apr 2016 07:19:41 -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 15F9D12D79F; Thu, 28 Apr 2016 07:19:41 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3SEJdak072667 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Apr 2016 09:19:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Peter Saint-Andre" Date: Thu, 28 Apr 2016 09:19:40 -0500 Message-ID: In-Reply-To: <57221AA1.5000609@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> MIME-Version: 1.0 Content-Type: text/plain; format=flowed 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, 28 Apr 2016 14:19:45 -0000 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 From nobody Thu Apr 28 09:09:17 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 1D31512D967; Thu, 28 Apr 2016 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 xKWzovus4nfS; Thu, 28 Apr 2016 09:09:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31212D969; Thu, 28 Apr 2016 09:00:43 -0700 (PDT) Received: from [10.28.173.111] (unknown [166.173.60.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 85310E8206; Thu, 28 Apr 2016 10:09:55 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Thu, 28 Apr 2016 10:00:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <29063029-3EC9-476A-A8CA-2EF7B6BA9984@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> To: Ben Campbell 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, 28 Apr 2016 16:09:16 -0000 Good point. I think "notification dialog" sounds right. I'm trying to avoid t= he term "subscription"... Sent from mobile, might be terse=20 > On Apr 28, 2016, at 8:19 AM, Ben Campbell wrote: >=20 >> On 28 Apr 2016, at 9:13, Peter Saint-Andre wrote: >>=20 >>> On 3/20/16 4:45 PM, Peter Saint-Andre wrote: >>> A further thought... >>>=20 >>> On 09/28/2015 09:32 PM, Ben Campbell wrote: >>>>> On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote: >>>>>=20 >>>>> On 9/24/15 11:55 AM, Ben Campbell wrote: >>>=20 >>> >>>=20 >>>>>>>> Also, how does this violate the SIP semantic? >>>>>>>=20 >>>>>>> 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)= . >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> Maybe. :-) >>>>>=20 >>>>> 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. >>>>=20 >>>> 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 epheme= ral. >>>>=20 >>>> 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 eithe= r >>>> side. >>>=20 >>> That too is helpful toward a better description of the mismatch in >>> models. >>=20 >> I propose to add the following paragraph to the introduction: >>=20 >> 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. >=20 > Hi Peter, >=20 > I think this is on the right track. But I'm afraid SIP people might confus= e "notification request" with "NOTIFY request", i.e. the NOTIFY message itse= lf. >=20 > To put things is SIP terms, would "subscription dialog" or "notification d= ialog" work? (Or maybe just "dialog"?) >=20 >> Then modify the rest of the document accordingly. >>=20 >> I started making these changes last night and will post a revised I-D eit= her today or tomorrow. >>=20 >> Peter >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From nobody Thu Apr 28 11:45:49 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 0354112D1EC; Thu, 28 Apr 2016 11:45:48 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428184547.5554.18070.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 11:45:47 -0700 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-7248bis-08.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: Thu, 28 Apr 2016 18:45:48 -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-08.txt Pages : 30 Date : 2016-04-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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stox-7248bis-08 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 Thu Apr 28 11:47:17 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 9EEB112D1EC; Thu, 28 Apr 2016 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 O1f786tAIPbo; Thu, 28 Apr 2016 11:47:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD58D12D85F; Thu, 28 Apr 2016 11:47:12 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D5ECE8242; Thu, 28 Apr 2016 12:56:25 -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> From: Peter Saint-Andre Message-ID: <57225AAF.8060007@stpeter.im> Date: Thu, 28 Apr 2016 12:47:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 28 Apr 2016 18:47:16 -0000 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