>>>>> On Mon, 26 Jun 2000 20:30:24 -0700 (PDT),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
> I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_-
> scope_id for what it was originally intended, to identify the zone from
> which a datagram was received and to identify the zone to which a datagram
> should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF
> does that is unfortunate but it certainly isn't the only or even the worst
> example of duplicated functionality in the API specifications.
> Application writers are familiar and confortable with the notion of
> specifying the outgoing interface to be used for multicast and I just don't
> see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make
> application writers' lives easier. Gratuitous changes to APIs piss
> people off even if they are improvements.
I agree with this.
We could implement Steve's proposal if we invented unique space of
identifiers that covers all scopes. And I admit it would be useful if
we can specify the outgoing interface by the sin6_scope_id field
without any other APIs (such as socket options), but it would be too
complecated for application programmers, especially on properly using
different type of sin6_scope_id values (i.e. sometimes use it as an
interface identifier, and sometimes use it as a zone identifier of a
larger scope).
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]
--------------------------------------------------------------------
