idnits 2.17.1 draft-ietf-simple-iscomposing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 579), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 311 has weird spacing: '...ding on the s...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 10, 2004) is 7199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 514, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '1') ** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Schulzrinne 2 Internet-Draft Columbia U. 3 Expires: February 8, 2005 August 10, 2004 5 Indication of Message Composition for Instant Messaging 6 draft-ietf-simple-iscomposing-03 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 8, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 In instant messaging (IM) systems, it is useful to know during an IM 39 conversation that the other party is composing a message, e.g., 40 typing or recording an audio message. This document defines a new 41 status message content type and XML namespace that conveys 42 information about a message being composed. The status message can 43 indicate the composition of a message of any type, including text, 44 voice or video. The status messages are delivered to the instant 45 messaging recipient in the same manner as the instant messages 46 themselves. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 52 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2 Message Composer Behavior . . . . . . . . . . . . . . . . 4 55 3.3 Status Message Receiver Behavior . . . . . . . . . . . . . 6 56 3.4 Message Content . . . . . . . . . . . . . . . . . . . . . 7 57 3.5 Additional Status Information . . . . . . . . . . . . . . 7 58 4. Using the Status Message . . . . . . . . . . . . . . . . . . . 8 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. XML Document Format . . . . . . . . . . . . . . . . . . . . . 9 61 6.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8.1 Content-Type Registration for 65 'application/im-iscomposing+xml' . . . . . . . . . . . . . 10 66 8.2 URN Sub-Namespace Registration for 67 'urn:ietf:params:xml:ns:im-iscomposing' . . . . . . . . . 11 68 8.3 Schema registration . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 72 10.2 Informative References . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . 14 76 1. Introduction 78 By definition, instant messaging (IM) is message-based: a user 79 composes a message by, for example, typing, speaking or recording a 80 video clip. This message is then sent to one or more recipients. 81 Unlike email, instant messaging is often conversational, so that the 82 other party is waiting for a response. If no response is 83 forthcoming, a participant in an instant messaging conversation may 84 erroneously assume that either the communication partner has left or 85 that it is her turn to type again, leading to two messages "crossing 86 on the wire". 88 To avoid this uncertainty, a number of commercial instant messaging 89 systems feature an "is-typing" indication that is sent as soon as one 90 party starts typing a message. In this document, we describe a 91 generalized version of this indication, called isComposing status 92 message. As described in Section 3 in more detail, a status message 93 is delivered to the instant message recipient in the same manner as 94 the messages themselves. The isComposing status messages can 95 announce the composition of any media type, not just text. For 96 example, it might be used if somebody is recording an audio or video 97 clip. In addition, it can be extended to convey other instant 98 messaging user states in the future. Below, we will call these 99 messages "status messages" for brevity. 101 The status messages are carried as XML, as instances of the XML 102 schema defined in Section 6 and labeled as an application/ 103 im-iscomposing+xml content type. 105 These status messages can be considered somewhat analogous to the 106 comfort noise packets that are transmitted in silence-suppressed 107 interactive voice conversations. 109 Events and extensions to presence, such as PIDF [7], were also 110 considered, but have a number of disadvantages. They add more 111 overhead, since an explicit and periodic subscription is required. 112 For page-mode delivery, subscribing to the right user agent and 113 set of messages may not be easy. An in-band, message-based 114 mechanism is also easier to translate across heterogeneous instant 115 messaging systems. 117 The mechanism described here aims to satisfy the requirements in [8]. 119 2. Terminology and Conventions 121 This memo makes use of the vocabulary defined in the IMPP Model 122 document [1]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE 123 SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in this memo are 124 used in the same meaning as defined therein. The key words MUST, 125 MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and 126 OPTIONAL in this document are to be interpreted as described in BCP 127 14, RFC 2119 [2]. 129 This document discusses two kinds of messages, namely the instant 130 message (IM) conveying actual content between two or more users 131 engaged in an instant messaging conversation, and the status message, 132 described in this document, that indicates the current composing 133 status to the other participants in a conversation. We use the terms 134 "content message" and "status message" for these two message types. 136 3. Description 138 3.1 Overview 140 We model the user of an instant messaging system as being in one of 141 several states, in this draft limited to "idle" and "active". By 142 default, the user is in "idle" state, both before starting to compose 143 a message and after sending it. 145 3.2 Message Composer Behavior 147 Only the instant messaging user agent actively composing a content 148 message generates status messages indicating the current state. When 149 the user first starts composing a content message (the actual instant 150 message), the state becomes "active" and an isComposing status 151 message containing a element indicating "active" is sent to 152 the recipient of the content message being composed. As long as the 153 user continues to produce instant message content, the user remains 154 in state "active". 156 There are two sender timers, the active-state refresh interval and 157 the idle time-out interval. 159 The active-state refresh interval determines how often "active" state 160 messages are sent while the composer remains in "active" state. The 161 interval is chosen by the composing user and indicated in the 162 element in the status message, expressed in integer 163 seconds. Each transmission of the isComposing message resets the 164 timer. The interval SHOULD be no shorter than 60 seconds. A message 165 composer MAY decide not to send active-state refresh messages at all. 166 It indicates that by omitting the refresh interval; this will cause 167 the receiver to assume that it has gone idle after 120 seconds. (In 168 most cases, the content message will have been sent by then.) No 169 refresh messages are sent in "idle" state. 171 The active-state refresh mechanism deals with the case that the 172 user logs off or the application crashes before the content 173 message is completed. 175 If the user stops composing for more than a configured time interval, 176 the idle timeout, the state transitions to "idle" and an "idle" 177 status message is sent. When the user starts composing again while 178 in "idle" state, the state transitions to "active", with the 179 corresponding status message being sent. Unless otherwise configured 180 by the user, the idle timeout SHOULD have a default value of 15 181 seconds. 183 If a content message is sent before the idle threshold expires, no 184 "idle" state indication is needed. Thus, in most cases, only one 185 status message is generated for each content message. In any event, 186 the message rate is limited to one status message per refresh 187 threshold interval. 189 The state transitions are shown in Figure 1. 191 +-------------+ 192 |+-----------+| 193 || || 194 +------>| idle |<--------+ 195 | || || | 196 | |+-----------+| | 197 | +------+------+ | 198 content | | | idle timeout 199 msg. sent | | composing | w/o activity 200 ----------- | | ------------- | ------------------ 201 -- | | "active" msg. | "idle" status msg. 202 | | | 203 | +------V------+ | 204 | | | | 205 | | | | 206 | | | | 207 +------+ active +--------+ 208 | | 209 | |------+ 210 +------^------+ | refresh timeout 211 | | -------------------- 212 | | "active" status msg. 213 +-------------+ 215 Sender state diagram 216 Figure 1 218 3.3 Status Message Receiver Behavior 220 The status message receiver uses the status messages to determine the 221 state of the content message sender. If the most recent "active" 222 status message contained a value, the refresh time-out is 223 set to that value; it is 120 seconds otherwise. The state at the 224 receiver transitions from "active" to "idle" under three conditions: 226 1. A status message with status "idle" is received. 227 2. A content message is received. 228 3. The refresh interval expires. 230 Receivers MUST be able to handle multiple consecutive isComposing 231 messages with "active" state regardless of the refresh interval. 233 The state transitions are shown in Figure 2. 235 +-------------+ 236 |+-----------+| 237 || || 238 +------>| idle |<------+ 239 | || || | 240 | |+-----------+| | 241 | +------+------+ | 242 | | | 243 "idle" recd. | |"active" msg.| refresh timeout 244 or content recd. | | | or 120s 245 | | | 246 | +------V------+ | 247 | | | | 248 | | | | 249 | | | | 250 +------+ active +------+ 251 | | 252 | | 253 +-------------+ 255 Receiver state diagram 257 Figure 2 259 3.4 Message Content 261 We briefly describe the message content to summarize the discussion 262 above. This description is non-normative. The schema (Section 6) 263 should be consulted for the normative message format. 265 The message consists of an element, with a mandatory 266 element indicating the composer state, i.e., idle or active. 267 In addition, there are three optional elements, , 268 indicating the time of last activity, , the type of 269 message being created, and , the time interval after which 270 the receiver can expect an update from the composer. Details are 271 given in the following section. 273 3.5 Additional Status Information 275 The status message contains additional optional elements to provide 276 further details on the composition activity. All of these can appear 277 in both "active" and "idle" state messages. 279 The optional element describes the absolute time when 280 the user last added or edited content. 282 The optional element indicates what type of media the 283 messaging terminal is currently composing. It can contain either 284 just a MIME media type, such as "audio" or "text", or a media type 285 and subtype, such as "text/html". It is best understood as a hint to 286 the user, not a guarantee that the actual content message will indeed 287 contain only the content indicated. It allows the human recipient to 288 be prepared for the likely message format. 290 In order to further describe message composition, the XML schema or 291 the set of allowable state names can be extended in future documents. 292 Recipients of status messages implementing this specification without 293 extensions MUST treat state tokens other than "idle" and "active" as 294 "idle". Additional elements MUST use their own namespaces and MUST 295 be designed such that receivers can safely ignore such extensions. 296 Adding elements to the namespace defined in this document is not 297 permitted. 299 The isComposing status message MAY be carried in CPIM messages [3]. 301 Such a wrapper is particularly useful if messages are relayed by a 302 conference server since the CPIM message maintains the identity of 303 the original composer. 305 4. Using the Status Message 307 The isComposing status message can be used with either page mode or 308 session mode, although it is a more natural fit with session mode. 309 In session mode, the status message is sent as part of the messaging 310 stream. Its usage is negotiated just like any other media type in 311 that stream, with details depending on the session mode protocol. 313 Sending the status messages within the session-mode messaging stream 314 has at least three benefits. First, it ensures proper ordering and 315 synchronization with the actual content messages being composed. In 316 messaging systems that guarantee in-order delivery of messages, this 317 approach avoids that message reordering across two delivery 318 mechanisms has an active indication appear at the receiver after the 319 actual message has been delivered. 321 Secondly, end-to-end security can be applied to the messages. 322 Thirdly, session negotiation mechanisms can be used to turn it on and 323 off at any time, and even negotiate its use in a single direction at 324 a time. 326 Usage with page mode is also straightforward. There, the status 327 message is carried as the body of a page mode message. In SIP-based 328 IM, The composer MUST cease transmitting status messages if the 329 receiver returned a 415 status code (Unsupported Media Type) in 330 response to a MESSAGE request containing the status indication. 332 The sender cannot be assured that the status message gets delivered 333 before the actual content being composed arrives. However, SIP page 334 mode is limited to one unacknowledged message, so that out-of-order 335 delivery is unlikely, albeit still possible if proxies are involved. 337 5. Examples 339 340 344 active 345 text/plain 346 90 347 348 349 353 idle 354 2003-01-27T10:43:00Z 355 audio 356 358 6. XML Document Format 360 An isComposing document is an XML document that MUST be well-formed 361 and SHOULD be valid. isComposing documents MUST be based on XML 1.0 362 and MUST be encoded using UTF-8. This specification makes use of XML 363 namespaces for identifying isComposing documents. The namespace URI 364 for elements defined for this purpose is a URN, using the namespace 365 identifier 'ietf'. This URN is: 366 urn:ietf:params:xml:ns:im-iscomposing 368 6.1 XML Schema 370 371 376 377 378 379 380 382 384 386 388 389 390 391 393 7. Security Considerations 395 The isComposing indication provides a fine-grained view of the 396 activity of the entity composing and thus deserves particularly 397 careful confidentiality protection so that only the intended 398 destination of the message will receive the isComposing indication. 400 Since the status messages are carried using the IM protocol itself, 401 all security considerations of the underlying IM protocol apply also 402 to the isComposing status messages. 404 There are potential privacy issues in sending isComposing status 405 messages before an actual conversation has been established between 406 the communicating users. A status message may be sent even if the 407 user later abandons the message. It is RECOMMENDED that isComposing 408 indications in page-mode are only sent when a message is being 409 composed as a reply to an earlier message. This document does not 410 prescribe how an implementation detects in page mode whether a 411 message is in response to an earlier one, but elapsed time or user 412 interface behavior might be used as hints. 414 8. IANA Considerations 416 8.1 Content-Type Registration for 'application/im-iscomposing+xml' 418 To: ietf-types@iana.org 419 Subject: Registration of MIME media type application/ 420 im-iscomposing+xml 421 MIME media type name: application 422 MIME subtype name: im-iscomposing+xml 423 Required parameters: (none) 424 Optional parameters: charset; Indicates the character encoding of 425 enclosed XML. Default is UTF-8. 426 Encoding considerations: Uses XML, which can employ 8-bit characters, 427 depending on the character encoding used. See RFC 3023 [4], 428 section 3.2. 429 Security considerations: This content type is designed to carry 430 information about current user activity, which may be considered 431 private information. Appropriate precautions should be adopted to 432 limit disclosure of this information. 433 Interoperability considerations: This content type provides a common 434 format for exchange of composition activity information. 435 Published specification: XXXX (this document) 436 Applications which use this media type: Instant messaging systems. 437 Additional information: none 438 Person & email address to contact for further information: Henning 439 Schulzrinne, hgs@cs.columbia.edu 440 Intended usage: LIMITED USE 441 Author/Change controller: This specification is a work item of the 442 IETF SIMPLE working group, with mailing list address 443 simple@ietf.org. 444 Other information: This media type is a specialization of 445 application/xml RFC 3023 [4], and many of the considerations 446 described there also apply to application/im-iscomposing+xml. 448 8.2 URN Sub-Namespace Registration for 449 'urn:ietf:params:xml:ns:im-iscomposing' 451 URI: urn:ietf:params:xml:ns:im-iscomposing 452 Description: This is the XML namespace for XML elements defined by 453 RFCXXXX to describe composition activity by an instant messaging 454 client using the application/im-iscomposing+xml content type. 455 Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, 456 Henning Schulzrinne, hgs@cs.columbia.edu 457 XML: 459 BEGIN 460 461 463 467 Is-composing Indication for Instant Messaging 468 469 470

