70 likes | 200 Vues
This document outlines significant changes made to the MSRP Base and Relay protocols as discussed in IETF 62. Key modifications include enhancements to SDP for improved usability, updated response codes, and revised URI structures for better state management. Security considerations are emphasized, particularly regarding the use of TLS for authentication. The document also introduces clearer definitions for commands and reorganizes content for improved understanding. These updates aim to align more closely with conventional SDP usage while maintaining robust security practices.
E N D
MSRP - Base & Relay IETF 62 - Simple WG Ben Campbell Cullen Jennings
Changes to MSRP Base • SDP Changes • Followed strong advice of mmusic chairs • Attempt to be more inline with “conventional” SDP usage • Protocol field changed to msrp/tcp • Address and port copied to “c=“ and “m=“ lines • MSRP devices still get address and port from Path attribute--no real change. • Reference changed to SDP-New
New Response Codes • 408 -- Timeout • 413 -- Stop sending message • 423 -- Parameter out of bounds
Miscellaneous • Report-Success, Report-Failure changed to Success-Report and Failure-Report to ease parsing • Allow "+”, "=”, and "/” in session-id part of URI--makes it easier to embed base64 encoded state • More security consideration language about TLS implications of running peer-to-peer vs. with relays • Cleaned up IANA consideration section • Various editorial fixes
Changes to MSRP RelayDigest Changed to Basic • The AUTH commands return a shared secret in the form of the relay URI • This cannot be revealed to attackers so the AUTH MUST be done over TLS • Inside TLS, basic is as strong as digest and easier and faster as there is no challenge • OK ?????
Other Changes to Relay • Add Max-Expires • Better explanation of multi relay AUTH • Reorganization of document • Made SDP, Response Codes, and URI consistent with base draft
Stateless Relay Implementation • Appendix A has non normative text that explains one way that a relay can push most of its state to the client • Should we delete this or leave it?