On 29 jan 2015, at 06:33, Mark Nottingham <mnot(_at_)mnot(_dot_)net> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail