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

Peter Saint-Andre <stpeter@stpeter.im> Sun, 20 March 2016 22:45 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 F2A9512D596; Sun, 20 Mar 2016 15:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 hJAHTen1-23X; Sun, 20 Mar 2016 15:45:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 085A112D555; Sun, 20 Mar 2016 15:45:43 -0700 (PDT)
Received: from [10.0.0.94] (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6767FE81DD; Sun, 20 Mar 2016 16:52:16 -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>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <56EF2815.8050407@stpeter.im>
Date: Sun, 20 Mar 2016 16:45:41 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <BD08A7FA-9722-4444-B5B7-3640D4AC2D56@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/2zu_wp0KDYnJd62ndqV5yYxvwnQ>
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: Sun, 20 Mar 2016 22:45:44 -0000

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'm going to ruminate on the matter but first (i.e., right now)
submit a revised I-D that incorporates (I think) all of the other fixes.

Peter