there were several pro-HTTP-URI comments in this thread; i picked the
one with the most technical meat. brian, jim, paul: thank you for your
comments.
Ray Bellis wrote:
On 05/11/2018 18:55, Joe Abley wrote:
2. Find a client-side solution to this, and try really hard not to
invent something new that is really just SRV with a hat and a false
moustache.
There *is* a big failing of SRV that's independent of the CNAME apex use
case, and that is its lack of support for wildcards. Since my proposal
doesn't use underscore prefix labels, wildcards will work, and this is
an important requirement for some large website operators.
on that basis, i would ordinarily withdraw my objection, since the
needed functionality is just not present in the existing code point.
The cost to the DNS community of *trying* my proposed HTTP record is
pretty negligible. Worst case, as Brian put it, is we burn a code point,
add a trivial amount of code to DNS servers, but the browsers don't
adopt it. It wouldn't be the first time, it won't be the last.
please don't think this way, and don't do the right thing for the wrong
reasons. the paragraph above is how the camel came to be -- one draft at
a time, all well-meaning.
the fully loaded long term cost to the economy of an "if" statement in a
widely deployed C program is about USD 10.000. we should never add to
this externalized cost unless we have a compelling reason to do so. "the
web people don't want even one extra RTT, ever" is not compelling. "the
web people need wildcards to work which they don't in SRV" however, is
compelling.
However, it only takes one of the big browser vendors to decide they'll
support it and I think the rest will shortly thereafter follow suit.
NB: this proposal currently satisfies the criteria for assignment via
expert review per RFC 6895.
as may be, this looks like an argument over who has to fetch the data.
the browser people don't want it to be them. i can't blame them, but the
reason SRV specifies opportunistic rather than mandatory additional data
is to keep the recursive DNS server from both fetching and caching (and
now, validating) the AAAA/A, from having to keep the SRV transaction
open longer (while its mandatory AAAA/A additionals are fetched and
before the very first answer, a possibly soft cache-miss, is sent), and
to avoid loading the network with a query whose answer might not be used
(something else about the SRV response might have caused a failure in
the www transaction such that the AAAA/A is never needed.)
those were solid and still-valid engineering-technology and
engineering-economics considerations. when we add "HTTP URI" we do so at
costs greater than a code point. and even the code point has to add some
"if" statements to the globally deployed system. that won't be cheap,
merely externalized. a cheeseburger that externalizes USD 10 of
environmental cleanup costs onto the economy is still a USD 10
cheeseburger, even if it only costs USD 0,25 to make and has a consumer
price of USD 1.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
