ietf
[Top] [All Lists]

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

2011-07-21 17:22:19
On Thu Jul 21 23:15:59 2011, Bruce Atherton wrote:
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.


Right.


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.


SRV lookup is pretty commonplace now in libraries. XMPP and SIP clients have no difficulty finding this functionality in a wide variety of environments. For the web, where there are substantially fewer web browsers than there are XMPP clients, I don't think this would pose any kind of problem.


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.


SIP survived because it was very small. I don't see WS making a transition, in the same way that repeated attempts have failed to move HTTP to SRV.

Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>