🚀 go-pugleaf

>> If I recieve a Presentation Address from Quipu (or any other X.50>0)
>> which has an NSAP component with a prefix of 540072872203, can I assume
>> that this is an encoding of a RFC 1006 address?

>> Is there another method for encoding RFC 1006 addresses into NSAPs, or
>> for  storing them in naming services such as X.500?

>> 		       Bob Tausworthe
>> 		       tozz@hpda.hp.com


>	Ts-bridges may prove very handy as a "last resort" way to achieve
>	connectivity between osi systems that are connected by tcp/ip.

I wasn't thinking so much about Ts-bridge use as storing RFC1006
bound systems' addresses in X.500 as part of application P-addresses.

>	However, the US Internet will not want to use a 54... prefix to
>	identify these addresses. I think that we need to revisit the idea
>	of encoding a 1006 address in the 470005 space.

My only concern has to do with choosing outbound path. In ISODE, their is
effectivly several transport entities: TP4, TP0/TCP/IP, TP0/X.25 . . .
During outbound connection establishment the choice of which TP entity to
use is made based on the Network Type. Therefore a clear and determinsitic
way had better be available to an RFC1006 implementor to determine
the context of the network address in question. The more methods there are
the harder it is to determine the context. Also, the more often changes
are made to the algorithm the more often working code breaks.

For instance, ISODE 6.0 uses Kille's method to determine if a NSAP is for
a system in the RFC1006 domain. If the Internet community decides to add
an encoding scheme of of the 470005 address space for RFC1006, then
ISODE and all other RFC1006 implementations will have to change to support
this.

What will the Internet community have to gain by using the 470005 prefix
as opposed to 5400728722 prefix? It was my impression that 470005 prefixes
were to be used so that existing TCP/IP systems would have an easily
obtainable NSAP by simply using their IP address and 470005 prefix.
Is my thinking on this incorrect?

>	While I am on the subject, is there any Good reason to provide the
>	flexiblity of port and udp/tcp selector? Tcp with port what-ever
>	(102?) seems good enough.

Relying only on port 102 forces all RFC1006 users to be created via tsapd.
I think some users will want to write their own applications which coexist
with tsapd but are not created by them, just as all TCP/IP applications are
not created via inetd today.

>Rob

                        Bob Tausworthe
                        tozz@hpda.hp.com