Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Feb 2013 16:23:45 -0600

Hi,

(I apologize for just getting to this now (usual excuses apply). I hope to avoid rehashing things already brought up, but if I fail in that, further apologies.)

I think this work is interesting, and I support it. I do have some concerns (that seem to pop up whenever adapting a protocol to ws is concerned):

** Major:

-- General: Interworking with legacy relays and endpoints:

I infer that an MSRP WebSocket Server is expected to also act as an ordinary MSRP relay, in that it can talk to legacy relays and clients. Is there a normative requirement for that that I missed? Is it allowed to have an MSRP WebSocket server that only enables communication between WebSocket Clients?

-- Use of TLS:

I'm very concerned about downgrading the 4976 MUST on use of TLS between a client and a relay that it authenticates to. This seems unacceptable on it's face. You indicate that the client code may have no control over this--can you elaborate?

** Minor:

-- 5.1:

Be careful with the terminology. In MSRP, a "message" means the pre-chunked content. If you split it, each piece is a "chunk". I think you mean to say that each WebSocket message must contain a single MSRP "chunk", correct?

Also, are there issues with large chunks? Does the MSRP concept of starting to send large content in a single chunk, but interrupting it if needed work with WebSockets?

-- 7:

Can you offer guidance on what should happen if a server tries to use HTTP Digest at the MSRP layer, but the client doesn't support it? (The reciprocal of "MAY" us usually "MUST". That is, if a device MAY do something, the peer MUST gracefully handle it.)

-- 9.1:

I'd like to see some guidance about server certificate matching. Do the rules in 4976 and 4975 still apply?

On Dec 17, 2012, at 4:29 PM, Victor Pascual Avila <[email-masked]> wrote:

> Dear DISPATCH,
> 
> comments on the draft below[1] would be appreciated. The proposed mechanism has been implemented and there's open-source code available for both client[2] and server[3] side implementations.
> 
> [1] http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> [2] http://code.google.com/p/crocodile-msrp/wiki/Overview
> [3] http://www.kamailio.org/wiki/features/new-in-devel#websocket
> 
> Thanks,
> Peter, Gavin and Victor
> 
> On 12/17/12 5:15 PM, "[email-masked]" <[email-masked]>
> wrote:
> 
> >
> >A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt
> >has been successfully submitted by Peter Dunkley and posted to the
> >IETF repository.
> >
> >Filename:       draft-pd-dispatch-msrp-websocket
> >Revision:       00
> >Title:          The WebSocket Protocol as a Transport for the Message Session
> >Relay Protocol (MSRP)
> >Creation date:  2012-12-17
> >WG ID:          Individual Submission
> >Number of pages: 19
> >URL:
> >http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-00.tx
> >t
> >Status:
> >http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
> >Htmlized:
> >http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> >
> >
> >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 Secretariat
> >
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Feb 2013 16:27:38 -0600

On Jan 7, 2013, at 11:28 AM, Peter Dunkley <[email-masked]> wrote:

>> - Section 6: maybe it should be mentioned that in the absence of a WS pint mechanism the defined MSRP way (that is, an empty SEND) should be used?
>> 
>> 
> I will add this to the next issue of the draft.
> 
>> 

Am I correct in assuming the _initial_  (possible empty) MSRP send still applies? That has downstream implications if you have non-WebSocket clients and/or relays on the other end.

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 21 Feb 2013 22:40:10 +0000

Yes, the initial SEND still applies.  What are the downstream implications that you see?

Regards,

Peter

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Feb 2013 17:10:33 -0600

If the downstream peer is the passive party in the TCP connection, it uses the initial send to make sure the peer has knowledge of it's MSRP URI from the SDP offer/answer. A downstream relay uses the initial send to trigger connection setup.

Thanks!

Ben.