@inproceedings{adjie-winoto:sosp-1999,
  title={The Design and Implementation of an Intentional Naming System},
  author={Adjie-Winoto, W. and Schwartz, E. and Balakrishnan, H. and
          Lilley, J.},
  booktitle={{ACM} Symposium on Operating Systems Principles},
  year={1999},
  pages={186--201}
}

Presents a system for descriptive naming & late binding as an overlay network service in a LAN environment. Names are written in a custom hierarchical attribute/value pair format. Routers aggregate the names into a tree which incoming queries are pushed through to determine matching destinations.

Definitely oriented toward a medium sized network. Every node needs to know about every other node. The name trees aggregate some information, but memory use and lookup processing could be substantial. An important consideration to keep in mind is that for networks with low latency (e.g. office settings) and rich descriptions, processing power could easily become a dominant bottleneck rather than the network. The paper investigates this somewhat in regard to their system, but makes apparently conflicting statements at two points, and doesn't seem to look at all issues, e.g. the (relatively) expensive sounding name extraction required in their scheme for every periodic update.

The naming scheme is slightly odd; it has unexpected semantics. For example, it seems that if I request a "printer, color" it will match against "printer." That's almost useful for a human user looking at directories, although they'll quickly be overwhelmed by small, irrelevant descriptions. It's completetly useless for a machine, e.g. if a print job is being forwarded that actually requires a color print. It also enables malicious users to receive or take all messages by posting ill-formed (short) descriptions.

The paper also discusses several times the ability of the system to keep sessions alive despite node failure; messages will simply be directed to another service. This is true with "session" in the sense of the overall run of the system. It is not true in the more common sense of two machines carrying out a conversation. Any evolved state would be lost when the service died, and the sequence would have to start over with the next host unless carefully crafted otherwise, which may not be possible in all cases (e.g. in sharing credentials).

Although perhaps out of scope for this, a spanning tree backbone overlay is perhaps not ideal. It would concentrate traffic along the backbone, wasting underutilized network resources on other links, artificially capping the network capacity, as well as possibly over-taxing host processing and power resources. Further, in this sort of relatively small, wireless environment, there is near ubiquitous support for single-hop IP multicast, which is an opportunity to amortize transmit costs by sharing messages as well as cheaply create redundant delivery paths.

One notable oversight in the paper though is that it discusses at several points the ability to route on application layer metrics such as geographic location or load. However, it is never discussed in more detail. Efficently representing, disseminating, and reasoning on the required data and criteria sounds problematic, especially for very dynamic features such as load.