[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction:draft-hellstrom-simple-text-transmission-00.txt
Ben,
Thanks for your comments and concerns.
Erik Zetterstöm will briefly present
draft-hellstrom-simple-text-transmission-00 in the SIMPLE meeting on Tuesday
early evening. The concern about using the chunking method to convey the
real-time segments of a text message can be discussed there.
In the presentation there is a slide listing the main known issues to solve.
One of the issues is the feasibility to use MSRP for real-time text.
The requirement for good real-time text performance satisfying the users is
that each typed character shall be presented to the receiver less than one
second after it was typed. In the RTP transport RFC 4103 we meet that by
time sampling of text in 300 ms samples and send them in an RTP packet. If
the receiving end smoothens out the presentation of the characters in a
received packet during the sampling interval, the user gets a good positive
impression of being in contact with the typer.
The IM concept needs this usability enhancement. When traditional text-IM
users get into an intensive dialogue that would have rquired real-time text,
they modify language and behaviour to try to make a pseudo-real-time
conversation through IM. That creates stress and not so good total
satisfaction.
The feasibility question for MSRP could be detailed to the following:
1. Is it feasible to use MSRP for text transmission with time sampled text
in 300 ms segments that are delivered within 700 ms from submission in order
to achieve the 1 second goal?
2. Is it feasible to use the chunk concept for transmitting the segments,
and put end-of-message at natural places in the text?
3. If the chunk concept is not feasible to use, what other method could be
used to be sure that consecutive text segments are displayed appending to
one unit of text until a formatting character arrives?
For no 3, we selected the chunk concept because the MSRP specification in
section 5.1 quite clearly shows the text "abcdEFGH" being sent as two
chunks. "abcd" and "EFGH". That is the effect we need, so we gladly adopted
that method.
An alternative is as you say, to send the time sampled text segments as
separate MSRP messages and have a strict presentation rule saying that if no
formatting character such as CRLF or NewLine has been received, then MSRP
text messages SHALL be presented in direct sequence without any formatting
introduced by the presenting application. (except for line wrapping at word
level to fit into a display area. )
If that alternative is preferred over the chunk model, two questions
directly arise:
a. Is it already too late to get that strict presentation convention settled
for the text/plain message Content-type? Have too many implementations
already starting putting in chat member labels in front of each MSRP
Message? If so, we need to register a new Content-type for this more
strictly controlled presentation, e.g. Content-type=text/t140m. ( pointing
at T.140 to be a general text presentation format commonly used for
real-time text conversations in various transport environments. )
b. In real-time text, the users need to be allowed to erase recently
transmitted text. With the message segmentation model, we thus need to allow
the contents of one message ( a BS character ) to erase presentation of an
earler presented message. I see no big problem in that, but it must be
defined to be allowable.
Thanks,
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
-----Original Message-----
From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf Of
Ben Campbell
Sent: Sunday, March 09, 2008 2:15 AM
To: Paul E. Jones
Cc: "'Gunnar Hellström'"; 'Simple WG'; 'Gregg Vanderheiden'
Subject: Re:
[Simple]I-DAction:draft-hellstrom-simple-text-transmission-00.txt
Apologies to all to jumping in here late--but I figured it was still better
to get my concerns on list prior to the meeting:
On Jan 30, 2008, at 5:24 PM, Paul E. Jones wrote:
> Folks,
>
> During the middle of the month, there was a little discussion on the
> draft draft-hellstrom-simple-text-transmission-00. As discussed, this
> draft is intended to provide a means of enabling real-time text
> transmission between devices using MSRP.
>
> Looking through the discussion that took place, I believe the only
> concern was that an MSRP relay might collect several text chunks and
> combine that, thus effectively breaking RTT communication. That's
> true and we cannot prevent it, but as Gunnar highlighted, there is an
> attribute included that provides a hint to relays that immediate
> delivery is required. We may need a stronger hint and/or means to
> select MSRP relays that will deliver the functionality we need.
>
Is the "strong hint" of which you speak the content-disposition header? If
so, then relays as currently defined are going to ignore it.
I don't think chunking is the right tool for handling the real-time text
presentation, due to the reasons in issue 4. The previous thread on the
subject talks about various ways to make relays treat real-time text
differently. I don't see how you can do this without serious modifications
to MSRP. One would be better off sending each time-slice as "whole message",
and define a higher level protocol to stream the messages together.
> Were there any other concerns?
I think someone mentioned bandwidth overhead. I have no idea how many
characters an average typist can type inside a 500ms window, but I can only
assume it's a small number. Even with the minimal set of MSRP headers, you
are talking about huge overhead. The chunk example in the draft has an
overhead on the order of 200-1.
>
>
> While there are certainly issues we need to address (and several noted
> in the initial draft), we wanted to put this before the group to try
> to build consensus for this general direction. It seems that there
> was support for this idea (and no objection that I could see). As
> such, would be acceptable to the group to make this a work item and
> begin actively progressing the draft within SIMPLE?
>
I have no objection to working on real-time text in SIMPLE--but I do not
think MSRP is the right tool for this. It's simply not designed for this use
case. Trying to force-fit real-time text requirements on MSRP is either
going to fail to meet the requirements, or it is going to result in
fundamental, probably non-backwards-compatible, changes to MSRP.
> Thanks,
> Paul
>
>
>
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple
__________ NOD32 2931 (20080307) Information __________
Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple