On Thu, Jul 21, 2011 at 10:24 PM, David Endicott <dendicott@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf