[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-00.txt - the need
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
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom at omnitor.se
Tel: +46708204288
www.omnitor.se
-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Saturday, March 22, 2008 4:29 AM
To: 'Gunnar Hellström'; 'Dean Willis'
Cc: 'Simple WG'; Erik.Zetterstrom at omnitor.se; 'Gregg Vanderheiden'
Subject: RE: [Simple] I-DAction:
draft-hellstrom-simple-text-transmission-00.txt - the need
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
> -----Original Message-----
> From: Gunnar Hellström [mailto:gunnar.hellstrom at omnitor.se]
> Sent: Friday, March 21, 2008 7:15 PM
> To: 'Paul E. Jones'; 'Dean Willis'
> Cc: 'Simple WG'; Erik.Zetterstrom at omnitor.se; 'Gregg Vanderheiden'
> Subject: RE: [Simple] I-DAction: draft-hellstrom-simple-text-
> transmission-00.txt - the need
>
> 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
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom at omnitor.se
> Tel: +46708204288
> www.omnitor.se
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Friday, March 21, 2008 5:57 PM
> To: 'Dean Willis'
> Cc: '"'Gunnar Hellström'"'; 'Simple WG'; Erik.Zetterstrom at omnitor.se;
> '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
>
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis at softarmor.com]
> > Sent: Monday, March 17, 2008 2:29 PM
> > To: Paul E. Jones
> > Cc: "'Gunnar Hellström'"; 'Simple WG'; Erik.Zetterstrom at omnitor.se;
> > 'Gregg Vanderheiden'
> > Subject: Re: [Simple] I-DAction: draft-hellstrom-simple-text-
> > transmission-00.txt - the need
> >
> >
> > On Mar 16, 2008, at 3:48 PM, Paul E. Jones wrote:
> >
> > >
> > > 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.
> >
> > 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
> >
>
>
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple