# URI minutes

Larry Masinter (masinter@parc.xerox.com)
Sun, 9 Apr 1995 09:56:39 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman: "Scheme extension mechanism"
- Previous message: Hubert Partl: "BOKU URL"
- Next in thread: Larry Masinter: "Re: URI minutes"
- Maybe reply: Larry Masinter: "Re: URI minutes"

    To: uri@bunyip.com

    Subject: URI minutes

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

    Message-Id: <95Apr9.095653pdt.2761@golden.parc.xerox.com>

    Date: Sun, 9 Apr 1995 09:56:39 PDT

Attached are the first draft of the minutes Margaret St. Pierre and
Stu Weibel. If you have additional notes from the meeting, please send
them. There are some phrases in the minutes so far that are not
complete sentences; if anyone would care to offer a disambiguation, it
would be much appreciated.

For those who spoke with slides (Leslie, Ron, Michael, etc.), please
send me (a pointer to) your slides or a summary of them, for inclusion
in the official minutes.

--------------------------------------------------------------------------

Minutes of Uniform Resources Identifiers Working Group, April 3 & 4, 1995.

Session I

(minutes by Margaret St. Pierre, saint@bluangel.com)

1. Reviewed of agenda, accept minutes from last meeting.

2. Leslie Daigle gave a presentation on URAs (Uniform Resource Agents).
URAs are a means of specifying network activities. For more information on
URAs, see:

<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-ura-00.txt>

3. URN-Fest: A 10-minute presentation was given to summarize each of the
URN schemes given below. For more information on each scheme, see the
associated URL.

Schema/Authority/Element
Speaker: Ron Daniel
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-yaurn-00.txt>

Path
Speaker: Michael Shapiro
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-urn-path-00.txt>

Handle
Speaker: Bill Arms
<URL:http://www.cnri.reston.va.us/home/cstr.html>

LIFN (Location Independent File Name)
Speaker: Keith Moore
URL = ?

General Syntax
Speaker: Mitra (Michael Mealling/Chris Weider)
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-resource-names-03.
txt>

4. The remainder of Session 1 was devoted to discussion of the
presentations, with a chance to ask any of the presenters questions on
their proposed URN schemes. The following issues were raised, and a
number of (sometimes contradictory) points were raised on each of
these issues, as described below:

Issue: Should one protocol or multiple protocols be used (e.g., whois++ and
http ) ?

- A single protocol approach would make it possible for client
software not to have to change to support all protocols.

- A single protocol would permit wider adoption.

- A security model that would support multiple protocols may be
difficult to achieve, although may not be a problem with a
security scheme such as SSL.

Issue: Will the URN schemes be able to scale up to over one million
publishers on the net, and how will administration of such a large number
of URNs be handled?

- A global server may have problems updating if the number of URNs
doubles each year.

- The solution to this problem depends on how many URNs are
registered globally versus locally.

- URNs have to be globally resolvable.

- Locality of reference cannot be assumed on the Web.

- The URI group should look into making use of the work the DNS
group is doing to handle administration and namespace issues.

- Use DNS name as the registration authority, e.g. the resolver
for gatech would be "uri.gatech.edu".

- Not all URLs will have a corresponding URN. There are not going
to be that many "published" documents that need to be cataloged
for the long term, and thus the number of URN's assigned will not
be a major problem.

- The URN scheme should be built to handle the assumption that
everyone will want to author, and that publishers should ensure
that URNs stay around for the long term.

- Name assignment is separate from the name resolution scheme, and
should be solved separately.

- People would be willing to wait for name resolution.

- People would not be willing to wait for name resolution; name
resolution should occur with less than a one-second retrieval
time.

Issue: How is payment for these schemes handled?

- A hierarchical URN scheme is attractive because billing can be
done locally.

-------------------------------------------------------------------

Session II, 1300-1500 (minutes by Stuart Weibel, weibel@oclc.org)

1. Reltive URLs: Roy Fielding
draft-ietf-uri-relative url-06.txt

The draft was declared complete without objections, and will be
submitted to IESG for 'last call' before becoming standards track RFC.

2. Z39.50 URL Status Report John Kunze
draft-ietf-ietf-uri-url-irp-02.txt

The ZIG mailing list has raised enough questions on this that the
author isn't ready to propose adoption. The URI list is asked for any
comments on the draft, however.

3. Finger, Mailserver URL-scheme extension mechanism

draft-ietf-uri-url-finger-02.txt
draft-ietf-uri-url-mailserver-01.txt

No comments on either... both can be submitted for last call
and proposed as Draft Standard.

ISSUE: How will such extensions be vetted in the future?

The working group is now reviewing extensions (3 so far)... in
future months, someone must edit revision of URL draft, and decide
how extensions will be done in future.
No one present at the meeting volunteered to adopt these responsibilities,
though there was recognition that it is necessary and important.

4. URC Scenarios and Requirements Ron Daniel and M Mealling

The authors are seeking feedback concerning the minor modifications made
to the document (Daniels, Mealling). We deferred discussion on this
issue in order to get back to the URN discussion.

5. Remainder of the session (about 75 minutes) were given over to
continued discussion of the 5 URL schemes and associated issues.

The following assertions or comments reflect the sense of the discussion;

It is time for a new namespace/resolution system - existing DNS is fragile
and flawed; extending these flaws into the URN arena will propagate these
flaws (eg.: flatness of .com space)

We should identify solutions to DNS problems and take advantage of
the existing investment in technology and administrative infrastructure...
do not confuse architecture (sound) with implementation (currently weak)

URNs will not, of themselves, solve the problem of persistence of
OBJECTs... only persistence of names. Schemes need not *assure*
persistence of objects, but some thought should be given to assure
that the problem is not exacerbated by the scheme.
What happens when something moves? (Review of the 'scenarios'
questions mailed by masinter to the WG mailing list).

examples:
All web documents from CERN move to INRIA, but high-energy
physics documents stay at CERN. What happens to URNs?

Grad-student graduates but someone wants to retain editorial
control of one of his pages. How can this happen?

A university retains all articles by staff members; someone on
the staff publishes the exact document in an online journal.
Does it get a new URN, or just keep the old one?

One or several URN schemes?
There may be call for several, some tailored to specific aspects of
the problem set. eg: LIFNs do not solve all the problems of the
URN domain, but might be very useful as a guarantee of version
identity (imagine wanting to assure a JAVA applet version or identity).

Name Resolution: Should it be to a location (URL) or to a URC?

There is a need for a private part of the name space; (spook.gov,
snidely.com, privacy.edu, for eg., will need mechanisms for assuring
security)
Are we trying to solve NIDR with permanent names? Names should last
as long as the issuing agency... go to a permanent naming authority if
you want your stuff to last
Names with human-readable components (built in semantics) are
intrinsically less persistent than those made of opaque strings
(OIDs, ISBNs, etc.)
Schemes must be maintainable over time frames of hundreds of years to
achieve acceptance as identifiers of important cultural records by
research libraries

Qualification of a name space with time stamp (possibly low
resolution; year or year-month) will help make the inclusion of
human readable info in URNs more accessible to long term interpretation.
Semantics should be kept out of the name space mechanism

Semantics may be included, but only as convenience; they should
be ignorable (processable as content free tokens).

Join the DNS WG if you think you can invent a better namespace;
anyone who thinks this can be done probably doesn't understand the
problems.

Hierarchical resolution cannot be done with acceptable resolution times
(sub-second responses).

Overloading names with semantics is necessary to achieve low
resolution times (sub-one-second).

The new scheme entries should formally apply the URN requirements
document to their schemes.

It's time to decide on a syntax and character set so experimental
work can go forward.

We must agree on the semantics before we do a syntax

A URN Scheme Bake Off is proposed for the Stockholm (or failing that, the
Dallas IETF).
Set ground rules by 20th of April
Report preliminary results by Stockholm
Argue results in Dallas
Chris Weider, Larry Masinter, and Tim Berners-Lee are nominated
to establish ground rules (having spoken up about them in the
meeting), though comment and proposals from others are welcome.
Theoretical models of performance, though suspect, may also help
to shed light or point in the direction of further experimentation.

- Next message: Paul Hoffman: "Scheme extension mechanism"
- Previous message: Hubert Partl: "BOKU URL"
- Next in thread: Larry Masinter: "Re: URI minutes"
- Maybe reply: Larry Masinter: "Re: URI minutes"