Re: sockets APIs extensions for Host Identity Protocol

[der Mouse <[e-mail]>]

>> The major thing *I* use it for is to insulate the application from
>> knowledge of what address families are available.
> that's just fine for some corner cases, and if it works for your app,
> great - but it's not the general case.

My "app"?  My app*s*.  I've converted probably at least a dozen
programs to getaddrinfo(), and so far the only one that has had to pry
off the AF-independence hood is a netcat variant which has specific
command-line options to control use of IPv4 and/or IPv6 - and even that
one is ready to handle address families other than v4 and v6 if you
don't use those options.

I can only infer that you and I work on rather different sorts of
networking code. :-)

> for instance, SMTP over DECnet (which does exist, or at least did
> exist) imposed a maximum line length of 512 bytes.

I'd argue that's not SMTP, but a different protocol confusingly similar
to SMTP.  SMTP is relatively well-defined and is rather specifically
*not* tied to TCP:

   SMTP is independent of the particular transmission subsystem and
   requires only a reliable ordered data stream channel.  While this
   document specifically discusses transport over TCP, other transports
   are possible.  Appendices to RFC 821 describe some of them.

> again, it's nice that getaddrinfo() gives you a way to pretend that
> IPv4 and IPv6 are interchangeable for the benefit of the apps that
> can use that feature, but it's not as if all apps can or should work
> that way.

Oh, certainly.  But that's also no reason to impose AF-awareness on
apps that *don't* need it, and as far as I have seen getaddrinfo() is
the only C-language alternative that doesn't impose AF-awareness now.
Have I missed something?

>>> - it's actually more difficult to set the parameters for
>>>    getaddrinfo() to get it to do what you want, than it is to
>>>    initialize the fields in a sockaddr_in*
>> I find it about evenly balanced whether getaddrinfo() or doing both
>> INET* AFs is messier, more difficult, whatever.
> there are more quirks than that.  you have to know whether you have a
> numeric address and port.

I have never had to care.  Perhaps this just means I've never run into
a suitably misbehaving getaddrinfo()....

>>> - getaddrinfo encourages use of string constants to specify ports,
>>>    rather than numeric constants, which is wrong -
>> No, this is very right.
> sorry, I've spent way too much time debugging brain-damaged code that
> used getservbyname() and which failed when the NIS server went down
> or the /etc/services file got corrupted EVEN THOUGH THE PORT TO BE
> USED WAS A DEFINED CONSTANT IN THE PROTOCOL SPECIFICATION.

As the people running ssh on ports other than 22 - or SMTP on ports
other than 25 - attest (or, more precisely, running a protocol
otherwise just like ssh on a port other than 22, or a protocol
otherwise just like SMTP on a port other than 25), those "defined
constant"s *aren't* constant in practice.

I still maintain that using strings to name ports is right.

>> The notion that "ports" are small integers is a *horribly*
>> IP-centric notion.
> and the vast majority of our protocols are, by definition, IP
> centric.

Really?  Most of the specs I've read say things like "can run over any
bidirectional flow-controlled octet stream; when used with TCP, uses
port NN by default" and are actually not IP-centric at all.  Perhaps
you and I have just been working with different sorts of protocols.

> part of the problem is, the definition of the function doesn't
> actually say what the function does with respect to DNS because it's
> too vague - probably as a result of trying to take future
> hypothetical networking stacks into account.

True.  But I think that's better than sticking it with dependency on
current technologies and having to replace it entirely when something
new comes out.  That's what happened with gethostbyname() - which
assumes a host will have addresses in at most one address family - and,
while I won't say getaddrinfo() is entirely right, I think its attempt
to future-proof applications *is* right.  (The desire, that is, not
necessarily the way it went about it.)

>>> - it's not specified to use DNS.
>> But it can't really be specified to use DNS, since it is not
>> restricted to address families that the DNS supports
> that's a bug, not a feature.

I think we'll have to disagree on this.

But I do know that if something arises which is defined to use the DNS,
I - and anyone else building code which needs to be useful in
environments such as isolated networks where DNS is not available -
will simply not use it.  (For general-purpose name->address resolution,
that is.  I've written code using DNS-specific calls, but only for
things such as MX lookup tools where the job is inherently
DNS-dependent.)

> I've seen so much variation between implementations of getaddrinfo
> that I've become convinced that it needs to be replaced for that
> reason alone.

Perhaps.  But I strongly believe that in order to be useful, any
replacement needs to at least support (not necessarily compel)
AF-agnostic code.  I'd prefer to see it support string port names, too,
but that is relatively easy to fix with a wrapper replacement as
necessary.

> But the variation seems to have resulted from two things: the
> vagueness of the spec (in turn the result of overgenerality) and a
> demand to get the interface nailed down before the requirements were
> understood.

I see getaddrinfo() as an experiment in generalizing gethostbyname().
You see it as unfixably flawed while I see it as fixably flawed; that's
not that big a deal (though it's annoying to have to rewrite all my
networking code *again* for yet another new API).  I think the
important disagreements are over what lessons the experiment has to
teach us.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B