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

From: Ben Campbell <[email-masked]>
Date: Sat, 8 Mar 2008 19:14:53 -0600

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

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 9 Mar 2008 08:12:42 +0100

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

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

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.

__________ NOD32 2931 (20080307) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 9 Mar 2008 13:34:17 +0100

Ben,
I also want to comment on your second concern: The overhead involved in
using MSRP for real-time text. 

You are right. If we have a medium intensive typer, typing 7 characters per
second, and transmit with 300 ms time sampling, it will be about two-three
payload characters per transmission. 

Sending them as chunks or as messages does not matter for the bandwidth and
number of packet overhead. In both cases this load seems to cause around 17
kbit/s bandwidth consumption and 12 packets per second. ( with variations
depending on relaying and selected options ) 

This is still much lower than a G.711 flow of usually 80 kbit/s and 50
packet/second, or good H.264 with 200 kbit/s and 75 packets/s.

The same typer would cause 3 packets per second and about 2 kbit/s load
using the RTP based RFC 4103 that still should be regarded the main
transport for real-time text when used in real-time conversational calls
where other media may be used as well. 

The MSRP application would mainly be to improve user experience of IM and
relieve some tension that appears from its traditional sentence-wise use
during intensive exchange.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Hellström
Sent: Sunday, March 09, 2008 8:13 AM
To: 'Ben Campbell'; 'Paul E. Jones'
Cc: [email-masked]; 'Simple WG'; 'Gregg Vanderheiden'
Subject: Re:
[Simple]I-DAction:draft-hellstrom-simple-text-transmission-00.txt

Ben,

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:

Thanks,
Gunnar

-----Original Message-----

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

---

From: Ben Campbell <[email-masked]>
Date: Sun, 9 Mar 2008 08:54:59 -0500

I think most of your email is best discussed at the meeting, but  
here's one comment inline:

> chunks. "abcd" and "EFGH". That is the effect we need, so we gladly  

That was an example only. It's not feasible to put large (2K and  
larger) chunks in text examples in an RFC. There is text elsewhere in  
the document recommending keeping your chunk size as large as you can.  
Also, there was no expectation in either that RFC or the relay spec  
that the example you site would be transmitted or rendered as real-time.

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 9 Mar 2008 23:02:26 +0100

OK, I hope there will be time for a good discussion on this topic in the
meeting.

I want to mention a third option for how to get time-sampled real-time
transmission to be possible to use together with MSRP.

That is to negotiate both RTP based transmission according to RFC 4103 for
the real-time transmission and display, and then regular message oriented
use of MSRP for the same contents. When the transmitting user has indicated
End-of-message, the whole message is retransmitted through MSRP, and
displayed in the session chat history.

That method is a hybrid RTP/MSRP method and is briefly introduced in section
5.4 of
http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-05.txt

If this method is adopted, it could provide increased connectivity over the
pure RTP or the pure MSRP based variants. 

Both m=text for RFC 4103 and m=message for MSRP would be negotiated plus
some way to indicate that the streams contain the same contents. 
-If both are accepted, a  real-time text experience is created by the RFC
4103 and MSRP is used for history and transmission of features not supported
in RFC 4103. 
-If only RFC 4103 is successfully agreed, then the real-time text can be
sent through it, and the history handled by it as well.
-If only message-wise MSRP was negotiated, the users will experience that
they get their text through, but with the delay introduced to wait for
messages to be completed. 

That leaves us with four options to discuss for real-time text:

1. Continue with RTP based transmission only for real-time text in real-time
conversational calls and give up on any IM/MSRP related variant. Let IM
users continue to use message mode only.

2. Use MSRP with time sampled text transported in MSRP chunks for adding
real-time in IM.

3. Use MSRP with time sampled text transported as MSRP Messages for adding
real-time in IM.

4. Use RFC 4103 for the real-time experience and MSRP in traditional message
mode for adding real-time in IM.

Which model do you find most feasible to continue specifying?

Remember that we discuss improvements on the IM concept to make its users
more satisfied.

For real-time conversational services, where RTP is the native media
transport, we already have RFC 4103 settled as the default transport.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Sunday, March 09, 2008 2:55 PM
To: Gunnar Hellström
Cc: 'Paul E. Jones'; [email-masked]; 'Simple WG'; 'Gregg
Vanderheiden'
Subject: Re:
[Simple]I-DAction:draft-hellstrom-simple-text-transmission-00.txt

I think most of your email is best discussed at the meeting, but here's one
comment inline:

On Mar 9, 2008, at 1:12 AM, Gunnar Hellström wrote:

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

That was an example only. It's not feasible to put large (2K and
larger) chunks in text examples in an RFC. There is text elsewhere in the
document recommending keeping your chunk size as large as you can.  
Also, there was no expectation in either that RFC or the relay spec that the
example you site would be transmitted or rendered as real-time.

__________ NOD32 2932 (20080309) Information __________

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 10:59:55 -0400

> Which model do you find most feasible to continue specifying?

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.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Mar 2008 11:22:04 -0400

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!

Ben.

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 11:29:22 -0400

> you need to reiterate it?

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

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 11 Mar 2008 08:03:26 +0100

Adam,
Thanks for a clear comment on the presented options.
I hope others will add their views, for example during the presentation of
the draft in the SIMPLE meeting this evening.

Gunnar  
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 4:29 PM
To: Ben Campbell
Cc: Gunnar Hellström; 'Paul E. Jones'; [email-masked]; 'Simple
WG'; 'Gregg Vanderheiden'
Subject: Re: [Simple]
I-DAction:draft-hellstrom-simple-text-transmission-00.txt

> you need to reiterate it?

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

/a

__________ NOD32 2933 (20080310) Information __________

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 16 Mar 2008 07:23:54 +0100

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

-----Original Message-----
Adam Roach
Cc: 'Paul E. Jones'; [email-masked]; Gunnar Hellström; 'Simple

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Mar 2008 16:48:16 -0400

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

> From: Gunnar Hellström [mailto:[email-masked]]
> Sent: Sunday, March 16, 2008 2:24 AM
> To: 'Simple WG'
> Cc: 'Paul E. Jones'; [email-masked]; 'Gregg Vanderheiden'
> Subject: RE: [Simple]I-DAction: draft-hellstrom-simple-text-
> transmission-00.txt - the need
> 
> redundant

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Mon, 17 Mar 2008 10:24:10 +0100

Gunnar,

It seems that at least I misunderstood some of the comments in the meeting. Some of the feedback was actually related to the proposed use of the chunking mechanism - and not against using MSRP for real-time text as such.  The usage of the chunking mechanism as transport optimization might not work.

There was raised concern about the overhead using MSRP as a transport.  A vanilla turn/msrp relay used for conferencing will have to handle 50 packets of audio and 200 packets of video per second per participant; IMHO 3 packets of MSRP data per second are not very intimidating.  It should also be an optional extension end-to-end, and relays not supporting such a heavy load should be left in the clear.  

