Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/uri/uri-minutes-94dec.txt

Text File | 1995-02-22 | 13KB | 319 lines

CURRENT_MEETING_REPORT_

Reported by Karen Sollins/MIT

Minutes of the Uniform Resource Identifiers Working Group (URI)

The URI Working Group held two sessions at the 31st IETF; the first on
5 December and the second on 7 December.


Approval of Minutes

The minutes of the previous meeting were approved by general agreement.


RFC Status

It was reported that the RFC Editor will clear the backlog of pending
RFCs by the end of this calendar year, and thus the three RFCs coming
from this group should be available by then.

Erik Huizer, as the group's Area Director, summarized the IESG
discussion of the proposed RFCs.  He reported that The IESG agreed that
they should go forward, but there were some concerns.  With respect to
URLs the two most serious concerns expressed were:

   o Scaling and replication, because embedding specific location in
     URLs does not scale well.  Erik noted that a URN/URC scheme might
     address the IESG concerns.

   o Protocol dependence, because embedding access methods in URLs
     bothered the IESG. The URL documents may simply talk about
     ``schemes'' rather than protocols explicitly, (e.g., ``news:''  is
     not protocol specific, but rather an address space name), many URL
     schemes are tied to a particular protocol.

In response to a comment about how many of these topics had been
discussed at length in the URI mailing list, it was pointed out that
ultimately the results of the working group must be reflected in the
documents put forward; while it may be reasonable to expect participants
in the working group to be familiar with some of the previous
discussion, the rationale for designs in the group's RFCs should appear
in the RFCs.  If the IESG did not understand for example that a URN/URC
scheme would address the problems of scaling and replication, then we
need to figure out how to say it better in the documents, specifically
the URN/URC documents.


Report on URC Requirements by Michael Mealling

This report was based on the Internet-Draft, draft-uri-urc-req-00.txt.

The central requirement for URCs is that they be the place for putting
meta-information.  The specific requirements are broken into broad
areas, encoding requirements and service requirements.  The encoding
requirements are:

   o Ignorability:  the ability to ignore any field that is not
     understood, while understanding and handling others.  It was
     pointed out that some fields may be critical to the whole URC or to
     others, and therefore may not be ignorable, such as copyright
     information, although this might be handled with precedence.

   o Simplicity:  there must be simplicity both in the encoding so that
     tools are easy to build, and in terms of structure, so that
     populating is easy.

   o Structure:  nesting is needed for complex information.

   o Security:  the problems here are both spoofing of the information
     and providing integrity and unforgeability for it.  There is an
     outstanding issue of providing this on each of the parts of a URC.

Main resolution service requirements are to be

   o Secure from spoofing
   o Updateable easily and in an automated manner
   o Fast enough to provide effective resolution

Discussion and questions occurred during the presentation.


Library Requirements

Stu Weibel gave a presentation on library requirements, specifically for
URCs.

What is most important is that the virtual and real libraries
interoperate to support users most effectively.  To this end, Stu has a
list of recommendations:

   o Because different sorts of objects will have different
     requirements, URCs should support different attribute types and
     attribute levels.

   o All URCs should share a common kernel of elements.

   o URCs should be algorithmically mappable into MARC records.

   o We must be prepared for URCs to be created from a wide variety of
     sources with a wide variety of tools.

   o Some standard forms of attributes will be important.

   o Versioning can be handled in naming in some schemes, such as ISBN
     and ISSN, which reflect different authorities with different ideas
     of versioning.

   o Two candidate URC kernels to consider are the Text Encoding
     Initiative Headers (in SGML) and the Core Bibliographic Records (a
     new library community standard for cataloging).

Stu promised (and has sent to the mailing list) a set of references on
this subject.


Comments on URC Requirements by Karen Sollins

Several architectural issues about URC requirements were discussed.
They are:

   o Might there be different URCs for a resource at different
     locations?

   o We need to address the problems of consistency among either the
     different URCs for a resource, or multiple copies of a single URC.

   o Can there be partial URCs returned in response to a request for
     either security or policy reasons?

   o If there is to be policy control over distribution of URCs, there
     must be authentication of the requester, having an implication on
     the communications protocol?

   o It is possible that we want to allow for a response to request for
     a URC to be sent elsewhere, in which case, we are using a
     continuation paradigm.  Whether we allow this or not, we are making
     a choice about the communications paradigm.

   o We must make a distinction between meta-information to be used in
     resource discovery (e.g., which URN one wants) and location
     discovery (URN to URL mapping).  There may be mostly an issue here
     of information management, because it will be accessed and managed
     differently.  (See comments below in discussion of URC
     specifications.)

   o ``Development'' URNs:  the distinction should not be in URNs, but
     perhaps in URCs.


URN Schemes and Testbeds

There are currently several efforts underway.  Mitra et al. and Michael
Mealling are using similar naming schemes, with a disagreement about
whether a DNS name should be used as part of the naming authority name
or not.  Otherwise, the two schemes are similar in that they both are of
the form:

     prefix:pubid:opaquestring.

where prefix is ``urn:''  the pubid is the ID of the naming authority
and may be hierarchical in both delegation and assignment, and
opaquestring is a string assigned by the naming authority that is unique
within its scope and long-lived.  Several implementations of this and
the mapping functionality needed to realize it are underway, at among
other places, Georgia Tech and Bunyip.  They described the details of
their designs as well.  Bunyip is beginning to think about making
choices about URLs, using this scheme, on the basis of cost.  This work
is represented by an internet draft.  The Georgia Tech proxy server is
now accessible on www.gatech.edu, port 8080 with more information
available at

     <URL:http://www.gatech.edu/iiir/>

Keith Moore reported on the work described in the internet draft on the
BFD (Bulk File Distribution), another alternative.  This maps URNs in
LIFNs, which in turn are mapped to specific URLs.  The hard part here is
caching to make it run fast enough.  This work is not being promoted as
a standard but as a basis for learning more about URNs and the BFD
model.  Code is now available.  Information is available at

     <URL:http://www.netlib.org/nse/bfd> and from
     <URL:mailto:[e-mail]>

URC specification proposal by Michael Mealling

(A new Internet-Draft, draft-ietf-uri-urc-spec-00.txt, will be available
soon).

Rather than presenting all the details of the proposal, Michael made
some high level comments:


   o The requirements document has some contradictory requirements, such
     as generality vs.  printability.  One might use binary encoding of
     non-printable forms, but some compromise is needed.

   o Compatibilities should be a primary concern in order to make URCs
     useful to other non-computer networking communities such as the
     library community.

   o There are two major functions of URCs:

      -  providing high level meta-information such as that maintained
         and used in library catalogs, where the information is complex,
         rich, and probably comes from an unlimited data set, encoded in
         many different schemes.

      -  supporting resource location discovery by means of a simple
         encoding of fairly restricted data, that is easily maintained
         and easily populated.


The basic element set is fairly limited with an extension mechanism
using ``x-''.

There were questions about whether URCs should simply be extremely
simple templates or structures with semantics built into them, such as
might be describable in SGML. Should they be parsable independently, in
other words are they self-describing.  There is also a question of
whether a nested structure and precedence should be possible.  Michael
would like to keep things as simple as possible at present and see how
far we can get with that, and how much we can learn from that, with the
possibility of extending it later.

There seemed to be general consensus in the room that precedence rules
were important, and therefore WHOIS++ will not support what is needed.

There was a certain amount of discussion about whether when a
``resolution'' that produces a URC may produce different things on
different occasions depending on context and perhaps different URCs will
be needed to support the different information needed in these different
contexts.


Report on Relative URLs by Roy Fielding

This report is based on draft-ietf-uri-relative-url-02.txt.  The slides
for Roy's talk are available as:

     <URL:http://www.ics.uci.edu/pub/ietf/uri/rurl-slides.ps.gz>

There are two main reasons for providing relative URLs.  First they save
space and second, they allow a tree of closely related resources that
will be co-located to have their location references be location
independent.  The idea is that relative URLs will be embedded in the
resources, and the base that is used to create a fully qualified URL is
the URL of that resource, as defined by the context in which the
resource was retrieved or by a base URL embedded in, or passed along
with, that resource.  This allows the whole tree to move together
without changing the embedded URLs.  It also allows the resource to be
simultaneously accessible and traversable via multiple access schemes.

There was concern expressed that a resource in such a tree cannot be
moved without its parent being moved as well, since the base URL must be
valid for a child (partial trees cannot be copied or moved) and that the
URI Working Group should not encourage more use of URLs as location
independent, long-lived identifiers of resources by providing yet more
schemes for embedding them in resources.

However, it was pointed out that it has yet to be determined whether or
not all sub-entities of a resource should have independent, long-lived
identifiers, or just the entry-point of a resource.  For example,
specifications on paper often use relative locators, in the form of
``see Section 3.2'', which are likewise dependent on internal structure.
Requiring that each subsection be fully-named would be inappropriate.

Roy will update the next draft of the rURL specification to change the
rURL resolution algorithm so that it is scheme-independent; this may
require some changes to the URL Draft Specification.


URLs and Z39.50 by John Kunze

John Kunze circulated to the mailing list and at the meeting a proposal
for Z39.50 URLs developed by the Z39.50 implementors group.  The unusual
thing about the document is that it proposes two new URL schemes because
Z39.50 does not fit our traditional model, on account of being a
stateful protocol.  Thus the two URLs are for creating a session and
performing a retrieval.  If a URL is used for retrieval, an existing
session may be used instead of creating a new session.

The URL Proposed Standard says that new URL schemes should be registered
by IANA, but until the standard is accepted and the procedure for
registering schemes is worked out, new schemes should be reviewed in the
URI Working Group.  It was agreed that we should have enough experience
first to give IANA strong guidelines and rules for such assignment,
before giving them this job.

There was a certain amount of discussion about the fact that WAIS URLs
are only retrieval URLs and that they are viewing the whole database as
a resource, in our terms.  More than one person wished to know whether
this were also possible to do in a Z39.50 URL scheme.

The suggestion was made to switch to a more common and modern syntax
within the opaque string, especially regarding use of `&' and `?'.

The Z39.50 Implementors' Group will meet in January and discuss the
comments from the IETF.


Additional Minor Issues With URNs by Chris Weider

Case-sensitivity is raising its head again.  The group reached consensus
some time ago that they would follow the path of case insensitivity --
to allow for maximum generality.  This was resolved with great pain in
the URN requirements document and should not be raised again.

The use of dashes (``-'') was mentioned.  Some host names contain them.
The group will discuss any creative ideas on this topic on the list.


AFS URLs

There has been discussion about AFS URLs.  It should continue on the
list.