In message <CAG5KPzxoza+rxyE0X74WtEX_+2kXoiKc6zEy+S5uH=hg0ur...@mail.gmail.com> , Ben Laurie writes: > On 20 May 2014 04:54, Paul Vixie <p...@redbarn.org> wrote: > > > > > > Ted Lemon wrote: > > > > On May 19, 2014, at 6:12 PM, David C Lawrence <t...@akamai.com> wrote: > > > > Not so much pushing required, at least of Akamai. You have a > > ready-made [SRV] ally in me, if only clients actually made good use of it. > > The clients are the real obstacle. > > > > Yup. It would be great if we could get the HTTP 1.1 clients to do it > > [SRV], but getting HTTP 2.0 clients to do it [SRV] seems at least as do-abl > e > > as any of the alternatives that have been proposed. > > > > > > i was there when SRV was conceived. we intended it to be used > > opportunistically, like MX before it, falling back to AAAA or even A querie > s > > if there was no SRV. it can be added to any protocol at any time, including > > HTTP/0.9 clients to the extent there are still any of those around. SRV's > > rules are defined for a service not by the client. if we decide that web > > servers can be reached by SRV records, then any web client can start lookin > g > > for the SRV that describes that service, falling back to whatever > > tin-cups-and-string it did before if it can't find the SRV it wants. > > Surely the problem is that the server must continue to support clients > that don't look for SRV. So, what's the incentive for a server to > start using it?
My that logic no one would be using MX record. The problem is we specifically prohibit the use for existing protocols without documenting how to do it. It's time we document how to do it. > > in that sense mark andrews' HTTP SRV I-D from all those years ago should no > t > > have been controversial. "if you want to do this, here's how everybody else > > agreed to do it." > > > > vixie > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
