[...] > 2. revise the textual representation section > in the form of <address>%<zone_id>, the <zone_id> part is now > formatted as follows: > <scope_type>.<id_in_the_scope> > where <scope_type> is a decimal number from 0 to 15 to specify a > scope type, which corresponds to the "scop" field values of multicast > addresses, and <id_in_the_scope> is a decimal number to identify a > zone. "." is a delimiter character to separate <scope_type> from > <id_in_the_scope>. > (the reason for the delimiter character "." is because it is used in > the "normal" address representation so address parser should escape > the character. And, "." is more intuitive and more readable than > other characters (i.e. ":", "a-f0-9").) > > 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. 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 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. /ot -------------------------------------------------------------------- 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] --------------------------------------------------------------------
