Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Christer Holmberg <> Sat, 18 January 2014 08:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A289C1ADDBD for <>; Sat, 18 Jan 2014 00:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lIdwteLlTgp8 for <>; Sat, 18 Jan 2014 00:53:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 397251ADD9D for <>; Sat, 18 Jan 2014 00:53:04 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-05-52da40e2d4e6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A9.C4.23787.2E04AD25; Sat, 18 Jan 2014 09:52:50 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Sat, 18 Jan 2014 09:52:50 +0100
From: Christer Holmberg <>
To: Mary Barnes <>, DISPATCH <>
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNzng
Date: Sat, 18 Jan 2014 08:52:49 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D104D91ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje4jh1tBBj/+aFg0P/zFZrF00gJW i8tbPrNbfN6/n9mBxePx11msHjtn3WX3WLLkJ5PHl8uf2QJYorhsUlJzMstSi/TtErgy9syU KDg6m7Fi65t5zA2MD1oYuxg5OSQETCSOHn3CCmGLSVy4t56ti5GLQ0jgEKPE8u/LmCCcJYwS d3rmA1VxcLAJWEh0/9MGaRAR8JJ48fsDWA2zQA+jxL29E1hAEsIC3hJTlr9lhijykbi5/QAT hG0k8W3CVDYQm0VAVeJm30Mwm1fAV2Lv3P9Qy9oYJfq2L2YHSXAKBErc3XAWrJkR6Lzvp9aA 2cwC4hIfDl5nhjhbQGLJnvNQtqjEy8f/oN5Rklix/RIjRH2+xJbDJ6GWCUqcnPmEZQKj6Cwk o2YhKZuFpAwiridxY+oUNghbW2LZwtdQ9boSM/4dYkEWX8DIvoqRPTcxMye93HATIzACD275 rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg9JmuuTFP3cHx JdvEdfWs5Z9mLsgRNCn1YJj+UN/Dde/JVIcbnT/uaJw9sOVZXS3Xh60+bmenCPF3nfaIOau/ bEq57dfzK8zFe4XKF/F+dT7LE/siWs5nKvvaNRW8Wyduuv36WXTiUf/Jtev0V0u4tK66KfKP pzGxx06mrOOzw9pzxm4c8rmflViKMxINtZiLihMB4gSjQY4CAAA=
Cc: Ben Campbell <>, "" <>
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Jan 2014 08:53:08 -0000


I have not followed the work on this draft, so I appologize if the following has been discussed.

While I do understand that a WS Client has to establish the WebSocket with the Web Server, I don't understand why we need to mandate the WS Server to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.



Lähettäjä: dispatch [] Puolesta Mary Barnes
Lähetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell;
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions.  Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so.    This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments.  Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.


Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separating normative text from non-normative is quite so helpful.  In general, we expect that in the case of standards track document use RFC 2119 language to indicate normative behaviors.  I think the first sentence is good, but that's not a terminology thing.   I just don't see a lot of value in writing the document this way.  For example, the definitions aren't stated to be non-normative, but I don't see anything normative about the definitions.  I think you could easily title Section 3 as "WebSocket Protocol overview" and that would clearly imply non-normative behavior.  There are also several places in the document in sections that I believe are intended to provide normative behavior, but there is certainly non-normative text in those sections (e.g., section 5.2.2, second paragraph).  I would suggest this document follow the typical (and accepted) style of identifying normative behavior with 2119 language (consistently using upper case for normative behavior and avoiding using 2119 language in cases where alternative words can be substituted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear to me this is normative behavior.  I don't think it is since it's referring to existing 4975 behavior. However, I didn't see that the reference given in 4975 relates to the second part of that sentence stating that implementations "should" already be allowing unrecognized transports.  It would be quite useful to have the exact reference here as I was trying to double check this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would be non-normative.  In particular given that 2119 language is clearly being used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered non-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection?

6) Section 11.  You should change the name of the registry to be the exact name of the IANA registry to avoid any confusion.- i.e.,:
  registry of WebSocket sub-protocols
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I would suggest you use the same information as the pointer to the Subprotocol Definition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.

On Thu, Dec 12, 2013 at 6:57 PM, <<>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list<>
Internet-Draft directories: