Subject: RE: draft-ietf-pkix-logotypes-06.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 24 Oct 2002 08:41:52 -0700

Trevor makes a good point. It is really easy for folk to
ignore accessibility issues.

I have a visual disability problem, whenever I am using a
telephone I cannot see the other person.

One of the main ways the Web was screwed up was that the
carefully designed accessible formats were bowlderized by 
Netscape. Inline font specifications instead of style
sheets, tables for text formatting instead of text flow etc.

As a result HTML is now pretty incompatible with cell phones
and PDAs.

Most computerised equipment has either a visual or an audio
interface. There is a very large class of device that
only has an audio interface.

One of the bugs of IETF process is that it allows people with 
no actual responsibility to customers to pontificate as to 
whether a feature is a requirement or not. Case in point
the ability to deploy DNSSEC in .com and .net has been a 
disputed requirement for over 3 years now.

If the spec describes audio and nobody deploys there is
no harm done.

If the spec does not describe audio and Microsoft and VeriSign
deploy anyway there is a small risk of loss of interoperability
but a much larger risk that people looking for the definitive
certificate specification look on the VeriSign and Microsoft
research sites.

It is completely illogical for people to make the fuss they are
making unless there is some reason that they think that by
disputing the issue here they can somehow stop the technology.
You don't stop a technology by filibustering a working group,
you stop a technology by filling a continuation in part on a
1956 patent claiming retrospectively to have invented it.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2002 8:09 PM
> To: Dean Povey; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-logotypes-06.txt 
> 
> 
> 
> Dean,
> The case for audio is simple. People with specific types of visual
> disability will not gain any benefit from a logotype image even if you
> magnify the image. To help these people the general advice from
> Microsoft and other accessibly groups is to add audio the interface
> design. 
> 
> Trevor
> 
> -----Original Message-----
> From: Dean Povey [mailto:[email-masked]] 
> Sent: Wednesday, October 23, 2002 4:04 PM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt 
> 
> 
> >
> >If audio is supported in the protocol in a well structured 
> manner, and
> >nobody deploys it, then it's just dropped before it becomes standard.
> >
> >I do believe though that the deployment industry is likely 
> to find some
> use
> >for it.
> >
> 
> Err, I think the rule is that we start with a firm requirement and
> implement something.  I think there has been a failure to 
> demonstrate a
> firm requirement. If someone can come up with a plausible meaningful
> reason
> to put audio in certificates then we can consider it.  Until then, we
> should concentrate on solving actual problems, not dreaming up
> hypothetical
> ones.  Why isn't there support for MPEG movies in the draft for 
> example? (I hope this doesn't give anyone ideas :-).
> 
> As someone who has to implement this stuff, let me just say that there
> is a
> cost to specifying something that won't (or shouldn't) be used.  You
> still
> end up having to implement and test it to give the perception 
> that your
> products are complying with standards.  It is precisely this
> overspecification in the ITU-T standards that has led to so 
> much garbage
> which has to be supported already.  The certificate path processing
> algorithm is a case in point.  Its complexity is created by a large
> number
> of rarely used extensions whose usefulness is dubious at best.
> 
> So, come up with a plausible use case for audio that cannot be met by
> existing mechanisms, and it can be considered, otherwise drop it, and
> make
> implementers lives a little easier.
> 
> -- 
> Dean Povey,             |em: [email-masked]|JCSI: Java security
> toolkit
> Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI
> toolkit
> Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL
> toolkit
> Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
> Signatures 
> 
>