Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

Peter Saint-Andre <> Thu, 28 April 2016 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EEB112D1EC; Thu, 28 Apr 2016 11:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O1f786tAIPbo; Thu, 28 Apr 2016 11:47:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD58D12D85F; Thu, 28 Apr 2016 11:47:12 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 3D5ECE8242; Thu, 28 Apr 2016 12:56:25 -0600 (MDT)
To: Ben Campbell <>
References: <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
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:
>>>> <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