draft-ietf-httpbis-alias-proxy-status: Refer to AI_CANONNAME

[bemasc]

I think the alias draft should probably have a (non-normative) reference to getaddrinfo's AI_CANONNAME functionality, in particular noting that:

• next-hop-aliases can be populated from the output of getaddrinfo.
• next-hop-aliases can be used to emulate or substitute for getaddrinfo.

[edmondsfastly]

I think the AI_CANONNAME flag to getaddrinfo only gives you the "canonical name" which is the final CNAME target at the end of the CNAME chain. If you want the full set of interior names across a chain of multiple CNAME records I don't believe you can retrieve that with getaddrinfo.

[tfpauly]

Yeah, I'm hesitant to add references to system APIs like getaddrinfo, and particularly for the reason given above. @bemasc what do you think?

[bemasc]

I think AI_CANONNAME is important historical context here. You can't understand where the draft is coming from without it. I also think that this extension will often be implemented by wrapping getaddrinfo, and some guidance about whether that is compliant would be appropriate. I think Robert's comment raises a good example of why this is not trivial, and hence is worth mentioning.

…

On Wed, Jan 18, 2023, 7:53 PM Tommy Pauly ***@***.***> wrote: Yeah, I'm hesitant to add references to system APIs like getaddrinfo, and particularly for the reason given above. @bemasc <https://github.com/bemasc> what do you think? — Reply to this email directly, view it on GitHub <#2358 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABO3SJ2J7L4CNLTS2YQH7LWTCF6RANCNFSM6AAAAAATRG33BE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tfpauly]

I'm not sure AI_CANONNAME is really required to understand the context of the draft. We don't use it at all on iOS/macOS implementations for current CNAME cloaking detection.

I do see that it may be good to warn that it is not sufficient to just wrap up AI_CANONNAME.