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