>>>>> On Thu, 20 Oct 2005 15:35:51 -0700 (PDT), 
>>>>> Samita Chakrabarti <[EMAIL PROTECTED]> said:

>> 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?

Not really.  I said some document (3494bis or addrselect doc or
whatever) should (1) define "unknown flags" clearly and (2) clarify
what getaddrinfo() should do if an "unknown" flag is specified.

Regarding (1), RFC3493 specifies explicit flag names: AI_PASSIVE,
AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and
AI_ADDRCONFIG, which could read that any flags other than those listed
are "unknown".  But perhaps the real intent is that "under flags" are
flags that the system (getaddrinfo implementation) does not support.

Regarding (2), it seems to me returning EAI_BADFLAGS is reasonable,
but I don't have a strong opinion on this point.

As for the relevance to the addrselct API, I was confused about one
point.  New applications that support this API would probably test the
availability of the flag first like this:

        hints.ai_flags = 0;
#ifdef AI_NEWFLAG
        hints.ai_flags |= AI_NEWFLAG;
#endif
        getaddrinfo(..., &hints, ..);

Thus, the problem occurs only when the flag definition and the
getaddrinfo() implementation are inconsistent (as Mark pointed out).
It would be fair to say such inconsistency is a bug and ignore such a
case.

I think it's still helpful if the addrselect document assumes the
consistency between the supported flag definitions and the
getaddrinfo() implementation.

                                        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
--------------------------------------------------------------------

Reply via email to