Message-Id: <9411040834.AA07997@mocha.bunyip.com>
To: uri@bunyip.com
Subject: generic IESG comments
Date: Fri, 04 Nov 1994 09:34:30 +0100
From: "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl>
While these documents represent major steps forward in the definition and
standardization of information resource location and identification, they do
not address at least two issues that will become increasingly important as
the Internet continues to grow. The necessity for solving these problems is
generally understood in the community and it is usually assumed that the
solution lies in URNs/URCs, but the URN requirements document does not yet
cover them. Resolution of the issues will be a precondition for moving of
the standards-track documents to Draft Standard.
The issues are:
--> Scaling and replication.
URLs point, or seem to point, to absolute locations on named hosts in
the DNS. While a number of "proxy" and "caching" schemes have been
proposed (and some have been deployed), Internet experience has been that
these problems are best solved by having multiple places in which to look,
not just caches of things found once already. Caches improve performance,
but do nothing for robustness. A long-term solution that provides the
ultimate client (or its proxy) multiple locations to look for the resource
is a requirement, just as the ability to support multihomed hosts and
multiple-preference MX records is a requirement for the DNS. Whether this
should be done through a modified URL, some URN construction, or some other
mechanism requires further definition and development.
--> Protocol-dependence.
The URL model involves a tuple of a protocol, a domain, and a
protocol-and-domain-specific string. A given resource might reasonably be
expected to be accessible via several protocols, and a server supporting
several protocols for one resource might rationally construct the
protocol-specific form of that resource on the fly during protocol negotiation.
Such a server would then want to advertise as many different URLs for the
same resource as the number of protocols it supported. This leads to
rapidly growing
aggregate record sizes for the information that might be returned in
response to a query. Whether this represents a problem should be the
subject of testing and examination while the documents are in Proposed
Standard status.
More important, the owner of the server might then make all resources on
that server
accessible via a new protocol simply by installing a handler/converter for
it. But the model set forth in these documents provides no model by with
existing records that point to the resource might be updated to the new
protocol information. This may be a significant point of
incompleteness in the model and proposed protocol. The mechanism for
propagating a new retrieval method from a multi-method repository/server
here must be resolved before the resource location documents move to Draft
Standard.