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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 28 April 2016 14:14 UTC

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 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 <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>
From: Peter Saint-Andre <stpeter@stpeter.im>
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: <http://mailarchive.ietf.org/arch/msg/stox/_5BQLhAOcNpAhmv9zPPAQX-46ik>
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: 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:
>
> <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.

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