As for the benefit; seeing how fast a teenager can compose, send and respond using SMS on mobiles - I have no doubt that real-time text could easily be adopted by such a community.  

Geir Arne

> Sent: 16. mars 2008 07:24
> To: 'Simple WG'
> Subject: Re: [Simple] I-DAction:draft-hellstrom-simple-text-transmission-
> 00.txt - the need
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Mar 2008 13:29:14 -0500

> certainly were open to it.

The problem as I understand it is fundamental to the way MSRP is  
currently specified.

MSRP relays may (and probably will) bundle up small packets into large  
ones. That is, they'll strip the real-time right out of the text.

Now, I personally feel MSRP is over-specified. It has all sorts of  
neat capabilities for muxing and controlling independent flows that  
I've heard it said we've reinvented SCTP. But it is what it is, and  
that's an awkward beast for carrying RTT.

To meet the requirements of RTT, we need something that is lighter  
than MSRP, but still has the reliability and congestion control of TCP.

I think this makes RTT an ideal candidate for something like the TOTE  
session protocol described in:

  http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt

I'm interested in getting a BOF going to look at multi-purpose session  
protocols suitable for end-to-end use in a session initiated by SIP or  
other rendezvous protocols. I think RTT provides a great use-case for  
such a protocol.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Wed, 19 Mar 2008 17:08:47 -0500

(As chair)

To be clear: SIMPLE did not take this as WG item.

There was some discussion, including technical feedback on the  
proposed use of MSRP,
in the room - refer to the notes in the minutes for the content. It  
was clear that more discussion
was needed before SIMPLE would take on any work.

RjS

On Mar 16, 2008, at 3:48 PM, Paul E. Jones wrote:

>> There was a good discussion about real-time text transport with  
>> MSRP in
>> the
>> I have observed that some people think that a real-time-text  
>> feature in
>> IM
>> 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
>> A: Sometimes multi-party chats for pleasure, but in 99% of the  
>> cases it
>> is
>> Q: Do you change your language when you have an intensive IM  
>> discussion
>> or
>> are in a hurry?
>> 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
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 20 Mar 2008 16:46:09 +0100

Paul,

Good to see that there is interest to smoothen MSRP text messaging by a
real-time text feature.

This is what I meant with the question: "What transport mechanism shall we
use for real-time text in connection with MSRP?":

I want to see an agreement captured in the
draft-hellstrom-simple-text-transmission specifying how the real-time
feature of MSRP text messaging is negotiated and transported.

A number of mwthods have already been suggested, and it is important for
harmonization to agree on one of them.

The following methods were mentioned:

1. NOT do it related to MSRP at all. Shift to RFC 4103 when the user wants
real-time text.

2. Use MSRP with time sampled text transported in MSRP chunks for adding
real-time in IM.
Add an indication in the chunk header to tell that the Relay should not
recombine chunks.

3. Use MSRP with time sampled text transported as MSRP Messages for adding
real-time in IM. Use a specific MIME submedium to agree that messages that
do not end with New Line shall be displayed adjacently.

4. Use MSRP chunks for real-time time sampled transmssion, and let the whole
session be one long Message of undefined length. Apply T.140 presentation
habits that e.g. allow erasure without limitation by New Lines or other
delimiters. 

5. Use RFC 4103 for the real-time experience and MSRP in traditional message
mode for adding real-time in IM. Coordinate the two transmission methods by
some indicators in stream or in headers. If only RFC 4103 is supported, then
use it throughout the session. If only MSRP is supported, then use only
message mode.

Gunnar   

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Sunday, March 16, 2008 9:48 PM
To: 'Gunnar Hellström'; 'Simple WG'
Cc: [email-masked]; 'Gregg Vanderheiden'
Subject: RE: [Simple]I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

Gunnar,

Paul

> 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.
> 
> 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.
> 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.
> 
> 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.
> 
> discussion or are in a hurry?
> statements so that I can keep the communication going. The language 
> gets corrupt, but we manage with the communication.
> 
> 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.
> 
> 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.
> 
> 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
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adam Roach
> Cc: 'Paul E. Jones'; [email-masked]; Gunnar Hellström; 
> 'Simple WG'; 'Gregg Vanderheiden'
> Subject: Re:
> >> some kind of correlation in the SDP to indicate that a specific 
> >> MSRP stream is associated with the specific RTP stream.
> >>
> >
> 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).
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 22 Mar 2008 00:15:11 +0100

Paul and all,
Here is the research that convinced me that real-time text IM is a
mainstream desire. 
http://www.cc.gatech.edu/~everyday-computing/projects/im/pubs/tensionsInIM-c
hi2002.pdf

The authors try to invent methods to avoid the traditional tensions
appearing in IM when it gets a bit intensive. Strangely enough, they do not
suggest time-sampled transmission, that solves most of the mentioned
tensions. 

But we in this group now know that time-sampled transmission is the solution
for modern intensive IM. 

Since MSRP is just about to be implemented, it is a good opportunity to
settle application rules to MSRP so that it can be used with time-sampled
transmission. 

I think it would be sad to give up with MSRP and start defining another
protocol, like TOTE. That would just increase the confusion and complexity
and reduce the opportunity for MSRP messaging users to get their messaging
exchange more lively. I think we should search our solution among the 5
alternatives I presented in an earlier posting on this thread.

Gunnar  

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 5:57 PM
To: 'Dean Willis'
Cc: '"'Gunnar Hellström'"'; 'Simple WG'; [email-masked]; 'Gregg
Vanderheiden'
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

Dean, at al,

Re-inventing SCTP with what?  RTT support or MSRP in general?

In any case, I do not think TOTE is the right solution.  I've also seen a
proposal to send RFC 4103 in parallel to MSRP.  I believe anything that is
outside of MSRP should be off the table for discussion, because anything
else would:
  1) Create a special solution for deaf users
  2) Create more work for everybody (phones, SBCs, softswitches, etc.)
  3) Require special consideration for all manufacturers and network
operators who
     must comply with regulatory requirements

I believe it is imperative that we bring to market a single IM solution for
SIP that works.  Thus far, that's not happened and I was excited by the
prospect that MSRP might make that happen.  I personally want a solution
that is as natural as possible and will not present significant complexity
to implement and deploy. 

I believe it is important to question whether we need real-time text.
Personally, I do not think we do.  However, many of the folks I've worked
with in the deaf community feel we do.  Who am I to say what the deaf
community needs?  In my view, if there is a significant portion of our
global population that feels they need RTT, then we should find a way to
make it work if there is a way to do it.

MSRP is designed in such a way that we can enable it to support RTT without
making great leaps.  Using the chunking method already defined within MSRP
is fairly straight-forward.  The only thing I see it doing is increasing the
bandwidth and number of packets that need to be processed.  As Geir Arne
rightly point out, text packets are nothing compared to the processing of
50pps of audio and become a blip on the radar compared to video.  Further,
there is nothing "illegal" about sending 1 character per packet today, so...
what would a system do?  It must handle it.

