Subject: Re: [rrg] Terminology: word-smithing

From: [email-masked] (Noel Chiappa)
Date: Sat, 28 Mar 2009 10:20:17 -0400 (EDT)

> From: Tony Li <[email-masked]>

    > defining some terminology to talk about routing. ... Here are some
    > straw man snippets to kick off the discussion. ... Comments?

Can I encourage people to pick terminology which separates i) the
characteristics of the name (e.g. 'includes location information'), and ii)
_what_ is named (endpoint, interface, etc)? So really you'd need a range of
terms for places on the first axis (which I'll call the 'characteristic'
axis), and a separate range of terms for the second (which I will call the
'object' axis), and then (if you're being complete) the cross-product of the
two.

When you want to make a selection along both axes, you either need to
double-barrel it (with something to talk about the characteristics, and
something to say _what_ is being named) - e.g. 'endpoint locator'; or create
some new word and set it to be a synonym for the term.

For an example of the latter, one might have a word for 'name with location
information, for an interface' (which is what 'locator' originally was, BTW,
although it originally had even more caveats). 

    > locator     A locator is a name that has topological sensitivity and
    >             must change if the point of attachment changes.

I am sort of OK with the one, even though it differs from the original
definition of the term (in RFC-1992). Using my taxonomy above, this has
meaning purely on the 'characteristics' axis, and none on the 'object' axis.

    > identifier  An identifier is the name of an endpoint.

This one I don't like, because it overloads a common word ("identifier"), one
which has a more generic meaning to most people (either as a synonym for
'name', or some slightly more restricted meaning - e.g. 'fixed-length binary
name').

There is therefore an increased probabilty of confusion, because it two
people are discussing something, and have different internal definitions of
the term, you can be sure the discussion will be problematic!

Some alternative possible words you could use for 'name with explicitly _no_
built in meaning other than simply identifying one particular entity' are
"selector", "individualizer", etc. Or you could coin a recognizable
neologism, e.g. "identificator".

So for 'endpoint identificator' (which is what you wanted to name?), which
makes selections along both axes, you either need to double-barrel (perhaps
with a resulting initialism/acronym), or create some new word.

    > Identifiers may have other properties, such as the scope of their
    > uniqueness (global or local) and the probability of their uniqueness
    > (absolute or statistical).

One 'word': "triple-barrel"! Actually, there's another important property,
which is the _lifetime_ of name. Presumably one property of an
'identificator' is that it should be permanent?

    > address     An address is a name that is both a locator and an
    >             identifier.

In IPvN, an "address" is both an 'interface locator' and an 'endpoint
identificator'. Trying to change that meaning is probably futile (and
potentially very confusing).

	Noel

---

From: Tony Li <[email-masked]>
Date: Sat, 28 Mar 2009 17:58:53 -0700

> 'object' axis), and then (if you're being complete) the cross-product of the

Ah, yes.  I was trying to articulate exactly this point yesterday. 
Thank you, I concur.

> meaning purely on the 'characteristics' axis, and none on the 'object' axis.

Given the discussion about MAC addresses, I suspect that we should also 
make this default to an L3 point of attachment.

> with a resulting initialism/acronym), or create some new word.

Or, perhaps we just make it more explicit that an identifier is a name 
that has no topological semantics and remove the object reference 
entirely?  This would bring it back in line with the more generic meaning.

> 'identificator' is that it should be permanent?

Ok, but we already know that some people, for the sake of privacy, want 
to have temporary identifiers.

> potentially very confusing).

Agreed.  I don't think we should try to change it, just make it more 
explicit.

Next pass after I absorb all comments...

Tony