[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