Re: glibc's getaddrinfo() sort order
Marc 'HE' Brockschmidt writes ("Re: glibc's getaddrinfo() sort order"):
> While I agree that the RFC is proposing a sort order which isn't useful
> (at all) in the actual implementation of internet routing, I believe
> diverging from upstream and the standard without proposing a better way
> to solve this problem to be a bad idea. A bad RFC is a (smallish)
> problem, but a slightly different, probably under-documented [1]
> behavior can lead to, eh, interesting problems as soon as applications
> use the upstream behavior for something useful.
I don't follow. For what problem are you saying I should propose a
solution ?
The existing behaviour - as provided by gethostbyname everywhere and
by getaddrinfo on FreeBSD and in glibc versions - is correct.
> To avoid this, spending some time to come up with a better solution
> that can be standardized seems like a good idea.
The existing standard is round robin DNS as implemented by BIND. Just
because it's not formalised as an IETF document doesn't mean that we
shouldn't follow it.
> Footnotes:
> [1] I haven't seen your patch, but I'm pretty sure it doesn't contain a
> big fat "DANGER! WARNING! INCOMPATIBILITIES BE HERE!" disclaimer
That's because the behaviour I'm proposing *doesn't have any
incompatibilities*.
It's the *new* behaviour that is incompatible, and that
incompatibility is what has brought this question to the TC.
In any case, if the libc maintainer doesn't like the details of my
patch they'd be free to add their own (incorrect, IMO) warnings of
incompatibilties and even to include a rant about how idiotic the TC
is, or whatever. Or they could upload a change first.
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > Slavish adherence to standards, or to the views of mistaken upstreams,
> > is a generally a mistake. This is particularly the case for the
> > Debian Technical Committee.
> >
> > The TC's job is to decide what the correct behaviour is, by
> > considering the technical merits. The TC's job is not to interpret
> > standards documents. (Indeed, within our jurisdiction, our job
> > includes changing them if we disagree with them.)
>
> As there's no actual standard document that describes this behavior,
> it's a bit weird you feel that you should be the one to change it.
I don't see the connection at all.
Perhaps you thought I meant we should change some standards document
to so that it mandates the old, compatible, behaviour. For the
avoidance of any doubt that's not what I'm suggesting and as you will
see my proposed resolution doesn't say that.
My point is similar to that made by Steve Langasek, who writes:
The purpose of following standards is to foster interoperation between
products of multiple vendors.
Implicitly, he argues (and I agree) that where following a standard
does not foster interoperation, we should not follow the standard.
Ian.
Reply to: