[ih] Multi-homing naming Was: Re: History question -- multi-homing

[John Day]

In 1975, Illinois put the first Unix on the Net. They made applications look like file names, e.g. ucsd//telnet. Several years later Steve Bunch and Michel Gien met with Bill Joy to convince him do the same. He refused. Had he agreed we could have seamlessly transitioned to application names or titles and phased out well-known ports and no one would have noticed.

This is unbelievable. Remember Shoch’s koan
Application names indicate what
Network addresses indicate where
Routes are how to get there

> On Sep 12, 2026, at 19:52, Brian E Carpenter via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Karl,
> 
>> That dynamic has created the need for not only what ISO/OSI called "titles" but also something more.
> 
> The hot money now is on how AI agents will find each another. I agree
> that DNS is not up to this task.
> 
> https://datatracker.ietf.org/group/dawn/about/
> 
> Regards/Ngā mihi
>   Brian Carpenter
> 
> On 13-Sep-26 10:56, Karl Auerbach via Internet-history wrote:
>> On 9/12/26 2:06 AM, vinton cerf via Internet-history wrote:
>>> It would be an interesting exercise to posit a different identification
>>> scheme that would scale and also permit multi-homing. Has someone already
>>> worked that out? Would it require a flat ID space?
>> Back in the 1970's my (now gone) friend (and Best Man at my wedding)
>> Frank Heinrich (student of Dave Farber and who worked on DCS) taught me
>> that we ought not to think of application-to-application associations as
>> having invariant locations for the participant entities.  The idea was
>> that on a network, application level stuff can move - that the binding
>> of applications to network addresses ought not to be considered as
>> immutable.
>> Others seem to have had similar thoughts - I, however, being slow on the
>> uptake, never really understood the reasons why ISO/OSI defined "titles"
>> for things.
>> It wasn't until the web came along, and more recently use of web
>> protocols as vehicles for service APIs, i.e. "cloud computing", that I
>> began to realize that we now live on a network in which Frank's wisdom
>> has come true.
>> In today's network world, at the application layer, we have entities
>> that split/partition, move, join, vanish, and appear.
>> That dynamic has created the need for not only what ISO/OSI called
>> "titles" but also something more.  We need more because after a
>> client-application association is created, the client or the application
>> could split/partition.  Yet because of things like state and caching, we
>> want to have handles that let us preserve that association relationship
>> without abandoning all of the context (or relying on troublesome things
>> like "cookies".)
>> To answer Vint's question: I think that our experience with DNS has
>> informed us that caching is not only important, it is necessary.  And
>> that structure in identifiers is needed in order to do effective caching
>> of what are very large (and growing), dynamic, name spaces and mappings.
>> Personally, I am dubious whether DNS is dynamic enough for this. (And I
>> certainly want to avoid the wars, particularly trademark wars, that have
>> burdened DNS administration - so my preferred format for elements of
>> these new kinds of names are tokens that do not carry human semantics.)
>> (I have come to also believe that on today's net we often need to find
>> instances of resources by attributes rather than names.  This suggests,
>> to me, that we need something parallel to DNS that does lookups based on
>> some sort of flexible and extensible set of attributes - sort of like
>> the core of a search engine, but better packaged as a network service
>> for software to use, and more efficient and dynamic.)
>> I wrote about this way back in 2010:
>> On Entity Associations In A Cloud Network
>> https://www.cavebear.com/archive/public/cloud-entities.pdf
>>          --karl--
> -- 
> 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