- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 16 Feb 2004 01:15:47 -0800
- To: Martin Duerst <duerst@w3.org>
- Cc: uri@w3.org
> Here are my comments on section 3: > > This section goes into details extremely quickly. In particular, > the paragraphs starting with "The scheme and path components..." > and "The authority component..." are full of design motivations > and general rules such as 'first-match-wins'. It would be better > to move the design considerations to the end of this section, > and to explain things like 'first-match-wins' in their own place > (maybe before the first grammar rule). Dropped due to editorial preference. > Last paragraph of 3.1: A pointer to the scheme registry would > be helpful. Maybe we can also smuggle in something saying that > schemes should be registered before used? I can't reference a bare URI due to RFC rules. The two RFCs that govern that process are already referenced. > 3.2, last paragraph before 3.2.1: The rule that scheme-specific > resolution should not ignore errors seems to be general, and > should be moved (Start of section 3? section 2?). Done. > 3.2.2, 4th paragraph: "A hostname takes the form...": This says > what the syntax is, but doesn't say that this is a domain name > from the DNS. The last paragraph of 3.2.2 says that actual lookup > in DNS is not required, and therefore implies that 'hostname' > is indeed bound to the DNS. But this should be stated explicitly. Done. > 3.2.2 Host: "square-brackets" -> "square brackets" > luckily, the "hyphenate everything" disease hasn't struck > this document much, and I don't see why it's needed here. Done. > 3.2.3 Port: "If port is omitted, a default may be defined by the > scheme-specific semantics of the URI." > > This seems to say that if the port is present, then there is > no default defined in the scheme-specific semantics. Please > change to something like: "Schemes may define a default port > in their scheme-specific semantics. If the port is omitted, > then this default port should be used." Done already. > 3.2.3 Port: "Likewise, the type of network port designated > by the port number (e.g., TCP, UDP, SCTP, etc.) is defined by the > URI > scheme. For example, the "http" URI scheme defines a default of TCP > port 80." > This mixes protocols and ports. TCP/UDP/... is not part of the port. > Otherwise, we would say "port TCP 80", and would have a means > to indicate the protocol as part of the port in the URI syntax. > I suggest to change this as follows: > > NOTE: The scheme-specific semantics define which protocol(s), > e.g. TCP, UDP, SCTP, etc., are used for this URI scheme. The > generic URI syntax does not provide a means to specify the > protocol. Something like that has been done already. > 3.3 Path: "They are intended for use at the > beginning of a relative path reference (Section 4.2) for indicating > relative position within the hierarchical tree of names, with a > similar effect to how they are used within some operating systems' > file directory structure to indicate the current directory and > parent > directory, respectively." > > This is an extremely long sentence. Please split. Done. > 3.3 Path: "reserved character allowed in segment" -> > "reserved character allowed in segments" Now "allowed in a segment" > 3.4 Query: "path (Section 3.3) component" -> "path component (Section > 3.3)" > (but I don't really thing this cross reference is needed, given > that in general, there are not so many, and this is just > immediately > after section 3.3) It looks better in the HTML version. > 3.4 The second paragraph and the note after that seem to speak about > the same thing: faulty client applications that include the query > part in the calculation of absolute URI references. So I think the > material in the Note should be included in the paragraph before. I moved the note back to the relative resolution section. > 3.5 Fragment: "However, if > that URI is used in a context that does call for retrieval and is > not > a same-document reference (Section 4.4), the fragment identifier is > only valid as a reference if a retrieval action on the primary > resource succeeds and results in a representation for which the > fragment identifier is meaningful." > > This may imply, or may be misunderstood to say, that for each > new fragment identifier, separate network action is needed, > i.e. that caching is disallowed. Please clarify that this does > not exclude the use of caching. Even just changing > "succeeds and results" to "succeeded and resulted" is a move > in the right direction, but I think more is needed to avoid > misunderstandings. I rewrote this last week. > 3.5 Fragment: "Fragment identifiers have a special role in information > systems as the primary form of client-side indirect referencing, > allowing an author to specifically identify those aspects of an > existing resource that are only indirectly provided by the resource > owner." > > Why 'indirect' (two times)? What is indirect? Maybe just > leave out that word. That is the whole point of the paragraph. > 3.5 Fragment: "it also serves to prevent information providers from > denying reference authors the right to selectively refer to > information within a resource." > > Another good reason for this behavior: reduction of privacy > exposure (the server only knows what documents somebody is > looking at, not what part). I think adding that would lead to more discussion than it is worth. ....Roy
Received on Monday, 16 February 2004 04:16:17 UTC