|
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. |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf