[ih] Why did location/identity separation not happen? (Was: Internet without entrenched factions?)

[Jack Haverty]

My earliest encounter with issues of name/address/route (or 
location/identity/...) was in the early 1970s, when I was working for 
Licklider at MIT, implementing a mail server.

We were musing about the architecture of "computer-assisted human-human 
communications".   Electronic mail as we know it today was one part of 
that.  In addition to identity (name) there was location (of mailbox) 
and routing (how to get it to the mailbox).  There was also another 
architectural concept - role.   John Shoch's recent message reminded me 
of role, but I think it had a different meaning in Xerox' architecture.

An individual human might have multiple roles.  Someone might be CEO of 
a corporation.  The same individual might also be the Coach of a 
school's sports team.  Each role might have different mailboxes. Same 
person, but different roles make handling human-human communications in 
possibly very different ways.

So, the architectural issues of name/address/routing appear at multiple 
levels of the mechanisms implementing them.  I'm using "levels" instead 
of "layers" because there's no relation to the OSI model.

At each level, a name is provided by the level "above", specifying the 
target destination for the information.  At every level, there are 
mechanisms that convert a name into an address, and another mechanism 
that converts an address into a plan for how to process the information, 
at least making a decision on the next stop in a route.  One level's 
name is the lower level's address.

For example, in the Internet's datagram service, a human-friendly name 
is converted into an IP address by the Domain system.  The IP address is 
subsequently provided to the datagram transport system as a "name".  
Routing mechanisms convert that name into an address on some network 
attached to the IP router.  If that network happened to be the ARPANET, 
the IMPs would see the target destination of perhaps a distant router as 
a "name", and use its own routing mechanisms to convert that into a 
specific connector on a specific IMP leading to a specific computer.  
Within the IMP code, that target name would be converted into the 
specific modem connection on which to send packets to the next IMP along 
the route.  On some networks, such as ARPANET, computers could use 
algorithms to convert a name into an address, by parsing the IP 
address.  Other networks, such as Ethernet, needed an additional 
mechanism to translate from names expressed in IP into addresses 
expressed in LAN formats, using mechanisms such as ARP.

If you think about this process starting at the level of email, there is 
a possibly complex sequence of name->address translations at each level.

To answer Dave Crocker's question about what problems occur... One of 
the characteristics of our email is that its architecture mixes together 
names and locations.  E.g., a mailbox such as "jack at 3kitty.org" 
specifies a name (me) and an address (3kitty.org).

That choice helps, but does not guarantee, uniqueness, but also results 
in some pragmatic problems - such as the difficulty of moving your 
mailbox from one ISP, corporation, or organization to another.  Humans 
still try to contact me using email addresses from decades ago.  There 
is no "email portability" scheme analogous to the telephone system's 
number portability.

I think X.400/X.500 tried to address issues such as "roles" but OSI 
didn't work out.  Humans compensate of course, typically by creating 
different email addresses for their different roles.  But humans aren't 
always very good about keeping their communications that organized.

Its often hard to locate a past communication you remember you had with 
a particular human when the information you're seeking might have been 
in any of multiple email "connections" (defined by the two mailboxes 
involved).  It's even more difficult if the communication you seek might 
actually have been in a SMS text, or messaging through some social media 
walled garden, or other means we now use to communicate.

Perhaps AI will be able to sort it all out someday.

/Jack Haverty


On 5/20/26 17:19, Joe Touch via Internet-history wrote:
>> On May 20, 2026, at 5:10 PM, vinton cerf via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>>> End-point has always been an intuitively appealing, but IMO problematic,
>>> term.  Is it an interface?  A host?  An application? (And which layer of
>>> an application service?  I always thought of an email address as
>>> defining an endpoint.  Until I dealt with EDI over email, where the
>>> receiving email inbox was only an intermediary, and an EDI identifier
>>> indicated that ultimate end-point..)
>>>
>> well, could one argue the endpoint at the IP layer gets you to the host,
>> TCP gets you to a process and after that it is an application layer
>> question?
> In Ethernet, address=interface, i.e., the “strong host” model. If a (unicast) frame doesn’t arrive at the correct interface, it’s dropped.
>
> For IP, address=host, even though there’s one or more IP addresses per interface, i.e., the “weak host” model. IP source addresses match interfaces when they go out, but “any port in a storm” is valid on input.
>
> This is discussed in RFC1122.
>
> FWIW, from my seat, the discussion location vs. identity hasn’t mentioned what I think are some key points:
>
> 	1) location vs. identity is one of label structure. Unstructured labels are considered names.
> 	Structured labels, where structure matches topology or place, are considered locations.
> 	They’re all just labels - it’s the structure and its meaning that make the difference.
>
> 	2) having multiple addresses, whether in a single header or stacked headers, is just a variation on indirection.
> 	One label provides the context (environment) and another provides the indicator within that environment (item).
>
> IMO, no single structure or environment/item pair ever satisfies everyone.
>
> Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260520/e99c1381/attachment.asc>