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

[Ben Campbell <ben at estacado.net>]

Apologies to all to jumping in here late--but I figured it was still  
better to get my concerns on list prior to the meeting:

On Jan 30, 2008, at 5:24 PM, Paul E. Jones wrote:

> Folks,
>
> During the middle of the month, there was a little discussion on the  
> draft
> draft-hellstrom-simple-text-transmission-00.  As discussed, this  
> draft is
> intended to provide a means of enabling real-time text transmission  
> between
> devices using MSRP.
>
> Looking through the discussion that took place, I believe the only  
> concern
> was that an MSRP relay might collect several text chunks and combine  
> that,
> thus effectively breaking RTT communication.  That's true and we  
> cannot
> prevent it, but as Gunnar highlighted, there is an attribute  
> included that
> provides a hint to relays that immediate delivery is required.  We  
> may need
> a stronger hint and/or means to select MSRP relays that will deliver  
> the
> functionality we need.
>

Is the "strong hint" of which you speak the content-disposition  
header? If so, then relays as currently defined are going to ignore it.

I don't think chunking is the right tool for handling the real-time  
text presentation, due to the reasons in issue 4. The previous thread  
on the subject talks about various ways to make relays treat real-time  
text differently. I don't see how you can do this without serious  
modifications to MSRP. One would be better off sending each time-slice  
as "whole message", and define a higher level protocol to stream the  
messages together.


> Were there any other concerns?

I think someone mentioned bandwidth overhead.  I have no idea how many  
characters an average typist can type inside a 500ms window, but I can  
only assume it's a small number.  Even with the minimal set of MSRP  
headers, you are talking about huge overhead. The chunk example in the  
draft has an overhead on the order of 200-1.


>
>
> While there are certainly issues we need to address (and several  
> noted in
> the initial draft), we wanted to put this before the group to try to  
> build
> consensus for this general direction.  It seems that there was  
> support for
> this idea (and no objection that I could see).  As such, would be  
> acceptable
> to the group to make this a work item and begin actively progressing  
> the
> draft within SIMPLE?
>

I have no objection to working on real-time text in SIMPLE--but I do  
not think MSRP is the right tool for this. It's simply not designed  
for this use case. Trying to force-fit real-time text requirements on  
MSRP is either going to fail to meet the requirements, or it is going  
to result in fundamental, probably non-backwards-compatible, changes  
to MSRP.


> Thanks,
> Paul
>
>
>
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

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