On Thu, Jul 21, 2011 at 10:24 PM, David Endicott
<dendicott(_at_)gmail(_dot_)com> wrote:
I find myself reminded of my reservations about HTTP Upgrade as the opening
handshake. It is clever, efficient and reflects some of the shared nature
between HTTP and WS. However, I felt it should be considered one of
several mechanisms for opening a WS connection, one especially suited for
a co-mingled environment. But not explicitly the only such method. (I was
unable to convince many of my position on that, so I could very well be in
the minority about this issue as well) I think DNS SRV is in a similar
area. It's a useful technology that if the client uses could be of
benefit. I'm just not convinced there is overwhelming cause to make it a
mandatory requirement. Saying that nobody will use it if it's not
legislated does not strike me as a good enough reason. The technological
advantages are worthy, when it's used, but when it doesn't come into play,
there are added inefficiencies. Also the name resolution of the HTTP that
serves the Javascript that opens the WS should remain constant. If WS
resolves the host/domain to a different address than the HTTP it was spawned
from, it becomes a method to bypass same-origin / CORS restrictions.
I favor a minimalist core with extensibility. Name resolution happens
before the WS opening handshake, so I continue to see this as outside the
domain of the WS protocol. I would prefer that name resolution be provided
by a selectable method. That way, in 20 years, when name resolution needs
have again changed, we'll have the ability to adapt.
How about some language like "SHOULD use SRV records to locate the
host unless specifically configured for an alternate name resolution
method"? I think that leaves open the possibility for clients that
know better to do so, but strongly encourages most client
implementations to use SRV records.
--
John A. Tamplin
Software Engineer (GWT), Google
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf