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

["Geir Arne Sandbakken" <[e-mail]>]

My fault. The header is fine by me. I just got stuck on the examples which do not include the header.  

Geir Arne

> -----Original Message-----
> From: Gunnar Hellström [mailto:[e-mail]] 
> 
> 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
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
> Tel: [phone]
> www.omnitor.se
> 
> -----Original Message-----
> From: Geir Arne Sandbakken [mailto:[e-mail]]
> 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
> 
> > -----Original Message-----
> > 
> > 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
> > [e-mail]
> > 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[e-mail]]
> > 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
> > 
> > [e-mail] 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-tex
> t-transmission
> > -00.txt
> > > 
> > > To remove yourself from the I-D Announcement list, send a
> > message to
> > > [e-mail] 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:
> > > 	[e-mail].
> > > 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/i-d-announce
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
> 
> __________ NOD32 2789 (20080114) Information __________
> 
> Detta meddelande är genomsökt av NOD32 Antivirus.
> http://www.nod32.com
> 
> 
> 


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