>>>>> On Tue, 19 Mar 2002 23:23:58 +0000,
>>>>> Ole Troan <[EMAIL PROTECTED]> said:
>> An example: a site-local address fec0::1 on the #2 site can
>> represented as fec0::1%5.2 (where 5 means the site scope and 2 means
>> the 2nd site)
> what is the reasoning behind this change? I certainly hope you still
> allow for the original <address>%<zone_id> where <zone_id> is one of
> number, name or interface.
I intended to introduce the new format as a replacement of the
previous "readable" format like "site2". Implementation dependent
zone "names" (including interface names) are still allowed.
As for "numbers", I'm not sure if it makes sense to keep them. Since
the consensus is zone IDs must contain scope type in its
representation, the form of <scope_type>.<zone_ID> is a kind of
"numeric" representation. Of course, the internal encoding of the
representation can be a single integer, but it might just be
complicated like 1342177281 (= 0x50000001) because it should contain
both the scope type and the zone ID. Do we still need the (possibly
complicated) "raw" numbers in the textual representation?
> while we're at it, I would suggest we change the prefix representation
> to: <prefix>%<zone_id> e.g fec0:0:0:1::/64%site2 which allows the use
> of '/' within the zone_id.
The motivation of the ordering is described in the 03 draft:
In this combination, it is important to place the zone index portion
before the prefix length, when we consider parsing the format by a
name-to-address library function [BASICAPI]. That is, we can first
separate the address with the zone index from the prefix length, and
just pass the former to the library function.
Though the API issue might not apply to all platforms, I believe it is
still reasonable enough.
>> The previous "readable" representation like "link2" or "site10" were
>> removed accordingly. The "unreadable" numerical representation like
>> 1342177281 (= 0x50000001) were also removed.
> good. how an implementation represents a zone with a numerical
> representation should be implementation specific. should suffice with
> a sentence saying that zones can be represented numerically.
Okay, if the consensus is to keep the "raw" numeric numbers in the
textual representation, we'll revise the text in a more generic
manner. (currently I'm planning just to remove this part.)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
