Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs

[JINMEI Tatuya / 神明達哉 <jinmei@xxxxxxxxxxxxxxxxxxxxx>]

>>>>> On Fri, 19 Nov 2004 15:57:06 -0500, 
>>>>> Bill Fenner <fenner@xxxxxxxxxxxxxxxx> 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.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------