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

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 04 Dec 2004 14:17:49 +0900

>>>>> On Fri, 19 Nov 2004 19:03:51 -0800, 
>>>>> "Roy T. Fielding" <[email-masked]> said:

> I don't think that they are actively used for significant operations.
> Yes, they are implemented (inconsistently) on multiple platforms
> (some allow names to occur after the '%", while others assume that
> the zone ID will be a small integer),

(a minor note) draft-ietf-ipv6-scoping-arch-02.txt specifies integers
as the minimum set of scope zone IDs that all implementations must
support.  All compliant specifications must accept decimal integers,
and *BSDs should behave so, although it prints attached interface name
by default.

> There is nothing we can do in the specifications to change the
> fact that using a % as a zone ID separator in URIs will result in
> interoperability failures.  Those applications are already deployed.
> It would be easier to change all of the deployed operating systems
> that contain IPv6 to allow an additional delimiter character if
> cut-and-paste is really important.

I don't buy this argument.  We can also say that system libraries with
'%' '%' as the delimiter and applications using the libraries are
already deployed.  As others already said, BSDs have been using for
several years, which is also merged into MacOS X.  In addition, as far
as I know recent versions of Windows and Linux implementations adopt
this specification.  I would say that saying "these are not actively
used for significant operations." is misleading.  First of all, what
"significant operations" mean is really not clear.  Additionally, why
can we be so sure that they are not actively used without knowing how
real IPv6 operators do or do not use the syntax?  As an IPv6 operator,
I often use this notation for diagnosing IPv6 routers or in some cases
DHCPv6/DNS servers.

I'm not insisting that we can ignore the deployed parser that are not
friendly with the '%' delimiter.  I just want to note that we cannot
simply say "XXX is not so deployed so it would be easier to fix it",
whether the XXX is existing systems with the % delimiter or existing
parsers which are unfriendly with the '%' delimiter.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 04 Dec 2004 14:18:19 +0900

>>>>> On Fri, 19 Nov 2004 15:57:06 -0500, 
>>>>> Bill Fenner <[email-masked]> 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