On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote:
In message
<4E28C035(_dot_)6020009(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp>,
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf