The pack scheme (DR 09-023) is now historical!
MURATA Makoto
eb2m-mrt at asahi-net.or.jp
Thu Dec 10 01:40:07 CET 2015
Dear colleagues,
I am surprised to see the pack URL scheme classified as historical at
IANA. It was provisional when ISO/IEC 29500 was approved, but it has
been historical since 2011-10-04. See
http://www.iana.org/assignments/uri-schemes/historic/pack
There appear to be a strong reason for making the pack scheme
historical. Reviewers in the IANA mailing list correctly pointed out
that pack URIs violates the syntax of URIs, as defined in RFC 3986.
(My analysis is at the end of this mail).
What should we do? Our plan was to document the pack scheme in the
revision of ISO/IEC 29500-2 and make IANA reference the revision.
1) We change the syntax of the pack scheme and try again. This
change will make all existing pack URIs incorrect.
2) We drop the pack URI scheme from ISO/IEC 29500. But now the
pack URI scheme is heavily used for defining how relative
references are resolved.
3) We continue to document the pack scheme in the revision of ISO/IEC
29500-2 and honestly state that pack URI schemes do not really
conform to RFC 3986.
Regards,
Makoto
--------------------------------------------------------------------------------------------
My analysis
The reviewers argued that the proposed pack scheme
violates the syntax as defined in RFC 3986.
Consider
pack://http:,,www.mysite.com,my.package/a/b/foo.xml
in 3.2 of the expired I-D.
They argued that "http:,,www.mysite.com,my.package" is not
a legitimate authority component, which is defined by
authority = [ userinfo "@" ] host [ ":" port ]
Let us consider the ":" character in
"http:,,www.mysite.com,my.package". Is it the one
preceding a port? No, because a port is a sequence of
digits. Thus, ",,www.mysite.com,my.package" is not
allowed as a port.
Is the ":" character then allows as a part of userinfo?
No, because "http:,,www.mysite.com,my.package" does not
contain "@", which is required if userinfo is present.
Then, does the non-terminal host allow ":"? A host
name is either an IP-literal, IPv4address, or reg-name.
host = IP-literal / IPv4address / reg-name
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
But "http:,,www.mysite.com,my.package" is not an
IP-literal, since it does not begin with "[". It is not
an IPv4address either, because dec-octet allows digits only.
Our last hope is reg-name. It is defined as
reg-name = *( unreserved / pct-encoded / sub-delims )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Obviously, a reg-name cannot contain ":".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20151210/20f8bcb3/attachment.html>
More information about the sc34wg4
mailing list