1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc4569.txt b/doc/rfc/rfc4569.txt
new file mode 100644
index 0000000..1ac4188
--- /dev/null
+++ b/doc/rfc/rfc4569.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                       G. Camarillo
+Request for Comments: 4569                                      Ericsson
+Category: Informational                                        July 2006
+
+
+        Internet Assigned Numbers Authority (IANA) Registration
+                    of the Message Media Feature Tag
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document registers with the IANA a new media feature tag
+   associated with the 'message' media type.  This media feature tag
+   indicates that a particular device supports 'message' as a streaming
+   media type.  Media feature tags can be used to route calls to devices
+   that support certain features.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Security Considerations .........................................2
+   3. IANA Considerations .............................................2
+   4. Acknowledgements ................................................3
+   5. Normative References ............................................3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                    Informational                      [Page 1]
+
+RFC 4569                  Message Feature Tag                  July 2006
+
+
+1.  Introduction
+
+   The Session Description Protocol (SDP) specification [5] defines a
+   number of media types.  RFC 3840 [4] registers with the IANA media
+   feature tags associated with all those media types except for the
+   'message' media type.  This document registers a new media feature
+   tag that is associated with the 'message' media type.
+
+   The reason why the 'message' media feature tag was not registered by
+   RFC 3840 was that when RFC 3840 was published, the SDP specification
+   was RFC 2327 [1].  RFC 3840 defined media feature tags for all the
+   media types defined by RFC 2327.  However, RFC 2327 did not define
+   the 'message' media type.  This media type was defined by the revised
+   SDP specification [5], which was published after RFC 3840.
+
+2.  Security Considerations
+
+   Section 11.1 of RFC 3840 [4] discusses security considerations
+   related to the use of media feature tags.
+
+3.  IANA Considerations
+
+   This specification registers a new media feature tag in the SIP [3]
+   tree per the procedures defined in RFC 2506 [2] and RFC 3840 [4].
+
+      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.
+
+
+
+
+Camarillo                    Informational                      [Page 2]
+
+RFC 4569                  Message Feature Tag                  July 2006
+
+
+4.  Acknowledgements
+
+   The need for this registration was discussed with Jonathan Rosenberg,
+   Colin Perkins, and Jon Peterson.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                    Informational                      [Page 3]
+
+RFC 4569                  Message Feature Tag                  July 2006
+
+
+Full Copyright Statement
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Camarillo                    Informational                      [Page 4]
+