On Tue Jul 19 12:51:16 2011, Iñaki Baz Castillo wrote:
2011/7/11 The IESG <iesg-secretary(_at_)ietf(_dot_)org>:
> The IESG has received a request from the BiDirectional or
> Server-Initiated HTTP WG (hybi) to consider the following
document:
> - 'The WebSocket protocol'
> <draft-ietf-hybi-thewebsocketprotocol-10.txt> as a Proposed
Standard
Hi, I assume there is no interest in making DNS SRV mechanism
exposed
in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
the WebSocket core specification, neither referencing it (in the
same
way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating
SIP servers").
As said before, making such DNS SRV specification an extension (so
present in other document) will mean no success at all, as WebSocket
client implementors (i.e. webbrowser vendors) will not be mandated
to
implement it and service providers could not rely on the support of
DNS SRV in web browsers. So nobody will use them (because IE10
decided
not to implement it, for example). IMHO this is sad due the real
advantages DNS SRV provides for a protocol like WebSocket.
Yes, in HTTP there is no special DNS stuff, all the load-balancing
and
failover mechanism are done at server side with very complex and
expensive solutions (www.facebook.com resolves to a single IPv4
!!!!).
The question is: should we also inherit every HTTP limitation in
WebSocket?
I agree wholeheartedly with this, and strongly recommend that
mandatory use of SRV is included in the core protocol.
I think with HTTP's very short lived requests, then it's possible to
work around the lack of SRV support (at a cost), but the benefit is
markedly higher with the long-lived, stateful sessions we're
anticipating with WebSocket.
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