[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: going back to stone axes
"Perry E. Metzger" <uunet!piermont.com!perry>
> The bits aren't especially complicated here. In fact, in general, they
> are usually very simple from what I can tell.
Without the characteristics of SPKI being spelled out I don't see how
it is possible to tell how simple or complex the bits on the wire will be.
> The complicated part of
> getting a protocol right has always been, for me, figuring out what
> you want the thing to do properly, never actually expressing the bits
> and exchanges once you've figured it out.
That is *precisely* why one would use ASN.1 as a modelling tool.
> > How do you propose handling internationalization? Is spki targeted
> > mainly at the English speaking world?
> Well, one might note that the major entities one might want to mention
> in a certificate are things like domain names, which are already
> constrained to be in ASCII. If it appears that other things have to be
> encoded, I'd say that going for UNICODE certificates would be a big
> mistake -- it would eliminate all the benefits of ASCII but force all
> the worst problems associated with such a format. If we had to encode
> such things routinely, either an ASCII encoding of those entities
> like the one used in mail headers ought to be stolen, or a binary
> format selected.
Given that we are presumably starting out from a "blank sheet of
paper", and given that we have not detailed the characteristics of
SPKI as yet, I can't make the assumptions that you do above. Use of
ASCII, only, has obvious benefits, but I don't think use of Unicode
should be ruled out until the decision has been made that the only
words one might ever want to encode efficiently in a certificate are
based on English.
I think it is probably premature to discuss how things will be
encoded, given that the characteristics of SPKI have not been
decided on as yet. Maybe this whole issue of encoding should
be put aside until SPKI takes on characteristics.