On Sun, Jul 24, 2011 at 08:52:32PM +0200, Iñaki Baz Castillo wrote:
Ok. But I don't see the problem. What about Google Apps? My own domain
uses Gtalk and Gmail by setting Google XMPP SRV and MX records. Now
imagine that I would host my personal webpage (domain "www.aliax.net")
in Google, wouldn't be great a SRV entry for HTTP
(_http._tcp.aliax.net has SRV record 10 0 80
web-server-01.google.com)? or do we prefer the ugly HTTP 30X
redirection or ugly CNAME?
Well, you gave the perfect example : here, CNAME is the exact equivalent
of SRV. None is cheaper nor better than the other. You just find it ugly
because it's called CNAME.
In my opinion SRV is not possible for HTTP since SRV appeared too
late. That's the main and enough reason IMHO.
I'd see it differently : the balance between its extra costs vs the
expected benefits does not push in the direction to massively deploy
it. You know, it only takes 4-5 browsers to enable it and make the
whole web use it. Pat already explained why he doesn't want it.
The fact that people is "confortable" enough with HTTP style-of-life
(a specification of 1999) and does not want to deal with "new
technologies" other than stuff and more stuff on top of HTTP, is not a
good argument for me.
It's not a matter of new vs old technologies. We're not trying to
paint HTTP in a shiny color to impress friends. We're dealing with
deployed setups and users with high expectations, which are currently
more or less met and for which your proposal doesn't sensibly improve
experience but can sensibly degrade it for many people.
HTTP is not the layer number 5 in OSI model.
Like it or not, it has inherited this role a long time ago because it
provides many advantages over plain TCP (such as easy reconnection,
authentication, etc...).
Willy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf