Comments on URL RFC

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

Received on Friday, 2 June 1995 15:24:24 UTC