In message <0DD53760-9B8A-4569-8C67-81421A8A24B6@xxxxxxxxxxxxxxxxxxxx>, Keith M oore writes: > On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote: > > >=20 > > In message <4E28C035.6020009@xxxxxxxxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf