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

Peter Saint-Andre <> Tue, 08 July 2014 08:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DA921B2AB4; Tue, 8 Jul 2014 01:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.553
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2GI-y8p4Txbn; Tue, 8 Jul 2014 01:46:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14F451B2A58; Tue, 8 Jul 2014 01:46:24 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id B9E0940332; Tue, 8 Jul 2014 02:46:22 -0600 (MDT)
Message-ID: <>
Date: Tue, 08 Jul 2014 02:46:21 -0600
From: Peter Saint-Andre <>
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 <>, Jari Arkko <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, "Romascanu, Dan \(Dan\)" <>, "" <>, XMPP Working Group <>
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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