I think it is important to decide whether we want to create an IM system
that will work in the same way for RTT and non-RTT.  I would argue that it's
a heck of a lot easier to accommodate both with MSRP than to consider
separate solutions.  I want to find a way that will reduce complexity,
reduce cost of development and deployment, and will enable us to meet
forthcoming regulatory requirements.

Paul

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, March 17, 2008 2:29 PM
> To: Paul E. Jones
> Cc: "'Gunnar Hellström'"; 'Simple WG'; [email-masked]; 
> 'Gregg Vanderheiden'
> Subject: Re: [Simple] I-DAction: draft-hellstrom-simple-text- 
> > 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.
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 22 Mar 2008 09:34:53 +0100

Paul,
The research was general. It is not only the lack of opportunity to erase
that causes stress in IM users. 

There are many valid reasons to cheer up the user experience of IM by making
it real-time. Taken together, you should realize that the reasons are
compelling, and start working hard on it. 

Gunnar

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Saturday, March 22, 2008 4:29 AM
To: 'Gunnar Hellström'; 'Dean Willis'
Cc: 'Simple WG'; [email-masked]; 'Gregg Vanderheiden'
Subject: RE: [Simple] I-DAction:

Gunnar,

User stress with using IM is not a very compelling reason for me.  I can't
erase a spoken word.

As I said, there are many good reasons for stopping at the message boundary.
Anything beyond that will introduce undue complexity.

Paul

> Sent: Friday, March 21, 2008 7:15 PM
> To: 'Paul E. Jones'; 'Dean Willis'
> Cc: 'Simple WG'; [email-masked]; 'Gregg Vanderheiden'
> Subject: RE: [Simple] I-DAction: draft-hellstrom-simple-text- 
> http://www.cc.gatech.edu/~everyday-
> computing/projects/im/pubs/tensionsInIM-c
> hi2002.pdf
> 
> appearing in IM when it gets a bit intensive. Strangely enough, they 
> do not suggest time-sampled transmission, that solves most of the 
> mentioned tensions.
> 
> But we in this group now know that time-sampled transmission is the 
> solution for modern intensive IM.
> 
> Since MSRP is just about to be implemented, it is a good opportunity 
> to settle application rules to MSRP so that it can be used with time- 
> sampled transmission.
> 
> I think it would be sad to give up with MSRP and start defining 
> another protocol, like TOTE. That would just increase the confusion 
> and complexity and reduce the opportunity for MSRP messaging users to 
> get their messaging exchange more lively. I think we should search our 
> solution among the 5 alternatives I presented in an earlier posting on 
> this thread.
> 
> Gunnar
> Cc: '"'Gunnar Hellström'"'; 'Simple WG'; [email-masked]; 
> 'Gregg Vanderheiden'
> In any case, I do not think TOTE is the right solution.  I've also 
> seen a proposal to send RFC 4103 in parallel to MSRP.  I believe 
> anything that is outside of MSRP should be off the table for 
> discussion, because anything else would:
> I believe it is imperative that we bring to market a single IM 
> solution for SIP that works.  Thus far, that's not happened and I was 
> excited by the prospect that MSRP might make that happen.  I 
> personally want a solution that is as natural as possible and will not 
> present significant complexity to implement and deploy.
> 
> Personally, I do not think we do.  However, many of the folks I've 
> worked with in the deaf community feel we do.  Who am I to say what 
> the deaf community needs?  In my view, if there is a significant 
> portion of our global population that feels they need RTT, then we 
> should find a way to make it work if there is a way to do it.
> 
> MSRP is designed in such a way that we can enable it to support RTT 
> without making great leaps.  Using the chunking method already defined 
> within MSRP is fairly straight-forward.  The only thing I see it doing 
> is increasing the bandwidth and number of packets that need to be 
> processed.  As Geir Arne rightly point out, text packets are nothing 
> compared to the processing of 50pps of audio and become a blip on the 
> radar compared to video.
> Further,
> I think it is important to decide whether we want to create an IM 
> system that will work in the same way for RTT and non-RTT.  I would 
> argue that it's a heck of a lot easier to accommodate both with MSRP 
> than to consider separate solutions.  I want to find a way that will 
> reduce complexity, reduce cost of development and deployment, and will 
> enable us to meet forthcoming regulatory requirements.
> 
> Paul
> 
> > > 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
> > I think this makes RTT an ideal candidate for something like the 
> > TOTE session protocol described in:
> >
> >   
> > other rendezvous protocols. I think RTT provides a great use-case 
> > for such a protocol.
> >
> > --
> > Dean
> >
> 
> 
>

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sat, 22 Mar 2008 12:51:38 -0500

> Who?  RFC 4103 is a derivative of RFC 2793 and was not 

> developed by any major phone manufacturer that I am aware of. 

GV: Ericsson commissioned the development of 2793

>  I might be wrong. Further, I'm not aware of any major phone 

> manufacturer desiring to support it, either.

4103 is in 3GPP specs and the next generation emergency telecom specs.

The rest of the email I think we are in agreement. 

And I DO think that MSPR should specify how to do REAL-TIME TEXT in MSRP so
that can proceed.

I ALSO believe that any aspect needed to coordinate MSRP with REAL-TIME TEXT
implemented using other technologies (as some on the list have suggested) is
a good idea as well. 

Thanks

Gregg

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sat, 22 Mar 2008 13:17:59 -0500

We absolutely need to have IM supported in emergency communication I
believe.

And MSRP is the best candidate I see for this.

It is very complicated though – so I would suggest that those interested in
this self-identify so that off line conversations (which will be lengthy)
can occur without drowning this list. 

Then the conclusions – or technical questions – can be brought back here. 

Those interested,  get ready to immerse yourself in a new world.    It is
something else.   (AND we want to think globally – not nationally…)

And there are so many ways that IM can be used in 9-1-1 situations to cause
mischief.    (e.g. if no solid way to authenticate source) 

VoIP is causing all sorts of problems – but those are being worked on and we
may find ways to ride those solutions.    

Gregg
 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 

If Attachment is a mail.dat try http://www.kopf.com.br/winmail/

  _____  

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Saturday, March 22, 2008 12:58 PM
To: 'Gregg Vanderheiden'; 'Dean Willis'
Cc: '"'Gunnar Hellström'"'; 'Simple WG'; [email-masked]
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

Gregg,

OK, so I stand corrected.

You raise a good discussion point with this extra information.  Do we
envisage using MSRP for emergency communication?  Or, will that be
exclusively RFC 4103?  Do the scope of these protocols cross or do we expect
clear boundaries to be drawn here?

Paul

