Subject: [DNSOP] HTTPSSVC/SVCB bikeshed: poll for what to name them

From: Erik Nygren <[email-masked]>
Date: Tue, 19 Nov 2019 21:55:26 -0500

It is time to finalize names for HTTPSSVC and SVCB. Following a thread on
the DNSOP list that Tommy started, I created a poll incorporating some of
the ideas.  After we get some feedback here, the WG chairs and authors will
pick a set to propose and see if we can get consensus.  Here is a poll to
fill out listing some of the suggestions listed so far for each of HTTPSSVC
and SVCB:

   https://forms.gle/HBE5e4QFgUjKHvVy7

Best, Erik

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Nov 2019 04:04:06 -0500

On Tue, Nov 19, 2019 at 09:55:26PM -0500, Erik Nygren wrote:

> It is time to finalize names for HTTPSSVC and SVCB. Following a thread
> on the DNSOP list that Tommy started, I created a poll incorporating
> some of the ideas.  After we get some feedback here, the WG chairs and
> authors will pick a set to propose and see if we can get consensus.
> Here is a poll to fill out listing some of the suggestions listed so
> far for each of HTTPSSVC and SVCB:
> 

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.

-- 
    Viktor.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 20 Nov 2019 10:18:20 +0100

Viktor,

> 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.

Cheers,

--
Shane

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Nov 2019 04:32:34 -0500

On Wed, Nov 20, 2019 at 10:18:20AM +0100, Shane Kerr wrote:

> And also similar to the even less-frequently used NIMLOC record
> 

FWIW, I don't see any opportunity for confusion, especially given how
little these others are used.  The idea is that something less cryptic
than a "B" suffix is better at conveying the purpose of the record.

Some similarity is harmless if there's no chance of confusion, and
the primary feature of the new record is an explicit "location",
the other key/value pairs are optional elements.

That said, if you don't like LOC, a related variant is:

    - SRVCONF
    - HTTPCONF

Which is configuration information about a generic service and an
HTTP service, but this loses precision, because configuration does
not capture the prominence of redirection to a new location.

-- 
    Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Nov 2019 09:58:34 +0000

On Nov 20, 2019, at 5:18 PM, Shane Kerr <[email-masked]> wrote:
> 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):
> 
> 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