Net2/usr/src/contrib/isode/ronot/READ-ME

This new top level directory is intended to provide routines which
implement the mappings defined for RO-Notation MACROS BIND and UNBIND
onto ACSE.

The mappings of the BIND and UNBIND macros onto RTSE are NOT provided.

The routines provided here are extensions of the code previously included in
the dsap/net library specifically for the directory.



RO-NOTATION BIND and UNBIND macros can map either onto ACSE or onto RTSE

BIND/UNBIND operations need not report outcome if they do, then it follows
the single data value form.

BIND maps to A-ASSOCIATE
UNBIND maps to A-RELEASE

BIND success =>
	accepted, user information = result if any

Nothing is said about what happens when an A-ASSOCIATE is well-formed
as such, but not as a BIND (which errors are used??)

An UNBIND operation may disrupt operations - this is the only disruption
of service.

If BIND operations collide, then 2 application contexts are established.
BIND unsuccessful
	rejected (permanent), user information = error if any

Everything looks OK the way it has been done, except for the separation
of the RO-BIND, RO-UNBIND implementation from the rosap library.

****

Having finally seen a copy of the standard for remote operations
notation i am even more strongly convinced that ISODE should provide
an interface to support RO-BIND and RO-UNBIND.

As far as quipu is concerned the changes required are structural, and
_should_ (although this is rarely completely the case) be achievable
without introducing any new errors.

Eventually, this code should be moved into the rosap library or a
library of its own. Attempts have been made to keep close to the
ISODE style used in rosap to allow this to be accomplished more easily.
Only the mapping of RO-BIND and RO-UNBIND for ROSE using ACSE is
tackled, a full solution requires a parallel library for the mapping
onto RTSE.

The ABSTRACT-BIND and ABSTRACT-UNBIND macros have a defined mapping onto
ACSE primitives. Currently ISODE does not directly support the use of
ABSTRACT-BIND and ABSTRACT-UNBIND, but leaves it to the application
programmer to implement the mapping. Quipu currently implements such
a mapping, but with poor abstraction.

An interface which supports the RO-BIND and RO-UNBIND operations as an
ACSE-user should be provided as soon as possible by ISODE for several
reasons:
	1) Tidying up quipu code
	2) Easier implementation of other ASE's
	3) Possible incorporation of BIND, UNBIND and perhaps
even APPLICATION CONTEXT into rosy.

The motivation here is 1), but ISODE styles will be followed where
this is simple and appropriate so that 2) and 3) are made easier
objectives. (Aside i am assuming that a suitable solution to the
ACSE-user vs. RTSE-user problem is to have separate libraries and
separate include files accepting the smallish costs of duplication
between them - this has the added benefit that the BIND user selects
the underlying services by selecting the right library which has the
additional benefit that the RoSetService no longer needs to be visible
in the application using RO-BIND.)

Use of ACSE as described in the ISODE manual is provided by the
routines:
	AcAsynAssocRequest()	A-ASSOCIATE.REQUEST
	AcInit()		A-ASSOCIATE.INDICATION
	AcAssocResponse()	A-ASSOCIATE.RESPONSE
	AcAsynRetryRequest()	A-ASSOCIATE.CONFIRMATION
	AcAsynRetryNext()	A-ASSOCIATE.CONFIRMATION
	AcRelRequest()		A-RELEASE.REQUEST
     (*)AcFINISHser()		A-RELEASE.INDICATION
	AcRelResponse()		A-RELEASE.RESPONSE
	AcRelRetry()		A-RELEASE.CONFIRMATION

(*) The routine AcFINISHser is called implicitly by RoWaitRequest()
having been selected at the ACSE level by a call to RoSetService()
with value RoPService. This routine should be replaced with an extended
routine (eg RoUNBINDser which would call AcFINSIHser) so that an
RO-UNBIND ARGUMENT can be looked for and decoded if present. (Presumably,
a similar change would be necessary to support the RTSE equivalent).
I made have made misguided comments in my previous message about
drastic changes to rosap, this was due to misunderstandings on my part.

Since no argument (or results or errors for that matter) are used in
the UNBIND of the X.500 protocols this problem can safely be ignored
for the moment.

One question i haven't been able to satisfy myself about is whether
the implementation of RO-BIND should return RoSAPindications or its
own definition eg RoBINDindications. I don't want to touch rosap itself
at the moment and so have implemented the second.

A straightforward use of the ISODE acsap routines can be made to provide
an ABSTRACT-BIND/ABSTRACT-UNBIND interface with the following routines:

	RoAsynBindRequest()
		Encodes bind argument
		Calls AcAsynAssocRequest()
		Maps AcSAPindications to RoBINDindications
		Calls RoSetService()
		If completed: Decodes bind result or bind error
	RoBindInit()
		Calls AcInit()
		Maps AcSAPindications to RoBINDindications
		Calls RoSetService()
		Decodes bind argument
	RoBindResponse()
		Encodes bind result or bind error
		Calls AcAssocResponse()
		Maps AcSAPindications to RoBINDindications
	RoBindRetryRequest()
		Selects either AcAsynRetryRequest() or AcAsynNextRequest()
		Maps AcSAPindications to RoBINDindications
		If completed: Decodes bind result or bind error
	RoUnBindRequest()
		Encodes unbind argument
		Calls AcRelRequest()
		Maps AcSAPindications to RoBINDindications
		If completed: Decodes unbind result or unbind error
	RoUnBindResponse()
		Encodes unbind result or unbind error
		Calls AcRelResponse()
		Maps AcSAPindications to RoBINDindications
	RoUnBindRetryRequest()
		Calls AcRelRetryRequest()
		Maps AcSAPindications to RoBINDindications
		If completed: Decodes unbind result or unbind error

All arguments, except the presentation element representing the user data,
and the replacement of the AcSAPindication parameter by an RoBINDindications
parameter are passed straight through.

Other questions i am less than sure about are:

Should rob use the rosap log?? I think it should.

Should RoBINDindication be a RoSAPindication?? Not sure.

Should rob define separate (non-ACSE) definitions?? Yes, but its costly.
This would allow the definition of RoSAPstart, RoSAPconnect, ... for
either of ACSE or RTSE, completely obscuring the underlying services from
the user of the RO-notation. This is what we want eventually and one reason
for pulling this stuff out of the bottom of the dsap library.