[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-00.txt - the need
Gunnar,
Based on what you've said, I assume that the group did not accept the draft
proposing the use of MSRP for RTT as a WG work item? I don't recall seeing
a firm statement on that either way.
In any case, building the case for why RTT is needed in IM seems reasonable
to me. That is the starting point that would justify the work and any
technical decisions.
What do you mean by "the transport system"? I thought the argument we were
making was for using MSRP as the transport. Honestly, I would think that if
we present a strong-enough case for the first question ("why RTT?"), then I
suspect there would be little debate over using MSRP. And, I still think
those arguing against MSRP have weaknesses in their systems. Our engineers
certainly were open to it.
Paul
> -----Original Message-----
> From: Gunnar Hellström [mailto:gunnar.hellstrom at omnitor.se]
> Sent: Sunday, March 16, 2008 2:24 AM
> To: 'Simple WG'
> Cc: 'Paul E. Jones'; Erik.Zetterstrom at omnitor.se; 'Gregg Vanderheiden'
> Subject: RE: [Simple]I-DAction: draft-hellstrom-simple-text-
> transmission-00.txt - the need
>
> There was a good discussion about real-time text transport with MSRP in
> the
> SIMPLE meeting, and an agreement to continue the discussion in the
> list.
>
> At least three topics crystallized:
>
> -The need for real-time-text among mainstream IM users.
>
> -The transport method for real-time-text in IM sessions.
>
> -The extent and mechanisms for erasure of already transmitted text.
>
> I want to start the discussion on the need for real-time text in
> connection
> with IM sessions.
>
> I have observed that some people think that a real-time-text feature in
> IM
> would be only for the benefit of deaf users. That view was also
> mentioned in
> the meeting.
> We will get much better push for implementations if we agree that this
> feature is something for all. It will enhance the user experience of
> any IM
> session, and especially intensive conversational ones.
>
> Some IM systems displays that the other end is typing a response. The
> fact
> that the designers felt the need to tell me that a response is
> currently
> being typed indicates a need for conveying that information. A more
> natural
> way of conveying that would be to start displaying what is being typed
> now
> rather than waiting for a whole message to be completed. The acceptance
> of
> that observation should be enough to convince all to introduce time-
> sampled
> real-time text transport in IM systems.
>
> If that is not enough to get an agreement that this is a generally
> desirable
> feature, I have a few more observations:
>
> I have noticed that if you ask people about their IM experience they
> tell
> things that should result in communications developers to implement
> real-time text functionality.
>
> These are typical examples of questions and answers when discussing
> message-wise IM:
>
> Q: Do you use IM.
> A: Yes, a lot, and it is good.
>
> Q: Do you have two-party chats, or multi-party chats?
> A: Sometimes multi-party chats for pleasure, but in 99% of the cases it
> is
> two-party chats set up by intention to sort out a specific question.
>
> Q: Do you change your language when you have an intensive IM discussion
> or
> are in a hurry?
> A: Yes, I shorten off sentences and break them up in short few word
> statements so that I can keep the communication going. The language
> gets
> corrupt, but we manage with the communication.
>
> Q: Do you have other concerns when typing?
> A: Yes, I want to send as soon as possible so that the other person
> does not
> start to think that they need to explain more or add items.
>
> Q: What do you think when you are waiting for next message?
> A: I often think "what will next entry be". I start to wonder if they
> need
> more info or more precise questions right away so they do not waste
> typing
> time on things I know. Sometimes this leads to me sending another
> message
> before I had a response, and then confusion starts. It starts to be
> complicated to know what answer belongs to what question.
>
> Real-time text can be used to sort out these witnessed draw-backs of
> message-wise IM among mainstream users. It would be sad to leave the IM
> systems without this feature. The real-time text feature is defined for
> real-time conversational service use in RTP by RFC 4103, but
> thereasoning
> above indicate a need to define the feature also for IM systems.
>
> So, if we have sufficient agreement on the reasoning above we can move
> to
> next question: What transport mechanism shall we use for real-time text
> in
> connection with MSRP?
>
> Gunnar
>
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> www.omnitor.se
>
> -----Original Message-----
> From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On
> Behalf Of
> Adam Roach
> Sent: Monday, March 10, 2008 4:29 PM
> To: Ben Campbell
> Cc: 'Paul E. Jones'; Erik.Zetterstrom at omnitor.se; Gunnar Hellström;
> 'Simple
> WG'; 'Gregg Vanderheiden'
> Subject: Re:
> [Simple]I-DAction:draft-hellstrom-simple-text-transmission-00.txt
>
> On 3/10/08 11:22 AM, Ben Campbell wrote:
> >
> > On Mar 10, 2008, at 10:59 AM, Adam Roach wrote:
> >
> >>
> >> I think #4 is exactly the right way to do it -- send the real-time
> >> text over RTP; reiterate it on message boundaries in MSRP; and do
> >> some kind of correlation in the SDP to indicate that a specific MSRP
> >> stream is associated with the specific RTP stream.
> >>
> >
> > I'm a little confused--if you have already sent it over RTP, why do
> > you need to reiterate it?
> >
> > Thanks!
>
> RTP doesn't have defined semantics around message boundaries. The
> redundant
> information in MSRP overlays those semantics on top of the real-time
> text.
> (It will also repair any text lost over the text RTP channel, as text
> RTP
> merely sends text redundantly, whereas MSRP's use of TCP involves
> explicit
> acknowledgments).
>
> Also, this kind of solution has nice incremental fail-back behavior: a
> client using this mechanism will end up negotiating a reasonable user
> experience with:
>
> 1. Other clients using this mechanism (with full functionality)
> 2. Clients that implement just MSRP but not RTP text (albeit without
> the realtime component)
> 3. Clients that implement just RTP text but not MSRP (albeit without
> the message boundary component).
>
> /a
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>
> __________ NOD32 2933 (20080310) 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