Thread Subject: Re: Postpone the Real-time text discussion

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Mon, Aug 13 2007 10:25 AM

Hi Peter,

Without specifics its hard to understand exactly what you are proposing.

But guessing as some things - here are a couple comments to start with.


* Part of this seems to be to allow people using different technologies (you
cite Skype) to use their own format for Real-time text. That is already
possible with the current language. No one has to use RFC-4103 or 4351
EXCEPT where they interface with OTHER systems using SIP. Otherwise they
are free to use whatever reliable real-time text format they wish.

* with what you do propose it is unclear how you would handle
interoperability.
- how would a person making a Skype out call to a phone ensure that the
real-time text program on your computer would work with their TTY?
- how would you ensure that it would work with an real-time text program on
a Mac?
- would all the real-time text help applications need to be the same and
use the same protocol? Else how would they interoperate?

* would old folk have to make two calls? One voice and one text? how would
they know to do this? how would they remember both numbers / addresses and
do them both together?

More questions but have to run to General call right now.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Monday, August 13, 2007 1:09 AM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Postpone the Real-time text discussion
>
> Hi Gregg,
>
> For #1 below ("A proposal from Peter on his alternate
> approach"), I don't have a "formal proposal" to hand.
>
> > In prep for the next discussion on Real-time text we were
> supposed to have > > 1) A proposal from Peter on his
> alternate approach > 2) A list of needs/requirements from
> consumers > 3) The combination proposals of D & E and also
> B& C if possible.
> >
> > #3 is completed and can be found from a link off of the
> EWG pages for this section at >
> http://teitac.org/wiki/EWG:_Draft_July_18:_Section_5_Comments
> >
> >
> > Gregg
>
> My thoughts on this come from the draft provisions requiring
> support for RTT (Real-Time-Text) everywhere that we current
> have audio communications on the desktop (which nearly by
> definition includes video), and everywhere where we have
> "chat" communications on the desktop. I do not come at this
> from a Telecom background, and have not thought through
> whether or how this would impact traditional telecommunications.
>
> The idea is that, from a user point of view, the desktop
> experience for RTT is very similar to the experience of
> following hyperlinks.
>
> Today on most graphical desktops, when a URL appears in your
> e-mail (Thunderbird, Evolution, Outlook, Eudora, etc.), it
> appears underlined and in blue, ready to be clicked on.
> Similarly when a URL appears in your office suite (MS-Office,
> StarOffice, OpenOffice.org), in your PDF viewer (Adobe
> Reader), etc. Whenever we see these "enabled hyperlinks", in
> a wide variety of different programs used for displaying
> text, we know we can click on them to invoke the hyperlink.
> And when we do, these various applications will all launch
> the "desktop web browser application" - typically Internet
> Explorer or Firefox. What these applications don't do is
> attempt to display the web page from within their own
> application (e.g. showing the web page there inside the
> OpenOffice.org window, or the Adobe Reader window) - they
> invoke the web browsing "helper application".
>
> In much the same way, I think we can address the requirement
> for RTT on the desktop. Rather than requiring that every
> audio/video/chat application itself implement a RTT option
> (and every audio/video/chat prototol support RTT directly,
> and every audio/video/chat server support RTT), instead these
> applications must simply invoke a desktop RTT "helper
> application" that handles the RTT communication, which could
> happen in parallel with the audio/video/chat conversation.
>
> If we address the RTT support in this fashion, it greatly
> reduces the expense on industry because it doesn't require
> that every audio/video/chat server support RTT directly. It
> doesn't require that the existing network protocols used for
> audio/video/chat be extended to support RTT (via RFC 4103 or
> any other specific protocol mechanism). It does require a
> few, fairly small things:
> 1. that the desktop define a "RTT application" that handles
> RTT protocols, in the same way as the desktop defines what
> "the default web browser" is (and what application should be
> invoked to read .gif files, .jpg files, etc.).
> 2. that every audio/video/chat application that conforms to
> the draft refreshed 508 standard be able to invoke the
> desktop RTT application 3. that the vcard information for
> users of every audio/video/chat application include a field
> for the users' RTT address (and that we define such a
> standard addressing scheme)
>
> I've talked with the Sun engineers involved in the video and
> chat applications we include in Solaris (and that we get from
> the open source GNOME community), and they have confirmed my
> suspicion - implementation of what I am proposing is a small
> number of engineer-months; implementing RTT into the
> applications directly (and the protocols and the servers) is
> multiple years of effort.
>
> Another attraction from going the "helper application" route
> is that it doesn't constrain innovation in communication
> protocols and mechanisms.
> We are seeing a lot of innovation in computer-based
> communication mechanisms - things like Skype for the desktop
> that didn't exist just a few years ago (and in Skype's case,
> a technology that uses peer-to-peer networking in order to be
> network utilization efficient and avoid the need for a large
> server infrastructure). I am personally very reluctant to
> insist that all future communications protocols explicitly
> include an implementation of RFC 4103 or any specific
> protocol. But I am quite comfortable saying that we should
> have a RTT helper application that handles such things, and
> that our audio/video/chat software should know enough to
> invoke it when the users requests it.
>
>
> What this means in end-user terms is that when they are
> engaging in a non-RTT conversation with someone, and want to
> shift to or supplement with RTT, that they use some keyboard
> or mouse gesture (which may differ from one audio/video/chat
> application to another) to indicate that they want to have a
> RTT conversation with the person they are communication with,
> and their RTT application initiates a connection to the
> remote users' system, doing so in another widow with another
> application (and via a different network protocol). As the
> RTT conversation is with a different application in a
> different window, the user may need to arrange/re-arrange two
> different windows in order to have them not overlap on their
> screen [something that they might have had to do even if RTT
> was "integrated" into their audio/video/chat application, as
> multi-windows for this might be an implementation detail -
> certainly the draft provision makes no mention of this].
> Also, as the RTT conversation is potentially using a
> different network protocol (and different servers, gateways,
> etc.), the performance characteristics may be different from
> the audio/video/chat conversation. E.g. a Skype user whose
> audio conversation is happening via a distributed
> peer-to-peer network might invoke a point-to-point RTT
> conversation (in which case, the RTT might in fact be
> faster!). Likewise an IRC chat conversation between two
> users in California might be going through a server in
> Sweden; the RTT conversation they invoke might again be
> point-to-point (or perhaps it goes through a different
> gateway in some other location than Sweden). This has
> implications on the relative performance guarantees one can
> make. Frankly because text consumes so much less bandwidth
> than audio or video, I believe in most cases an overall
> bandwidth deficit for RTT won't in practice be an issue.
> This is something we would need to model in practice, with
> prototype implementations in a variety of situations, to verify.
>
>
> In our con-call last week, if memory serves Gregg
> Vanderheiden suggested that the existing draft provisions
> would accommodate the "helper application" approach I have
> sketched out. Perhaps so, but I am not so certain of that.
> I find the language too ambiguous to feel comfortable telling
> my engineers that such an implementation would comply under
> the draft language. For example, if a user I am
> communicating with doesn't choose to have an RTT vcard field
> (e.g. they expressly decline to engage in RTT conversations),
> would the helper application implementation then fail to meet
> 508 (how can my implementation require an end user expose
> certain information)? Likewise, if the desktop selection of
> the RTT helper application were to get altered/corrupted,
> would that then make my chat application non-compliant? And,
> as I noted in my original concerns about the Section 5 draft
> language on RTT requirements, when the audio/video/chat
> software is part of a larger operating system release (which
> contains a RTT helper application), but I am having to
> provide a 508 assessment of *just* the audio/video/chat
> software alone, how can I state whether that software
> complies with the RTT provisions?
>
>
> What I would like to do is:
> 1. Verify that the implementation I have sketched out does
> or does not meet the desires of the community seeking RTT
> support 2. If this does meet those desires, review and
> update the language to make this unambiguously clear 3. If
> this does meet those desires, figure out how this impacts the
> more traditional (e.g. non-desktop) telecommunications world,
> especially when it comes to interoperability
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University