RE: [Simple] Re: I-DAction:draft-hellstrom-simple-text-transmission-00.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 13 January 2008 08:16 UTC

Return-path: <simple-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDy1U-0002nN-FQ; Sun, 13 Jan 2008 03:16:52 -0500
Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1JDy1S-0002mR-8W for simple-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 03:16:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDy1L-0002iX-Fd for simple@ietf.org; Sun, 13 Jan 2008 03:16:43 -0500
Received: from s87.loopia.se ([194.9.94.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDy1K-0004fV-7K for simple@ietf.org; Sun, 13 Jan 2008 03:16:43 -0500
Received: (qmail 15410 invoked from network); 13 Jan 2008 08:16:40 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <gunnar.hellstrom@omnitor.se>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <simple@ietf.org>; 13 Jan 2008 08:16:40 -0000
Received: (qmail 78324 invoked from network); 13 Jan 2008 08:16:40 -0000
Received: from h240n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.240]) (envelope-sender <gunnar.hellstrom@omnitor.se>) by s24.loopia.se (qmail-ldap-1.03) with SMTP for <pkyzivat@cisco.com>; 13 Jan 2008 08:16:40 -0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: 'Paul Kyzivat' <pkyzivat@cisco.com>, 'Simple WG' <simple@ietf.org>
Subject: RE: [Simple] Re: I-DAction:draft-hellstrom-simple-text-transmission-00.txt
Date: Sun, 13 Jan 2008 09:16:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-reply-to: <47898B0A.8040800@cisco.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-index: AchVl+8amUpQKL+vQOq4aAuV/aK/sAAIFJkg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Message-Id: <E1JDy1S-0002mR-8W@megatron.ietf.org>
Cc:
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Paul,
The real-time feature transmitting characters in time-sampled chunks as they
are avialable really gives new life to text-IM. Many of the annoying
drawbacks of traditional sentence-wise IM are resolved by this feature. You
do not need any presence indicator that the other person is typing, when you
really whant to know is WHAT is typed. Here you get it. And you do not need
to rush composing your message to completion so that the other participant
shall understand a new appearing situation. Your first keystrokes will be
immediately visible and make it apparent that you are about to explain the
situation. There are numerous situations when the real-time text feature is
very useful. 

But you are right in pointing at issue 4, saying that MSRP relays may need
to know that they should avoid buffering an re-combination of chunks when
the chunks are used for real-time text. Some additional rules may be needed
for relays. E.g. "do not recombine chunks with text/plain contents and less
than 10 characters of payload". 

Also multi-party sessions, with more than one active user typing may cause
an extensive message flow. I have calculated that one message flow with
three transmissions per second, including relay addressing, takes
approximately 17 kbit/s and 12 packets / second. With three typers it
becomes 51 kbit/s and 36 packets/s for this session between the relay and
the user terminal. 

So, an issue 5 might be needed: Is it feasible, regarding bandwidth
consumption and processing? If not, can something be done to make this
important functional enhancement of text-IM feasible? 

There is now also a draft available talking more about the presentation
aspects that gives complementing information:
http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-04.txt



Thanks 
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Sunday, January 13, 2008 4:53 AM
To: Simple WG
Subject: [Simple] Re:
I-DAction:draft-hellstrom-simple-text-transmission-00.txt

I find this to be pretty interesting. My feeling has been that the best
chance for pervasive support of real time text is for it to be incorporated
into a widely used application and protocol. IM qualifies as a widely used
application, though MSRP doesn't yet qualify as a widely used protocol. This
could however be synergistic - it might result in some pressure to support
MSRP.

BUT the problem mentioned as Issue 4 is potentially fatal. If relays are
involved in the session, it is likely that they would think it appropriate
to buffer and re-chunk the  chunks, destroying the real time
characteristics. I don't see how to avoid this unless some way to negotiate
the behavior of relays can be devised.

Also, if relays multiplex multiple MSRP sessions on a single, that can also
impact the real time characteristics.

	Thanks,
	Paul

Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 	Title           : Coding and transmission of text in real-time and
en-bloc mode based on MSRP
> 	Author(s)       : G. Hellstrom, et al.
> 	Filename        : draft-hellstrom-simple-text-transmission-00.txt
> 	Pages           : 15
> 	Date            : 2008-01-09
> 
> 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.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-hellstrom-simple-text-transmission
-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> i-d-announce-request@ietf.org with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-hellstrom-simple-text-transmission-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE
/internet-drafts/draft-hellstrom-simple-text-transmission-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

__________ NOD32 2785 (20080111) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com




_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple