>>>>> On Thu, 21 Mar 2002 10:54:25 +0200, 
>>>>> Markku Savela <[EMAIL PROTECTED]> said:

> The
>       <address>%<scope_type>.<id_in_the_scope>

> just does not feel right to me. I don't like notations which allow
> writing erroneous expressions, whenever it can be avoided. And, I'm
> not yet quite convinced, that this case needs such "error-allowing"
> notation.

> Thus I prefer

>       <address>%<id_in_the_scope>

As for this, I made another proposal in a reply to Margaret.

> and scope type is from address. And, then make sure every address has
> a definite scope designated (the ones for which scope is a bit unclear
> are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind
> addresses).

I think ::/3 (except ::/128) should be treated as global, in terms of
*IPv6* scoping architecture.  

(The address selection draft (by Rich Draves) treats (e.g.)
::ffff:10.1.1.1 as site-local, but, in my understanding, the main
purpose of this is to compare IPv4 addresses and IPv6 addresses in the
destination address ordering in terms of scoping.  Thus, I don't think
the definition in the scoping arch draft contradicts with the
definition in the address selection draft.)

> I thought my proposal was nice for listen sockets, you don't need a
> special separate socket option to set the scope, if you want to limit
> your listen to any address of specificic scope. With definitions

>      fe80::%<zoneid> - ANY address in specified link local zone
>      fec0::%<zoneid> - ANY address in specified site zone

> and normal bind as before, the process seems very simple (how this is
> reflected in internal data structures of listen socket is different,
> implementation matter).

Honestly, I'm not so fascinated by this trick in API, but anyway, this
kind of API extension is out of scope of the architecture draft.

                                        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]
--------------------------------------------------------------------

Reply via email to