Re: draft-fielding-uri-rfc2396bis-03 (appendices)

These are my comments for the back matter.

[UTF-8]: This is being updated (already passed IESG last call).
        So please change to 'RFC XXXX', with a note to the
        RFC editor to put in the right number when publishing.

Appendix B: 'breaking-down' -> 'breaking down'

Appendix B, after subexpression matches:
        The text here should explain how to find out whether
        a component is empty or undefined. E.g.:
        $8 and $9 both empty -> fragment undefined
        $8 == '#', $9 empty -> fragment empty
        and so for schee, authority, query, and fragment.

Appendix C, general comment:
        This is not very helpful the way it is written, because it
        is mostly wishful thinking. It is not really reflecting current
        practice. For example, in an vaverage email, instead of:
           Yes, Jim, I found it under "http://www.w3.org/Addressing/",
           but you can probably pick it up from <ftp://ds.internic.
           net/rfc/>.  Note the warning in <http://www.ics.uci.edu/pub/
           ietf/uri/historical.html#WARNING>.
        an average email would contain:
           Yes, Jim, I found it under http://www.w3.org/Addressing/,
           but you can probably pick it up from
           ftp://ds.internic.net/rfc/.
           Note the warning in
           http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING.
        So this section should also mention that there are additional
        conventions for plain text, e.g.:
        - Just use whitespace as delimiters
        - Remove trailing punctuation
        - Also accept non-ASCII as delimiter (some email clients do that,
          but it won't scale well for IRIs)


Appendix C, details:

    "most importantly, printed on paper": Please explain why paper
                                          is most important.

    "the fragment would be placed" -> "The fragment is placed"


Appendix D: "licence to unescape any octets": This is currently not
             true, but under discussion (see TBL's mail)

          'the "DAV:" namespace': It may be better to just say
          'the "DAV:" URI', to avoid having the reader think about
          'namespace' (not all readers of this document will be
          familliar with namespaces or the use of URIs for namespaces)
          [on the other hand, it may be good to add a reference to
           namespaces in section 6, and probably there are other references
           that will help the reader understand some of the new stuff]

          "the ABNF of qualified": Very difficult to parse when reading.
          I suggest "the ABNF of 'qualified'".

          "The resolving relative references algorithm" ->
          "The algorithm for resolving relative references"

          "o [RFC2396], section 5.2,...: "no path" -> "an empty path"

Index: It would be great if xml2rdf did two-column indices.
Otherwise, the RFC editor should be able to do this.
Some terms are missing, such as 'character encoding',
'UTF-8', 'US-ASCII',...

The only section missing now is section 2. I'll hope to be able
to send the comments today, otherwise tomorrow. I have quite
a few comments on section 2.


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 Monday, 23 June 2003 14:28:48 UTC