RFC 4569

Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag

πŸ“… published July 2006, from ietf

Network Working Group RFC 4569 πŸŽ€

Title: Internet Assigned Numbers Authority (IANA) Registration of the Message Media Feature Tag πŸ’–

Author: G. Camarillo (Gonzalo Camarillo), Ericsson ✨

Category: Informational πŸ“š

Date: July 2006 🌸

The header doesn't list anything this document obsoletes or updates. πŸ™ˆ


Status of This Memo 🫢

okay so this memo gives info to the Internet community. It does not specify an Internet standard of any kind, so no pressure, bestie. Distribution of this memo is unlimited. πŸ’…

Copyright (C) The Internet Society (2006). πŸ¦‹

Abstract 🧚

okay so this doc registers a brand new media feature tag with the IANA, and it's tied to the message media type. ✨ The tag says a device supports message as a streaming media type. Media feature tags are how you route calls to devices that support certain features, which is literally the main character energy of call routing. πŸ“žπŸ‘‘

Table of Contents πŸ“

   1. Introduction ....................................................2
   2. Security Considerations .........................................2
   3. IANA Considerations .............................................2
   4. Acknowledgements ................................................3
   5. Normative References ............................................3

1. Introduction 🌈

okay so the Session Description Protocol (SDP) spec [5] defines a bunch of media types. RFC 3840 [4] registered IANA media feature tags for all of those media types except message. This doc is the one that registers a new media feature tag for message. πŸ’œ

Why did RFC 3840 skip it? πŸ€” When RFC 3840 came out, the SDP spec was RFC 2327 [1]. RFC 3840 made media feature tags for every media type in RFC 2327, but RFC 2327 never defined message. That media type showed up later in the revised SDP spec [5], which was published after RFC 3840. So it's not that anyone forgot, the timing just didn't line up. 😭

2. Security Considerations πŸ”

Section 11.1 of RFC 3840 [4] covers the security considerations for using media feature tags. Go read it, it's giving serious. πŸ’€

3. IANA Considerations πŸ“‹

This spec registers a new media feature tag in the SIP [3] tree, following the procedures in RFC 2506 [2] and RFC 3840 [4]. ✨ Here's the registration, verbatim:

   Media feature tag name: sip.message

   ASN.1 Identifier: 21

   Summary of the media feature indicated by this tag: This feature
   tag indicates that the device supports message as a streaming
   media type.

   Values appropriate for use with this feature tag: Boolean.

   The feature tag is intended primarily for use in the following
   applications, protocols, services, or negotiation mechanisms: This
   feature tag is most useful in a communications application for
   describing the capabilities of a device, such as a phone or PDA.

   Examples of typical use: Routing a call to a phone that can
   support session-based instant messaging.

   Related standards or documents: RFC 4569.

   Security Considerations: Security considerations for this media
   feature tag are discussed in Section 11.1 of RFC 3840.

4. Acknowledgements 🫢

The need for this registration got talked through with Jonathan Rosenberg, Colin Perkins, and Jon Peterson. Thank you, besties. πŸ’–

5. Normative References πŸ“š

  • [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  • [2] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
  • [3] 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.
  • [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
  • [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

Author's Address 🏑

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com

Copyright (C) The Internet Society (2006).

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 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 on 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 on whether any license under such rights might or might not be available. It also doesn't say it has made any independent effort to identify such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79. πŸ“œ

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this spec can be found in 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 needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. πŸ’Œ

Acknowledgement 🌸

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). πŸ’œ

πŸ“¦ where this page comes from