# *Revised* minutes, URI working group

Larry Masinter (masinter@parc.xerox.com)
Wed, 28 Dec 1994 13:41:03 PST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: Library Standards and URIs"
- Previous message: Karen R. Sollins: "Re: Correction to Minutes, URI working group"
- Next in thread: John A. Kunze: "Re: *Revised* minutes, URI working group"
- Maybe reply: John A. Kunze: "Re: *Revised* minutes, URI working group"
- Reply: minutes@cnri.reston.va.us: "Re: *Revised* minutes, URI working group"

    To: minutes@cnri.reston.va.us

    Subject: *Revised* minutes, URI working group

    From: Larry Masinter <masinter@parc.xerox.com>

    Message-Id: <94Dec28.134110pst.2760@golden.parc.xerox.com>

    Date: Wed, 28 Dec 1994 13:41:03 PST

I don't know if it is too late to get revisions into the 'official
minutes', but here's a revision; the section on Relative URLs has been
revised.

Minutes of Uniform Resources Identifiers Working Group, December 5 &
7, 1994 Revised 12/28/94 per comments on URI mailing list.

Many thanks to Karen Sollins for taking minutes.
================================================================
Session I

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

2. It was reported that the RFC editor will clear the backlog of
pending RFCs by the end of this calendar year, and thus the 3 RFCs
coming from this group should be available by then. Status of RFCs:
Jon Postel reports that he will get them out by end of Dec.

Erik Huizer, as the group's Area Director, summarized the IESG
discussion of the proposed RFCs: the IESG agreed that they should go
forward, but there were some concerns.

With respect to URLs the two most serious concerns expressed were:

* 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.

* 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 didn't 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.

3. Report on URC requirements by Michael Mealling

This report was based on the Internet Draft.
<URL:ftp://ds.internic.net/internet-drafts/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:

a. 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.

b. 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.

c. structure: nesting is needed for complex information

d. 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

a. secure from spoofing
b. updateable easily and in an automated manner
c. fast enough to provide effective resolution

Discussion and questions occurred during the presentation.

4. 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 recommendations:

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

* All URCs should share a common kernel of elements.

* URCs should be algorithmically mappable into MARC records.

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

* Some standard forms of attributes will be important.

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

* 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.

5. Comments on URC Requirements by Karen Sollins

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

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

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

* Partial URCs: can there be partial URCs returned in response to a
request for either security or policy reasons?

* 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?

* Communications paradigm: 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.

* 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.)

* "Development" URNs: the distinction should not be in URNs, but
perhaps in URCs.

6. 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:bfd-info@cs.
utk.edu>.

Sesion II

7. URC specification proposal by Michael Mealling: (new internet draft
available soon as draft-ietf-uri-urc-spec-00.txt).

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

* 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.

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

* There are two major functions of URCs:

a. 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.

b. 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.

8. Report on Relative URLs by Roy Fielding

(Ed note: this section has been updated from the previous version of
the Working Group minutes.)

Report based on <URL:ftp://ds.internic.net/internet-drafts/
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 it's 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.
9. 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 2 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 retrieval. If a URL is sent for retrieval, either an
existing session will be used or a session creating URL will be sent
first.

The URL proposed standard says that new URL schemes should be
registered by IANA, but until the standard accepted and the procedure
for registering schemes is worked out, we should review new schemes 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. It is also possible to do this in a
Z39.50 URL scheme.

The Z39.50 implementors' group will meet in January and discuss the
comments from the IETF.

10. Some additional minor issues with URNs by Chris Weider

* Case-sensitivity is raising its head again. The group reached
consensus some time ago that we 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.

* Use of dashes ("-"): Some host names contain them. We will discuss
any creative ideas on this topic on the list.

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

12. The meeting was adjourned.

- Next message: Dirk Herr-Hoyman: "Re: Library Standards and URIs"
- Previous message: Karen R. Sollins: "Re: Correction to Minutes, URI working group"
- Next in thread: John A. Kunze: "Re: *Revised* minutes, URI working group"
- Maybe reply: John A. Kunze: "Re: *Revised* minutes, URI working group"
- Reply: minutes@cnri.reston.va.us: "Re: *Revised* minutes, URI working group"