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

Mary Barnes <> Fri, 10 January 2014 22:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 934DC1AC4A7 for <>; Fri, 10 Jan 2014 14:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GLvpbo_0yEZY for <>; Fri, 10 Jan 2014 14:59:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22b]) by (Postfix) with ESMTP id A49B81A8031 for <>; Fri, 10 Jan 2014 14:59:08 -0800 (PST)
Received: by with SMTP id k14so4707429wgh.10 for <>; Fri, 10 Jan 2014 14:58:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ymRBS3stbyXdxYIJlQH4z21XC64Z7yLuMGYpHz78ns=; b=af9xrijYEGJXkuifJTbooPJ78wGznHRaTEfotCb0MOs9aii8NqbJKezAYSf1vXtFNC oUIR0ZQbY5ub8GDB8WyZJTBXUKjVSGfc7NlBVCnUIomURbjmG59FFxI7L80MNVTT4vJL xPc/sZt3K0Y86izS1zTRh3X9ncGQPTyxZ0qrf92iuYuSQ9tn2IYpwiIxtm/H5lY8Fciw fy/FXIbs8vuC8nWaGH9452kql4ZBhSKAxiv2INL1TyBCOP1nQFTOlRjvgbEUItZpA7na wXywcVukgdRcsJAgzWRLEjQ8A1vbg2kYXncs9BGAcHDV68rLvmwV1zoh2zAZhUmlL64W LNqw==
MIME-Version: 1.0
X-Received: by with SMTP id g4mr15195wjy.85.1389394738090; Fri, 10 Jan 2014 14:58:58 -0800 (PST)
Received: by with HTTP; Fri, 10 Jan 2014 14:58:57 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 10 Jan 2014 16:58:57 -0600
Message-ID: <>
From: Mary Barnes <>
Content-Type: multipart/alternative; boundary=047d7bea41fed1166304efa5ab96
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: Fri, 10 Jan 2014 22:59:11 -0000

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

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
> Abstract:
>    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
>    4976.
> 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:
> or