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).


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?


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?).


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.


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.


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."


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.


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.


3.3 Path: "reserved character allowed in segment" ->
    "reserved character allowed in segments"


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)


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.


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.


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.


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).


Regards,    Martin.

At 19:07 03/06/06 -0700, Roy T. Fielding wrote:

>I have just submitted draft 03, which can also be obtained via
>the issues list at
>
>    http://www.apache.org/~fielding/uri/rev-2002/issues.html
>
>Please note that all issues have been fixed or closed.  If you'd
>like to raise a new issue or reopen an old one, please do so
>within the next two weeks.
>
>
>Cheers,
>
>Roy T. Fielding, Chief Scientist, Day Software
>                  2 Corporate Plaza, Suite 150
>                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
>                  (roy.fielding@day.com) <http://www.day.com/>
>
>                  Co-founder, The Apache Software Foundation
>                  (fielding@apache.org)  <http://www.apache.org/>

Received on Thursday, 19 June 2003 11:11:10 UTC