Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02

Ben Campbell <ben@nostrum.com> Fri, 06 June 2014 19:54 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B581A0195 for <xmpp@ietfa.amsl.com>; Fri, 6 Jun 2014 12:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 2X57k3syoSdy for <xmpp@ietfa.amsl.com>; Fri, 6 Jun 2014 12:54:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377351A0078 for <xmpp@ietf.org>; Fri, 6 Jun 2014 12:54:26 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s56JsGe7000353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 14:54:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53921B7C.8080403@stpeter.im>
Date: Fri, 6 Jun 2014 14:54:16 -0500
X-Mao-Original-Outgoing-Id: 423777256.140981-8404061a8f615e127eba9678c365bfa7
Content-Transfer-Encoding: quoted-printable
Message-Id: <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com>
References: <F8275190-9346-4879-9843-A3DF6C604F8C@nostrum.com> <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/YbVBJIEQevi66ygW9bu7ddYW1y0
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 19:54:27 -0000

On Jun 6, 2014, at 2:50 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> On 6/6/14, 1:47 PM, Ben Campbell wrote:
>> Sorry for the delay. I just returned from a very disconnected vacation.
>> 
>> On May 27, 2014, at 1:31 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>> 
>>> Connection managers are trusted server components, so the administrators of the service are aware that there is a CM in the mix, but the server need not be (all it knows is that sessions have been created and that some trusted entity did so).
>>> 
>>>> Is it assumed to
>>>> implement this draft?
>>> 
>>> The server doesn't really need to implement the websocket aspect of things, since that's handled by the CM.
>>> 
>>>> Are we requiring special behavior of the
>>>> server, without the server knowing it needs to do it?
>>> 
>>> Not as far as I can see.
>> 
>> Is there any reason to mention connection managers at all? Unless I missed something, the draft only mentions them parenthetically, but it does so in a normative statement. It's starting to sound like an implementation detail that doesn't need anything normative, if any mention at all.
> 
> It is in fact an implementation detail.

Strictly as an individual, I then propose we either remove the mention entirely (my preference), or move it to an "implementation note" so that it cannot be conflated with the normative statement it's currently attached to.

But I realize that's pretty pedantic, and  if the authors are tired of making new versions, I can live with it as is :-)

> 
> Peter