Subject: [Simple] Re: I-D Action:draft-hellstrom-simple-text-transmission-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Jan 2008 22:52:42 -0500

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

[email-masked] 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
> [email-masked] 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:
> 	[email-masked].
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 13 Jan 2008 09:16:41 +0100

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
[email-masked]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
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

> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hellstrom-simple-text-transmission
-00.txt
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE
/internet-drafts/draft-hellstrom-simple-text-transmission-00.txt".

__________ NOD32 2785 (20080111) Information __________

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

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Mon, 14 Jan 2008 19:32:26 +0100

Gunnar,

If packet rate, bandwidth or processing limitations are a concern,  you could think about adding a throttle mechanism. Like an MSRP method that would request the client to adjust it's sample rate, or even turn off/on a real time text extension.  

As an MSRP session can be used for many purposes, you might be required to tag each MSRP message.  The relay could then treat the messages differently on a message by message basis.  

Cheers,
Geir Arne

> 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:
> 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
> 
> > 	Title           : Coding and transmission of text in 
> real-time and
> en-bloc mode based on MSRP
> > 	Filename        : 
> draft-hellstrom-simple-text-transmission-00.txt
> > 	Pages           : 15
> > 	Date            : 2008-01-09
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 14 Jan 2008 20:10:12 +0100

Geir Arne,

You say: "you might be required to tag each MSRP message"

In section 5, item b we have this proposal:

   b.  A Content-disposition=immediate-presentation to be included in
   the MSRP headers in the chunks and messages.  

(This new value of Content-disposition then needs to be registered by IANA.
)
Do you regard tat to be a suitable tagging, or do you have any other
mechanism in mind that is possible to use on text/plain, Charset=utf-8

Gunnar
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Geir Arne Sandbakken [mailto:[email-masked]] 
Sent: Monday, January 14, 2008 7:32 PM
To: Gunnar Hellström; Paul Kyzivat; Simple WG
Subject: RE:
[Simple]Re:I-DAction:draft-hellstrom-simple-text-transmission-00.txt

Gunnar,

If packet rate, bandwidth or processing limitations are a concern,  you
could think about adding a throttle mechanism. Like an MSRP method that
would request the client to adjust it's sample rate, or even turn off/on a
real time text extension.  

As an MSRP session can be used for many purposes, you might be required to
tag each MSRP message.  The relay could then treat the messages differently
on a message by message basis.  

Cheers,
Geir Arne

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

__________ NOD32 2789 (20080114) Information __________