Namespace for SIMPLE iscomposing extension

471

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

472

See RFCXXXX.

473 474 475 END 477 8.3 Schema registration 479 This section registers a new XML schema per the procedures in [5]. 481 URI: urn:ietf:params:xml:schema:im-composing 482 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 483 Henning Schulzrinne (hgs@cs.columbia.edu). 485 The XML for this schema can be found as the sole content of Section 486 6.1. 488 9. Acknowledgements 490 Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson, 491 Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi, 492 Jonathan Rosenberg and Xiaotao Wu provided helpful comments. 494 10. References 496 10.1 Normative References 498 [1] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 499 Instant Messaging", RFC 2778, February 2000. 501 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 502 Levels", BCP 14, RFC 2119, March 1997. 504 [3] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: 505 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 506 progress), January 2003. 508 [4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 509 3023, January 2001. 511 [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 512 2004. 514 [6] Handley, M. and V. Jacobson, "SDP: Session Description 515 Protocol", RFC 2327, April 1998. 517 10.2 Informative References 519 [7] Sugano, H. and S. Fujimoto, "Presence Information Data Format 520 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 521 2003. 523 [8] Rosenberg, J., "Advanced Instant Messaging Requirements for the 524 Session Initiation Protocol (SIP)", 525 draft-rosenberg-simple-messaging-requirements-01 (work in 526 progress), February 2004. 528 Author's Address 530 Henning Schulzrinne 531 Columbia University 532 Department of Computer Science 533 450 Computer Science Building 534 New York, NY 10027 535 US 537 Phone: +1 212 939 7004 538 EMail: hgs@cs.columbia.edu 539 URI: http://www.cs.columbia.edu/~hgs 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the IETF's procedures with respect to rights in IETF Documents can 550 be found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2004). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.