On Nov 20, 2019, at 5:18 PM, Shane Kerr <[email protected]> wrote: > > Viktor, > > On 20/11/2019 10.04, Viktor Dukhovni wrote: >> My proposal: >> 1. SVCB -> SRVLOC >> Service location, less cryptic than SVCB, and manifestly a >> generalization of SRV. >> 2. HTTPSSVC -> HTTPLOC >> HTTP location, manifestly a variant of the generic service location, >> with HTTP in the name. >> Definitely agree on the need for a single lexeme, these names end up as >> enum names in various programming languages. > > Unfortunately these are similar to the fun but rarely-used LOC record: > > https://tools.ietf.org/html/rfc1876 > > And also similar to the even less-frequently used NIMLOC record (which seems > to be from a routing architecture that hasn't been worked on in 20 years): > > http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt > > Not necessarily a complete veto, but definitely a mark against > SRVLOC/HTTPLOC, I think.
Even though this is bikeshedding, I fully disagree with the concern that Shane brings up here. RRtypes are exact match, and we haven't seen any "sounds like" problems in the past. I like "fooLOC" as a naming scheme here. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
