>>>>> On Fri, 19 Nov 2004 15:57:06 -0500, >>>>> Bill Fenner <[EMAIL PROTECTED]> said:
>> My dump question (that exposes my lack of knowledge about URIs/etc.) is >> since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" >> in the literal IPv6 address, why can't the "%" be used in the same >> way? For example: >> >> http://[fe80::20d:60ff:fe2f:8df5%4] >> >> Please excuse my ignorance on this, but it would be good to explain this >> (and include this information in the draft). (snip) > The basic issue is how special % is in URLs, because of > percent-encoding. Section 2.4 of draft-fielding-uri-rfc2396bis > (the full Standard URI spec, currently in the RFC-Editor's queue) > says: > Because the percent ("%") character serves as the indicator for > percent-encoded octets, it must be percent-encoded as "%25" in order > for that octet to be used as data within a URI. > The newer IRI spec (in IESG Evaluation; draft-duerst-iri-10.txt) > specifies an encoding of URIs to IRIs that assumes that any percent > anywhere in the URI begins a percent-encoded octet. Allowing a > bare "%" would complicate these rules quite a bit. There would be > no way to know without parsing the URI further whether the % began > a %-encoded octet or not. I see the complication in the specification. But aside from the specification issue, if you allow me ask a naive question as an implementor I'm still wondering why we cannot parse the syntax like http://[fe80::20d:60ff:fe2f:8df5%4] implementation-wise. If I were a parser programmer, I'd first find the pair of [ and ], and then pass the content (fe80::20d:60ff:fe2f:8df5%4) to a name-to-address conversion function such as getaddrinfo(). I'd do this procedure before doing sanity checks on the % character as an escape character. Of course, it is technically a bad idea to rely on such a hidden assumption. If we were going to make the specification from the scratch, I'd oppose to that. However, (in my understanding) we are discussing a more subtle issue; how to deal with the inconsistency between the 100%-compliant URI (or IRI) syntax and existing and deployed implementations. So, we'll probably seek a reasonable compromise... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
