[rfc-i] Review:: draft-shur-pack-uri-scheme

Frank Ellermann nobody at xyzzy.claranet.de
Sun Apr 6 09:35:11 PDT 2008


Hi, some issues in draft-shur-pack-uri-scheme:

 1) The grammar in section 3.3 is no valid RFC 4234 ABNF
    as claimed, it uses // to introduce a comment or prose
    specification instead of ; or angle brackets resp.
    The grammar also uses "|" instead of "/" to indicate
    alternatives.

 2) RFC 4234 was obsoleted by STD 68.

 3) Redefining the STD 66 <authority> is confusing.  What
    is apparently wanted here is a complete URI replacing
    slashes by commas everywhere.

 4) Complete STD 66 URIs may contain query parts introduced
    by a question mark, such URIs cannot be used in the
    pseudo-<authority> construct of the pack: construct.

 5) Complete STD 66 URIs may contain commas, the draft does
    not say what to do with real commas in comparison with
    commas representing slashes.  

 6) An "obvious" solution to percent-encode question marks
    and commas could require to percent-encode all percents
    resulting in a double-encoding.

 7) The draft doesn't mention that embedded complete STD 66
    URIs are supposed to contain no fragment introduced by
    "#".  Fragments have to be stripped, not percent-encoded.

 8) The case insensitive comparison of <path>s should note
    what this means in the case of percent-encoded UTF-8 as
    specified in RFC 3987.  Compare section 2.6 of RFC 4395.
   
 9) The comparison of <path>s might require a canonical form
    without any unnecessarily <percent-encoded> STD 68 VCHAR. 

10) The draft does not clearly say what a "part" is.  If it
    is something in the direction of a file in a ZIP-archive
    case insensitive <path>s could be a security issue.

11) A possibly old version of a normative reference uses a
    transformation, where apparently any Unicode string can
    be transformed to IRIs, and IRIs can be transformed to
    URIs.  The second step is clear (RFC 3987).  The first
    step is less clear, see a report on the public IRI list.

 Frank



More information about the rfc-interest mailing list