Re: [RAM] revised draft proposed definitions

[JFC Morfin <[e-mail]>]

Brian,
Tony said "a string of bits", this seems adequate.

I am not sure that you want an address to always be binary. I start 
working on multilingual semantic addressing support in relation with 
the cctags (they actually root national linguistic relational spaces 
taxonomies, as in a some more granular way the langtags do, from a 
linguistic POV). These addresses are not binary. They are not used to 
route through the network (at least now), but they can locally to the 
destination.

If you consider HTTP.1.1 it supports binary (network) and non-binary 
(virtual host) addresses collapsing naming and addressing space at 
local level into a single space. This is something you may not wish, 
but this is something possible and being used.

Also, just remember that multi-level naming (one can use for 
multilevel semantic addressing and multilevel IP addressing, must be 
self-similar (another way to say it must scale)). However, 
"self-similar" makes clearer that this can be up/down scalarity. And 
therefore, since the current binary/semantic syntax is something 
being used, which works correctly, and will therefore be used, so you 
must stay compatible with it.



jfcm

On 10:38 12/06/2007, Brian E Carpenter said:
>Content-Transfer-Encoding: 7bit
>
>On 2007-06-11 22:05, Tony Li wrote:
>...
>>That still fails the test of describing what things are.  What we 
>>want is to take a constructive approach:
>>An identifier is an element of a namespace.  There is a 1:1 mapping 
>>between the namespace and the entities being enumerated.
>>
>>>>Locator:    An object that is used only for forwarding packets
>>>>         or determining location, never for identification.
>>>
>>>Same comment only in reverse ;-)  "A locator denotes presence at a 
>>>specific point in the network.  When one's location within a 
>>>network changes, one locator changes".
>>
>>Ok, but a locator does NOT denote reachability.  Thus, a locator is 
>>a string of bits that indicates a topological location.
>
>It seems relevant to paste in the definitions I use in
>draft-carpenter-idloc-map-cons. I strongly agree with Tony that
>we must relate the notion of ID to a specific namespace. We may
>differ slightly on Loc:
>
>    Locator: A binary quantity (not necessarily an IP Address) that can
>    be used by a routing or forwarding device to decide where to send a
>    packet.
>
>    Identifier: A binary quantity (not necessarily an IP Address) that
>    can be used by a Stack "A" to uniquely identify another Stack "B"
>    both for bilateral communication and for informing a third Stack "C"
>    that it should communicate with Stack "B".  (Note that there is an
>    assumption in this definition that a Stack is the entity we require
>    to identify; in this era of virtualized servers with failover
>    capabilities, and of mobile clients, this seems to be a reasonable
>    assumption.)
>
>    Namespace: a set of natural numbers, each of which is referred to as
>    a name.  Since it is a set, by definition each name is unique and
>    thus the namespace is unambiguous.  Locators and Identifiers must
>    belong to specific namespaces.
>
>    Namespace Context: the context within which a given namespace retains
>    its uniqueness property.  (For example, the Namespace Context of the
>    Namespace created by [RFC1918] is a single Internet site.)
>
>       Brian
>
>_______________________________________________
>RAM mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ram


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram