To: Larry Masinter <masinter@parc.xerox.com>
Subject: Correction to Minutes, URI working group
In-Reply-To: Your message of "Sat, 24 Dec 1994 14:16:42 PST."
<94Dec24.141651pst.2760@golden.parc.xerox.com>
Date: Mon, 26 Dec 1994 19:38:29 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id: <9412261938.aa05876@paris.ics.uci.edu>
Here are my corrections to the minutes regarding the discussion on
relative URLs. Most are interleaved with the original (> prefixed).
> 8. Report on Relative URLs by Ron Fielding
Roy Fielding
> Report based on <URL:ftp://ds.internic.net/internet-drafts/
> draft-ietf-uri-relative-url-02.txt>. The slides for Ron's talk are
Roy's
> 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).
Although it is true that relative URLs remain dependent on
the internal structure of the tree, being independent of the external
structure is still of great value.
A second concern expressed was
> that we as a 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.
> There was general sentiment
> that relative URLs will be used anyway, so we should agree on them and
> this was a reasonable proposal for that.
Scratch this:
> Ron will revise the document to be compatible with the URL
> specification.
The current rURL spec is 100% compatible with the URL specification.
What I will do for the next draft is change the rURL resolution
algorithm so that it is scheme-independent, thus introducing some
incompatibilities between the two specs which will suggest changes
to the URL Draft Specification.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>