Network Working Group G. Hellstrom Internet-Draft Omnitor Intended status: Standards Track P. Jones Expires: July 12, 2008 Cisco Systems, Inc. G. Vanderheiden Trace R&D Center, University of Wisconsin-Madison January 9, 2008 Coding and transmission of text in real-time and en-bloc mode based on MSRP draft-hellstrom-simple-text-transmission-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo describes conventions for exchange and presentation of text in SIP sessions through the Message Session Relay Protocol MSRP. It covers two different methods for taking the initiative to transmit. Hellstrom, et al. Expires July 12, 2008 [Page 1] Internet-Draft Transmission of text in MSRP sessions January 2008 These methods are timer initiated real-time text and user requested en-bloc transmission in Messaging. The document gives specific guidance on handling of text presentation and presentation control of conversational sessions. It specifies how the capability to conduct MSRP sessions with real-time text is declared so that session negotiation can make decisions on what transport protocol to use and how to route the calls to get the desired support for text communication. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Consistent view of text communication based on MSRP . . . . . 4 2. Functional requirements . . . . . . . . . . . . . . . . . . . 5 2.1. Common requirements . . . . . . . . . . . . . . . . . . . 5 2.2. Requirements on real-time text mode . . . . . . . . . . . 5 2.3. Requirements on en-bloc mode . . . . . . . . . . . . . . . 6 3. Media type and subtype specification . . . . . . . . . . . . . 6 4. Presentation coding . . . . . . . . . . . . . . . . . . . . . 8 4.1. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Time division . . . . . . . . . . . . . . . . . . . . . . 8 4.3. New Line . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Alert in session . . . . . . . . . . . . . . . . . . . . . 8 4.5. End of Message . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Erasure . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.7. Other presentation controls . . . . . . . . . . . . . . . 9 5. Indication and negotiation of the real-time text transmission capability . . . . . . . . . . . . . . . . . . . 9 6. Time sampled transmission . . . . . . . . . . . . . . . . . . 10 7. Presentation of received text . . . . . . . . . . . . . . . . 11 8. Routing of calls to real-time text capable devices. . . . . . 11 9. Sessions including MSRP based real-time text and other media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 14. Temporary section - issues list . . . . . . . . . . . . . . . 12 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 15.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Hellstrom, et al. Expires July 12, 2008 [Page 2] Internet-Draft Transmission of text in MSRP sessions January 2008 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Hellstrom, et al. Expires July 12, 2008 [Page 3] Internet-Draft Transmission of text in MSRP sessions January 2008 1. Consistent view of text communication based on MSRP A set of mechanisms must be defined in order to assure consistent user experience when using MSRP RFC 4975 [RFC4975] for text communication in SIP [RFC3261] sessions. One style of usage of MSRP based text sessions is the real-time text conversation that makes use of time sampled transmission. Another style is Instant Messaging with user initiated transmission of complete messages. MSRP is a general transport method mainly intended for messages. The capability for real-time text transmission needs to be indicated, so that the users can agree on a common view of the conversation. A time sampling of 500 ms or less is required in order to achieve the end to end delay of less than 1 second that is needed for effective real time text conversation, . Requirements for presentation of conversations using real-time text is found in [draft-hellstrom-textpreview] [I-D.hellstrom-textpreview]. Traditionally the real-time text medium can be transmitted with RTP, as specified in RFC 4103[RFC4103]. This specification describes how to implement these functions with MSRP.User initiated transmission of MSRP text messages also need to follow presentation conventions in order to be presented as expected by the sending user. It is specifically the following features that need to be defined: Functional requirements. Media type and subtype specification and negotiating. Presentation coding. Text Erasure New lines Other presentation control functions Indication and negotiation of the time-sampled transmission capability Time sampled transmission Routing of calls to real-time text capable devices. Sessions including MSRP-based real-time text and other media. Performance Hellstrom, et al. Expires July 12, 2008 [Page 4] Internet-Draft Transmission of text in MSRP sessions January 2008 Security 2. Functional requirements The procedures defined in this specification are intended to provide a text transport mechanism fulfilling the following requirements. 2.1. Common requirements o Presentation of text shall be possible in one internationally useable character set. o Presentation within messages shall be done contiguously so that it is easily read. o It shall be possible to use the text transport method in a session together with other media. o It shall be possible to use the text transmission in SIP sessions. o A set of characters shall be defined for any specific language environment to cause end of message. o It shall be possible to protect the text contents from reading and modification from others than authorised adressees. o It shall be possible to guide routing of calls who may need text to specific devices capable of handling text transmission. 2.2. Requirements on real-time text mode o The real-time transmission and presentation of text shall be done in a way so that the users experience a flow of text approximately as it is typed. o The delay from character entry to remote display needs to be less than 1 s in order to maintain effective real-time conversation. Therefore the maximum delay before transmission of any character shall not be longer than 500 ms. o It shall be possible to erase already transmitted text in the current message.[see issues-list] o It shall be possible to negotiate between MSRP and other SIP-based standardised transport methods for real-time text at session Hellstrom, et al. Expires July 12, 2008 [Page 5] Internet-Draft Transmission of text in MSRP sessions January 2008 setup. o It shall be possible to transmit at least 30 characters per second. o It shall be possible to guide routing of calls who may need real- time text to specific devices capable of handling this text transmission mode. The main purpose of this requirement comes from the requirment to find a text capable gateway to PSTN for text telephony. o It shall be possible to use the real-time text transmission in SIP sessions. 2.3. Requirements on en-bloc mode o The transmission and presentation of text shall be done so that the users experience a transmission of text when a specific transmission action is made. 3. Media type and subtype specification In SIP[RFC3261] sessions, SDP[RFC4566] MUST indicate the media type 'message'. The Content-type is specified in the MSRP header. For real-time text, support MUST be provided for content-types text/ plain and for message/cpim with text/plain content. In addition, other content-types MAY be supported in real-time text mode. Hellstrom, et al. Expires July 12, 2008 [Page 6] Internet-Draft Transmission of text in MSRP sessions January 2008 SDP Examples Endpoint A wishes to invite Endpoint B to an MSRP session. A offers the following session description: v=0 o=usera 2890844526 2890844527 IN IP4 alice.example.com s= - c=IN IP4 alice.example.com t=0 0 m=message 7394 TCP/MSRP * a=accept-types:message/cpim text/plain a=real-time-text a=path:msrp://alice.example.com:7394/2s93i93idj;tcp B responds with its own URI: v=0 o=userb 2890844530 2890844532 IN IP4 bob.example.com s= - c=IN IP4 bob.example.com t=0 0 m=message 8493 TCP/MSRP * a=accept-types:message/cpim text/plain a=real-time-text a=path:msrp://bob.example.com:8493/si438dsaodes;tcp Figure: SDP example for a text-only session The MSRP messages and chunks contain headers indicating the media type and subtype actually used. For the real-time text usage a send request MAY look like this: Hellstrom, et al. Expires July 12, 2008 [Page 7] Internet-Draft Transmission of text in MSRP sessions January 2008 MSRP Chunk exaMPLE MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-5/* Content-Type: text/plain; charset=utf-8 Hey B -------a786hjs2+ Example: MSRP chunk 4. Presentation coding 4.1. Text Text shall be coded with an internationally applicable character set. The text/plain MIME type is defined to be used according to this specification. Coding with utf-8 shall be used. RFC 3629 [RFC3629] 4.2. Time division When operating in real-time text mode, text shall be collected for transmission during a time interval and then transmitted as an MSRP chunk. The maximum delay of any character before transmission MUST be 500ms. For good flow it SHOULD be 300 ms. For en-bloc mode, no timer-initiated tansmissions are required. Text MAY be sent in chunks, and recombined in complete messages by the receiver. 4.3. New Line It shall be possible to insert a new line in the text. A new line serves as message delimiter. Unicode Line Separator (UCS-16 2028) or CRLF SHALL be used for transmission. In reception, Line Separator, CR, CRLF, LF shall all have the same effect and be regarded as one operation. 4.4. Alert in session BEL may be sent to cause an external alerting action from the receiving terminal, but shall otherwise be treated as a non-printable character and have no impact on the display. Hellstrom, et al. Expires July 12, 2008 [Page 8] Internet-Draft Transmission of text in MSRP sessions January 2008 4.5. End of Message The following actions MAY cause the End of Message condition: Pressing Enter, pressing Return and pressing a Send button. The actual selection of end of message reasons is a sending application decision. At the End of Message condition, any unsent characters in the session MUST be transmitted with an End of Message indication in MSRP. 4.6. Erasure Erasure of the last character shall be signalled by a 'BS' character. Erasure shall have effect on the local and remote presentation of text. Locally inserted new lines by presentation logic only for layout purposes shall not be transmitted and therefore do not require any specific erasing action. New Lines inserted by the sending user MUST require one BS to be erased. The complete current message MUST be kept available for erasure. Characters that do not occupy a position in the display shall not require any BS for erasure, but if they have any effect on the presentation, they shall be regarded to be erased when the character before it is erased. BEL is one such character. Completed messages are not available for erasure.[see issues-list] [To issues-list: The relation between character position indications in MSRP headers and real printable position in a message needs to be defined. Possible alternative erasing action by chunk position and new character for replacement may be introduced] 4.7. Other presentation controls When using the media format text/plain, no other presentation controls than the ones described above can be conveyed in communication. Both users may vary their presentation locally. 5. Indication and negotiation of the real-time text transmission capability The capability to present and transmit real-time text with MSRP MUST be declared by the following means: a. An attribute a=real-time-text, in the media description for the media=message declaration intended for the real-time text conversation. Hellstrom, et al. Expires July 12, 2008 [Page 9] Internet-Draft Transmission of text in MSRP sessions January 2008 b. A Content-disposition=immediate-presentation to be included in the MSRP headers in the chunks and messages. c. The capability to present and transmit real-time text by any transport SHALL be declared by a media feature tag sip.real-time- text= in the SIP Contact header. This tag is also used by other text transports and may be used to determine if there is any real-time text support in the remote device. 6. Time sampled transmission The availability of characters ready for transmission MUST be checked at regular time intervals. The interval MUST be set to 300 ms for good user experience. When there is something to transmit at the end of an interval, the text SHALL be transmitted in an MSRP message chunk. No extra character SHALL be added to the text before transmission. When an End of Message condition is detected, the last characters of the message shall be sent immediately, with an End of Message MSRP indication. [see issues list]The chunk position counter shall be regarded to point at a position in a message transmission buffer including all characters that have been transmitted for that message. BS and BEL shall thus increase the chunk position value as any other characters. The Chunk position MUST NOT be used to directly address any presentation position on a display of the text.[see issues list] Hellstrom, et al. Expires July 12, 2008 [Page 10] Internet-Draft Transmission of text in MSRP sessions January 2008 Example: MSRP dkei38sd SEND Message-ID: 4564dpWd Byte-Range: 1-2/* Content-Type: text/plain; Charset=utf-8 He -------dkei38sd+ MSRP dkei38ia SEND Message-ID: 4564dpWd Byte-Range: 3-9/9 Content-Type: text/plain; Charset=utf-8 y Bob! -------dkei38ia$ Figure: Real-time text chunks. 7. Presentation of received text Text received from one session participant MUST be presented with some indication of the source. Text received within one message MUST be presented in one contiguous area. MSRP Chunks of the same message MUST be presented consecutively as soon as possible after reception, with no inserted character or editing control between the chunks. Characters MAY be added to a display singly so as to smooth presentation. Local presentation conventions MAY be applied to e.g break lines with word-wrapping. 8. Routing of calls to real-time text capable devices. A real-time text indicator in the SIP header MAY be used for routing of calls to real-time text capable devices, using the principles of caller capabilities and callee preferences from RFC 3840 and 3841. Hellstrom, et al. Expires July 12, 2008 [Page 11] Internet-Draft Transmission of text in MSRP sessions January 2008 9. Sessions including MSRP based real-time text and other media. Other media MAY be negotiated in the same SIP session setup as the MSRP session. 10. Security 11. IANA Considerations This specifications register the following new items: MSRP SDP attribute a=real-time text Indicates capability to use real-time text. [see issues-list] Contents-disposition=immediate indicates that if fragments of the complete text message is received, the fragments shall be presented without waiting for later fragments.[see issues- list] Note to RFC Editor: this section may be removed on publication as an RFC. 12. Security Considerations 13. Acknowledgements 14. Temporary section - issues list This chapter contains a collection of issues that have been discussed and not yet been resolved. The intention is to delete this section after resolving the issues. 1. Erasure 1. A possibility to erase back over message borders may be appreciated. One of the tensions appearing in traditional IM is of the non-erasable characteristics of sent text. Technically it gets complex to allow erasure further back, because MSRP does not have any defined way to address earlier messages than the current one. Also in interpreting the presentation of a dialogue after modification can cause confusion. But, it is a desired feature. A check with users is needed to decide on the functionality. A proposed function is to allow erasure represented by the earlier completed message being brought back for editing, but only erasure is Hellstrom, et al. Expires July 12, 2008 [Page 12] Internet-Draft Transmission of text in MSRP sessions January 2008 allowed, and shall have te effect of replacing characters with xxx. When new text is then typed. The partially erased message is closed and a new message begun. 2. Erasure 2. The use of charater position within chunk and message must be explored and defined. It must also be explained how it is affected by erasure. Shall BS always be translated into a replacement of a previously sent character by its position? 3.Erasure 3. Is the wording of handling of non-printable characters during erasure sufficiently described. 4. The use of chunks for time sampled transmission of text has been questioned. The primary intent of the chunk concept was said to be for avoiding congestion situations. It needs to be agreed if the reason to get a progressive presentation of a growing message is also an appropriate use of chunks. 15. References 15.1. Normative References [I-D.hellstrom-textpreview] Hellstrom, G., "Text conversation with real-time preview", draft-hellstrom-textpreview-02 (work in progress), August 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. Hellstrom, et al. Expires July 12, 2008 [Page 13] Internet-Draft Transmission of text in MSRP sessions January 2008 15.2. Informative References [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. Authors' Addresses Gunnar Hellstrom Omnitor Box 92054 Stockholm, 12006 Sweden Phone: +46 8 589 000 56 Fax: +46 8 589 000 51 Email: gunnar.hellstrom@omnitor.se Paul Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park,, NC 27709 USA Phone: +1 919 392 6948 Fax: Email: paulej@packetizer.com URI: Gregg Vanderheiden Trace R&D Center, University of Wisconsin-Madison 1550 Engineering Drive Madison, Wi 53706 USA Phone: Fax: Email: gv@trace.wisc.edu URI: http://www.engr.wisc.edu/ie/faculty/vanderheiden_gregg.html Hellstrom, et al. Expires July 12, 2008 [Page 14] Internet-Draft Transmission of text in MSRP sessions January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hellstrom, et al. Expires July 12, 2008 [Page 15]