Replying to many threads.
1) I am glad to hear that it is agreed that any WG in this area will 'be a marathon'. This is an important problem and it needs to be done right. And that means discussing the set of use cases to be addressed, developing requirements and only then looking at solutions. Do it right or not at all.
2) WS-* did too achieve its principal goal of making work for consultants. It looked promising at first and then...
3) We might well want to delay a decision on this issue until after the IAB ename workshop which might well lead to a game changer.
4) I agree with Mark Nottingham that this is an API thing and that IETF does not own the specs where the key APIs are defined. That is WebAPIs for JS (W3C) and POSIX.
But here is the thing, if IETF says a DNS interface should look like X then by golly, I bet W3C and POSIX etc. will be only too happy to follow the lead. And the strange thing is that IETF has already got a DNS Interface which is really, really good and not the ones I proposed:
It has Apple's name on the spec so there is one major platform on board. And it is 2013 and supported by quite a bit of running code. The only real problem with the spec is that it is presented as 'one option' on how to do service discovery.
Please, do not give me six ways to do a thing, give me one. And do not let application developers choose either. Pick one method that serves all the requirements and tell people to stick to it unless there is reason not to. Standards are all about taking away choices that don't matter. Have six ways to implement service discovery and I have to implement whichever one is picked for a protocol myself. Pick just one as the default and it will be there for me in a library.
Yes, we can grandfather legacy protocols like HTTP and SMTP. But lets not force everyone to implement everything.
The only problem I have with RFC6763 is that the power of the idea had to be hidden to get through process. This draft takes the ideas in RFC6763 and takes them to their logical conclusion:
In short, what I think the _javascript_, C, C# API for service discovery should look like is:
Connection = Interface.GetService (<address>, <protocol>)
for example:
Connection = Interface.GetService ("example.com", "_http._tcp")
That is it. I want all the extraneous stuff to go away or be hidden as options. It should be possible for the DNS records to force use of a security enhancement (e.g. a specific version of TLS with specific trust anchor)
That API could be implemented using existing DNS protocol at the client certainly. The incentive to change the client-resolver protocol would be motivated by latency, not by functionality. The big problem with DNS is that the protocol is only reliable for one request and one response and even if you could do multiple requests in one packet, the discovery mechanisms are more complex and inherently require multiple round trips.