![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to READ-ME CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / ronot|
Return to READ-ME CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / ronot |
1.1 root 1: This new top level directory is intended to provide routines which
2: implement the mappings defined for RO-Notation MACROS BIND and UNBIND
3: onto ACSE.
4:
5: The mappings of the BIND and UNBIND macros onto RTSE are NOT provided.
6:
7: The routines provided here are extensions of the code previously included in
8: the dsap/net library specifically for the directory.
9:
10:
11:
12: RO-NOTATION BIND and UNBIND macros can map either onto ACSE or onto RTSE
13:
14: BIND/UNBIND operations need not report outcome if they do, then it follows
15: the single data value form.
16:
17: BIND maps to A-ASSOCIATE
18: UNBIND maps to A-RELEASE
19:
20: BIND success =>
21: accepted, user information = result if any
22:
23: Nothing is said about what happens when an A-ASSOCIATE is well-formed
24: as such, but not as a BIND (which errors are used??)
25:
26: An UNBIND operation may disrupt operations - this is the only disruption
27: of service.
28:
29: If BIND operations collide, then 2 application contexts are established.
30: BIND unsuccessful
31: rejected (permanent), user information = error if any
32:
33: Everything looks OK the way it has been done, except for the separation
34: of the RO-BIND, RO-UNBIND implementation from the rosap library.
35:
36: ****
37:
38: Having finally seen a copy of the standard for remote operations
39: notation i am even more strongly convinced that ISODE should provide
40: an interface to support RO-BIND and RO-UNBIND.
41:
42: As far as quipu is concerned the changes required are structural, and
43: _should_ (although this is rarely completely the case) be achievable
44: without introducing any new errors.
45:
46: Eventually, this code should be moved into the rosap library or a
47: library of its own. Attempts have been made to keep close to the
48: ISODE style used in rosap to allow this to be accomplished more easily.
49: Only the mapping of RO-BIND and RO-UNBIND for ROSE using ACSE is
50: tackled, a full solution requires a parallel library for the mapping
51: onto RTSE.
52:
53: The ABSTRACT-BIND and ABSTRACT-UNBIND macros have a defined mapping onto
54: ACSE primitives. Currently ISODE does not directly support the use of
55: ABSTRACT-BIND and ABSTRACT-UNBIND, but leaves it to the application
56: programmer to implement the mapping. Quipu currently implements such
57: a mapping, but with poor abstraction.
58:
59: An interface which supports the RO-BIND and RO-UNBIND operations as an
60: ACSE-user should be provided as soon as possible by ISODE for several
61: reasons:
62: 1) Tidying up quipu code
63: 2) Easier implementation of other ASE's
64: 3) Possible incorporation of BIND, UNBIND and perhaps
65: even APPLICATION CONTEXT into rosy.
66:
67: The motivation here is 1), but ISODE styles will be followed where
68: this is simple and appropriate so that 2) and 3) are made easier
69: objectives. (Aside i am assuming that a suitable solution to the
70: ACSE-user vs. RTSE-user problem is to have separate libraries and
71: separate include files accepting the smallish costs of duplication
72: between them - this has the added benefit that the BIND user selects
73: the underlying services by selecting the right library which has the
74: additional benefit that the RoSetService no longer needs to be visible
75: in the application using RO-BIND.)
76:
77: Use of ACSE as described in the ISODE manual is provided by the
78: routines:
79: AcAsynAssocRequest() A-ASSOCIATE.REQUEST
80: AcInit() A-ASSOCIATE.INDICATION
81: AcAssocResponse() A-ASSOCIATE.RESPONSE
82: AcAsynRetryRequest() A-ASSOCIATE.CONFIRMATION
83: AcAsynRetryNext() A-ASSOCIATE.CONFIRMATION
84: AcRelRequest() A-RELEASE.REQUEST
85: (*)AcFINISHser() A-RELEASE.INDICATION
86: AcRelResponse() A-RELEASE.RESPONSE
87: AcRelRetry() A-RELEASE.CONFIRMATION
88:
89: (*) The routine AcFINISHser is called implicitly by RoWaitRequest()
90: having been selected at the ACSE level by a call to RoSetService()
91: with value RoPService. This routine should be replaced with an extended
92: routine (eg RoUNBINDser which would call AcFINSIHser) so that an
93: RO-UNBIND ARGUMENT can be looked for and decoded if present. (Presumably,
94: a similar change would be necessary to support the RTSE equivalent).
95: I made have made misguided comments in my previous message about
96: drastic changes to rosap, this was due to misunderstandings on my part.
97:
98: Since no argument (or results or errors for that matter) are used in
99: the UNBIND of the X.500 protocols this problem can safely be ignored
100: for the moment.
101:
102: One question i haven't been able to satisfy myself about is whether
103: the implementation of RO-BIND should return RoSAPindications or its
104: own definition eg RoBINDindications. I don't want to touch rosap itself
105: at the moment and so have implemented the second.
106:
107: A straightforward use of the ISODE acsap routines can be made to provide
108: an ABSTRACT-BIND/ABSTRACT-UNBIND interface with the following routines:
109:
110: RoAsynBindRequest()
111: Encodes bind argument
112: Calls AcAsynAssocRequest()
113: Maps AcSAPindications to RoBINDindications
114: Calls RoSetService()
115: If completed: Decodes bind result or bind error
116: RoBindInit()
117: Calls AcInit()
118: Maps AcSAPindications to RoBINDindications
119: Calls RoSetService()
120: Decodes bind argument
121: RoBindResponse()
122: Encodes bind result or bind error
123: Calls AcAssocResponse()
124: Maps AcSAPindications to RoBINDindications
125: RoBindRetryRequest()
126: Selects either AcAsynRetryRequest() or AcAsynNextRequest()
127: Maps AcSAPindications to RoBINDindications
128: If completed: Decodes bind result or bind error
129: RoUnBindRequest()
130: Encodes unbind argument
131: Calls AcRelRequest()
132: Maps AcSAPindications to RoBINDindications
133: If completed: Decodes unbind result or unbind error
134: RoUnBindResponse()
135: Encodes unbind result or unbind error
136: Calls AcRelResponse()
137: Maps AcSAPindications to RoBINDindications
138: RoUnBindRetryRequest()
139: Calls AcRelRetryRequest()
140: Maps AcSAPindications to RoBINDindications
141: If completed: Decodes unbind result or unbind error
142:
143: All arguments, except the presentation element representing the user data,
144: and the replacement of the AcSAPindication parameter by an RoBINDindications
145: parameter are passed straight through.
146:
147: Other questions i am less than sure about are:
148:
149: Should rob use the rosap log?? I think it should.
150:
151: Should RoBINDindication be a RoSAPindication?? Not sure.
152:
153: Should rob define separate (non-ACSE) definitions?? Yes, but its costly.
154: This would allow the definition of RoSAPstart, RoSAPconnect, ... for
155: either of ACSE or RTSE, completely obscuring the underlying services from
156: the user of the RO-notation. This is what we want eventually and one reason
157: for pulling this stuff out of the bottom of the dsap library.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.