RFC 4975
The Message Session Relay Protocol (MSRP)
15. IANA Considerations
This specification instructs IANA to create a new registry for MSRP parameters. The MSRP Parameter registry is a container for sub- registries. This section further introduces sub-registries for MSRP method names, status codes, and header field names. Additionally, Section 15.4 through Section 15.7 register new parameters in existing IANA registries.15.1. MSRP Method Names
This specification establishes the Methods sub-registry under MSRP Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). SEND - [RFC4975] REPORT - [RFC4975] The following information MUST be provided in an RFC publication in order to register a new MSRP method: o The method name. o The RFC number in which the method is registered.15.2. MSRP Header Fields
This specification establishes the header field-Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined as follows:
To-Path - [RFC4975]
From-Path - [RFC4975]
Message-ID - [RFC4975]
Success-Report - [RFC4975]
Failure-Report - [RFC4975]
Byte-Range - [RFC4975]
Status - [RFC4975]
The following information MUST be provided in an RFC publication in
order to register a new MSRP header field:
o The header field name.
o The RFC number in which the method is registered.
15.3. MSRP Status Codes
This specification establishes the Status-Code sub-registry under
MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor
submission). Its initial population is defined in Section 10. It
takes the following format:
Code [RFC Number]
The following information MUST be provided in an RFC publication in
order to register a new MSRP status code:
o The status code number.
o The RFC number in which the method is registered.
15.4. MSRP Port
MSRP uses TCP port 2855, from the "registered" port range. Usage of
this value is described in Section 6.
15.5. URI Schema
This document requests permanent registration the URI schemes of
"msrp" and "msrps".
15.5.1. MSRP Scheme
URI Scheme Name: "msrp"
URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in
Section 9 of RFC 4975.
URI Scheme Semantics: See Section 6 of RFC 4975.
Encoding Considerations: See Section 6 of RFC 4975.
Applications/Protocols that use this URI Scheme: The Message Session
Relay Protocol (MSRP).
Interoperability Considerations: MSRP URIs are expected to be used
only by implementations of MSRP. No additional interoperability
issues are expected.
Security Considerations: See Section 14.1 of RFC 4975 for specific
security considerations for MSRP URIs, and Section 14 of RFC 4975
for security considerations for MSRP in general.
Contact: Ben Campbell (ben@estacado.net).
Author/Change Controller: This is a permanent registration request.
Change control does not apply.
15.5.2. MSRPS Scheme
URI Scheme Name: "msrps"
URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in
Section 9 of RFC 4975.
URI Scheme Semantics: See Section 6 of RFC 4975.
Encoding Considerations: See Section 6 of RFC 4975.
Applications/Protocols that use this URI Scheme: The Message Session
Relay Protocol (MSRP).
Interoperability Considerations: MSRP URIs are expected to be used
only by implementations of MSRP. No additional interoperability
issues are expected.
Security Considerations: See Section 14.1 of RFC 4975 for specific
security considerations for MSRP URIs, and Section 14 of RFC 4975
for security considerations for MSRP in general.
Contact: Ben Campbell (ben@estacado.net).
Author/Change Controller: This is a permanent registration request.
Change control does not apply.
15.6. SDP Transport Protocol
MSRP defines the new SDP protocol field values "TCP/MSRP" and "TCP/
TLS/MSRP", which should be registered in the sdp-parameters registry
under "proto". This first value indicates the MSRP protocol when TCP
is used as an underlying transport. The second indicates that TLS
over TCP is used.
Specifications defining new protocol values must define the rules for
the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/
MSRP" protocol values allow only one value in the format field (fmt),
which is a single occurrence of "*". Actual format determination is
made using the "accept-types" and "accept-wrapped-types" attributes.
15.7. SDP Attribute Names
This document registers the following SDP attribute parameter names in the sdp-parameters registry. These names are to be used in the SDP att-name field.15.7.1. Accept Types
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-types Long-form Attribute Name: Acceptable media types Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-types" attribute contains a list of media types that the endpoint is willing to receive. It may contain zero or more registered media-types, or "*" in a space-delimited string.15.7.2. Wrapped Types
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: accept-wrapped-types Long-form Attribute Name: Acceptable media types Inside Wrappers Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "accept-wrapped-types" attribute contains a list of media types that the endpoint is willing to receive in an MSRP message with multipart content, but may not be used as the outermost type of the message. It may contain zero or more registered media-types, or "*" in a space-delimited string.15.7.3. Max Size
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: max-size Long-form Attribute Name: Maximum message size Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: The "max-size" attribute indicates the largest message an endpoint wishes to accept. It may take any whole numeric value, specified in octets.15.7.4. Path
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: path Long-form Attribute Name: MSRP URI Path Type: Media level
Subject to Charset Attribute: No
Purpose and Appropriate Values: The "path" attribute indicates a
series of MSRP devices that must be visited by messages sent in
the session, including the final endpoint. The attribute contains
one or more MSRP URIs, delimited by the space character.
16. Contributors and Acknowledgments
In addition to the editors, the following people contributed
extensive work to this document: Chris Boulton, Paul Kyzivat, Orit
Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert
Sparks.
The following people contributed substantial discussion and feedback
to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson,
Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi,
Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
17. References
17.1. Normative References
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[9] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, August 1997. [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [18] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.17.2. Informative References
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. [20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, October 2006. [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Session Relay Protocol (MSRP)", RFC 4976, September 2007. [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [25] Jennings, C., Peterson, J., and J. Fischl, "Certificate Management Service for SIP", Work in Progress, July 2007. [26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [27] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001. [29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004. [30] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. [31] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [32] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
Authors' Addresses
Ben Campbell (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 USA EMail: ben@estacado.net Rohan Mahy (editor) Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA EMail: rohan@ekabal.com Cullen Jennings (editor) Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 421-9990 EMail: fluffy@cisco.com
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.