At 8:30 PM -0700 6/26/00, Tim Hartrick wrote:
>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.
Sure, there's a good backwards compatibility argument for keeping
IPV6_MULTICAST_IF, and I don't pretend to be able to judge how much
hassle it would be for anyone if it were to disappear, so it's not
something I want to argue strongly for. But if it is indeed duplicated
functionality, we should perhaps at least point that out in one of the
API specs, so users don't have to scratch their heads wondering if it
is or it isn't.
>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.
Point taken and conceded.
>I have been as guilty as anyone of beating the snot out of the dead horse
>that is rfc2553 but I don't see any upside to making this change at this
>late date.
Probably right. I'm more interested in us all understanding and agreeing
on the architecture, so we can actually agree whether a particular API
function is redundant or not, than to produce a pristine API.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
