summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3994.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3994.txt')
-rw-r--r--doc/rfc/rfc3994.txt731
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]
+