On Wed, Jul 27, 2011 at 12:46:28PM +0200, Iñaki Baz Castillo wrote: > Hi Willy, as I've explained several times in these threads, if a WS > client is not mandated to perform SRV given a WS URI domain, then the > service provider cannot rely on SRV records. This is, let's assume > that a WS service provider offers a WS URI like "ws://mydomain.org", > with these records (simplifying): > > - SRV: 1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90 > - A: 1.1.1.1 No, he would have : - SRV: 1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90 - A: 1.1.1.1, 1.1.1.2, 1.1.1.3 > So assuming that SRV is optional for clients, the provider does not > know how many clients would use SRV or just A. That's mainly the point : the provider would offer a service which is designed to work both ways and which a part of the users would experience better due to their consideration of the SRV record. > Imagine the service > provider expects millons of concurrent users. He must be ready to > receive all those users in 1.1.1.1 (if they don't use SRV). So the > service provider must build a complex/expensive balancer system in > server side (BGP and all that stuf) just for the case in which most of > the clients would not perform SRV procedures. So 1.1.1.1 would be in > fact a balancer with N hosts providing the WS service behind it. > > At the same time, if clients use SRV then load-balancing and failover > would be automatically provided by the SRV capabilities. No need for > like-BGS solutions in server side. Once again, the goal to make SRV adopted BY USERS is not to ensure that it tries to cover all the server-side needs, but that it offers better quality of service to USERS. That way USERS will massively adopt it and server will one day be able to safely rely on it. Just like neither Javascript nor cookies nor flash are mandatory, still all of them are very common in practice and many service providers happily rely on them. > So the question is: which service provider would spend resources, time > and efforts building two different load-balancing/failover systems?. > If a provider can build the "BGP" solution then it will not need SRV. > And another provider which cannot build a "BGP" solution could not > entirely rely on SRV capabilities as maybe most of the clients would > not use it. You can't transform the Internet in one day after publishing one draft. Look at the Set-Cookie2 header. It was a massive failure. It was thought that the broken Set-Cookie header could be fixed by one new RFC, and nobody adopted it. The reason is that it was proposed as a replacement. I think that Opera might be the only browser to parse it. In contrast, if your proposal is backwards compatible and incites users to enable it on their side, then in a few years it can become a de-facto standard. > In the other side, if service providers must be ready to accept all > the traffic in the IP resolved via single DNS A query, then nobody > would need SRV and webbrowsers would just remove it (the Mozilla > developer has already said in these threads that he won't implement it > "due to latency reasons"). That's why I explained that you have to find what other benefits *for the end user* can be brought by this. End users are deciding, not site owners. > Also the fact that DNS is not mandated by HTTP neither WS makes things > even worse. That's why SRV cannot be made mandatory. > In contrast, in XMPP and SIP protocols DNS is mandatory > and also SRV procedures. If you are a SIP provider hosting the service > with domain "mydomain.org" you don't ever need to have a working A > record for mydomain.org, but just SRV (and optionally NAPTR). Or you > could just have A record and not use SRV at all. SIP client procedures > for locating servers (RFC 3263) mandate first trying SRV and then > A/AAAA, so things would work in any case. > > So correct me if I'm wrong, but making SRV optional for clients (in > *any* protocol) is not something I consider feasible or useful. Feasible yes, useful I don't know, and I'm not the one trying to argue that it can add value. If it can bring value to the user, some users will enable it despite the possible added latency. If it does not bring them anything, they won't use it. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf