[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on SPKI draft of 25 March 1997
At 11:37 AM 3/29/97 EST, Ron Rivest wrote:
>
>On object names:
>
>The proposal envisions two types of object names, the "long form" and
>the "short form", as in
> c = certificate
> na = not-after
>and so on.
>
>I would argue AGAINST having two forms of any object names (except for
>case variations) as follows:
>
>-- consider the two reasons for having two forms:
> -- readability (favors the longer forms)
> -- compression (favors the shorter forms)
There is a third reason: typeability (sp?). For this, I prefer the short
form. If we ever actually compose certificates in a text editor (as opposed
to just viewing them there), I strongly prefer the short form.
I also personally prefer the short form for readability.
I believe it has been a monsterous mistake to adopt long, self-descriptive
names (e.g., in X programming, in COBOL, in most ASN.1, in many OOP
examples, ...). I grant that the long form, being self-descriptive,
(hopefully) carries its own man page with it (in a way) and that might help
people interpret what they see in front of them, but it's not just out of
laziness that all the examples I gave in the I-D used the short form of the
names. When you use a long-form name, you are using up valuable area on
the user's display. [I spent many years in the display business and have
been battling the limitations of display size ever since 1966 but especially
since 1969. Displays get a little better with time, but they are still
far too limited.]
When you use valuable sq-mm for a self-descriptive name (or, with typical
ASN.1, for a chain of twelve of them, separated by "." or "->", to get to the
variable of interest), you have reduced the number of objects visible on a
screen at once. For me, readability comes from the number of objects I can
see in front of me, not from how certain I am of the meaning of some
individual token. [Of course, I'm an emacs and UNIX user -- so I'm used to
having to memorize far more abbreviations and control characters than
we'll ever have for top level object names.]
- Carl
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
References: