Subject: Re: [Speechsc] Re: Request for review and feedback ondraft-ietf-speechsc-reqts-02.txt

From: "Guido Gybels" <[email-masked]>
Date: Fri, 06 Jun 2003 16:28:11 +0100

David,

<<I realized that I may never have replied to this, although the spec was updated a while ago based on these very good comments. It will be 
re-submitted for IESG review in the next few days.>>

Thanks for the reply and for the very positive way you have approached the issues of people with disabilities. It seems most of the open questions we had have been answered/addressed. There is, however, one remaining issue:

<<Guido: 6.1 Requesting SI/SV
"   The SPEECHSC framework MUST allow a Media Processing Entity to
    request the SI/SV Server to perform speaker identification or
    verification on an RTP stream, returning the results over
    SPEECHSC."
Presumably, the results of the identification/validation are returned
over SPEECHSC?
In the context of SIP: In the event of a speech impaired user, who
would prefer using an outbound text stream, how would he, as a
"speaker", be identified or verified? Is there some sort of
pass-through to another protocol to identify/verify him?>>

<<David: This is an example of a general problem of what to do when use of speech 
processing may be simply inappropriate. I've added the following text to 
the on the general requirement to address handicapped users:
"It is also important that implementers of SPEECHSC clients and servers bec
 ognizant that some interaction modalities of SPEECHSC may be inconvenient,o
 r simply inappropriate for handicapped users. Hearing-impaired users mayf
 ind TTS of limited utility. Spech-impaired users may be unable to make useo
 f ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC need 
to, where feasible, provide alternative interaction modes or avoid the useo
 f speech processing entirely.">>

I think we must make it clear to service providers that it is imperative (and more and more a legal requirement) to build services and products in such a way that they are accessible and usable by *all* people, regardless of their abilities and preferences. Also, I have some issues with the way we talk about people with disabilities, so I suggest we change this to the following:

"It is also important that implementers of SPEECHSC clients and servers be cognizant that some interaction modalities of SPEECHSC may be inconvenient, or simply inappropriate for people with disabilities. Hearing-impaired users may find TTS of limited utility. Spech-impaired users may be unable to make use of ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC MUST provide alternative, equivalent interaction modes or avoid the use of speech processing entirely."

Let me all know what you think. I'll be in Vienna, so we can talk in more detail about this there as well if you want to.
Best regards,

Guido

Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069

************************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.

If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.

If you have received this email in error please notify the RNID
Helpdesk by telephone on: +44 (0) 207 296 8282.

The Royal National Institute for Deaf People  
Registered Office 19-23 Featherstone Street 
London EC1Y 8SL No. 454169 (England)
Registered Charity No. 207720
************************************************************************

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: David Oran <[email-masked]>
Date: Fri, 06 Jun 2003 14:09:55 -0400

--On Friday, June 06, 2003 4:28 PM +0100 Guido Gybels 
<[email-masked]> wrote:

> David,
>
> <<I realized that I may never have replied to this, although the spec was
> updated a while ago based on these very good comments. It will be
> Thanks for the reply and for the very positive way you have approached
> the issues of people with disabilities. It seems most of the open
> questions we had have been answered/addressed. There is, however, one
> remaining issue:
>
The exact mechanism is likely to be implementation-specific, but my 
suspicion is that there would be some kind of fallback to a text-based 
scheme rather than pass-through. Since we have the requirement discussed 
below, this means that whatever is providing the front end client to 
SPEECHSC will have to figure out it is interacting with a handicapped user. 
For example, if it's a SIP based user endpoint owned by the handicapped 
user (e.g. a PC or PDA-like device) the device knows already who the user 
is and what the capabilities are, and would have the state and policy 
information to know that some alternative interaction modality has to be 
used, or possibly it would have the ability to "spoof" user input (e.g. 
play out a pre-recorded anme for speaker announcement - this works for 
conference servers but obvious not for authentication/authorization usage).

In the case of a legacy device or a gateway to a legacy device, there would 
need to be some heuristics. For example, detecting a TTD instead of an 
audio input from a phone would cause the media processing entity in the 
speechsc model to know it should not do certain things with Speechsc. 
Assuming some kind of VXML-driven IVR application, it seems the appropriate 
thing to do is to redirect to an IVR-menu tree specifically crafted for a 
hearing/speech impaired user.

This is a long way of saying that I think we have the bases covered by the 
requirement cited below.

> <<David: This is an example of a general problem of what to do when use
> of speech  processing may be simply inappropriate. I've added the
> following text to  the on the general requirement to address handicapped
> users:
> "It is also important that implementers of SPEECHSC clients and servers
> be cognizant that some interaction modalities of SPEECHSC may be
> inconvenient,o  r simply inappropriate for handicapped users.
> Hearing-impaired users mayf  ind TTS of limited utility. Spech-impaired
> users may be unable to make useo  f ASR or SI/SV capabilities. Therefore,
> systems employing SPEECHSC need  to, where feasible, provide alternative
> interaction modes or avoid the useo  f speech processing entirely.">>
>
> I think we must make it clear to service providers that it is imperative
> (and more and more a legal requirement) to build services and products in
> such a way that they are accessible and usable by *all* people,
> regardless of their abilities and preferences. Also, I have some issues
> with the way we talk about people with disabilities, so I suggest we
> change this to the following:
>
> "It is also important that implementers of SPEECHSC clients and servers
> be cognizant that some interaction modalities of SPEECHSC may be
> inconvenient, or simply inappropriate for people with disabilities.
> Hearing-impaired users may find TTS of limited utility. Spech-impaired
> users may be unable to make use of ASR or SI/SV capabilities. Therefore,
> systems employing SPEECHSC MUST provide alternative, equivalent
> interaction modes or avoid the use of speech processing entirely."
>
I'm happy with your replacement text, if the Area directors are. One thing 
we have taken care to dance around is to what extent we can/should write 
requirements for the implementation of client applications which do not 
themselves affect the design or implementation of the protocol. I don't 
want to run afoul or overstepping the charter of the WG in this regard.

I have already sent the txt in for final approval by the IESG and 
publication, so if it's ok with the ADs I can recommend this change as 
edits to be done by the rfc editor as part of the publication process.

> Let me all know what you think. I'll be in Vienna, so we can talk in more
> detail about this there as well if you want to. Best regards,
>
I'll look forward to seeing you, but hopefully the requirements will be 
already published as an RFC by then and we can forge ahead with making sure 
the protocol in fact meets the requirements!

Best regards, Dave.