>> 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.
>with the only benefit of this separation ... The benefit of putting the service name behind a transport name is to put the service names in a separate namespace where they don't collide with anything else and they're already managed by IANA. >or we inject additional labels, making the name further removed >from identifying a DANE application at a given DNS node: > > _application._tcp._client._dane.box.example. IN TLSA 3 1 1 ... > >because _client might be used in non-dane contexts, No, it's _application._client._tcp.box.example, and it's because someone might use _application in other contexts. > and we want to distinguish TCP from UDP, Not really. > ... But what's the real benefit to all this? You're avoiding name collisions down the road. >James makes a plausible point about _client as a way to carve out >a zone for clients, but because unlike SMIME/A or OPENPGPKEY the >base domain is here typically not a zone apex, but rather a specific >host, carving out a new zone under each host scales poorly. Surely we don't have to review the difference between name components and zone cuts. Nobody has proposed putting a new zone under each host name. R's, John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
