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

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
-------------------------------------------------------------------
Gunnar Hellström
Omnitor

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
Ben Campbell
Sent: Sunday, March 09, 2008 2:55 PM
To: Gunnar Hellström
Cc: 'Paul E. Jones'; Erik.Zetterstrom@omnitor.se; '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.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

__________ NOD32 2932 (20080309) Information __________

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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple