On 29 jan 2015, at 06:33, Mark Nottingham <mnot@xxxxxxxx> wrote: > >> The RRType is registered and can not be changed. >> >> That said, what can be referred to is a "better" registry for services. IETF do not have a registry for services for SRV. If IETF did, then I would have referenced that registry. I think it is "stupid" to create a new registry. This draft refer to the ENUM Service Registry. For SRV no real registry exists, but the DNS-SD people have this: <http://www.dns-sd.org/servicetypes.html> > > I think most of my concern centres around things appearing in the registry without coordination with the community surrounding that service -- such as the Web / HTTP case. I completely understand. > I.e., if the URI RR points to a registry, and that registry contains an entry for a service "foo", I expect that applications that implement "foo" should use the URI RR in their operation. > > When this isn't the case, it's not good for interoperability, potential security issues are introduced, and the community of the service often isn't involved in the registration. The draft and registries for prefixes in DNS (specifically SRV, as I explain above) has been discussed in the apps area of IETF for years, and no resolution of that question have been reached yet. :-( > So, I'm going to ever-so-gently push back on your characterisation of a new registry here as "stupid." Oh, sorry, it was not my intention to express things that strongly. What I think I think (!) is that as we do not have any clear registry for service prefixes in DNS, and SRV has been surviving quite well without, and to some degree also many parts of "the web" community, is it important to have _any_ specific registry? Can this just evolve? >> Is your suggestion to add more examples? I think that is a fair request that makes lot of sense. > > It'd help, yes. It'd also be good to have the conversation with the Web folks, to see where that goes (perhaps they'll want to support it, but if they don't, it might be good to take that > example out). Ok. >> And on top of that you have already pointed at the issue with lookups in DNS compared to the HTTP transport, where also lots of redirects are common, specifically in CDNs, virtual hosting (www.example.com / example.com is a trivial example of course) etc. > > For now -- note that as we write, the IAB workshop on TCP evolution is considering how to move protocols like HTTP to UDP :) ...and some people want to move DNS to TCP and give up UDP :-) >> But you also point at a for the IETF sensible issue. When the well known URI was discussed, I did present the URI RRType (and SRV, and NAPTR and...) but as too often happens "the web community" responded with "we can only look up A records". So the use of more efficient mixes of DNS and HTTP to reach the for the user best experience was never really discussed. Not there, not then, not before and not after. :-( > > We've been trying to get discussion going between the HTTP and DNS communities, with limited success. Maybe it's time to try again (e.g., in Dallas as a Bar BoF)? Yeah, see the discussions around what DNS features are expected in HTTP/2 and I am crying a bit. Now when we are trying to get a GOOD protocol definition, why can not that include good things from BOTH http and DNS worlds(*)? paf (*) I am thinking of including SRV/URI/whatever higher abstraction layer in DNS in the protocol spec, and "limit" "happy eyeballs" to repeated HTTP transactions over A/AAAA record types. I do not think that discussion have been held, as pushback from web to DNS community feels like "oh no, that is too hard", which is as I know you and I agree about, the wrong answer.
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail