>
> Hi Jinmei,
>
> Thanks for bringing up this point.
> Please see my comment below.
>
> > > As requested, here are my comments about the addrselect-api draft.
> >
> > One additional comment (I think this has not been pointed out by
> > anyone. sorry if not):
> >
> > Using new flags for ai_flags of getaddrinfo() may have a compatibility
> > issue. RFC3493 says:
> >
> > The ai_flags field to which hints parameter points shall be set to
> > zero or be the bitwise-inclusive OR of one or more of the values
> > AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
> > AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
> >
> > I personally don't think this prohibits the use of other flags, but
> > some existing implementations seem to interpret this part in the
> > strictest way. Those return an error of EAI_BADFLAGS if an unknown
> > flag is specified in hints.ai_flags. getaddrinfo contained in BSD
> > variants and in the "libbind" library of ISC BIND behave this way.
> > For those implementations, applications that use this API extensions
> > will simply not be working, which is probably what we want to avoid.
> >
>
> It may vary implementation to implementation. I can't think of any other
> way than changing the implementation to support the new API. Those
> implementations that don't support the new AI_* flag will return
> EAI_BADFLAGS with getaddrinfo(). I'd say that similar could be true for
> new socket options.
>
> > However, I cannot think of any other solutions than having these
> > implementations change the behavior. So, we should probably first
> > agree on what the implementation should do for unknown flags and
> > describe the clarification in this document.
>
> As you mentioned that RFC3494 already defines :
>
> [EAI_BADFLAGS] The flags parameter had an invalid value.
>
> Are you implying that the document (RFC3494) should clarify that the
> implementation can return EAI_BADFLAGS for unknown flag value?
>
> If so, it makes sense to me. However, I'd interpret unknown value
> as invalid value as well.
>
> -Samita
This really is only a problem when a flag is defined in the
header file but the implementation doesn't support it or
one of the old flags is now permitted by getaddrinfo().
AI_ADDRCONFIG is a example of such a flag. A little bit
of looping addresses this however.
Mark
#ifdef USE_GETADDRINFO
memset(&hints, 0, sizeof(hints));
if (!have_ipv6)
hints.ai_family = PF_INET;
else if (!have_ipv4)
hints.ai_family = PF_INET6;
else {
hints.ai_family = PF_UNSPEC;
#ifdef AI_ADDRCONFIG
hints.ai_flags = AI_ADDRCONFIG;
#endif
}
hints.ai_socktype = SOCK_STREAM;
#ifdef AI_ADDRCONFIG
again:
#endif
result = getaddrinfo(hostname, NULL, &hints, &ai);
switch (result) {
case 0:
break;
case EAI_NONAME:
#if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME)
case EAI_NODATA:
#endif
return (ISC_R_NOTFOUND);
#ifdef AI_ADDRCONFIG
case EAI_BADFLAGS:
if ((hints.ai_flags & AI_ADDRCONFIG) != 0) {
hints.ai_flags &= ~AI_ADDRCONFIG;
goto again;
}
#endif
default:
return (ISC_R_FAILURE);
}
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
