[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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