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

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Hi Denis,
Can you please elaborate on you comment of "... adding audio to the
interface design does not mean adding audio for everything" I don't
understand the point you are making. 

The decision on if or when to display the logotype / play the audio is
down to the interface designer. There are plenty of UI designs shipped
in products for X.509 certificates just displaying text names which are
unusable - but I don't hold that to be the problem RFC3280.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx] 
Sent: Thursday, October 24, 2002 2:37 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: draft-ietf-pkix-logotypes-06.txt


Stefan,

> I mostly agree with you.
> 
> What I mean is that there is some line, beyond which you just need to
accept
> the whish to do something and say - OK if some implementers want to do
this
> type of thing, what is the best way to do it?
> 
> I think the most cases where a firm requirement is badly needed is
where
> someone what to do something in a different way, where current
standard
> gives another way of doing almost the same thing, and where doing the
> proposed changes/amendments would produce alternative solutions to
closely
> related problem (Like the PI versus serialNumber Attributes, OCSPv2
versus
> SCVP, CMP versus CMC .....)
> 
> I think Trevor has demonstrated a reasonable need to use audio with
> Logotypes.

The argument from Trevor is not convincing: adding audio to the
interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or
bad), 
from at least two of the co-editors of the document. :-(

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: owner-ietf-pkix@xxxxxxxxxxxx
>>[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Dean Povey
>>Sent: Thursday, October 24, 2002 1:04 AM
>>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
>>
>>
>>
> 
> 
>