On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote: > So do you have a use case where you think the behavior described in rule 9 > *is* desirable?
Any application written assuming this behaviour, works correctly on
Windows, Solaris, *BSD and glibc based systems in general, but not
on Debian.
In the bug log, Pierre reported this behaviour is already supported on
most of those sytems:
] On that matter, according to Aurelien, Vista (maybe XP),
] {Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
] and solaris come to mind). So it's kind of a decision of Debian vs. the
] rest of the world. And if I don't really care about the issue of the
] decision technically, this aspect worries me.
Hrm, I see RFC5014 (from this month) provides some socket options for
changing the way RFC3484 source address selection works, and envisages
the possibility of doing the same for destination address selection. It
assumes prefix matching is undertaken in getaddrinfo in order to achieve
one of its aims.
> Even if you do have one, I still don't see any reason to think this is a
> reasonable default behavior on the real-world Internet.
As it happens I largely agree with that. I don't agree with making a
decision to go against an IETF standard and glibc upstream lightly,
though, no matter how many caps Ian expends repeating that it's at the
least mature level of Internet standard. If it's also the case that
the RFC-specified behaviour is a de facto standard amongst other OSes,
as the above seems to indicate, then that's even more reason to make
sure we have a clear decision backed up by good, clear reasoning.
Cheers,
aj
signature.asc
Description: Digital signature
