On 21 Feb 2025, at 17:09, Niall O'Reilly wrote:
On 20 Feb 2025, at 16:00, Timothe Litt via curl-library
made a number of insightful comments, which I really appreciate; he
wrote:
You might consider extending getaddrinfo instead of creating yet
another API and (likely) library.
It has the 'hints's argument & ai.flags... and extending the addrinfo
struct in a backward-compatible manner seems possible. A heavier
initial lift to get acceptance, but could be better in the long
run.
My initial idea was to develop something which could supersede
getaddrinfo()
in the same way that this superseded gethostby*(), which would need
similar
heavy lifting to get acceptance.
I prefer your suggestion, and your assessment that a
backward-compatible extension
seems possible.
I wonder whether the diplomacy/politics/marketing necessary for an
update to POSIX
(or just glibc) can be completed in my lifetime.
This last consideration was decisive in negotiating the formation of a
project
team at the Hackathon.
We decided instead on a "wrapping" approach, like the current definition
of `struct Curl_dns_entry` in *lib/hostip.h*, but with a pointer to a
(chain of)
type-agnostic object(s), rather than to a single type-specific object
representing
data extracted from the RDATA of an HTTPS RR.
A team was formed around a merger of two projects, the other of which
needed data
from the TLSA RR (RFC6698) instead of the HTTPS RR. Having contrasting
requirements
helped us find an architecture flexible enough to accommodate possible
future
use-cases.
We still have to finish writing up our project; for anyone who is
interested,
the material can be found at https://github.com/DNS-Hackathon/LHB
The approach we used seems to offer the possibility of using RDATA from
the MX RR
"under the hood" in libcurl, instead of needing to identify the target
host for
a **mailto:** URL using an option.
/Niall
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
