Indeed, resource discovery has long been a difficult problem. I was particularly intrigued by the old IF-MAP work from a couple of decades ago. (There is a modern if-map but I am not sure it bears any resemblance - I don't seem to be able to quickly drag up any references to that old work - in other words I am having a resource discovery problem. ;-) I notice all the avahi and other resource announcements bouncing around my home network. The older methods that I've seen seemed derived from the kind of hard, usually somewhat pre-fixed and ordained taxonomies that are often used to index books in libraries, not the kind of somewhat more free form stuff that we are seeing from search engines and "AI" tools. (In our businesses we have to deal with export control regulations so I am always banging my head against the hard, and increasingly obsolete, taxonomies used by the import and export people in governments. Sometimes the choice can have some serious financial side effects. Same problem seems to exist in medical procedure coding.) There are several dimensions - such as whether targets register their existence to a registration point or whether they just pop up and announce. Back when I was doing entertainment grade video there were some horrid "solutions" that conflated DNS proximity with both proximity to a service and a good path to that service. That was what drove me to begin, but not finish, what I called the Fast Path Characterization Protocol to quickly and cheaply evaluate the suitability of a proposed client-to-service binding - https://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html ) And I've hit the common flaws - such as finding the nearest printer, which happens to be one floor directly above me. Yes, it is close but it will take me a long walk, stairs (or elevator) to get there. I've long been intrigued by perhaps the most successful resource discovery system on our world: Insects finding one another for reproduction. The method is chemical - pheromones. Those have some nice properties - such as the "find me" signal is attenuated with distance. I've played with some protocol designs based on random lofting of UDP packets that contain several announcements, each with a TTL, and relay points that expire items with TTL expiration, and add other announcements. And I've played with "designated noses" to act as collectors that can announce that they exist using the same methods. The barrier I hit was that in chemistry I've got lots and lots of data bits - long chains can carry a lot of data - and that network packets are not even close to large enough to obtain the kinds of announcements which could be possible. (This is similar to some ideas that I have to adopt CRISPR techniques for very-long pattern matching to facilitate things like crypto cracking and also video compression - yes, I am imagining a kind of chemical-bio-electronic computational system.) No single resource discovery system will meet all needs. Rather I foresee that there will be a need for various methods depending on the application space. And I suspect that URL/URI structures (with DNS names) will be part of the inner (but often hidden from users) machinery of these methods. --karl-- On 10/26/25 6:57 PM, bzs@theworld.com wrote:
Just to avoid the possibility of re-inventing the wheel how much of this idea is covered by systems like CORBA (1991, now mostly obsolete tho latest release was 2014), X.500, and LDAP (a simplified subset of X.500)? And Microsoft's Active Directory? Or logical extensions thereof (where is ____?)
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/X.500 https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol https://en.wikipedia.org/wiki/Active_Directory
or the various "See Also" on those wikipedia pages (Apple Open Directory, etc etc etc)? And I guess URIs/URLs in general?
There's a rich history of people throwing themselves against this idea of locating objects in a network, particularly at a generic level (where is a printer I can use which does two-sided color printing and is at least 20ppm? Or a game server for <GAME> or whatever.)
Also, the CDNs like Akamai dabble in this more than a little.
Geoff Houston had a great article in a recent "Internet Protocol Journal" (May 2025, V28.1), "The IPv6 Transition", which goes way beyond what the title might imply and talks about how between NAT, CGNAT, CDNs, DNS, and DDNS "this ain't yer grandparents internet anymore"...you'd have to read the article, it's only several pages long but I had several "oh yeah he's right" moments reading it.
On October 25, 2025 at 14:27 karl@cavebear.com (Karl Auerbach) wrote:
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines.
In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session.
DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems.
DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical.
Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds.
I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names".
In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change.
--karl--
On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?