From: Gregg Vanderheiden [mailto:[email-masked]] 
Sent: Saturday, March 22, 2008 1:52 PM
To: 'Paul E. Jones'; 'Dean Willis'
Cc: '"'Gunnar Hellström'"'; 'Simple WG'; [email-masked]
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

 

 

Thanks

Gregg

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 Mar 2008 09:15:06 +0100

Gregg,
You are right that IM need to be supported by emergency services. And also
real-time text. 
That is defined by the ecrit group of IETF. They have included requirements
for support of:
 
RFC 4103 for real-time text.
RFC 3428 SIP Message for IM outside sessions.
RFC 4975 MSRP for in-session IM.
 
That is a good set, because you need to have ´support for the everyday tool
you have for communication also in the emergency situation. The message-wise
variants create stress and problems because of the waiting times in silently
composing messages. But if that is what you use daily, you would not fiddle
with your communication tools to find other protocols the day you have an
emergency. And text based information can be a very valuable addition to any
kind of emergency call.
So, this may be the most valid reason to introduce a real-timish use of
MSRP. 
 
I think you are right in that the SIMPLE list is not the right place to
discuss deeper application concerns for emergency service features. It could
possibly be ecrit. (?)
Results of such discussions should be brought back here for possible
protocol influence.
 
So, I think we are back to the fact that a real-time feature for use with
MSRP text sessions is desired, we have identified 5 ways to do it, and would
need to get to an agreement of which one to use and get that recorded in
draft-hellstrom-simple-text-transmission.
 
Gunnar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gregg Vanderheiden
Sent: Saturday, March 22, 2008 7:18 PM
To: 'Paul E. Jones'; 'Dean Willis'
Cc: [email-masked]; '"'Gunnar Hellström'"'; 'Simple WG'
Subject: Re: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

Gregg

 

  _____  

Gregg,

Paul

 

 

Thanks

Gregg

__________ NOD32 2967 (20080321) Information __________

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 Mar 2008 10:57:44 +0100

Paul,
You do not want to cross message borders with erasures, and I want to, in
order to satisfy user´s desires.

The MSRP message is a transport level construct, intentionally made neutral
for media and presentation. So, we get no clue from interpreting MSRP about
how to handle and present erasures, messages, chunks etc. It seems that each
MIME type and subtype used for contents need to define its own presentation
rules.

Has there been any efforts anywhere else to define a presentation level for
MSRP based text messaging?  OMA?

In the current draft-hellstrom-simple-text-transmission, we say that it
shall be possible to use real-time transmission with text/plain contents. If
there is already a definition saying that there are limitations in how you
can handle erasures of text/plain contents, then we can instead register a
new text subtype, e.g. text/t140m and explicitly define the presentation
characteristics we want for that subtype. It can adopt the presentation
characteristics of T.140, where limitless erasure is expected.

However, I think there is value in having a real-time presentation agreement
for text/plain. Currently I do not see any strong reasons to not satisfy
user needs for erasures there, but I am willing to listen to arguments from
others. 

Why not try to eliminate as much as possible of the inconveniencies
witnessed by IM users now, when we are redefining it?

Gunnar

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Saturday, March 22, 2008 5:34 PM
To: 'Gunnar Hellström'; 'Dean Willis'
Cc: 'Simple WG'; [email-masked]; 'Gregg Vanderheiden'
Subject: RE: [Simple] I-DAction:

Gunnar,

The industry has for years.  It has been extremely hard to get any consensus
on IM technology, let alone RTT.  According to my own notes, back in March
1999 the IMPP (Internet Message and Presence Protocol) working group shifted
its focus from developing design goals and requirements for building "an
internet-scale end-user presence awareness, notification and instant
messaging system."  I don't even have notes on the day it was that Mark Day
introduced the word "presentity"... but it has been far too long to still
not have a solution.

Perhaps one thing that slowed progress was the introduction of XMPP.  Even
so, XMPP progressed through the IETF, there are now standards in place, it
work, it is highly-scalable, fully federated, and ... I have no complaints
with it.  If I were deploying an enterprise IM system for my own corporate
network, XMPP would be my protocol of choice.

This group is trying to find a workable IM solution for use with SIP.  We
finally have a protocol that I think it workable (MSRP).  So, we have an
opportunity to get this done.  And, I'm fully supportive.  But, I want to
limit complexity.

Given MSRP's chunking behavior, it can fairly easily accommodate RTT.  My
own daughter would transmit messages in rapid succession so as to make any
IM protocol look real-time, so MSRP must be able to stand up to high load.

But, I do not want to cross the message boundary with erasure.  Once the
user hits ENTER (or whatever that will indicate that the end of the message
has been reached), I do not agree that any display device, IM logging
system, or other MSRP-enabled entity should have to deal with erasure back
past a message boundary.

Paul

> Sent: Saturday, March 22, 2008 4:35 AM
> The research was general. It is not only the lack of opportunity to 
> erase that causes stress in IM users.
> 
> There are many valid reasons to cheer up the user experience of IM by 
> making it real-time. Taken together, you should realize that the 
> reasons are compelling, and start working hard on it.
> 
> Gunnar
> 
> 
> 
> User stress with using IM is not a very compelling reason for me.  I 
> can't erase a spoken word.
> 
> > to settle application rules to MSRP so that it can be used with 
> > time- sampled transmission.
> >
> > and complexity and reduce the opportunity for MSRP messaging users 
> > to get their messaging exchange more lively. I think we should 
> > search
> our
> > Cc: '"'Gunnar Hellström'"'; 'Simple WG'; 
> > [email-masked]; 'Gregg Vanderheiden'
> > solution for SIP that works.  Thus far, that's not happened and I 
> > was excited by the prospect that MSRP might make that happen.  I 
> > compared to the processing of 50pps of audio and become a blip on 
> > the radar compared to video.
> > Further,
> > there is nothing "illegal" about sending 1 character per packet
> today,
> > so...
> > > Cc: "'Gunnar Hellström'"; 'Simple WG'; 
> > > [email-masked]; 'Gregg Vanderheiden'
> > > neat capabilities for muxing and controlling independent flows 
> > > that I've heard it said we've reinvented SCTP. But it is what it 
> > > is, and that's an awkward beast for carrying RTT.
> > >
> > > protocols suitable for end-to-end use in a session initiated by 
> > > SIP
> > or

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sun, 23 Mar 2008 14:50:43 -0500

Good,

One small edit to this.

I think it is  “agreement on which one to use for interconnection”   not
“get to an agreement of which one to use”

I don't think we should be dictating what companies do within closed
systems.   We might specify required performance, but not the transport
protocols.  

The key is that they interoperate – and can connect to each other (or
transport on the public systems) in a standard way.   But what they do
inside a proprietary or even closed system  (as long as they can
successfully transport and interconnect) should not be something we specify.

Agree?  

Gregg

 

  _____  

From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Sunday, March 23, 2008 3:15 AM
To: 'Gregg Vanderheiden'; 'Paul E. Jones'; 'Dean Willis'
Cc: [email-masked]; 'Simple WG'
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need

Gregg,

Gunnar

  _____  

Gregg

 

  _____  

Gregg,

Paul

 

 

Thanks

Gregg

---

From: Gregg Vanderheiden <[email-masked]>
Date: Fri, 21 Mar 2008 12:17:26 -0500

Hi Paul,

I don't think 4103 in parallel is "something else just for deaf people".  I
think (and have seen with AIM REAL-TIME/IM ) that there is very real market
for IM with real-time preview for mainstream users.  Not all want it - not
all want voice or video.  But many do.

The advantages of parallel 4103 and MSRP are many.

- better compatibility with other IM and REAL-TIME TEXT systems
- lower bandwidth
- MSRP looks like what people expect (and increases probability people won't
mess it up in implementation or setup)
- redundancy (failure of either channel for any reason is backed up by the
other  (Very important if going to be used for emergencies in the future)
- better compatibility with terminals that don't understand both
(implementing either correctly results in proper operation and successful
messages).

Compatibility with the older TTY is also important since one of the things
we are trying to do is eliminate the requirement on industry by the FCC that
TTYs be supported except in special gateways.   But it must work well there.

Finally - it would provide better compatibility with products that already
implement REAL-TIME TEXT using 4103.

HAVING SAID THAT -

I also fully support systems that want to do it ENTIRELY in MSRP.  But that
would be within their systems.  And it should be a companies (Or system's )
choice.    MSRP w/REAL-TIME TEXT preview or   MSRP with 4103 REAL-TIME TEXT
preview.   (or whatever IM and RTT they want to use)

Gregg

> Sent: Friday, March 21, 2008 11:57 AM
> To: 'Dean Willis'
> In any case, I do not think TOTE is the right solution.  I've
> also seen a proposal to send RFC 4103 in parallel to MSRP.  I
> believe anything that is outside of MSRP should be off the
> table for discussion, because anything else would:
>   3) Require special consideration for all manufacturers and
> network operators who
> I believe it is imperative that we bring to market a single
> IM solution for SIP that works.  Thus far, that's not
> happened and I was excited by the prospect that MSRP might
> make that happen.  I personally want a solution that is as
> natural as possible and will not present significant
> complexity to implement and deploy.
>
> Personally, I do not think we do.  However, many of the folks
> I've worked with in the deaf community feel we do.  Who am I
> to say what the deaf community needs?  In my view, if there
> is a significant portion of our global population that feels
> they need RTT, then we should find a way to make it work if
> there is a way to do it.
>
> MSRP is designed in such a way that we can enable it to
> support RTT without making great leaps.  Using the chunking
> method already defined within MSRP is fairly
> straight-forward.  The only thing I see it doing is
> increasing the bandwidth and number of packets that need to
> be processed.  As Geir Arne rightly point out, text packets
> are nothing compared to the processing of 50pps of audio and
> become a blip on the radar compared to video.  Further, there
> is nothing "illegal" about sending 1 character per packet today, so...
> I think it is important to decide whether we want to create
> an IM system that will work in the same way for RTT and
> non-RTT.  I would argue that it's a heck of a lot easier to
> accommodate both with MSRP than to consider separate
> solutions.  I want to find a way that will reduce complexity,
> reduce cost of development and deployment, and will enable us
> to meet forthcoming regulatory requirements.
>
> Paul
>

---

From: Gregg Vanderheiden <[email-masked]>
Date: Fri, 21 Mar 2008 23:23:42 -0500

Yes Paul it would be entirely redundant.  That was my point.  That would be
one of its strengths.

I don't think it necessarily complicates things.  They are both established
standards.  Voice and MSRP are both used together.   MSRP and 4103 can too.
Each have their strengths, and using them together may be much more
straightforward than trying to get one to function as two.

I think we should explore them both and see how the work out.  ALSO I think
both should be options going forward.  Companies can choose their options.

Gregg

> Sent: Friday, March 21, 2008 10:04 PM
> I view sending 4103 in parallel to MSRP as entirely
> redundant.  It will also be more complicated to deliver.
>
> In the face of all of the other complexities trying to get a
> single internationally supported IM system working -- and I
> will be quick to point out that we (the IETF) have been at
> this for nearly a decade -- I do not want to further delay
> efforts by adding more complexity.
>
> Paul
>
> > Sent: Friday, March 21, 2008 1:17 PM
> > I don't think 4103 in parallel is "something else just for deaf
> > people".  I think (and have seen with AIM REAL-TIME/IM )
> that there is
> > very real market for IM with real-time preview for
> mainstream users.
> > Not all want it - not all want voice or video.  But many do.
> >
> > - MSRP looks like what people expect (and increases
> probability people
> > won't mess it up in implementation or setup)
> > - redundancy (failure of either channel for any reason is
> backed up by
> > the other  (Very important if going to be used for
> emergencies in the
> > future)
> > (implementing either correctly results in proper operation and
> > successful messages).
> >
> > Compatibility with the older TTY is also important since one of the
> > things we are trying to do is eliminate the requirement on
> industry by
> > the FCC that
> > TTYs be supported except in special gateways.   But it must
> work well
> > there.
> >
> > Finally - it would provide better compatibility with products that
> > already implement REAL-TIME TEXT using 4103.
> >
> >
> > HAVING SAID THAT -
> >
> > I also fully support systems that want to do it ENTIRELY in
> MSRP.  But
> > that would be within their systems.  And it should be a
> companies (Or
> > system's )
> > choice.    MSRP w/REAL-TIME TEXT preview or   MSRP with
> 4103 REAL-TIME
> > TEXT
> > > personally want a solution that is as natural as possible
> and will
> > > not present significant complexity to implement and deploy.
> > >
> support RTT
> > > without making great leaps.  Using the chunking method already
> > > defined within MSRP is fairly straight-forward.  The only thing I
> > > see it doing is increasing the bandwidth and number of
> packets that
> > > need to be processed.  As Geir Arne rightly point out,
> text packets
> > > are nothing compared to the processing of 50pps of audio
> and become
> > > a blip on the radar compared to video.  Further, there is nothing
> > > "illegal" about sending 1 character per packet today,
> > so...
> > > reduce complexity, reduce cost of development and deployment, and
> > > will enable us to meet forthcoming regulatory requirements.
> > >
> > > Paul
> > >
> > > > > would think that if we present a strong-enough case for the
> > > > > first question ("why RTT?"), then I suspect there would be
> > > little debate

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sat, 22 Mar 2008 12:01:12 -0500

Paul,

You make statements like " there is no consideration whatsoever for RFC
4103."   Yet it was developed under commission from a major phone mfgr and
is embodied in carrier standards.

In fact there are more products that support 4103 than MSRP.  But that is
irrelevant.   That is like saying there are more PSTN phones than VoIP
phones so we should do VoIP.

Looking backward or even sideways is not the way to handle this discussion.

We need to look at what is correct going forward.  We need to keep an open
mind and look at all the options,  look in DETAIL at the implementations.

Things that look complicated often are not so bad and may be more stable.
Things that look simple have a nasty tendency to get more complicated in the
details.   Mixing things sometimes helps and sometimes is worse.

So instead of declaring one solution (That we haven’t implemented) the
winner lets at least get some implementations up and see how hard it is do
to things.   and their relative merits.

Lets do it quickly. Then lets look at both.   Then lets decide.   I do think
we want to move quickly.  I don't think we want to move precipitously.

Act in haste - repent at leisure.

So - lets stop deciding the results before we have the data.  Lets make some
systems both ways and look at implementation times and resulting robustness.
And see how both match up to the 'human' factor.

Gregg

> Sent: Saturday, March 22, 2008 10:51 AM
> I really see no value in the redundancy and I really do
> believe it complicates things.
>
> RFC 4103 all by itself complicates things enough, given that
> it is carried in an RTP stream that is separate from the
> voice steam.  For a gateway, this is a ugly.  For an IM
> client of some sort, it introduces a whole new protocol suite
> (RTP/RTCP and RFC 4103) that would otherwise not be there.
>
> If you're suggesting that an enterprise might do whatever it
> wants, I have no objection.  But, if you want to require that
> the carrier networks must transport both RFC 4103 and MSRP in
> parallel, I have real objections.
> Carriers in the US have largely agreed to use MSRP and there
> is no consideration whatsoever for RFC 4103.
>
> Paul
>
> > Sent: Saturday, March 22, 2008 12:24 AM
> > Yes Paul it would be entirely redundant.  That was my point.  That
> > would be one of its strengths.
> >
> > standards.  Voice and MSRP are both used together.   MSRP
> and 4103 can
> > too.
> > I think we should explore them both and see how the work
> out.  ALSO I
> > think both should be options going forward.  Companies can choose
> > their options.
> >
> >
> > Gregg
> [email-masked]
> redundant.  It
> > > will also be more complicated to deliver.
> > >
> > > In the face of all of the other complexities trying to
> get a single
> > > internationally supported IM system working -- and I will
> be quick
> > > to point out that we (the IETF) have been at this for nearly a
> > > decade -- I do not want to further delay efforts by adding more
> > > complexity.
> > >
> > > Paul
> > >
> > [email-masked]
> > > > Compatibility with the older TTY is also important since one of
> > > > the things we are trying to do is eliminate the requirement on
> > > industry by
> > > > the FCC that
> > > >  -- ------------------------------ Gregg C Vanderheiden Ph.D.
> > > > >   2) Create more work for everybody (phones, SBCs,
> softswitches,
> > > > etc.)

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Mar 2008 04:16:05 -0500

> Re-inventing SCTP with what?  RTT support or MSRP in general?

MSRP. It has a lot of the stream-muxing, HOLB-hacks, independent 
real-time channels and whatnot going on.
>   1) Create a special solution for deaf users

They seem to WANT a special solution. I'd rather rip my nose hair out 
with tweezers than do real time text, but if that's what people like to 
do, I'll help make tweezers. Just as long as it isn't MY nose.

> that is as natural as possible and will not present significant complexity

MSRP is currently a long way from making that happen -- its vey design 
goals are somewhat antagonistic towards real-time text.

> make it work if there is a way to do it.

I'm in favor of making it work.

> what would a system do?  It must handle it.

telnet frequently sends 1 cpp, and nobody complains much about it 
anymore. OTOH, it's TCP, so it is congestion friendly, which RTT/RTP is not.

> forthcoming regulatory requirements.

My guess is that the best answer to that is to revisit chat entirely and 
rip most of the complexity out of MSRP. But who knows, maybe some added 
complexity can make it work.

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Mar 2008 04:26:48 -0500

> order to satisfy user´s desires.

I'd like to cross message boundaries with erasure for email so I could 
backspace over this whole thread of conversation, but it isn't 
happening. Stop and think about it for a minute and you'll realize why 
-- we're talking about a one to many store and forward architecture, 
where many participants have a record-everything regulatory regime.

We've already defined a one-to-one real time text protocol with erasing. 
It's called "ntalk", and it's in pretty much every unix implementation 
out there and has been for years. People seem to have given up on taking 
it any further because of the limitations of trying to do n-way 
conferencing witout message boundaries.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 27 Mar 2008 19:22:55 -0400

Dean,

> do, I'll help make tweezers. Just as long as it isn't MY nose.

That's a graphic depiction.  I'm not sure if I'll be able to sleep tonight.

I don't want to create a special solution, either, which is why I want to
see RTT support within MSRP.  The way I view it, supporting
character-at-a-time transmission would not present a huge obstacle, since
MSRP allows for chunking as little as one character.

What I am really afraid of is requiring RFC 4103, either separately or in
parallel to MSRP.  Who would use it? Billions of people want an IM solution,
including the deaf community.  If we can get IM and RTT working via the same
protocol we all win.

On your UA, you would configure it to send messages in whole and to display
in whole.  You'll be happy.  A person who prefers RTT could configure their
UA to send character-at-a-time and display as soon as text arrives.

Like you, I really don't want to use a character-at-a-time transmission
mode, either.  Moving text is really hard for me to read, but I'm not sure
why.  It's quite distracting and I see no value in it personally.  But,
others want it-- so I would like to find a solution that makes it possible
to meet everybody's requirements.  And, I want to do that without having to
produce multiple solutions.

So, I guess the first question is whether MSRP is the right solution.

For in-dialog IM, is there any other alternative now or planned?

If not, other than the "it was not intended to be used for RTT" response, is
there a good reason to not use it?  (I say this as I am listening to a
128Kbps, 44KHz MP3 audio stream over HTTP... *ahem*).

The important thing to remember is that we *must* provide some solution that
will enable deaf people to communicate.  Every equipment manufacturer will
be given this mandate (sooner or later, and quite possibly soon).  I
personally do not think that we have to produce products with this solution
next week, because we still have to move all of the core telephony networks
to IP, else things will just break at every other gateway.  At the same
time, we can't wait until we've moved everything to IP and then try to
retrofit the solution, either.

So, I think the timing is appropriate.  We just need a solution and I do not
care what we do so long as it:
1) Does not require separate solution only used by the deaf community
2) Does not require a separate solution that must be implemented in parallel
to an IM solution that the vast number of people in the world want
3) Does not force me to watch text character-at-a-time
4) Does not require Dean to extract nasal hair

Paul

---

From: Gregg Vanderheiden <[email-masked]>
Date: Fri, 28 Mar 2008 00:50:02 -0500

I wish people would stop talking about "requiring" 4103.  No one is
suggesting that.

The most that has been suggested is that 4103 be supported at the periphery
for real-time text.

For real-time/IM and IM both - people can use what they like.

For REAL-TIME/IM
ONE -  OPTIONAL -  approach is to use an IM technology with a real-time text
technology to create real-time/IM.   This is what AOL did with their next
AIM client.    In their case they used their own IM and own real-time
technology.
     You can also use RFC4103 and an IM technology in this fashion - and it
has a number of advantages.   It requires implementing 4103 but if you have
RTP for voice - it is a simple addition.

ANOTHER - OPTIONAL - approach is to use an IM technology for both the
real-time text and the IM parts such as MSRP

I don't think we want to REQUIRE that people use anything.

For compatibility with other real-time text system we may say you need to be
able to interconnect with 4103 for real-time text.

For compatibility with other IM systems - we may want to say that you need
to be able to interconnect to MSRP for IM.

But what you use should be up to you within any closed systems.
At least that is where I thought we were headed.  Where we should be headed.

Gregg

> Sent: Thursday, March 27, 2008 6:23 PM
> To: 'Dean Willis'
> Cc: ''Gunnar Hellström''; 'Simple WG'; [email-masked]; 'Gregg
> Vanderheiden'
> Subject: RE: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-
> 00.txt - the need
>
> Dean,
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Mar 2008 19:07:54 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul E. Jones
>

