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

Lance Stout <> Tue, 08 July 2014 06:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B5BA1B2A7F; Mon, 7 Jul 2014 23:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7LXzGt5mKD72; Mon, 7 Jul 2014 23:51:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 177561B2A7C; Mon, 7 Jul 2014 23:51:05 -0700 (PDT)
Received: by with SMTP id et14so6804264pad.35 for <multiple recipients>; Mon, 07 Jul 2014 23:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iMrNdtC2pvLNUMzQ3rqk6tcHLFXFgJ/KOq7youYTCjk=; b=pN3nhQyEqgeOpfkMLGXYoPJJ/s1TV1NZoHflQJ4/kxUBXBPTu4EVqz2vD7PZr1w73n Z5v+yE7B8gRcVMsEHPtJOVfdVr649uW26Q4ghstx0cPRPz26QV6nypU0gIHOMzieG3MZ lidKyKQ3ue+SGpBxsYwqLIep8w84kwFp19Mw5XiCKsqN8cQ5MbV/4KgmxgTmfAzlWTL6 SphyVcSG2E3IZzVX2JkFti/UfYXgKpSCIq+jyXmHf79y9M4IJ7CKYpsc2OolB/bS7o5H +kOgl1/YV7GNu0iYcf/VOEZdaD3Uyi8J1stByHxd4GoOW2+1bmKtKezeXa3ma0p8lAzd ic9Q==
X-Received: by with SMTP id fx5mr7810534pbb.118.1404802264655; Mon, 07 Jul 2014 23:51:04 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id pq3sm54663245pbb.57.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 23:51:03 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_296B2C4B-DAAA-46F7-9B5C-E3D5DDC8A7D6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Lance Stout <>
In-Reply-To: <>
Date: Mon, 7 Jul 2014 23:51:01 -0700
Message-Id: <>
References: <> <>
To: Jari Arkko <>
X-Mailer: Apple Mail (2.1878.2)
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 06:51:07 -0000

> 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. 

> 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.

— Lance