>>>>> On Fri, 3 Dec 2004 09:32:31 -0800,
>>>>> Bill Fenner <[EMAIL PROTECTED]> said:
>> There were >100 e-mails on the ipng ML at December 1999 about the
>> representation. Actually we considered the all possible characters.
>> One reason to reject '_' was that it should be used for <zone_id>.
> There are very few messages (around 10) in the archive that actually
> discuss the specifics of delimiter selection (mostly with subject "Re:
> Scope ID secret Cabal (minutes)"). The only message that I saw suggesting
> that "-", "." and "_" might be reserved because they could be used in
> the <zone_id> also said that he preferred "-" or "_" as the delimiter.
> I'd say that message could be used to argue for either side of the issue.
I've also been recalling the previous discussions, including
non-public, internal ones. And I admit we did not find any clear
conflict with "_" at that time. If we just started the scope-arch
work, it would definitely be better to adopt "_", not "%". The
problem is that % as the delimiter has been in the scope-arch spec for
several years, and implementations using the spec have been quite
widely deployed, making the transition costly.
So, IMO, we need to make a decision considering following points:
1. how costly it is to change the existing implementation
2. how seriously we want (to allow) the use of scoped address syntax
in IRIs or URIs
I'm quite sure opinions vary on these points. Speaking for myself,
I'm very reluctant to change the existing implementations. Regarding
the migration cost, I basically agree with Juergen. I'd also really
like to ask others not to underestimate the deployment base.
Regarding point 2, I personally suspect the reality, at the risk of
exposing my ignorance. I remember two possible use cases were shown:
- configuring a home router/dhcp/dns server via HTTP via a link-local
address
- SNMP URIs that get passed between different agents/managers on the
same system.
In the former case, I guess we can simply use the "default zone ID" in
many cases (although some implementations may not yet support that, in
which case we'll need to fix them). I'd say the latter use case is
very minor, while I must admit just saying "it should be minor" is not
convincing.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in
the RFC editor queue for over 3 months. Is anyone know whether this
is a usual delay or the issues with the URI syntax is working as a
showstopper?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
