- From: Ronald E. Daniel <rdaniel@acl.lanl.gov>
- Date: Fri, 9 Jun 1995 06:59:10 -0600
- To: uri@bunyip.com
7 Requirements Satisfaction
This section reviews how the proposed URC specification meets the
requirements set forth in [1]. That document divided the requirements
into two categories: requirements on the URC and requirements on the
URC service.
7.1 Requirements on the URC
Machine Consumption
Consistent External Representation
Transport Friendliness
Readability: The scenarios paper set forth several requirements on
the URC and its encoding. The first set of those requirements
were Machine Consumption, Consistent External Representation,
Transport Friendliness, and Human Readability. Those requirements
are very difficult, if not impossible, to meet simultaneously.
For example, having a human-readable printed representation makes
it possible to cut and paste URCs and send them around via e-mail.
Unfortunately, differing conventions for handling EOL, tabs, etc.
mean that there will not be a consistent representation for the
purposes of digital signatures. These apparently conflicting
requirements were addressed in section 5 on multiple transfer
syntaxes. It suggests that a variety of transfer syntaxes be
allowed. For human readability, a simple text version might be
requested. For digital signatures, a binary transfer syntax might
be used, and the client would take responsibility for displaying
Ron Daniel [Page 15]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
the URC to the user.
Simplicity: Utilizing the defaults for the attribute set and transfer
syntax, URCs can be simple enough for hand entry.
Rearrangeability: The rearrangability requirement originated with the
need to sort locations according to preferences such as cost,
format, size, etc. While this is a very reasonable thing to do,
sorting by author name is not so reasonable.
The default attribute set is independent of element order.
Developers of other attribute sets are encouraged to maintain this
flexibility. Developers of software for manipulating URCs are
also encouraged to think carefully about what they are doing and
not rearrange fields without good reason.
Generality
Structure
Ignorability: The requirements that the URC be general enough to
store ANY sort of data, and that it have a self-describing
structure, are met by the use of SGML DTDs for URC definition.
Being able to determine the extent of novel elements is a function
of particular transfer encodings.
Searchable: The trivial query language provides enough capability
for URN resolution, but it does not provide the general query
capability imposed by the searchability requirement. A more
capable query language specification is under development. This
is discussed further in section 8.1.
Subsettable
Incrementally Modifiable: It is possible to create new URCs from
pieces of other ones. Because all the elements of the default
attribute set are optional, any URC prepared according to it can
be decimated while still leaving a legal URC. For URCs prepared
according to other attribute sets, the attribute set definition
must take this requirement into account. There is nothing in this
specification that prevents modifying existing elements in a URC
or adding new elements.
Separable: This is an issue for binary transfer syntaxes.
Versioning: Versioning URC changes is still an open issue (see
section 8.2).
Caching: Because of the use of HTTP as the resolution protocol,
existing HTTP caches and proxy servers can be utilized for caching
URC information.
Ron Daniel [Page 16]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
Grandfathering: The use of multiple transfer syntaxes and multiple
attribute set definitions may ease the grandfathering of older
metadata schemes, but this has not been a major consideration in
the development of this specification.
7.2 Requirements on the URC Service
Resolution: As shown in section 2, it is possible for the URC service
to resolve URNs into URCs. Resolving the URC into a URL can also
be performed manually or automatically.
Multiple Syntaxes: Multiple transfer syntaxes are a feature of this
specification.
Query Language: As mentioned earlier, the trivial QL in section 6
does not meet all the requirements in [1]. This is discussed
further in section 8.1.
Security: Because we have used HTTP as the resolution protocol,
we believe we can utilize secure HTTP to meet the security
requirements. It may be that only particular transfer syntaxes
can be secured, but that is deemed acceptable.
Authentication Chain: Until we have a reasonable public key
infrastructure, this requirement can not truly be met. The system
has been architected for the assumption that such a service will
arise, and that domain names can be registered as distinguished
names in that hierarchy. Do we need to account for the time of a
domain name?
Access Control: Access control is handled through exiting HTTP
mechanisms.
Maintenance: It is believed that nothing in the URC specification
prevents maintenance of the URC information. Particular details
of maintenance procedures are for implementations to establish and
are outside the scope of this spec.
Synchronization: Synchronizing the content of multiple URC servers is
outside the scope of this specification.
Development: This specification allows multiple URNs to be associated
with a single URC, thus meeting the development requirement.
Choice: This requirements is more properly addressed as part of the
URN resolution specification, but nothing in this specification
assumes that users must always go through a particular gateway
server. (Note that efficiency considerations may make it very
very common to do so, in order to gain the benefits of a caching
Ron Daniel [Page 17]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
HTTP proxy, but there is certainly no requirement that we do so).
Scalability: This proposal does not forward resolution queries. Am I
answering the problem here?
Administrative Contact
Hierarchical Operations: The trivial query language provides a query
for determining administrative information and the structure of
the local publication hierarchy. It also provides queries to
determine the attribute sets used, which can be used to speed
subject-specific resource discovery.
8 Open Issues
8.1 Query Language
Requirements say that ``It must be possible to select a URC based on
a search of its components. It must be possible to select which
components will be searched and which will not be searched.'' They
also say ``It must be possible for simple resolution queries to be
augmented with information on the version of a resource desired, and
an indication of whether signature information should be supplied. It
must be possible to select sets of URCs based on criteria such as data
of last modification, etc.'' The trivial QL in section 6 does not
meet those requirements. Do we need to put a more capable QL into
this paper, can we refer to an external draft under development, or do
we relax the requirements?
8.2 Meta-metadata
At its simplest, the URC for a resource only contains data about
the resource. Of course, this quickly breaks down. The URC can
be modified over time, in fact, one of the requirements on the URC
service is that we be able to do so. This implies that we might want
to know information about the URC - when it was created, by whom, what
is its version, what changes were made since the last version and
why, etc. Where to put this meta-metadata and how to access it are
open issues. Because of the syntax-independence property we wish to
provide, URN resolvers will already be constructed with the assumption
of dynamically generating the required output. Therefore, it probably
makes sense for the resolver to maintain the metadata, meta-metadata,
... locally and only provide it when requested. The default
attribute set will probably be augmented with some basic meta-metadata
capabilities as this specification is developed further.
Ron Daniel [Page 18]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
8.3 Attribute set object encapsulation
Since attribute sets are fundamental to our view of the URC service,
it is appropriate to ask what sorts of operations will be defined over
them. This is one of our current areas of work. At this time, all
the operations we are exposing to the client are "get" methods. Get
the complete attribute set, get just the changes from the parent, or
the base, get the name of the parent, get the name of the base, get
the names of the elements that are new or overridden in the changes,
etc.
Since the AID is a URN, that means it has a URC, and that URC will
also have an attribute set. While we do not want to mandate all the
attribute sets - the meta-attribute set may be an appropriate element
for standardization.
9 Acknowledgments
This specification is the result of many people submitting their ideas
to the crucible of the URI-WG, from whence I have shamelessly plucked
them. In particular, I would like to acknowledge Terry Allen, of
O'Reilly and Associates, for all his help getting this SGML neophyte
going, and his careful commenting on the DTDs. He will probably
be shown as a co-author on the next revision of this draft. Eric
Miller of OCLC also deserves thanks for helping me with SGML, and for
providing the original DTD for the Dublin metadata set that I have
turned into something he might prefer not to think about on a queasy
stomach. Dan Connolly, of the W3O, deserves thanks for his unwitting
contribution of the SGML declaration which I ripped off from the
HTML validation package. . Many other WG members have contributed
to the development of this specification, I am sorry that I cannot
adequately acknowledge all of them. However, particular mention must
go to the working group chair, Larry Masinter of Xerox PARC, for the
notion of named attribute sets that is central to this specification.
Finally, I would like to thank Dave Forslund of Los Alamos National
Laboratory for finding the funding to allow this work to continue, and
Carol Hunter of Lawrence Livermore National Laboratory for lobbying to
have that funding increased so that I can pursue this work nearly
full-time.
Ron Daniel [Page 19]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
10 References
References
[1] Ron Daniel and Michael Mealling, ``URC Scenarios and Require-
ments'',
<URL:ftp://cnri.reston.va.us/internet-drafts/draft-ietf-uri-urc-
req-01.txt>
[2] Paul Hoffman and Ron Daniel, ``x-dns-2 URN Scheme'',
<URL:ftp://cnri.reston.va.us/internet-drafts/draft-ietf-uri-urn-
x-dns-2-00.txt>
[3] Paul Hoffman and Ron Daniel, ``Trivial URC Syntax: urc0'',
<URL:ftp://cnri.reston.va.us/internet-drafts/draft-ietf-uri-urc-
trivial-00.txt>
[4] Stuart Weibel, Jean Godby, Eric Miller, and Ron Daniel (eds),
``OCLC/NCSA Metadata Workshop Report'',
<URL:http://www.oclc.org:5046/conferences/metadata/dublin_core_report.html>
[5] T. Berners-Lee, R.T. Fielding, and H. Frystyk Nielsen,
``Hypertext Transfer Protocol -- HTTP/1.0'',
<URL:ftp://cnri.reston.va.us/internet-drafts/draft-fielding-
http-spec-01.ps>
11 Security Considerations
The URC service will provide information of considerable value,
especially once Internet payment systems become common. Future
versions of this specification must address how transactions can be
validated if desired without imposing significant delays on unsecured
operations. The author believes that supporting multiple syntaxes
will help in this area, and that new attribute sets can be defined
which will carry digital signature information. This is addressed in
the current version of [1].
Contact Information
Ron Daniel Jr.
MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA 87545
Ron Daniel [Page 20]
INTERNET-DRAFT An SGML-based URC Service June 7, 1995
voice: (505) 665-0139
fax: (505) 665-4939
rdaniel@lanl.gov
http://www.acl.lanl.gov/ rdaniel/
Received on Friday, 9 June 1995 08:59:10 UTC