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

Re: going back to stone axes

Speaking for myself and not as chair...

Bancroft Scott writes:
> "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 experimentation I've been part of leads me to believe that there
is no real complexity here.

Having designed a large number of ad hoc protocols over the years,
encodings have never once been a serious time consumer for me, EXCEPT
in those situations where to "save effort" systems like ASN.1
compilers were used to "help" the designers.

> > 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.

I don't think you get it. ASN.1 would be a good tool if, and only if,
worrying about the bits was a problem and it freed you from having to
worry about the bits so you could concentrate on the
protocol. However, worrying about the bits has never actually been a
major concern, so the motivation goes away. Furthermore, in my own
opinion, ASN.1 is neither simple or pleasant to use. I realize you
will argue otherwise, but I doubt you will succeed in convincing me --
I have too much personal experience.

Last, and most importantly, ASN.1 could only help you once, in the
design phase, which is short and not particularly important compared
to the usage phase, which is forever. Its damn simple for me to write
and debug tools to communcate with, say, SMTP servers, and I
frequently produce Ad Hoc tools to do that sort of thing, even in very
simpleminded languages like Perl. Trying to write and debug tools to
communicate with SNMP servers is hard, precisely because of the
"simplification" that the ASN.1 brings you.

I'd say that a design goal here should be that you should be able to
prototype most of the software for the system in a small amount of
Perl or scheme or some similar fairly simple language.

> > > 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.

The point of using ASCII as the encoding format is the fact that the
natural tools most of us use day to day manipulate ASCII. I'm in one
of those tools right now, a text editor. I have lots of good tools for
manipulating ASCII -- Perl, awk, simple function calls in C, etc.
ASCII is a very "natural" encoding. However, most of us do not have
any tools to easily manipulate UNICODE, so using UNICODE can be ruled
out right now from the point of view of providing the same benefit
using ASCII would provide. I could write a very simple ASCII
certificate manipulation system in a few lines of Perl -- I can't do
that with UNICODE. We would get the same flaws ASCII would give us --
having to worry about canonicalization, having to deal with an
expansive encoding instead of a compact one, etc, and gain new
problems, like having to parse UNICODE represented numbers and in
general having to manipulate UNICODE, without having the benefits of
simplicity and wide tool availability.  This seems very obvious to me,
and does not require that we have a detailed specification for SPKI's
characteristics worked out. UNICODE isn't ASCII.

> 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.

It is and it isn't. I think its a useful tool to stimulate thinking
about how simple we can try to make the overall system.