- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 2 Jun 1995 12:23:15 PDT
- To: uri@bunyip.com
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