URC spec 5/6

["Ronald E. Daniel" <[e-mail]>]

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:  [phone]
fax:  [phone]
[e-mail]
http://www.acl.lanl.gov/ rdaniel/