[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Display types?
Paul,
funny that you ask about it today. I just sent private email to Carl about
this issue this morning. Several people I talked to about SPKI like it a
lot, but agree that the display hints are not necessary as part of SPKI. So,
in hope of getting a discussion on this going, I'm including my post to
Carl.
Robert
--------------
Carl,
I want to try to make my argument for the simplification of s-expressions
one more time. Sorry to be so insistent, but since s-expressions are the
textual interface to / representation of SPKI I think it important that they
are clear, concise and as simple as possible.
First, on display hints: I understand that you might want to have a way of
conveying type information. But, two problems arise. First, they are not
sufficient. In protocols like HTTP or document encodings such as multi-part
MIME messages, you need strictly more information than just the content
type, often conveyed as a list of name-value pairs. But, a display hint is
just one single value. Second, for many applications of s-expressions, they
are not used at all. Case in point is SPKI where the overall type of a byte
string is obvious from previous tags and there usually is no need for
display hints. Therefore, display hints are either too much or too little,
and I think it would be best to drop them altogether.
If they stick around, I would recommend changing the default hint to include
the UTF8 encoding instead of ISO 8859-1. UTF8 contains the lower 127
encodings from 8859-1 but can accommodate all Unicode characters if
necessary. And, there clearly seems to be a trend towards the use of UTF8 in
internet protocols.
Next, on the advanced transport: My understanding is that the advanced
transport is best used in situations where machine-human communication may
take place (or human inspection). They are clearly more powerful than the
basic transport encodings and require more sophisticated parsers. So, why do
you include the optional length for the string, hex, and base 64 encodings?
The parser has to handle byte strings without them anyway and wherever a
human is involved they will most likely not create a length. So, I would
drop the optional length.
As to the compatibility with Scheme, I will not insist on that (but will
spend some more time figuring out which minimal mods would make everyone
happy).
So, I hope I'm not pushing these points to hard, and apologize if I do. From
the people I talked to about SPKI I get the feeling that many would agree
with me on dropping hints, while they clearly like it otherwise.
Robert
---------------
For completeness, Carl's earlier reply on display hints was:
Ah -- yes. Unfortunately, that was the only way we thought of to handle
international character sets, images, sound files, etc.