On Jul 24, 2011, at 4:42 AM, Iñaki Baz Castillo wrote:
2011/7/23 Roy T. Fielding <fielding(_at_)gbiv(_dot_)com>:
Right. If WS borns with no SRV (as a MUST for WS clients) then just
forget it and let inherit all the ugly limitations from HTTP protocol.
I am tired of this. SRV is not used for HTTP because SRV adds latency
to the initial request for no useful purpose whatsoever.
And I'm really tired of hearing the argument of the "latency" which
nobody demostrates (but just talks about it without replying me how
the same is not a problem in realtime protocols like SIP and XMPP).
Try using a protocol analyzer. It is a problem with SIP and XMPP.
Chat and telephony have different user expectations about the initial
connect time, so people just don't notice it as much as they do when
a web page rendering process stalls because embedded resources require
two additional DNS requests.
SRV records for
XMPP and MX records for mail are useful because there is only one such
server expected per domain
$ host -t srv _xmpp-server._tcp.gmail.com
_xmpp-server._tcp.gmail.com has SRV record 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269
xmpp-server3.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269
xmpp-server2.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269
xmpp-server4.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269
xmpp-server1.l.google.com.
No comments.
I meant server as in authority to answer for the domain, of course.
and it is *very* desirable to maintain central
control over that routing.
I don't know what this means.
It means that admins care a great deal about what machines in the network
are allowed to receive mail for that network, and likewise for XMPP, since
both are store and forward protocols that contain messages with personal
information for individual addresses which are routed on a hop-by-hop basis.
HTTP has none of those characteristics. Hence, Mail and XMPP are centralized
services for an entire domain, whereas HTTP services are specific to the
services provided by each individual host.
In contrast, HTTP is deployed in an anarchic
manner in which there are often several HTTP servers per machine
(e.g., tests, staging, production, CUPS, etc,).
Could you explain me why DNS A is good but DNS SRV is bad in such
"anarchic" deployments?
Because DNS A for a server is deployed as soon as the server is made
available on the network (Intra or Inter). It is one of the first things
done when installing an OS. SRV, in contrast, requires that the zone
manager reconfigure DNS.
AFAICT, WebSockets is
even more anarchic than HTTP -- it will have to be, given that the sane
network admins will block it by default.
------------------------
It is up to the system administrator whether to set, or not, DNS SRV
resource records for the WebSocket protocol within the provided
service. This specification allows the system administrator to use
the DNS SRV [RFC2782] mechanism to improve the service reliability by
providing load-balancing and failover capabilities, but does not
mandate it (the system administrator could choose whichever
scalability strategy).
------------------------
*shrug*
In short, SRV is not used by the Web because it is inappropriate for HTTP.
I have seen no reason to believe that it would be appropriate for WebSockets.
If you want SRV to be part of the proposed standard, then you have to
convince
the people implementing WS to use SRV. None have done so, yet, so we can't
expect the editor to add it to the spec just because you have an opinion.
Ok, so the argument "I don't know SRV but I feel fine with HTTP
limitations for years" will win. Great design decissions.
No, the argument is that I know SRV, I know a lot more about HTTP, and I know
for a fact that SRV is not desirable for HTTP. So, whenever you suggest that
lack of SRV is somehow a failing of HTTP, you should understand that it makes
your arguments look clueless. Please, find some other example.
....Roy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf