tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4975

 
 
 

The Message Session Relay Protocol (MSRP)

Part 4 of 4, p. 55 to 63
Prev RFC Part

 


prevText      Top      Up      ToC       Page 55 
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:

Top      Up      ToC       Page 56 
      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.

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
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

Top      Up      ToC       Page 59 
   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.

Top      Up      ToC       Page 60 
   [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.

Top      Up      ToC       Page 61 
   [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.

Top      Up      ToC       Page 62 
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

Top      Up      ToC       Page 63 
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.