I seem to have missed something - what does RTT IM have to do with the deaf community?  Last time I checked my IM doesn't make much noise. ;)

Are you thinking of an application where the audio RTP gets converted to RTT using speech-to-text?  And wouldn't that be done either within the UA of the deaf person, or by some application service for them which implements whatever special needs they have for such as well anyway? (and doesn't speech-to-text work better with longer input?)

Not that I don't think RTT is an interesting use-case, I just don't get what it has to do with the deaf community.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 28 Mar 2008 22:08:27 -0400

Hadriel,

> > So, I think the timing is appropriate.  We just need a solution and I
> do
> > not
> I seem to have missed something - what does RTT IM have to do with the
> deaf community?  Last time I checked my IM doesn't make much noise. ;)

After turning off those silly message notifications noises on my client,
mine is pretty quiet, too.  In any case, the requirement for a RTT solution
is being driven largely by a need to replace the legacy TTY devices used by
deaf people for something more modern-- and we need a solution that works
with SIP.  Deaf users need something that works in conjunction with the
phone -- not something that could be used separately from the phone, as
(virtually all) IM solutions are today.

In any case, the point you're getting at is that anybody can use this
technology and you're entirely correct.  However, we have to be careful not
to produce a solution that effectively reproduces the TTY and isolates
people.  Suppose, for example, that phones are required by law to support
RFC 4103.  All of the media richness possible through MSRP is lost: RFC 4103
is just text plain text.  Further, there's no concept of message separation:
it's a continual stream of text that works like the TTY.  If the government
mandates that on phones, would you use that or a richer IM client with buddy
lists, emoticons, avatars, stylish fonts, etc?

If the government mandates that the banks, hospitals, government agencies,
etc. must support something, then they will comply.  Whatever gets mandated,
I want it to be the technology that everybody wants and is ubiquitous.  I am
of the personal opinion that if RFC 4103 were mandated, then deaf people
will use one system and the rest of the world would use another.

So, that's the background :)
 
> Are you thinking of an application where the audio RTP gets converted
> to RTT using speech-to-text?  And wouldn't that be done either within
> the UA of the deaf person, or by some application service for them
> which implements whatever special needs they have for such as well
> anyway? (and doesn't speech-to-text work better with longer input?)

No, nothing to do with speech/text conversion.

> Not that I don't think RTT is an interesting use-case, I just don't get
> what it has to do with the deaf community.

Hopefully the explanation above makes sense.  We must produce something to
help move the deaf communicate away from TTYs.  They need an IP-based
solution and I would like that solution to be the same one everybody else in
the world is using.

Paul

---

From: Gregg Vanderheiden <[email-masked]>
Date: Sat, 29 Mar 2008 00:26:30 -0500

Actually real-time text does have to do with speech.  One of the major uses
of real-time text is and will be to caption speech.  People who are hard of
hearing have a caption service that will caption telephone calls for them.
They can hear the person at the other end speaking (so they get all the
intonation and rich paralinguistic information) but they have captions as
well so the can understand all the words they miss.  It is critical that the
caption be as close to the speech as possible.  Already the speech to text
(which is semi-automated and uses speech recognition - but an operator
re-voices everything today to make it work) -- already the speech to text
introduces a delay which causes some problems - but they do not want to
increase this delay any more.

SO yes - the real-time text is used with speech.

For people who are deaf - they also use it AS speech.   We, who can hear,
like messaging but we also use the phone a lot.  Different types of
communication at different times.    Some people who are deaf like IM BETTER
than real-time text.  Some like real-time text a lot better than IM when
they are conversing.   (Just like some people who can use the phone --
prefer IM while others prefer the phone).

For emergencies - the delay introduced by IM is substantial - especially for
people who type very slowly.   Or VEERRRYYY slowly.   It also leads to
crossed messages which can be a real problem.

In addition there are many who are still on the PSTN and do not have any IP
access.   They must use TTYs and need to have a natural way to communicate
with IP based population.

So it is multifaceted.

Again let me emphasize that no one is suggesting that anyone HAS to use any
technology within their systems.   There are some that PREFER to use 4103
for the real-time text and MSRP for messaging.   There are others the PREFER
to use MSRP for both.

We need to describe how each would work well for those who want to use each

And we need to describe how they would interconnect and interoperate.
There are already 4103 systems that need to interconnect and TTY gateways.
And there are systems that use real-time text that do not support IM.

So if we can focus on how each is done - and how to interconnect I think it
would be most useful.    As long as there is a debate about who prefers what
then we waste time and bandwidth.

The nature of standards is to allow different approaches to exist.  They
must interoperate but they do not need to be the same.

AND - real-time text is ALWAYS an option.   There is no requirement that you
use speech when you use IM.   There is not requirement that you use video
when you IM.   And there is no requirement that you use real-time text when
you IM either.     Many people hate the thought of video when IMing.   And
many will hate the thought of real-time text when IMing too. So it should
always be an option.  And aside from 9-1-1 situations I've never heard of it
being discussed as anything but an option.

In sum
- real-time text is always an option
- methods using only MSRP   as well as methods using MSRP and 4103 should be
defined for those who wish to use them

Thanks.

Gregg

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: Friday, March 28, 2008 9:08 PM
> To: 'Hadriel Kaplan'; 'Dean Willis'
> Cc: [email-masked]; ''Gunnar Hellström''; 'Simple WG'
> Subject: Re: [Simple]I-DAction:
> draft-hellstrom-simple-text-transmission-00.txt -the need
>
> Hadriel,
>
> > > So, I think the timing is appropriate.  We just need a
> solution and
> > > I
> > do
> > > not
> > > 2) Does not require a separate solution that must be
> implemented in
> > > parallel to an IM solution that the vast number of people in the
> > > world want
> After turning off those silly message notifications noises on
> my client, mine is pretty quiet, too.  In any case, the
> requirement for a RTT solution is being driven largely by a
> need to replace the legacy TTY devices used by deaf people
> for something more modern-- and we need a solution that works
> with SIP.  Deaf users need something that works in
> conjunction with the phone -- not something that could be
> used separately from the phone, as (virtually all) IM
> solutions are today.
>
> In any case, the point you're getting at is that anybody can
> use this technology and you're entirely correct.  However, we
> have to be careful not to produce a solution that effectively
> reproduces the TTY and isolates people.  Suppose, for
> example, that phones are required by law to support RFC 4103.
>  All of the media richness possible through MSRP is lost: RFC
> 4103 is just text plain text.  Further, there's no concept of
> message separation:
> it's a continual stream of text that works like the TTY.  If
> the government mandates that on phones, would you use that or
> a richer IM client with buddy lists, emoticons, avatars,
> stylish fonts, etc?
>
> If the government mandates that the banks, hospitals,
> government agencies, etc. must support something, then they
> will comply.  Whatever gets mandated, I want it to be the
> technology that everybody wants and is ubiquitous.  I am of
> the personal opinion that if RFC 4103 were mandated, then
> deaf people will use one system and the rest of the world
> would use another.
>
> > Not that I don't think RTT is an interesting use-case, I just don't
> > get what it has to do with the deaf community.
>
> Hopefully the explanation above makes sense.  We must produce
> something to help move the deaf communicate away from TTYs.
> They need an IP-based solution and I would like that solution
> to be the same one everybody else in the world is using.
>
> Paul
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 29 Mar 2008 07:38:35 +0100

