🚀 go-pugleaf

I think you will find that Kille's paper "An interim approach to use of
Network Addresses", which has been out for nearly a year now, addresses
all of your concerns.
///////
Before I explain it a bit, I will address the following to all readers
of the lists I'm replying to:

    Before you enter this discussion why don't you read Kille's paper?
    You can find a copy in the ISODE source distribution (look in the
    directory doc/interim/).  Or, you can find a reasonable summary of
    it in the professional text *The Open Book* published by
    Prentice-hall.

The reason I make this request is that outside of the message containing
the original question, all responses (other than my own!) have either
misunderstood the issues or made proposals which aren't necessary.  In
either case, Kille's paper explains the issues and presents a workable
solution.  (The solution has been in use for a year now without problems.)

Forgive me for seeming high-and-mighty, but there's no point in
continuing the flow of misinformation.
///////
The motivation for Kille's paper is this:

1. OSI applications ultimately run on top of the OSI transport service.
As demonstrated back in '86 by RFC983 (the predecessor to 1006), you
don't need to use OSI end-to-end protocols (e.g., TP4) to realize that
service, you just have to be able to convincingly emulate that service
using whatever protocols you wish.  As a convention, we use the term
"TS-stack" to refer to a combination of transport protocol and network
service that is used to provide the OSI transport service.  One example
of a TS-stack is TP4/CLNP, another is TP0/X.25, a third, my favorite
(naturally!) is RFC1006/TCP.

2. The sad part is that not all TS-stacks interwork.  For example,
TP4/CLNP does not interwork with TP0/X.25.  This is an example of what's
commonly referred to as the "CO/CL mess" which is the fault of "the
other side of the Atlantic", regardless of which side of the Atlantic
you are on.  So, we introduce another term, the OSI "community", which
is a collection of hosts sharing a common TS-stack along with basic
connectivity.  Hence, if two hosts are in the same community they can
interwork.  In a perfect world, there would be a single OSI community.
Ha, ha.

3. Given this model of the world, when an OSI application wishes to
establish an association, that application identifies an "application
entity" that provides the service desired for communication.  For
example, in the case of a file transfer application, an application
might identify a "filestore" service.  In all cases, the service is
identified in terms of an "application entity title". 
The identity of an application entity is its "Distinguished Name" in the
OSI Directory.

Once the application entity title is generated, it is given to the OSI
Directory and the corresponding "presentation address" is returned. This
presentation address consists of a presentation selector, session
selector, and a transport address.  When the association is to be
initiated, there are two parameters of interest to us: the presentation
address, and the communications quality-of-service (QoS).  The first
identifies the location of the desired service, the second identifies
the characteristics of the association to be established to that service.

After passing through the highest layers, the transport address,
consisting of a transport selector and one or more network addresses, is
given to the transport service, and a request is made to establish a
transport connection.  The local transport entity then follows these steps.

    Step 1: look at each network address and decide which mode of
	    network service, CONS or CLNS, to use for that address.
	    Based on the network service and the communications-QoS
	    desired by the initiating application, select a transport protocol
	    for that network address.  This is done by local rules.

	    In brief, for each network address, select a TS-stack to be
	    used to reach that network address.

    Step 2: order the network addresses based on QoS and "closeness" of
	    the network address.  This is done by local rules.

	    Things like economic reasons might make one address
	    preferable over another.

    Step 3: for each network address, start the protocol machine for the
	    TS-stack associated with that address.  This results in a
	    transport protocol and underlying network service being
	    invoked.  As soon as a transport connection is established,
	    the remainder of the addresses are ignored.

4. Now as you can see, this model relies on all network addresses having two
properties: they must be storable in the OSI Directory and they must
somehow provide a mapping to the OSI community to which they belong.
For network addresses associated with "less than pure" OSI communities,
(e.g., for IP-addresses associated with the RFC1006/TCP TS-stack used in
the Internet community), Kille's paper addresses these two issues.
These kinds of network addresses (of which IP is only one) are referred
to as "interim addresses".

For interim addresses, Kille uses a part of the NSAP naming space which
is never going to be used (the TELEX space where he works).  He defines
an NSAP encoding for those addresses, so that they appear to be real OSI
network addresses.  Hence, the OSI Directory is kept happy.  However,
you will never see any OSI lower-layers ever carry those addresses as NPAI
(network protocol addressing information), because those addresses are
used only by non-OSI protocols, e.g., the TCP.

It is for this reason, that Hagens' remarks on "well maybe we should use
the 470005 space" are simply incoherent.  You are never going to carry
an address for an RFC1006/TCP TS-stack in TP4 or CLNP or any other OSI
lower-layer protocol.  You are going to carry those addresses inside IP.
And you're not going to carry it in NSAP form, you are going to carry it
as ... an IP address!

In addition to providing these NSAP mappings, Kille provides a
means for identifying the OSI community to which the address belongs.
Thus, if "interim network address" are in use, you can algorithmically
determine which community is being referenced.  If non-interim network
addresses are being used, then you are back to the original case of
having to deduce it somehow (the decision usually being hardwired into
most implementations).

Finally, I will point out that none of the above is idle speculation or
theorizing.  Kille, as chief architect of the world's largest X.500
pilot, had a huge problem in trying to get several OSI communities using
the Directory and interworking to some level.  The interim approach for
network addresses is a practical, pragmatic, and workable solution to
the problems he encountered.  This solution has been in the field for
over a year and actually works.  Given this, I'm having a hard time
figuring out why either a) we need to use different prefixes, or b) we
need to define different mappings.  There is no problem, Kille solved it
for us.

End of lecture!

/mtr