[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SDSI syntax
>The ability to nest objects inside each other is tremendously powerful
>and useful. That is one reason why in SDSI[1] Butler Lampson and I
>decided in favor of fully parenthesized S-expressions, rather than having
>data structures that are flat (as I understand the whois++ data structures
>are).
Agreeing with Ron here, its worth noting that much of the hassle with PICS and
PEP was attempting to obtain a structured form using RFC822 headers. PEP uses
curly braces because parentheses are defined as comments in RFC-822 and certain
proxies are in the habit of stripping them out :-(
I think that there is value in collecting up certain very often used terms to
form a URI. I believe that in general anything that is a name should have URI
syntax. As a bit of history, in the distant days when the Web was called Mesh it
consisted pretty much of URIs and HTML. HTTP was introduced because FTP turned
out to be inappropriate and too diversely implementaed to be usefull.
In my entity signing stuff I use URIs of the form:-
RSA:Hi7KugV013Tv978d...00vCpQ==
Which Ron expresses as
( Public-Key:
( Algorithm: RSA-with-SHA-1 )
( N: =Hi7KugV013Tv978d00vCpQ== )
( E: #11 ) )
I think that there is value in collapsing the terms into a single syntactic
unit. In my case I use PKCS#1 as a generic encoding form.
The advantages of having a compact, atomic name is that it then can from a basis
for negotiation in a convenient manner. If we are negotiating the public key to
use then we cannot negotiate the N: and E: parameters independently. This form
would also key into HTML and HTTP better. Both are somewhat unfortunate in their
handling of whitespace.
Phill