[Standards] XEP-0308 and "Linear Real-Time Text" (TDD/textphones) - it is NOT a technical solution to social problem in this case.

Mark Rejhon markybox at gmail.com
Wed Aug 15 03:43:36 UTC 2012


On Tue, Aug 14, 2012 at 11:37 PM, Mark Rejhon <markybox at gmail.com> wrote:
> On Tue, Aug 14, 2012 at 3:21 PM, Kim Alvefur <zash at zash.se> wrote:
>> On 2012-08-14T20:09:28 CEST, Kurt Zeilenga wrote:
>>> The more I think about it, the more I think I that this XEP is a bad idea.
>>
>> I think the concept itself is a bad idea, but since some people really
>> want to have this feature, having a XEP for it might be better than not
>> having one.  I do agree with Peter about this largely being a technical
>> solution to a social problem.
>
> Actually, not necessarily a technical solution to a social problem,
> for certain situations:
> It solves the "linear real-time text problem".   TDD's (text
> telephones) transmit as a single stream of continuous real time text,
> with no message boundaries.

Note -- RFC4103 is another linear real-time text technology that has
no concept of message boundaries.
(On RFC4103, you can backspace linefeeds).  So the combination of 0301
and 0308 can enhances gateway interop with linear real-time text
technologies;

Sincerely,
Mark Rejhon
>
> Gatewaying instant messaging (with XEP-0301 real time text) to text
> telephones or other linear real-time text technologies, represents
> some compromises when needing to backspace across message boundaries
> (e.g. to the previous message).
>
> The existence of XEP-0308 solves this problem.
> And, the existence of multiple-message correction allows backspacing
> back across more than one message (especially if several <Enter>
> keypresses were accidentally hit on a TDD / text telephone)
>
> Therefore, XEP-0308 (as agreed by me and Gunnar) is one solution to
> the "linear real time text" problem; it makes it possible to backspace
> across message boundaries, when gatewaying between linear real-time
> text to instant messaging, and vice-versa.
>
> Sincerely,
> Mark Rejhon



More information about the Standards mailing list