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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf