Re: [rrg] Terminology (was: belated msg: further description of the recommend...

[[e-mail]]

In einer eMail vom 16.12.2009 02:07:54 Westeuropäische Normalzeit schreibt  
[e-mail]:

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