Message-Id: <199408151910.NAA03844@idaknow.acl.lanl.gov>
To: ccoprmm@oit.gatech.edu (Michael Mealling)
Subject: Re: Additional requirements for URCs?
In-Reply-To: Your message of "Mon, 15 Aug 94 09:01:09 EDT."
<199408151301.AA18429@oit.gatech.edu>
Date: Mon, 15 Aug 94 13:10:16 -0600
From: rdaniel@acl.lanl.gov
Michael Mealling sez:
>
> Mitra said this:
> > What is required is the ability to be able to express concepts in a URC,
> > for example
>
> How 'bout this:
>
> URN:foo.bar:ABCDEF
> Author: Fred Smith <fred@foo.bar>
> {:Integrity
> Checksum: 12345
> }:
>
> This way it's still a valid template and my dumb client can just ignore
> those attributes it doesn't understand....
I think that what we need to standardize is the syntax we use for exchanging
URC information, and the syntax used for building querys. We should not
specify the internal representation used by the URC servers, because people
may want to make different space/time tradeoffs. Michael's concern seems
implementation-specific. It certainly is not a natural syntax.
I have been thinking about the URC structure quite a bit recently, and
should have a detailed write-up fairly soon. In that I have a "Signature"
element to deal with the authenticity problem. There are lots of ways of
doing signatures, with different ease/security tradeoffs. To accomodate these
different schemes, the "Signature" field would have a schema identifier. For
example:
Signature:MD-5: adspofgiuh4509ugvnpdfyh2409jh
Signature:gnu-cksum: 987634
Signature:RSA: pjhsdf0o89q475pojqvbhwq97y4, rdaniel@lanl.gov
Signature:X-new-scheme: 09845;087945;09428;9076435
Michael uses a colon-separated name pair elsewhere in the spec to carry info
on what version scheme is being used, so I assume this doesn't break the
template. Note, however, that the whitespace after the final colon
should probably be significant to make parsing easier. But then what about
URL: and URN: fields - should there be whitespace after the colon?
This is not exactly free text, but it might be confusing for novices.
Alternatively, we could use a different character than ':' to separate
field from scheme. Semicolon? Suggestions please.
Mitra used braces in his suggestion. I would like to use braces for the
purpose of grouping related information, rather than indicating methods
for achieving a particular purpose. Examples of stuff that would go in
braces are the various means for contacting an author, various information
about a particular instance of a resorce, information about versions of
a resource, etc. This is similar to the precedence rules in Michael's draft,
but I think braces (or other explicit scope delimiter) will be a better
choice for the long-term. I am worried about the interactions between
precedence rules, whitespace continuation, and nesting.
Some examples for the fun of it:
Author: Daniel, Ronald E. Jr. // We should have a default field so
or // descriptions can be compact, but
Author { // if we want a bigger description
Name: Daniel, Ronald E. Jr. // we can do it too. Here, Name: is
Email: rdaniel@lanl.gov // the default attribute of the
Work-phone: 1 505 665 0139 // Author: object.
}
// Here is another grouping of related info - URCs can have any number of
// Location objects. The default field would be the URL. The stuff in a
// location talks only about the resource at that location. Other locations
// may have different lengths, types, signatures, etc.
Location {
URL: http://www.acl.lanl.gov/~rdaniel/Home.html
Signature:PGP: pirghjq34in[rowichj304[qih[43ghfhujui49r
Content-type: text/html
Content-length: 4072
Version:RCS: 1.3a2
}
// The next example shows a particuar type of version object (an RCS object)
// and fields for it. A simple decimal version object might only have
// a version ID field.
Version:RCS {
ID: 1.3a2
Supplants: 1.3a1
Changed-by: Daniel, Ronald E. Jr.
Change-reason: Added silly picture
Change-date:structured: 19940809143025+7 // note that we have 2 ways of
Change-date:text: Aug. 8, 1994 2:30 PM MDT // representing time, so we use
// : as a specializer, not braces
}
Anyway, more on this later. Feel free to ask questions, it will help me
clarify the spec.
> > The second requirement "a democratic publishing module", is going to be
> > hard in any kind of hierarchical, decentralised allocation setup. If the
> > publishing entity has a FQDN its easy. otherwise they are going to have
> > to have some way of obtaining a publishers id. Maybe we'll see services
> > that only allocate publisher id's within their own name space, so making
> > the URN independant of any other service that the publisher may require.
>
> That's one of the major reasons I don't want URNs tied to DNS. If you just
> make it a PubID devoid of FQDNs then anyone can assign withing a namespace.
> I very much want to see an 'alt' namespace where any tom,dick or harry can
> publish his recipe for marijuana brownies.....
But how will they provide their recipe to the world without a URL? This means
they will have to have a server with a FQDN. The only purpose that would be
served by having a "free press" PubID without the http (or whatever) server
to back it up would be to let people know about stuff they can get through
postal or telephone means. I don't want to exclude that, but I think it is
not our primary purpose. Internet access to information is.
Ron Daniel