# Comments on URL RFC

Larry Masinter (masinter@parc.xerox.com)
Fri, 2 Jun 1995 12:23:15 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Re: URA headsup"
- Previous message: Leslie Daigle: "Re.: URA headsup"

    To: uri@bunyip.com

    Subject: Comments on URL RFC

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

    Message-Id: <95Jun2.122319pdt.2763@golden.parc.xerox.com>

    Date: Fri, 2 Jun 1995 12:23:15 PDT

Date: Fri, 2 Jun 1995 11:36:53 -0700
From: A_E_Salwin%caasd1@mwmgate1.mitre.org
To: masinter@parc.xerox.com, mpm@boombox.micro.umn.edu
Subject: RFC1738

The following are my comments on RFC1738, dated December 1994.
Overall I find the RFC technically sound, but have some detailed suggestions
that I feel would improve the understandability. Here goes:

1. Section 2 introduces three terms: "operations", "access method", and
"scheme". Please clarify the relationships among these terms. For example,
could "access method" be called "access operation"? Is a particular access
method a scheme, such as ftp?

2. Section 2.2, sentence 2 begins "A URLs". Change to "A URL"

3. "Reserved:" subsection under section 2.2, states, "If the character
corresponding to an octet is reserved in a scheme, the octet must be encoded."
This is somewhat misleading in that "@" for example, would not be encoded in
user@hostname. A few pagraphs later, better wording is employed ("reserved
characters used for their reserved purposes may be used unencoded within a
URL"). Suggestion is to use this better wording in both places.

4. Section 3.1: the distinction between an empty field and no field is not
clear. Maybe the following example would help clarify:
<URL:ftp://foo@host.com/> Which is this--empty or no password?

5. Section 3.2, paragraph 2 begins, "A FTP URL follow". Change to "An FTP URL
follows" (two changes)

6. Only the ftp section does not show the format of the URL. All other
sections (http, etc) show it. Recommend that section 3.2 begin with the full
URL format for the convenience of the reader, so it's all together in one
place, if for no other reason than to show the scheme part. That way they
don't have to go to the BNF in section 5. Also 3.2 says that ftp URLs really
just follow the generic format. However, the BNF in section 5 seems to define
ftp URLs independently of the generic definition. For consistency, I'd
recommend that section 3.2 define ftp distinctly, just as 3.3 does for http.

7. Section 3.3 notes that the trailing "/" is optional. However, I have found
some nodes where it seems to make a difference between fetching a default home
page or a particular page.

8. Section 5: the purpose of defining genericurl is not clear, since it is
not used (except for otherurl).

9. The appendix starts talking about URIs without telling (in a sentence or
so) what they are, giving a reference to what they are, or even spelling out
the acronym.

Thank you for considering my comments. I hope at least some of them prove
useful.

Art Salwin
salwin@mitre.org

- Next message: Mitra: "Re: URA headsup"
- Previous message: Leslie Daigle: "Re.: URA headsup"