On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote: > > In message <4E28C035.6020009@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Masataka Ohta writes: >> Dave Cridland wrote: >> >>> It's proven impossible, despite effort, to retrofit SRV onto HTTP; >> >> Where is a proof? >> >> Masataka Ohta > > Transitioning HTTP to use SRV is trivial even with proxies. > > Transitioning HTTPS to use SRV is complicated because of proxies. > There needs to be changes to how clients talk to proxies for HTTPS > + SRV to work through proxies. > > HTTP and HTTPS's use of the DNS is a abomination. CNAME is totally > misused. If you want to host a service on another machine you use > a record that indicates that. You don't use a alias because aliases > mean so much more. > > Getting back to WS and SRV, WS needs to be SRV aware from day one > or it needs its own type in the DNS. If you don't have SRV records > then you fallback to straight address records. I'm fairly convinced that in the vast majority of cases, SRV is a bad idea. DNS is already too out of sync from hosts in many situations; SRV just makes the situation worse. Or to put it another way, if you want to give every DNS admin the ability to impose fine-grained control over what all of the hosts named by his DNS zones can do, deploy SRV universally. There are situations where this makes sense, but overall, giving that level of control to DNS administrators is an extremely bad idea. That said, if this protocol is going to use SRV, it absolutely needs to do it from day one. There's no way to retro-fit SRV to most protocols without breaking compatibility with existing implementations of those protocols. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf