In einer eMail vom 16.12.2009 02:07:54 Westeuropäische Normalzeit schreibt [email protected]:
The last couple of decades have, I think, shown us that by the time you cross-product not just the syntax of the meta-names (i.e. a name for a class of names), along with their semantics, but also _what_ kind of thing is being named (interface, stack, etc, etc) we either need i) multi-part meta-names (e.g. 'stack identifier'), or _lots_ of meta-names (e.g. 'locator' = 'topology-dependent interface name'). The deeper sense of the loc/id-split discussion of so many years is to grasp the need for a location-identifier. (maybe the same is meant by topology-dependent interface name ?). I did provide such one as well as a description how to form it: 16 bits square-degree-geopatch# (between 1 and 64800) 12 bits square-minute-geopatch# (between 1 and 3600) 6 bits longitude-second (resp. 60 minus longitude second) 6 bits latitude-second (resp. 60 minus latitude second) Extensions aiming for more granular location identification (plus height consideration) would be a simple task. Moore's law would be enabled and caching wouldn't be needed anymore. Every high school student is able to write the algorithm for deriving such a location identifier from the geographical coordinates. And also for deriving the numbers of all square-degree geopatches which are grouped around some particular one (and recursively around some particular cluster of them). And even some of those can be divided further, e.g. by syntax: so we have 'fixed-length locators' (e.g. LISP RLOCs) and 'variable-length locators'... Sure, more thoughts are welcome to cater for more flexibility wrt. extended granularity, ANYWHERE-Cast,etc. Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
