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:trevorf@xxxxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, October 23, 2002 8:09 PM > To: Dean Povey; Stefan Santesson > Cc: ietf-pkix@xxxxxxx > 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:povey@xxxxxxxxxxxxx] > Sent: Wednesday, October 23, 2002 4:04 PM > To: Stefan Santesson > Cc: ietf-pkix@xxxxxxx > 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: povey@xxxxxxxxxxxxx|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 > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature