[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE: text/T 140 andaudio/t140)
Agee with Keith but also, if we did put those words in, I don't think it
would in any way change the percentage of devices that did or did not
support t140.
On 7/18/04 6:14 AM, "Drage, Keith (Keith)" <drage at lucent.com> wrote:
> Sorry but NO.
>
> MSRP is the protocol definition, not the characteristics of an end device that
> may implement MSRP, and therefore should be independent of whether the UA is
> end user terminal, gateway or whatever. Additionally they are totally out of
> the current scope (abstract in IETF terms because they do not define MSRP).
>
> These words you have just proposed affect all UA and proxy implementations.
>
> If you want these words, put it in a device specification, and not the core
> MSRP definition.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: Eric Burger [mailto:eburger at brooktrout.com]
>> Sent: 18 July 2004 07:33
>> To: simple at ietf.org
>> Cc: Drage, Keith (Keith)
>> Subject: Suggested RTT text (was RE: [Simple] RE: [Sipping] RE:
>> text/T140 andaudio/t140)
>>
>>
>> After 420 pages of "discussion", may I humbly propose the
>> following text for
>> the MSRP document:
>>
>> User interfaces and user communities for instant messaging
>> and real-time
>> text telephony are extremely similar. MSRP is not an ideal
>> protocol for the
>> negotiation and transport of real-time text. However, devices that
>> implement MRSP SHOULD implement real-time text telephony,
>> using standard SIP
>> (RFC3261) and text/t140 (RFC2793bis) mechanisms.
>>
>>
>>
>> Rationale:
>> 1. It looks like consensus to putting RTP under MSRP is far,
>> far, away,
>> assuming it even makes sense, which it probably doesn't.
>>
>> 2. A whole bunch (80%?) of the code for an IM device would be
>> shared with a
>> RTT device - character input, character display, Internet
>> connectivity, SIP
>> stack, etc.
>>
>> 3. We have a charter obligation to make protocols amenable to building
>> devices that are accessible to everyone.
>>
>> This is an opportunity to meet the objections to trying to
>> shoehorn RTT into
>> MSRP (#1) with our Charter obligations (#3) without an undue
>> burden on the
>> implementer (#2).
>>
>>> -----Original Message-----
>>> From: Drage, Keith (Keith) [mailto:drage at lucent.com]
>>> Sent: Monday, July 05, 2004 5:54 AM
>>> To: simple at ietf.org
>>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140
>>> was:[avt]C omments/questions on draft-ietf-av
>>>
>>>
>>> Given the length of time this discussion has been going on,
>>> and the number of messages exchanged, is it not about time we
>>> reached some conclusions. These lists are to advance the
>>> deliverables in the working groups concerned, so how do any
>>> conclusions affect those deliverables.
>>>
>>> SIMPLE has a charter to produce instant messaging protocols.
>>> I do not see in all the discussion of the advantages of
>>> instant messaging versus real-time text removing that charter
>>> item. Therefore I suggest we STOP that discussion, or the
>>> proponents move it elsewhere.
>>>
>>> SIMPLE does not have a charter item to produce real-time text
>>> protocols. There is already an existing capability in IETF
>>> for real-time text protocols. It is not really up to SIMPLE
>>> to discuss whether that works well or not, as it was not
>>> developed under SIMPLEs charter.
>>>
>>> How terminals mix and match applications is not something
>>> that IETF traditionally deals with. Therefore I would suggest
>>> that any requirements that state RTT and IM must be
>>> implemented in the same terminal are out of scope of IETF.
>>> They should certainly be in some device specification rather
>>> than in the MSRP specification which SIMPLE is specifically
>>> delivering.
>>>
>>> I guess the questions as affecting MSRP really fall down to these:
>>>
>>> - Are there capabilities in MSRP that would lead to a
>>> valid RTT protocol that works better than the existing IETF
>>> solution, in addition to it fulfilling the requirements to
>>> provide an IM protocol. From the exchange of messages I have
>>> seem so far, it seems to me that the conclusion should be NO.
>>>
>>> - In order to deal with a body of users that have IM, and
>>> prefer to use IM, and a body of users that have RTT, and
>>> prefer to use RTT, is there a need to be able to interwork
>>> the two protocols at some intermediate point, and not just
>>> within the terminal by supporting both protocols under a
>>> common user interface? I see that as an element of the
>>> discussion just raised by Paul. Does such interworking, if
>>> required, have any impact on the contents of MSRP?
>>>
>>> regards
>>>
>>> Keith
>>>
>>> Keith Drage
>>> Lucent Technologies
>>> drage at lucent.com
>>> tel: +44 1793 776249
>>>
>>>
>>>> -----Original Message-----
>>>> From: Arnoud van Wijk [mailto:a.vwijk at viataal.nl]
>>>> Sent: 04 July 2004 10:43
>>>> To: hisham.khartabil at nokia.com; paulej at packetizer.com;
>>>> pkyzivat at cisco.com; Guido.Gybels at rnid.org.uk
>>>> Cc: fluffy at cisco.com; simple at ietf.org; gv at trace.wisc.edu;
>>>> toip at snowshore.com; gunnar.hellstrom at omnitor.se;
>> smundra at telogy.com
>>>> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 andaudio/t140
>>>> was:[avt]Comments/questions on draft-ietf-av
>>>>
>>>>
>>>> Never say never.
>>>> Have you tried interactive text/real-time text?
>>>> Did you?
>>>>
>>>> First try it and THEN you can say if you like it or not.
>>>>
>>>> If you want to determine how useful it is. Test it.
>>>> Use it
>>>> Try it
>>>> Compare it with IM.
>>>> See the differences between IM and RTT/Interactive text.
>>>> See that both text communication methods have their advantages and
>>>> disadvantages.
>>>> And use both for the best situations.
>>>>
>>>> And if you still don't want to use RTT/Interactive
>>>> text..fine..I just hope
>>>> that when I call you, that you can still receive my call.
>>>> Just use it only
>>>> when the other person uses Interactive text/RTT.
>>>> Even if it is then 3-4 times per year.
>>>>
>>>> Can you with IM:
>>>> * directly call the other?
>>>> * forward the call?
>>>> * put on hold?
>>>> * have the call go to multiple terminals?
>>>> * not being logged on a buddy list server, where you may get
>>>> flooded by 20
>>>> users at the same time saying hi! And such?
>>>> * being able to leave a message on an answering machine?
>>>> * using a service that allows a ring notifivation as soon the
>>>> other user is
>>>> ready with his/her other phonecall? (ring back on busy).
>>>>
>>>> There are more.. but I am unfamiliar with voice calls. I am
>>>> just enjoying my
>>>> freedom of communications beyond the IM limitations.
>>>>
>>>> And I enjoy using IM also..even though I am forced to use
>>>> Trillian, since
>>>> there is NO one universal standard for IM right now!
>>>>
>>>> Interactive text is!
>>>>
>>>> Greetz
>>>>
>>>> Arnoud
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> Simple at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
>>
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple