[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

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


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.