After reading your response it occurs to me that James was suggesting adding _at as a label rather than encoding it in the hash - makes
more sense. Having said that, I still question whether _at really helps much since humans aren¹t likely to read/write the encoded user name. Even if we decide to not hash the user name it will need to be encoded because of special characters. On 7/20/15, 11:11 AM, "Viktor Dukhovni" <[email protected]> wrote: >On Mon, Jul 20, 2015 at 10:41:08AM -0400, James Cloos wrote: > >> They should be at the same place even though multiple lookups are likely >> to be required anyway -- not everything will fully support an ANY query. >> >> And I renew my (previously ignored) suggestion that they, along with >> tlsa records for client certs where the cn or other lookup -- such as >> a sip url or the like -- has an @ in it -- be under _at. >> >> Mapping @ to _at makes it easy to remember and easy to read. > >Mnemonic value notwithstanding, the main advantage of _at is that >that it is *short*. So if the namespaces are unified (segregated >only by RRtype not qname), then "_at", seems like a sensible choice >of generic empty non-terminal. > >In terms of query efficiency, if there are any MUAs out there that >support both OpenPGP and SMIME, and try to find either set of keys, >then a common qname that yields NXDOMAIN is likely to cached by >the iterative resolver just long enough to save a full round-trip >just to find out that neither set of keys exists. > >-- > Viktor. > >_______________________________________________ >dane mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
