In the DNS, service names only appear as subnames of transport names.
So one possibility would be to register smtp-client as a service name,
so the DNS label would be _smtp-client._tcp.whatever.example.
I would say "only appear *today* under transport names", but this isn't a
hard and fast requirement. ...
We should feel free to construct TLSA owner names in a form that makes
sense for the specific application.
They've appeared under transport names for the past 15 years, which means
that people have expectations about how they're used which I would not
casually ignore.
There are a lot of other prefixed names floating around the DNS. If
someone attempted to use a client name like _spf or _sip or _domainkey or
_dmarc or _adsp or _vouch they and their users would experience an
eternity of pain from name collisions.
For the purposes of this draft, including a transport label might make
sense if we expected clients to have distinct transport protocol
specific authentication credentials for the same application. This seems
unlikely to me.
It has very little to do with distinct transport protocols, and everything
to do with avoiding name collisions. Nobody runs POP or IMAP over UDP,
but the SRV names are still _pop3._tcp and _imap._tcp.
If your names are subnames of _tcp or another transport, you know that the
only names you can collide with are ones in the IANA services list, and
you can easily register yours to tell people about them. If they aren't,
they could collide with anything. Dave Crocker has been working on a
registry for general prefixed names, but it's not likely to exist any time
soon.
See Viktor's previous note about why we excluded a _client label.
I saw it, and I have to say it strikes me as penny wise and pound foolish.
You're getting a tiny simplification in code that for the most part hasn't
even been written yet, at the cost of having to deal with potential
collisions with every future use of prefixed names.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
