From nobody Wed May 25 12:56:05 2016
Return-Path: <ben@nostrum.com>
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 69AD912D156; Wed, 25 May 2016 12:56:03 -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 6E54OeIGOAHm; Wed, 25 May 2016 12:56:01 -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 E62B712D160; Wed, 25 May 2016 12:56:00 -0700 (PDT)
Received: from [10.0.1.18] (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 u4PJtxma034404 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 14:56:00 -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.18]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre" <stpeter@stpeter.im>
Date: Wed, 25 May 2016 14:55:59 -0500
Message-ID: <FBCF24A9-9E39-4A6D-970D-49C6E0EFE4F9@nostrum.com>
In-Reply-To: <57225AAF.8060007@stpeter.im>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com> <56EF2815.8050407@stpeter.im> <57221AA1.5000609@stpeter.im> <B6D0869C-3E60-425E-827F-66A6BD8C6DA8@nostrum.com> <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> <57225AAF.8060007@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/UAKT8QjxTxtCzxTl10xUq5W3JmQ>
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 <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: Wed, 25 May 2016 19:56:03 -0000

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 <ben@nostrum.com> 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:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>>>>>> 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 Wed May 25 13:09:57 2016
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 234E212D543; Wed, 25 May 2016 13:09:55 -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=unavailable 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 3DJUiD04eHd1; Wed, 25 May 2016 13:09:54 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0169812D8D6; Wed, 25 May 2016 13:03:47 -0700 (PDT)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 355C8E8206; Wed, 25 May 2016 14:14:51 -0600 (MDT)
To: Ben Campbell <ben@nostrum.com>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com> <56EF2815.8050407@stpeter.im> <57221AA1.5000609@stpeter.im> <B6D0869C-3E60-425E-827F-66A6BD8C6DA8@nostrum.com> <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> <57225AAF.8060007@stpeter.im> <FBCF24A9-9E39-4A6D-970D-49C6E0EFE4F9@nostrum.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <57460522.4030600@stpeter.im>
Date: Wed, 25 May 2016 14:03:46 -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: <FBCF24A9-9E39-4A6D-970D-49C6E0EFE4F9@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/ybOn7NXOVK5aJeXIzcbu1gtJIao>
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 <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: Wed, 25 May 2016 20:09:55 -0000

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 <ben@nostrum.com> 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:
>>>>>>
>>>>>> <snip/>
>>>>>>
>>>>>>>>>>> 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 Wed May 25 13:25:24 2016
Return-Path: <ben@nostrum.com>
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 970C112D99F; Wed, 25 May 2016 13:25:22 -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 JZNX2jeOk09x; Wed, 25 May 2016 13:25:21 -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 AD96C12D9C3; Wed, 25 May 2016 13:25:16 -0700 (PDT)
Received: from [10.0.1.18] (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 u4PKPFMO036775 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 15:25:16 -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.18]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre" <stpeter@stpeter.im>
Date: Wed, 25 May 2016 15:25:15 -0500
Message-ID: <002F8A7B-C85C-4814-BDFA-EA576F8B01E5@nostrum.com>
In-Reply-To: <57460522.4030600@stpeter.im>
References: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com> <56036577.3000204@andyet.net> <1794408B-8BE1-4F24-8A26-F40B1A0804EF@nostrum.com> <5609F9D5.2080306@andyet.net> <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com> <56EF2815.8050407@stpeter.im> <57221AA1.5000609@stpeter.im> <B6D0869C-3E60-425E-827F-66A6BD8C6DA8@nostrum.com> <29063029-3EC9-476A-A8CA-2EF7B6BA9984@stpeter.im> <57225AAF.8060007@stpeter.im> <FBCF24A9-9E39-4A6D-970D-49C6E0EFE4F9@nostrum.com> <57460522.4030600@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/eN496rK0qwSAINuMsWYBM2bz7mA>
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 <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: Wed, 25 May 2016 20:25:22 -0000

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.

Only if you think it needs it. Otherwise I will dive in shortly.

Thanks!

Ben.

>
> 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 <ben@nostrum.com> 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:
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>>>>>>>> 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