Re: Library Standards and URIs

Michael Shapiro (mshapiro@ncsa.uiuc.edu)
Wed, 4 Jan 1995 23:58:17 -0600 (CST)


From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)
Message-Id: <9501050558.AA17275@void.ncsa.uiuc.edu>
Subject: Re: Library Standards and URIs
To: winograd@cs.stanford.edu (Terry Winograd)
Date: Wed, 4 Jan 1995 23:58:17 -0600 (CST)
Cc: rdaniel@acl.lanl.gov, hoymand@gate.net, michael.mealling@oit.gatech.edu,
In-Reply-To: <v03000a12ab30b9594bc0@[192.203.7.234]> from "Terry Winograd" at Jan 4, 95 01:58:02 pm

The requirement that the URN be at the top of the  URC  seem  too
restrictive.   The  problem could be solved by types - the URN is
really an object id for the URC. If the URN  entry  is  typed  as
"object-id",  then it could be placed anywhere in the URC.  (Look
at how ASN.1 has defined object identifiers as a special type.)

For example, if the URN needed to be  signed,  along  with  other
info the URC:

    urc {
	x: xjxhxhxjxjx
	y {
	    URN: sjdhdgsuwhdhgrg
	    z: sjkdhwj3y465shgfgh
	    signature {
		    rsa: skfjkdhfkhd
		    md5: 34567
	    }
	}
	related-docs {
	    URN: sjdhwl34.sj
	    URN: 123sjdh.welk
	}
    }

(The syntax here is only for illustrative purposes)
The item 'y' contains the URN, and a signature which is computed
based on the 'y.URN' and 'y.z' items. 'related-docs' is a list of
other documents that a local site thought it needed in its URCs
and are only to illustrate that there might be more than one URN
item in the URC.

Types could be used here:

    urc {
	x: xjxhxhxjxjx
	y signed {
	    URN object-id: sjdhdgsuwhdhgrg
	    z: sjkdhwj3y465shgfgh
	    signature {
		    rsa: skfjkdhfkhd
		    md5: 34567
	    }
	}
	related-docs {
	    URN: sjdhwl34.sj
	    URN: 123sjdh.welk
	}
    }

y signed      - y has a signature in it.
URN object-id - URN is the object id for the entire urc.

(This doesn't resolve the semantic problems - externally defined types
would have to be used for that.)

|
|At 5:40 PM 12/31/94, Ronald E. Daniel wrote:
|>Fortunately, I think that the requirement that we be able to put just about
|>ANYTHING into the URC points us to a possible solution. If people can add
|>their own attributes to their URCs (which I think is good), we are going to
|>see name clashes (which is bad). We also have the problem of knowing how to
|>interpret these new attributes, after all, someone else might want to
|>utilize them. To overcome these problems, I suggest that non-standard
|>attributes carry along the URN of a human-readable explanation of their
|>purpose, semantics, and syntax
|...
|>In talking with Larry Masinter about this in San Jose, he suggested that
|>we put the URN of the "attribute set" being used at the top of the URC.
|