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

[Willy Tarreau <[e-mail]>]

On Thu, Jul 21, 2011 at 07:15:13PM +0200, Iñaki Baz Castillo wrote:
> If WS spec does not mandate DNS SRV resolution in WS clients (so
> webbrowsers mainly) then let's forget SRV balancing/failover
> capabilities. If the WS core draft does not want to handle this topic,
> then refer to another document mandating it (in the same way SIP RFC
> 3261 mandates the usage of DNS NAPTR/SRV in RFC 3263 for SIP clients).
> 
> So you can split WS in:
> - transport specification RFC (handshake, frames and so).
> - location WS servers (a MUST for WS clients when resolving WS URI's).

But you can't make usage of DNS a MUST. While it generally is acceptable
over the wide Internet, it's almost always anti-pattern on internal
networks. Application developers in particular can never rely on this
because the guy who manages the DNS is not the same who manages servers
and generally doesn't accept to add any input for an application that is
not in production. Similarly, DNS which announce "public" records for
some services will cause trouble to local clients which would always
make use of the DNS first because of the MUST, and would not be able
to connect to the local address:port which is not announced anywhere.

If someone were to develop a backup/restore solution based on WS, it would
be funny to discover that it cannot be used to restore the DNS server when
this one fails...

However in my opinion it could be good to document a recommended DNS
architecture for WS, that is judged optimal and the most interoperable.
This could clearly be a separate RFC suggesting how clients and server
can make use of DNS SRV records for HA and LB.

> > In practice, if there are new elements of DNS SRV that are specific to WS,
> > they should probably be added to the DNS SRV spec and not the WS spec.
> 
> No. DNS SRV spec (RFC 2782) just explains the DNS SRV mechanism. Any
> protocol can decide wheter to include/mandate it or not. Each protocol
> can register in IANA new "service" values SRV, in the same way SIP and
> XMPP RFC's create "sip" and "xmpp-server" values.

Then maybe the name should be reserved as soon as the protocol spec is
released, and the document should refer to it.

> > Maybe the WS spec should mention that it addresses transport only and
> > not address resolving. It may recommend to follow some principles to
> > perform the resolving but should not specify how to do it.
> 
> That would be great, so another document/spec would *mandate* how WS
> clients MUST resolve WS destinations.

MAY

> But that is not true now as WS
> core spec states simple A/AAAA resolution for locating a WS server.

It does not even say that. It only talks about DNS when suggesting how
a client may select a limit on the number of concurrent connections (#5.1).

Regards,
Willy