[ih] History of Naming on The Internet - is it still relevant?

John Day jeanjour at comcast.net
Wed Jul 23 17:40:32 PDT 2025


Finally, getting to this

> On Jul 22, 2025, at 08:15, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
> 
>> From: John Day
> 
>> Saltzer defines "resolve" as in "resolving a name" as "to locate an
>> object in a particular context, given its name."
>> IOW, in computing systems one can't name something without locating and
>> can't locate it without naming it.
>> This is why all of the solutions trying to use it don't scale very
>> well. 
>> What was trying to be done with loc/id split was to find a work around
>> to the fact that Internet lost the internet layer. IP was supposed to
>> be in the internet layer, not the network layer.
>> ...
>> All addresses name the entity in the layer, that they reside. To use
>> Saltzer again, (N)-layer address is a node address, and (N-1)-layer
>> address is a point of attachment address.
> 
> I waited to read this until first thing in the morning, when my myalgic
> encephalomyelitis has the least effect on my ability to think, but I afraid
> that I still do not understand what point you are trying to make.

;-)  I have to agree with you. Getting old is a pain in the ‘you know what’! ;-) But as they say, the alternative is worse.

At least you are just fighting fatigue. Besides some minor joint issues, I am down to less than one eye, but it doesn’t seem to affect my vision too much or my enjoyment of the pursuit of ideas.

> 
> Let me briefly recount the process I go through in considering this problem,
> as my process seems to be very different from the one you are using.
> 
> To me, one has to start by ignoring _all_ potential names; one first has to
> consider the _kinds of things_ one will need/want to name. I saw/see the need
> for two kinds of things (at least, at the levels I was considering; further
> up, things like associations might get added, but I'm ignoring them for now).
> 
> First, there are the actual things used to carry bits around: physical
> links/networks, switches (routers, at the moment), the interfaces to hosts,
> etc. Then, we need names for all these things - and the naming system has to
> also be able to name (recursively) connected _groups_ of these things - so
> that path selection will scale. (Several PhD theses about what to do when
> a connected group becomes disconnected ignored.)

I can see where you go off the rails. But keep going.

I have seen lots of PhD’s written on flawed assumptions. On this topic, it has been especially amusing.

> Next, there are the fate-sharing entities which are the players in the
> end-end communications.

;-) Yes, this played a major role in the original endpoint paper as the means to escape an infinite regress.

> I pass over the things one will want to _do_ with the
> names for these - which will drive the semantics and syntax of those names.
> 
> And, once one has all that, on will need mechanisms to able to relate them
> all - e.g. to be able to find the name of the network location (interface) at
> which the desired end-end entity is currently to be found.

;-) Still hung up on interfaces, I can see?

Do layers fit into this somewhere? What are they? What sort of objects?
> 
> But, one has to start with the _things_ - the names come later.
> 
> 	Noel
> 
> PS: The "loc/id split" was because a thing (of either of the two classes
> above) always has both an identity ('who am I') and a location - but if one
> only has a _single_ name to convey both, if the thing changes its location,
> one is stuck.

That can happen if you aren’t careful. 

But the trick is to define a class of identifiers (name spaces) that are location-dependent (relative to one topology) and route-independent relative to that topology. As well as, name-spaces of identifiers that appear location-independent (relative to the previous topology, but actually location-dependent relative to a different topology.)

BTW, in the last 20 years you have learned the definition of a topology, right?

However, your response above is pretty much at the 50,000 foot level, how do you bring it down to your endpoint paper and to the RRG discussions?

Take care,
John

> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history



More information about the Internet-history mailing list