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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 02 July 2014 13:00 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 557751A00E7; Wed, 2 Jul 2014 06:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MweuvzPB2Mb2; Wed, 2 Jul 2014 06:00:24 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0D41A00AB; Wed, 2 Jul 2014 06:00:23 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.01,587,1400040000"; d="scan'208,217"; a="63390369"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Jul 2014 09:00:20 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 02 Jul 2014 08:40:39 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 15:00:18 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: Gen-ART review for draft-ietf-xmpp-websocket-07
Thread-Index: Ac+V9YqRw3Q1VXAJQcaxdgarBYq69g==
Date: Wed, 2 Jul 2014 13:00:17 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C823BB2@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C823BB2AZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VIYb6vFPuTZZfInLoZYJx0xPvg0
X-Mailman-Approved-At: Thu, 03 Jul 2014 08:07:04 -0700
Cc: "draft-ietf-xmpp-websocket.all@tools.ietf.org" <draft-ietf-xmpp-websocket.all@tools.ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>
Subject: [xmpp] 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: Wed, 02 Jul 2014 13:00:26 -0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments you may receive.

Document: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

Reviewer: Dan Romascanu

Review Date: 7/2/2014

IETF LC End Date: 7/4/2014

IESG Telechat date: 7/10/2014

Summary: ready with minor issues

Major issues:


Minor issues:

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


              I am wondering whether it would not be appropriate to reflect this in the document header by adding Updates 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


        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.

Nits/editorial comments:

In Section 3.1 I believe that the example should be preceded by some text that indicates that this is an example, such as: 'An example of a successful handshake and start of session follows:'