Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Keith M
oore writes:
> On Jul 21, 2011, at 10:16 PM, Mark Andrews wrote:
> 
> >=20
> > In message <[e-mail]>, 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: [phone]                 INTERNET: [e-mail]