Internet DRAFT - draft-hellstrom-simple-text-transmission
draft-hellstrom-simple-text-transmission
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=<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]
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]
