🚀 go-pugleaf

I have recently added another transport stack to ISODE to support our
local Class 3 implementation.  I have defined TS_TSPI as the transport
stack identifier and use NA_NSAP as the network address style.  In
compat/tailor.c I have added {"tspi", TS_TSPI} to ts_pairs and make use
of "realns" for ts_communities. 

For the loading of responders I have defined NT_TSPI (= 'P').  I cannot
use tsapd because our implementation does not permit a network
connection to pass across fork() or exec() system calls but this is not
too much of a problem because the network will load an arbitrary process
in response to a T-CONNECT-indication for a particular TSEL; in effect
the network contains its own tsapd. 

My problems come in trying to put appropriate entries in isoentities (or
elsewhere if that is more appropriate) which will cause applications to
use TS_TSPI/NA_NSAP addressing for hosts with this type of transport
service.  I have enabled only "ts_stacks tspi" and "ts_communities
realns" in isotailor.  I have generated entries like (BTW is there any
way I can specify the portion after NS+ as an ascii string instead of
spelling it out in hexadecimal?):

    # Concurrent Computer Corp, ESDG, Slough1, U.K.: 1.17.4.1.1.1
    #	1.17.4.1.1.1.1	sl10c

    sl10c		default			1.17.4.1.1.1.1.0 \
			NS+534c313043

    #	1.17.4.1.1.1.2	sl80a

    sl80a		default			1.17.4.1.1.1.2.0 \
			NS+534c383041

but whether or not the entry is used seems a bit hit-and-miss.  In
particular, on machines which also support TS_TCP/NA_TCP (but without
them enabled in ts_stacks, ts_communities) an address of the form
"Internet=sl10c" is often generated.

I have read the documentation and a fair quantity of the code but I
still have little real idea how all this addressing works.  Given that I
want to add a TP0 bridge stack using TS_TSPI as the network service
sometime soon I should really like to get a handle on all this.  Any
pointers would be very much appreciated. 

Alan Young.