At Mon, 12 Mar 2007 18:14:53 +0100,
Julien Laganier <[EMAIL PROTECTED]> wrote:
> > This new version still breaks ABI compatibility,
> > meaning any implementors would have to rebuild any
> > software using getaddrinfo against a new library.
>
> [...]
>
> Sorry, overlooked that part below:
>
> > To avoid this, either a new API is defined (e.g.
> > geteaddrinfo with a struct eaddrinfo), or preference
> > flags are stored in ai_flags which still has more
> > than enough bits available for this purpose.
>
> The reason for introduction of the extended flag is
> that indeed someone complained that the ai_flags field
> will get crowded, and worse, to IPv6 benefit only.
I guess that "someone" includes (or is) me. I was and am against
about abusing the neutral ai_xxx flag space for purposes specific to
one particular address family (I know we already have such flags; I
argued we shouldn't do it this time). I thought I also pointed out
the available space might not be that large since it's an 'int' field
(which may be 16-bit long).
(The "abuse" aspect of the issue is not resolved even with ai_eflags,
though, so I'm personally not 100% happy with the current
specification).
Regarding the example that would be broken by the extension to the
addrinfo structure, it seems to me artificial and very rare (if it
ever happens). It's not surprising that the extension is unfriendly
with some tricky usage, but IMO the point is whether the benefit of
the extension outweighs the possible breakages. I'm actually not sure
if I have a clear opinion on it; on one had, the breakage example
given so far looks artificial as I said above (so a concrete example
of an existing application would be helpful if it exists). On the
other hand, I don't see much benefit in this extension either,
because, as far as I can see, only very few and special type of
applications want to use it.
In conclusion, I'd personally not support this document to be
published; however, I don't want to be a show-stopper just due to some
philosophical arguments either. If I were to vote, I'd thus probably
abstain.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
