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.

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. 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Consistent view of text communication based on MSRP
2.  Functional requirements
    2.1.  Common requirements
    2.2.  Requirements on real-time text mode
    2.3.  Requirements on en-bloc mode
3.  Media type and subtype specification
4.  Presentation coding
    4.1.  Text
    4.2.  Time division
    4.3.  New Line
    4.4.  Alert in session
    4.5.  End of Message
    4.6.  Erasure
    4.7.  Other presentation controls
5.  Indication and negotiation of the real-time text transmission capability
6.  Time sampled transmission
7.  Presentation of received text
8.  Routing of calls to real-time text capable devices.
9.  Sessions including MSRP based real-time text and other media.
10.  Security
11.  IANA Considerations
12.  Security Considerations
13.  Acknowledgements
14.  Temporary section - issues list
15.  References
    15.1.  Normative References
    15.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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 (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975] for text communication in SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Hellstrom, G., Williams, N., Wijk, A., and G. Vanderheiden, “Presentation of Text Conversation in realtime and en-bloc form,” March 2010.). Traditionally the real-time text medium can be transmitted with RTP, as specified in RFC 4103[RFC4103] (Hellstrom, G. and P. Jones, “RTP Payload for Text Conversation,” June 2005.). 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

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

• Presentation of text shall be possible in one internationally useable character set.
• Presentation within messages shall be done contiguously so that it is easily read.
• It shall be possible to use the text transport method in a session together with other media.
• It shall be possible to use the text transmission in SIP sessions.
• A set of characters shall be defined for any specific language environment to cause end of message.
• It shall be possible to protect the text contents from reading and modification from others than authorised adressees.
• 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

• 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.
• 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.
• It shall be possible to erase already transmitted text in the current message.[see issues-list]
• It shall be possible to negotiate between MSRP and other SIP-based standardised transport methods for real-time text at session setup.
• It shall be possible to transmit at least 30 characters per second.
• 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.
• It shall be possible to use the real-time text transmission in SIP sessions.

2.3.  Requirements on en-bloc mode

• 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) sessions, SDP[RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) 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.

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:

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 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [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.

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.

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=<any defined value> 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]

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.

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 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

15.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.