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

[Peter Dunkley <[e-mail]>]

Hi Christer,

There is working code for the document as-is and plans for more
implementations. I think that if someone has a need for MSRP-CEMA in this
scenario then they should join with the current authors to contribute the
text and working code for this.

Regards,

Peter


On 20 January 2014 03:28, Christer Holmberg
<[e-mail]>wrote:

>  Hi,
>
> I see no reason why it should be a separate document, as it should not have any affect on the websocket specific procedures, which is the main scope of the document.
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Peter Dunkley <[e-mail]> wrote:
>
>
>  Hello,
>
>  Perhaps the document title should be corrected. MSRP-CEMA is outside of
> the scope of this document as this document is intended to describe
> connecting to a WebSocket server that is an MSRP relay.
>
>  I can see no reason why MSRP-CEMA can't be used over WebSockets, but if
> anyone has an interest in this I think that they should put it in a
> document of its own.
>
>
>  Regards,
>
>  Peter
>
>
> On 18 January 2014 08:52, Christer Holmberg <
> [e-mail]> wrote:
>
>>  Hi,
>>
>>
>>
>> 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.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> *Lähettäjä:* dispatch [mailto:[e-mail]] *Puolesta *Mary
>> Barnes
>> *Lähetetty:* 11. tammikuuta 2014 0:59
>> *Vastaanottaja:* DISPATCH
>> *Kopio:* Ben Campbell; [e-mail]
>> *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.
>>
>>
>>
>> Regards,
>>
>> Mary.
>>
>>
>>
>> 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.,:
>>
>> OLD:
>>
>>   registry of WebSocket sub-protocols
>>
>> NEW:
>>
>>   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, <[e-mail]> 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:
>> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>
>
>
>  --
>  Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>



-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd