From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3994.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc3994.txt (limited to 'doc/rfc/rfc3994.txt') 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 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 + 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 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 element, with a mandatory + element indicating the composer state; i.e., idle or active. + In addition, there are three optional elements: , + indicating the time of last activity; , the type of + message being created; and , 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 element describes the absolute time when + the user last added or edited content. + + The optional 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 + + + + active + text/plain + 90 + + + + + idle + 2003-01-27T10:43:00Z + audio + + +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 + + + + + + + + + + + + + + + + +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 + + + + + + Is-composing Indication for Instant Messaging + + +

Namespace for SIMPLE iscomposing extension

+

urn:ietf:params:xml:ns:im-composing

+

See RFC3994.

+ + + 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] + -- cgit v1.2.3