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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 14 January 2008 19:10 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 1JEUhJ-0000pb-Tc; Mon, 14 Jan 2008 14:10:13 -0500
Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1JEUhI-0000hp-P0 for simple-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 14:10:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEUhI-0000eh-AH for simple@ietf.org; Mon, 14 Jan 2008 14:10:12 -0500
Received: from s87.loopia.se ([194.9.94.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEUhG-0002l9-WC for simple@ietf.org; Mon, 14 Jan 2008 14:10:12 -0500
Received: (qmail 19255 invoked from network); 14 Jan 2008 19:10:07 -0000
Received: from s34.loopia.se (HELO s57.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>; 14 Jan 2008 19:10:07 -0000
Received: (qmail 94295 invoked from network); 14 Jan 2008 19:10:07 -0000
Received: from h240n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.240]) (envelope-sender <gunnar.hellstrom@omnitor.se>) by s57.loopia.se (qmail-ldap-1.03) with SMTP for <geir.sandbakken@tandberg.com>; 14 Jan 2008 19:10:07 -0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: 'Geir Arne Sandbakken' <geir.sandbakken@tandberg.com>, 'Paul Kyzivat' <pkyzivat@cisco.com>, 'Simple WG' <simple@ietf.org>
Subject: RE: [Simple]Re:I-DAction:draft-hellstrom-simple-text-transmission-00.txt
Date: Mon, 14 Jan 2008 20:10:12 +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
Thread-Index: AchVl+8amUpQKL+vQOq4aAuV/aK/sAAIFJkgAEgOlVAAAf2X0A==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-reply-to: <9F6ACAE02B6DD040A1E259977622CFDB01268B76@oslexcp1.eu.tandberg.int>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
Message-Id: <E1JEUhI-0000hp-P0@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

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
gunnar.hellstrom@omnitor.se
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com] 
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
> 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-tex
t-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
> 


_______________________________________________
Simple mailing list
Simple@ietf.org
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
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple