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

[Bruce Atherton <[e-mail]>]

I think there is some misunderstanding as to what is being proposed, at 
least as I understand it. Iñaki, please correct me if I am wrong.

You are right that it would be impossible to require all environments 
that wanted to add Websockets support, whether client or server, to 
change their DNS to have NAPTR and SRV records. After all, Websockets is 
intended to integrate easily into the already existing HTTP infrastructure.

What is being proposed, though, is to require clients to resolve the 
hostname portion of ws: and wss: URLs by _first_ looking for NAPTR and 
SRV records (unless, of course, the hostname is already an IP address). 
If a NAPTR record is found, use it to look up an SRV record (otherwise 
use a default). If an SRV record is found, use it to look up the A or 
AAAA record. If no SRV record is found, look up the record exactly the 
same as if you were looking up an HTTP host, by using the host name from 
the URL.

So if you have no control over the DNS, it is not a problem. The host 
will be resolved exactly the same way as it is now, using a hosts file 
or A record or whatever. The only change is that the client is required 
to try to use the more advanced mechanism if it is available.

I admit that I find it a little troubling to use MUST for the client to 
follow this procedure as there is a burden on implementers to understand 
how to code this since it isn't done by default in the standard 
libraries the way that ordinary name resolution is. Making it the 
recognized best practice with a SHOULD would be preferable all else 
being equal.

It can be argued that not using a MUST may well open up interoperability 
problems because some Websockets clients contact the wrong host. 
However, keep in mind that in the older SIP RFC2543 it provided two 
resolution mechanisms. It specified that clients SHOULD look up address 
records, but MAY use the DNS SRV mechanism. SIP survived that without 
too much of a hassle. And specifying that Websockets clients SHOULD use 
DNS SRV, but MAY use address records alone looks like an improvement.

As for where the enhanced location definition should live, I think a 
separate document is the best choice. No need to hold up this one.

On 21/07/2011 11:01 AM, David Endicott wrote:
> I am strongly opposed to any MUST definition for any type of URL 
> resolution.
>
> I'm ok with inheriting / mimicking HTTP.    Since it is intended to 
> live in the same universe as HTTP, I'm ok with it sharing mechanisms / 
> limitations.
>
>
>
> On Thu, Jul 21, 2011 at 1:52 PM, Iñaki Baz Castillo <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     2011/7/21 Dave Cridland <[e-mail]
>     <mailto:[e-mail]>>:
>     > It's proven impossible, despite effort, to retrofit SRV onto
>     HTTP; there is
>     > no way it'll be possible to retrofit onto WS.
>
>     Right. If WS borns with no SRV (as a MUST for WS clients) then just
>     forget it and let inherit all the ugly limitations from HTTP protocol.
>
>     --
>     Iñaki Baz Castillo
>     <[e-mail] <mailto:[e-mail]>>
>
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi