Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

Peter Saint-Andre <stpeter@stpeter.im> Tue, 08 July 2014 08:46 UTC

Return-Path: <stpeter@stpeter.im>
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 2DA921B2AB4; Tue, 8 Jul 2014 01:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 2GI-y8p4Txbn; Tue, 8 Jul 2014 01:46:25 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 14F451B2A58; Tue, 8 Jul 2014 01:46:24 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B9E0940332; Tue, 8 Jul 2014 02:46:22 -0600 (MDT)
Message-ID: <53BBAFDD.70407@stpeter.im>
Date: Tue, 08 Jul 2014 02:46:21 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Lance Stout <lancestout@gmail.com>, Jari Arkko <jari.arkko@piuha.net>
References: <9904FB1B0159DA42B0B887B7FA8119CA5C823BB2@AZ-FFEXMB04.global.avaya.com> <7CC08F3C-4747-4B65-9743-A19CDAE9F940@piuha.net> <42688FF4-DA40-40AA-B99E-247EA635AA00@gmail.com>
In-Reply-To: <42688FF4-DA40-40AA-B99E-247EA635AA00@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/FN5F7CHgIG-XA9WxlIf9GQxr_90
Cc: "draft-ietf-xmpp-websocket.all@tools.ietf.org" <draft-ietf-xmpp-websocket.all@tools.ietf.org>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "gen-art@ietf.org" <gen-art@ietf.org>, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
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: Tue, 08 Jul 2014 08:46:26 -0000

<hat type='shepherd'/>

On 7/8/14, 12:51 AM, Lance Stout wrote:
>> I would like to see some thoughts from the editors regarding the two points that you raised.
>
> Hrm, did my earlier response on the 3rd not make it through moderation to the gen-art list?
>
>
>
>> 1. In order to accommodate the Websocket binding this document describes several
>> deviations from RFC6120. For example, in Section 3.3 it says: The WebSocket
>> XMPP sub-protocol deviates from the standard method of constructing and using
>> XML streams as defined in [RFC6120] by adopting the message framing provided by
>> WebSocket to delineate the stream open and close headers, stanzas, and other
>> top-level stream elements. I am wondering whether it would not be appropriate to
>> reflect this in the document header by adding Updates RFC6120
>
> This is creating a new binding, separate from the TCP binding defined in RFC6120. While
> this document introduces framing (thus deviating from RFC6120) it does not actually
> modify anything in RFC6120.

That seems accurate to me (also with my RFC6120-author hat on).

>> 2. In Section 3.6.1:
>>
>>    If the server wishes at any point to instruct the client to move to a
>>    different WebSocket endpoint (e.g. for load balancing purposes), the server
>>    MAY send a <close/> element and set the "see-other-uri" attribute to the
>>    URI of the new connection endpoint (which MAY be for a different transport
>>    method, such as BOSH (see [XEP-0124] and [XEP-0206]).
>>
>>         I do not understand the usage of MAY in this paragraph. Is there another
>> method to move to a different Web socket endpoint that is described here or some
>> other place? In not, why is not the first MAY at least a SHOULD? The second
>> usage seems to describe a state of facts, so it needs not be capitalized at all.
>
> That is the only method, so I agree that can be a SHOULD, and also agree on the
> second point.
>
> After proposing changing this to SHOULD to the WG, some members have questioned if
> 2119 language is even needed here at all, as there is no alternative way to do this.

Right. I might change "the server MAY send a <close/> element and 
set..." to, simply, "the server sends a <close/> element and sets..." 
since, as you say, this is just how it's done. (These conditionally 
normative statements are always a bit confusing - "if X then MUST Y" and 
such.)

Peter