Hey, folks,
I've reviewed this draft (draft-pd-dispatch-msrp-websocket-13) as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other (belated) IETF last call comments, addressing them in conjunction with the present IESG review.
I've reviewed this draft (draft-pd-dispatch-msrp-websocket-13) as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other (belated) IETF last call comments, addressing them in conjunction with the present IESG review.
Summary: This draft specifies the WebSocket sub-protocol for MSRP, the SIP-based messaging protocol. It is very similar to RFC 7118, WebSocket as a Transport for SIP, which is already a PS. It does not appear to pose any transport-related danger, and is broadly ready for publication as a PS.
Although the draft looks ready to go from a transport point of view, I have a couple of small questions:
Section 5
Does the second sentence in the following mean "impossible for a WebSocket MSRP client to communicate directly with other MSRP clients"? The paragraph is confusing.
Does the second sentence in the following mean "impossible for a WebSocket MSRP client to communicate directly with other MSRP clients"? The paragraph is confusing.
WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is impossible for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server.
Section 8
bob.example.com:8145 occurs in many of the path examples. Although I notice it also occurs in the MSRP Relay RFC (4976) along with many other unassigned port numbers from the User Space, I wonder if it could be replaced with a port from the Dynamic space (49152-65535) - in this draft, it's the only unassigned port, and this could be one RFC that doesn't confuse port users IRL.
Thanks and good luck,
Allison