Hadriel and Paul,
Two applications are discussed:

1. The phone concept extended by real-time text.
--------------------------------------------------
This application makes it possible to extend the real-time conversational
"phone" to handle any combination of real-time video, real-time text and
real-time audio in an ordered way so that you get good interoperability and
suitable quality for intensive conversations.

Text as well as the other media need to flow as they are produced to keep
both users in good contact and not start to wonder if the other party has
lost attention to the call. 

That application is covered by including RTP based real-time text according
to RFC 4103 in phones and videophones. 
In such intensive conversational situations, the users just want to type,
and do not take time to add extra features as pictures and andvanced
formatting. The basic Unicode set used in RFC 4103 seems to be sufficient
and a way to structure the text by using NewLine as a kind of message
delimiter.

Once you have this implemented in phones, it tends to be used quite often.
For hearing people it may be for items during a call that need exactness,
e.g. adresses, phone numbers, spellings etc. The rapidity helps, so that the
other party knows that text is coming and can start getting what it is.

It may be of extra value for deaf, hard-of-hearing, speech-impaired,
deaf-blind, people in noisy locations, people in locations requiring
silence, people with different dialects, people with different languages
etc, where the voice channel is of low or no use. 

But it is of good use for anyone, and more the more people have it in their
phones in an interoperable way. It extends the application area of the
"regular phone call". It is well standardised, deployed, works fine and
phone users would benefit from it being more widely spread. 

2. A live mode of Instant Messaging. ( and that is why we discuss it here in
SIMPLE )
----------------------------------------------------------------------------
---------
IM is picked up and deployed as a very useful tool. Originally it was
deployed separately from the phone concept, using its own protocols. Usually
the sender collects a sentence or a message before making a special action
to send it. It is perfect as long as it is used for a relatively slow
discussion, when it is more important to formulate your thoughts properly
than to make the other party aligned with your thinking.

When discussion get hot it shows some drawbacks that can be amended by
introducing automatic sending in suitable time samples, so that the other
party gets informed of what you are thinking without requiring you to make
any action to break up your text in shorter messages or anything. 

Both users get calmed by this transmission mode; the transmitting side knows
that the other party is following the thought so no need to search for the
earliest possible place to send, and the receiver can grasp the thoughts as
they evolve and do not need to sit in a stressful vacuum, starting to think
of new questions to place or more info to send. The discussion can get
intensive without causing stress and confusion.

This is of value for anyone and the list has shown enough interest for it to
continue defining a real-time mode of MSRP. 
People who have little or no use of voice are extra eager IM users, and
cannot divert to a voice call when the discussion gets too hot for the
message-wise mode of IM. Therefore the discussion about the interest for
deaf users to have this mode generally available. There are also relay
services based on IM today for translation between voice calls and text,
intended to connect deaf and hearing users. They would need the more lively
real-time mode of time-sampled transmission to get higher usability. 

The merge
----------
Seen separately, there are very good reasons to extend the phone concept by
including RTP based real-time text, and there are very good reasons to
soften the IM concept by a time-sampled text transmission mode. 

However, there is a tendency to include IM support in phones and a voice or
video call option in IM applications. RTP based real-time text is included
in general multimedia telephony  standards and product plans (sometimes
called Total conversation). If IM is made real-time in such merged
applications, the user experience can get quite similar to the extended
phone concept, even if the text component comes from different application
environments. That causes risks of interoperability problems between
different designs that can do similar things in different ways, that need to
be tackled.

The links to communication for deaf people
-------------------------------------------
Yes, there are some deaf-specific interest in this area. In PSTN, there are
textphones (TTYs in USA) that transmit character-by-character.
Interoperability with them requires gateways and a real-time text mode also
on the IP side. Some services, such as relay services and emergency services
are available in text mode only to such PSTN textphone interfaces and it is
important to maintain access to these services when moving to IP. There is
good work on including real-time text in emergency service and relay service
developments for IP, but you cannot be sure that implementations of IP
access to these services are phased with introduction of IP based terminals
with real-time text features everywhere. Therefore gateways are also needed.

Speech-to-text and text-to-speech
---------------------------------
There is of course also interest for speech-to-text and text-to-speech
applications from deaf people as well as from anybody. Once the straight
end-to-end transmissions of real-time text are common, it is fruitful to
continue building such services on top of it. A human operated such service
is the text relay service, that need the real-time text feature to perform
smoothly. 

Conclusion
----------
We have two ways to do real-time text. One ready RTP based that naturally
goes with phone and videophone designs to create Total conversation, and one
MSRP based in creation that we discuss here and applies to an enhanced
real-time IM experience. Both have general applications but have some
specific interests for deaf applications as well. Defining the real-time
text method in IM has some interoperability concerns with real-time text in
the phone concept, but it is better to give IM users an opportunity to have
smooth conversations than to avoid mentioning this feature in the IM world. 

Gunnar

-----Original Message-----
Paul E. Jones
Sent: Saturday, March 29, 2008 3:08 AM

Hadriel,

> > 2) Does not require a separate solution that must be implemented in 

 

Paul