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

[Dean Willis <dean.willis at softarmor.com>]

Paul E. Jones wrote:
> Dean, at al,
> 
> 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.
> 
> 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

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.

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

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


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

I'm in favor of making it work.


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

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.

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

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.

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