doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3994.txt b/doc/rfc/rfc3994.txt
new file mode 100644
index 0000000..e3c78d8
--- /dev/null
+++ b/doc/rfc/rfc3994.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                     H. Schulzrinne
+Request for Comments: 3994                                   Columbia U.
+Category: Standards Track                                   January 2005
+
+
+        Indication of Message Composition for Instant Messaging
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In instant messaging (IM) systems, it is useful to know during an IM
+   conversation whether the other party is composing a message; e.g.,
+   typing or recording an audio message.  This document defines a new
+   status message content type and XML namespace that conveys
+   information about a message being composed.  The status message can
+   indicate the composition of a message of any type, including text,
+   voice, or video.  The status messages are delivered to the instant
+   messaging recipient in the same manner as the instant messages
+   themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 1]
+
+RFC 3994                      isComposing                   January 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology and Conventions  . . . . . . . . . . . . . . . . .  3
+   3.  Description  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
+       3.2.  Message Composer Behavior  . . . . . . . . . . . . . . .  4
+       3.3.  Status Message Receiver Behavior . . . . . . . . . . . .  5
+       3.4.  Message Content  . . . . . . . . . . . . . . . . . . . .  6
+       3.5.  Additional Status Information  . . . . . . . . . . . . .  6
+   4.  Using the Status Message . . . . . . . . . . . . . . . . . . .  7
+   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  XML Document Format  . . . . . . . . . . . . . . . . . . . . .  8
+       6.1.  XML Schema . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+       8.1.  Content-Type Registration for
+             'application/im-iscomposing+xml' . . . . . . . . . . . . 10
+       8.2.  URN Sub-Namespace Registration for
+             'urn:ietf:params:xml:ns:im-iscomposing'  . . . . . . . . 11
+       8.3.  Schema Registration  . . . . . . . . . . . . . . . . . . 11
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+       10.1. Normative References . . . . . . . . . . . . . . . . . . 12
+       10.2. Informative References . . . . . . . . . . . . . . . . . 12
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
+
+1.  Introduction
+
+   By definition, instant messaging (IM) is message based:  A user
+   composes a message by, for example, typing, speaking, or recording a
+   video clip.  This message is then sent to one or more recipients.
+   Unlike email, instant messaging is often conversational, so the other
+   party is waiting for a response.  If no response is forthcoming, a
+   participant in an instant messaging conversation may erroneously
+   assume either that the communication partner has left or that it is
+   her turn to type again, leading to two messages "crossing on the
+   wire".
+
+   To avoid this uncertainty, a number of commercial instant messaging
+   systems feature an "is-typing" indication sent as soon as one party
+   starts typing a message.  In this document, we describe a generalized
+   version of this indication, called the isComposing status message.
+   As described in Section 3 in more detail, a status message is
+   delivered to the instant message recipient in the same manner as are
+   the messages themselves.  The isComposing status messages can
+   announce the composition of any media type, not just text.  For
+
+
+
+Schulzrinne                 Standards Track                     [Page 2]
+
+RFC 3994                      isComposing                   January 2005
+
+
+   example, it might be used if somebody is recording an audio or video
+   clip.  In addition, it can be extended to convey other instant
+   messaging user states in the future.  Below, we will call these
+   messages "status messages" for brevity.
+
+   The status messages are carried as XML, as instances of the XML
+   schema defined in Section 6, and labeled as an
+   application/im-iscomposing+xml content type.
+
+   These status messages can be considered somewhat analogous to the
+   comfort noise packets that are transmitted in silence-suppressed
+   interactive voice conversations.
+
+      Events and extensions to presence, such as PIDF [6], were also
+      considered but have a number of disadvantages.  They add more
+      overhead, as an explicit and periodic subscription is required.
+      For page-mode delivery, subscribing to the right user agent and
+      set of messages may not be easy.  An in-band, message-based
+      mechanism is also easier to translate across heterogeneous instant
+      messaging systems.
+
+   The mechanism described here aims to satisfy the requirements in [7].
+
+2.  Terminology and Conventions
+
+   This memo makes use of the vocabulary defined in the IMPP Model
+   document [1].  In this memo, terms such as CLOSED, INSTANT MESSAGE,
+   OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT
+   are used with the same meaning defined therein.  The key words MUST,
+   MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
+   OPTIONAL in this document are to be interpreted as described in BCP
+   14, RFC 2119 [2].
+
+   This document discusses two kinds of messages; namely, the instant
+   message (IM) conveying actual content between two or more users
+   engaged in an instant messaging conversation, and the status message,
+   described in this document, which indicates the current composing
+   status to the other participants in a conversation.  We use the terms
+   "content message" and "status message" for these two message types.
+
+3.  Description
+
+3.1.  Overview
+
+   We model the user of an instant messaging system as being in one of
+   several states, in this document limited to "idle" and "active".  By
+   default, the user is in "idle" state, both before starting to compose
+   a message and after sending it.
+
+
+
+Schulzrinne                 Standards Track                     [Page 3]
+
+RFC 3994                      isComposing                   January 2005
+
+
+3.2.  Message Composer Behavior
+
+   Only the instant messaging user agent actively composing a content
+   message generates status messages indicating the current state.  When
+   the user starts composing a content message (the actual instant
+   message), the state becomes "active", and an isComposing status
+   message containing a <state> element indicating "active" is sent to
+   the recipient of the content message being composed.  As long as the
+   user continues to produce instant message content, the user remains
+   in state "active".
+
+   There are two sender timers: the active-state refresh interval, and
+   the idle time-out interval.
+
+   The active-state refresh interval determines how often "active" state
+   messages are sent while the composer remains in "active" state.  The
+   interval is chosen by the composing user and indicated in the
+   <refresh> element in the status message, expressed in integer
+   seconds.  Each transmission of the isComposing message resets the
+   timer.  The interval SHOULD be no shorter than 60 seconds.  A message
+   composer MAY decide not to send active-state refresh messages at all.
+   This is indicated by omitting the refresh interval; this will cause
+   the receiver to assume that it has gone idle after 120 seconds.  (In
+   most cases, the content message will have been sent by then.)  No
+   refresh messages are sent in "idle" state.
+
+      The active-state refresh mechanism deals with the case in which
+      the user logs off or the application crashes before the content
+      message is completed.
+
+   If the user stops composing for more than a configured time interval,
+   the idle timeout, the state transitions to "idle", and an "idle"
+   status message is sent.  If the user starts composing again while in
+   "idle" state, the state transitions to "active", and the
+   corresponding status message is sent.  Unless otherwise configured by
+   the user, the idle timeout SHOULD have a default value of 15 seconds.
+
+   If a content message is sent before the idle threshold expires, no
+   "idle" state indication is needed.  Thus, in most cases, only one
+   status message is generated for each content message.  In any event,
+   the message rate is limited to one status message per refresh
+   threshold interval.
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 4]
+
+RFC 3994                      isComposing                   January 2005
+
+
+   The state transitions are shown in Figure 1.
+
+                      +-------------+
+                      |+-----------+|
+                      ||           ||
+               +------>|   idle    |<--------+
+               |      ||           ||        |
+               |      |+-----------+|        |
+               |      +------+------+        |
+   content     |             |               | idle timeout
+   msg. sent   |             | composing     | w/o activity
+   ----------- |             | ------------- | ------------------
+    --         |             | "active" msg. | "idle" status msg.
+               |             |               |
+               |      +------V------+        |
+               |      |             |        |
+               |      |             |        |
+               |      |             |        |
+               +------+   active    +--------+
+                      |             |
+                      |             |------+
+                      +------^------+      | refresh timeout
+                             |             | --------------------
+                             |             | "active" status msg.
+                             +-------------+
+
+                   Figure 1. Sender State Diagram
+
+3.3.  Status Message Receiver Behavior
+
+   The status message receiver uses the status messages to determine the
+   state of the content message sender.  If the most recent "active"
+   status message contained a <refresh> value, the refresh time-out is
+   set to that value; otherwise, it is 120 seconds.  The state at the
+   receiver transitions from "active" to "idle" under three conditions:
+
+      1.  A status message with status "idle" is received.
+      2.  A content message is received.
+      3.  The refresh interval expires.
+
+   Receivers MUST be able to handle multiple consecutive isComposing
+   messages with "active" state, regardless of the refresh interval.
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 5]
+
+RFC 3994                      isComposing                   January 2005
+
+
+   The state transitions are shown in Figure 2.
+
+                           +-------------+
+                           |+-----------+|
+                           ||           ||
+                    +------>|   idle    |<------+
+                    |      ||           ||      |
+                    |      |+-----------+|      |
+                    |      +------+------+      |
+                    |             |             |
+       "idle" recd. |             |"active" msg.| refresh timeout
+   or content recd. |             |             | or 120s
+                    |             |             |
+                    |      +------V------+      |
+                    |      |             |      |
+                    |      |             |      |
+                    |      |             |      |
+                    +------+   active    +------+
+                           |             |
+                           |             |
+                           +-------------+
+
+                 Figure 2. Receiver State Diagram
+
+3.4.  Message Content
+
+   We briefly describe the message content to summarize the discussion
+   above.  This description is non-normative.  The schema (Section 6)
+   should be consulted for the normative message format.
+
+   The message consists of an <isComposing> element, with a mandatory
+   <state> element indicating the composer state; i.e., idle or active.
+   In addition, there are three optional elements: <lastactive>,
+   indicating the time of last activity; <contenttype>, the type of
+   message being created; and <refresh>, the time interval after which
+   the receiver can expect an update from the composer.  Details are
+   given in the following section.
+
+3.5.  Additional Status Information
+
+   The status message contains additional optional elements to provide
+   further details on the composition activity.  Any of these can appear
+   in both "active" and "idle" state messages.
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 6]
+
+RFC 3994                      isComposing                   January 2005
+
+
+   The optional <lastactive> element describes the absolute time when
+   the user last added or edited content.
+
+   The optional <contenttype> element indicates the type of medium in
+   which the messaging terminal is currently composing.  It can contain
+   either just a MIME media type, such as "audio" or "text", or a media
+   type and subtype, such as "text/html".  It is best understood as a
+   hint to the user, not a guarantee, that the actual content message
+   will indeed contain only the content indicated.  It allows the human
+   recipient to be prepared for the likely message format.
+
+   To further describe message composition, the XML schema or the set of
+   allowable state names can be extended in future documents.
+   Recipients of status messages implementing this specification without
+   extensions MUST treat state tokens other than "idle" and "active" as
+   "idle".  Additional elements MUST use their own namespaces and MUST
+   be designed so that receivers can safely ignore such extensions.
+   Adding elements to the namespace defined in this document is not
+   permitted.
+
+   The isComposing status message MAY be carried in CPIM messages [3].
+
+      Such a wrapper is particularly useful if messages are relayed by a
+      conference server since the CPIM message maintains the identity of
+      the original composer.
+
+4.  Using the Status Message
+
+   The isComposing status message can be used with either page mode or
+   session mode, although session mode is a more natural fit.  In
+   session mode, the status message is sent as part of the messaging
+   stream.  Its usage is negotiated just like any other media type in
+   that stream, with details depending on the session mode protocol.
+
+   Sending the status messages within the session-mode messaging stream
+   has at least three benefits.  First, it ensures proper ordering and
+   synchronization with the actual content messages being composed.  In
+   messaging systems that guarantee in-order delivery of messages, this
+   approach avoids having an active indication appear at the receiver
+   after the actual message has been delivered, due to message
+   reordering across two delivery mechanisms.
+
+   Secondly, end-to-end security can be applied to the messages.
+   Thirdly, session negotiation mechanisms can be used to turn it on and
+   off at any time, and even to negotiate its use in a single direction
+   at a time.
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 7]
+
+RFC 3994                      isComposing                   January 2005
+
+
+   Usage with page mode is also straightforward: The status message is
+   carried as the body of a page mode message.  In SIP-based IM, The
+   composer MUST cease transmitting status messages if the receiver
+   returned a 415 status code (Unsupported Media Type) in response to a
+   MESSAGE request containing the status indication.
+
+   The sender cannot be assured that the status message is delivered
+   before the actual content being composed arrives.  However, SIP page
+   mode is limited to one unacknowledged message, so out-of-order
+   delivery is unlikely, albeit still possible if proxies are involved.
+
+5.  Examples
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
+   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
+   iscomposing.xsd">
+     <state>active</state>
+     <contenttype>text/plain</contenttype>
+     <refresh>90</refresh>
+   </isComposing>
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
+   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+   xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
+   iscomposing.xsd">
+     <state>idle</state>
+     <lastactive>2003-01-27T10:43:00Z</lastactive>
+     <contenttype>audio</contenttype>
+   </isComposing>
+
+6.  XML Document Format
+
+   An isComposing document is an XML document that MUST be well formed
+   and SHOULD be valid.  isComposing documents MUST be based on XML 1.0
+   and MUST be encoded by using UTF-8.  This specification makes use of
+   XML namespaces for identifying isComposing documents.  The namespace
+   URI for elements defined for this purpose is a URN using the
+   namespace identifier 'ietf'.  This URN is:
+
+      urn:ietf:params:xml:ns:im-iscomposing
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 8]
+
+RFC 3994                      isComposing                   January 2005
+
+
+6.1.  XML Schema
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing"
+     elementFormDefault="qualified"
+     attributeFormDefault="unqualified"
+     xmlns:xs="http://www.w3.org/2001/XMLSchema"
+     xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing">
+     <xs:element name="isComposing">
+       <xs:complexType>
+         <xs:sequence>
+           <xs:element name="state" type="xs:string"/>
+           <xs:element name="lastactive" type="xs:dateTime"
+             minOccurs="0"/>
+           <xs:element name="contenttype" type="xs:string"
+             minOccurs="0"/>
+           <xs:element name="refresh" type="xs:positiveInteger"
+             minOccurs="0"/>
+           <xs:any namespace="##other" processContents="lax"
+             minOccurs="0" maxOccurs="unbounded"/>
+         </xs:sequence>
+       </xs:complexType>
+     </xs:element>
+   </xs:schema>
+
+7.  Security Considerations
+
+   The isComposing indication provides a fine-grained view of the
+   activity of the entity composing and thus deserves particularly
+   careful confidentiality protection so that only the intended
+   recipient of the message will receive the isComposing indication.
+
+   Since the status messages are carried by using the IM protocol
+   itself, all security considerations of the underlying IM protocol
+   also apply to the isComposing status messages.
+
+   There are potential privacy issues in sending isComposing status
+   messages before an actual conversation has been established between
+   the communicating users.  A status message may be sent even if the
+   user later abandons the message.  It is RECOMMENDED that isComposing
+   indications in page mode are only sent when a message is being
+   composed as a reply to an earlier message.  This document does not
+   prescribe how an implementation detects whether a message is in
+   response to an earlier one in page mode, but elapsed time or user
+   interface behavior might be used as hints.
+
+
+
+
+
+
+Schulzrinne                 Standards Track                     [Page 9]
+
+RFC 3994                      isComposing                   January 2005
+
+
+8.  IANA Considerations
+
+8.1.  Content-Type Registration for 'application/im-iscomposing+xml'
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/
+      im-iscomposing+xml
+   MIME media type name: application
+   MIME subtype name: im-iscomposing+xml
+   Required parameters: (none)
+   Optional parameters: charset; Indicates the character encoding of
+      enclosed XML.  Default is UTF-8.
+   Encoding considerations: Uses XML, which can employ 8-bit characters,
+      depending on the character encoding used.  See RFC 3023 [4],
+      section 3.2.
+   Security considerations: This content type is designed to carry
+      information about current user activity, which may be considered
+      private information.  Appropriate precautions should be adopted to
+      limit disclosure of this information.
+   Interoperability considerations: This content type provides a common
+      format for exchange of composition activity information.
+   Published specification: RFC 3994
+   Applications which use this media type: Instant messaging systems.
+   Additional information: none
+   Person & email address to contact for further information: Henning
+      Schulzrinne, hgs@cs.columbia.edu
+   Intended usage: LIMITED USE
+   Author/Change controller: This specification is a work item of the
+      IETF SIMPLE working group, with the mailing list address
+      simple@ietf.org.
+   Other information: This media type is a specialization of
+      application/xml RFC 3023 [4], and many of the considerations
+      described there also apply to application/im-iscomposing+xml.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 10]
+
+RFC 3994                      isComposing                   January 2005
+
+
+8.2.  URN Sub-Namespace Registration for
+      'urn:ietf:params:xml:ns:im-iscomposing'
+
+   URI: urn:ietf:params:xml:ns:im-iscomposing
+   Description: This is the XML namespace for XML elements defined by
+      RFC 3994 to describe composition activity by an instant messaging
+      client using the application/im-iscomposing+xml content type.
+   Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
+      Henning Schulzrinne, hgs@cs.columbia.edu
+   XML:
+
+    BEGIN
+      <?xml version="1.0"?>
+      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+      <html xmlns="http://www.w3.org/1999/xhtml">
+      <head>
+           <meta http-equiv="content-type"
+           content="text/html;charset=iso-8859-1"/>
+           <title>Is-composing Indication for Instant Messaging</title>
+      </head>
+      <body>
+          <h1>Namespace for SIMPLE iscomposing extension</h1>
+          <h2>urn:ietf:params:xml:ns:im-composing</h2>
+          <p>See <a href="[URL of published RFC]">RFC3994</a>.</p>
+       </body>
+       </html>
+      END
+
+8.3.  Schema Registration
+
+   This section registers a new XML schema per the procedures in [5].
+
+   URI: urn:ietf:params:xml:schema:im-composing
+   Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
+      Henning Schulzrinne (hgs@cs.columbia.edu).
+
+   The XML for this schema can be found as the sole content of Section
+   6.1.
+
+9.  Acknowledgements
+
+   Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson,
+   Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi,
+   Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 11]
+
+RFC 3994                      isComposing                   January 2005
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
+        Instant Messaging", RFC 2778, February 2000.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
+        (CPIM): Message Format", RFC 3862, August 2004.
+
+   [4]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC
+        3023, January 2001.
+
+   [5]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
+        2004.
+
+10.2.  Informative References
+
+   [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
+        J. Peterson, "Presence Information Data Format (PIDF)", RFC
+        3863, August 2004.
+
+   [7]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
+        Session Initiation Protocol  (SIP)", Work in Progress, February
+        2004.
+
+Author's Address
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   US
+
+   Phone: +1 212 939 7004
+   EMail: hgs@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu/~hgs
+
+
+
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 12]
+
+RFC 3994                      isComposing                   January 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 IETF's procedures with respect to rights in IETF 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Schulzrinne                 Standards Track                    [Page 13]
+