In message
<0DD53760-9B8A-4569-8C67-81421A8A24B6(_at_)network-heretics(_dot_)com>, Keith M
oore writes:
On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote:
=20
In message
<4E28C035(_dot_)6020009(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp>,
Masataka =
Ohta writes:
Dave Cridland wrote:
=20
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
=20
Where is a proof?
=20
Masataka Ohta
=20
Transitioning HTTP to use SRV is trivial even with proxies.
=20
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.
=20
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.
=20
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.
What a load of FUD. SRV records are no differnet to CNAME/MX records
in terms of control. We don't shy away from adding MX records for
email or CNAME records for HTTP when CNAME is used a SRV equivalent.
Note even with SRV you have fallback to A/AAAA records when no SRV
record is present.
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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf