Re: draft-fielding-uri-rfc2396bis-03, section 3

> 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