Date: Tue, 29 Nov 1994 14:51:40 +0500
From: jak@nlm.nih.gov (John A. Kunze)
Message-Id: <9411291951.AA09569@dot.csb>
To: uri@bunyip.com
Subject: Re: draft-ietf-uri-irl-fun-req-01.txt IESG comments
This is in response to the IESG comments on the IRL requirements document.
It is intended to feed into the RFC-editor process and probably will not
need discussion time at the live URI meeting. I've sent the current draft
off for publishing and at the end of this message I've appended the usual
"diffs" between the previous and current drafts.
> To: uri@bunyip.com
> Subject: draft-ietf-uri-irl-fun-req-01.txt IESG comments
> Date: Fri, 04 Nov 1994 09:35:27 +0100
> From: "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl>
>
> "A resource locator is a kind of resource identifier."???
> As Noel as frequently emphasised on big-internet, there is a difference
> between a name (an identifier, a topologically insensitive thing), and
> a locator. An irl (and a url) is a locator. It describes where something
> is right now. It is not the identifier for the thing. Permitting this
> confusion will, sooner or later, cause difficulty.
The point is taken. I'm afraid I'm not familiar with the discussions
within which these definitions applied, but I can imagine environments
(eg, a C program) in which one would never call a storage location
"a kind of identifier".
The URI group certainly had a difficult time coming up with the name "URI"
for itself and the name "URL" for its first born. Somehow I trust that
the in-depth discussion I witnessed and participated in, with all its
twists and turns, resulted in the very best names for these two terms.
The 'I' always stood for Identifier and the 'L' always stood for "a kind
of resource identifier" known as a Locator. Given how entrenched the
precedent is I doubt that it would be productive to try to budge it.
The URI problem has been haunted by the complexity and unpredictability
of how human beings identify concepts that they manipulate in their own
environments, which are different from formal environments. Is the airplane
seat named "33A" a locator that is a kind of identifier? or vice versa?
What about the hotel room named "2204"? Human beings will probably always
find good reason to use locators as identifiers, and human beings are
already using URIs as part of their own no-so-formal environments.
I think we have to take our cues from them.
> It is interesting that section 3.3 says that the document makes
> few uniqueness requirements. In fact it explicitly makes NO
> uniqueness requirements under any definition of uniqueness.
> I think that the introduction to section 3.3 ought to say that uniqueness
> is a non-goal, and that these are the specific forms of uniqueness that
> were considered in reaching that conclusion.
I've changed it along the lines suggested and think it's clearer now.
> While this is probably irrelevant, I actually find it odd that the
> "locator" includes the "service" to access the resource. This
> is probably defensible, but it is odd.
It may be that the word "locator" suggests too much a single model
of service, namely, that the resource out there is just a chunk of data
to be fetched back to the client. This single service model dominates
the way that ftp, gopher, and http services are used via URL, but services
in general need not be so similar.
A service-independent locator is one thing, and it requires a single model
of service. A locator is a richer thing, incorporating multiple models
of service. The model popularized by the *current* crop of Web browsers
maps a single user interface easily onto three very common protocols
(remembering that "protocol" is different from "service"), but that needn't
lead us to conclude that there are not other service models.
> missing security section
> missing authors address
These sections have been added. Diffs follow.
-John
=====================================
*** req-01.txt Tue Nov 29 14:18:45 1994
--- req-02.txt Tue Nov 29 14:34:33 1994
***************
*** 2,5 ****
Internet-Draft IS&T, UC Berkeley
! Category: Informational
! 27 July 1994
--- 2,4 ----
Internet-Draft IS&T, UC Berkeley
! 28 November 1994 Expires in six months
***************
*** 7,8 ****
--- 6,8 ----
Functional Requirements for Internet Resource Locators
+ <draft-ietf-uri-irl-fun-req-02.txt>
***************
*** 207,212 ****
The topic of a "uniqueness" requirement for resource locators has been
! discussed a great deal. This document recognizes several aspects of
! uniqueness, but deliberately makes few requirements regarding them.
! It is incumbent upon a resource location standard that takes on this
! topic to be clear about which aspects it addresses. Some of them follow.
--- 207,212 ----
The topic of a "uniqueness" requirement for resource locators has been
! discussed a great deal. This document considers the following aspects
! of uniqueness, but deliberately rejects them as requirements. It is
! incumbent upon a resource location standard that takes on this topic
! to be clear about which aspects it addresses.
***************
*** 353,356 ****
! 6. Conclusion
Resource location standards, which define Internet resource locators,
--- 353,381 ----
! 6. Security Considerations
!
! While the requirements have no direct security implications, applications
! based on standards that fulfill them may need to consider two potential
! vulnerabilities. First, because locators are transient, a client using an
! invalid locator might unwittingly gain access to a resource that was not
! the intended target. For example, when a hostname becomes unregistered
! for a period of time and then re-registered, a locator that was no longer
! valid during that period might once again lead to a resource, but perhaps
! to one that only pretends to be the original resource.
+ Second, because a locator consists of a service and a parameter package,
+ potentially enormous processing freedom is allowed, depending on the
+ individual service. A server is vulnerable unless it suitably restricts
+ its input parameters. For example, a server that advertizes locators for
+ certain local filesystem objects may inadvertently open a door through
+ which other filesystem objects can be accessed.
+
+ A client is also vulnerable unless it understands the limitations of the
+ service it is using. For example, a client trusting a locator obtained
+ from an uncertain source might inadvertently trigger a mechanism that
+ applies charges to a user account. Having a clear definition of service
+ limitations could help alleviate some of these concerns.
+
+
+ 7. Conclusion
+
Resource location standards, which define Internet resource locators,
***************
*** 374,376 ****
! 7. Acknowledgements
--- 399,401 ----
! 8. Acknowledgements
***************
*** 398 ****
--- 423,433 ----
+
+ 9. Author's Address
+
+ John A. Kunze
+ Information Systems and Technology
+ 293 Evans Hall
+ Berkeley, CA 94720
+ jak@violet.berkeley.edu
+ Voice: (510) 642-1530
+ Fax: (510) 643-5385