[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,
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:paulej at packetizer.com]
Sent: Saturday, March 22, 2008 5:34 PM
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,
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
> -----Original Message-----
> From: Gunnar Hellström [mailto:gunnar.hellstrom at omnitor.se]
> Sent: Saturday, March 22, 2008 4:35 AM
> 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,
> 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.tx
> > > t
> > >
> > > 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