Thread View: comp.protocols.iso
3 messages
3 total messages
Started by Brian May
Tue, 13 Oct 1992 02:09
XOM and XDS - more info
Author: Brian May
Date: Tue, 13 Oct 1992 02:09
Date: Tue, 13 Oct 1992 02:09
76 lines
3138 bytes
3138 bytes
A couple of people have expressed interest in further explanation. Most of those are lucky enough to have the task of implementing (at least) XOM for support of other X/Open APIs. ----- First of all, a little about XOM - as all X/Open OSI Application APIs require it. The specification/definition for XOM is text based with C like definitions of the functions. The descriptions of those functions are fairly sparse and leave a fair amount open to interpretation. A very brief description follows. Comments/corrections welcome. XOM --- XOM manages 'OSI' or 'ASN.1' data objects for an application API. XOM has 2 different concepts of these objects which it calls PUBLIC and PRIVATE. Public & Private objects ------------------------ PUBLIC objects are those which the client can modify the contents of. PUBLIC objects are basically arrays of descriptors (which hold type, syntax and value of attributes). This obviously makes insertion/deletion/allocation of attributes within the object a pain! A PRIVATE object's structure is implementation dependent. Only the header to an object must have a common structure. The attribute descriptors can be implemented any way you wish (eg doubly linked list). Clients of this API can only use PUBLIC objects and have to create a PRIVATE object, and subsequently take a PUBLIC copy for use. EG. When a DUA wishes to create a bind argument, it must first directly use XOM to create the object, take a public copy of the object, then use the XOM encode function before it can send the bind request via XDS and the protocol stack. OIDs and Class Tables --------------------- XOM holds a _static_ class table containing all the OIDs it knows about. If you want to dynamically use/create a new object, it'll have to be re-compiled into XOM's class tables. Class table structure is left up to the implementor. Encode/Decode ------------- These merely create the relevant structures for sending/receiving ASN.1 data relevant to the protocol stack in use. (We use PEPSY for ISODE) Diagrams -------- I have a couple of MacDraw diagrams available which show the relationship between a DUA, XDS, XOM and a protocol stack (ISODE). They are available via anonymous ftp from: mel.dit.csiro.au in the directory staff/brian/API I'll put TIFF and PostScript versions there also. --------------- brian -- | Brian.May@mel.dit.csiro.au | Open Systems Program | | CSIRO/DIT, 723 Swanston st | TEL +61 3 282 2613 -- FAX +61 3 282 2600 | |Carlton, VIC 3053, Australia| Experimental Scientist |
Re: XOM and XDS - more info
Author: Tai Nguyen
Date: Wed, 14 Oct 1992 19:56
Date: Wed, 14 Oct 1992 19:56
31 lines
1554 bytes
1554 bytes
In article <1992Oct13.020901.3410@mel.dit.csiro.au>, brian@mel.dit.csiro.au (Brian May) writes: ... Stuff deleted |> |> OIDs and Class Tables |> --------------------- |> |> XOM holds a _static_ class table containing all the OIDs it knows about. |> If you want to dynamically use/create a new object, it'll have to be |> re-compiled into XOM's class tables. |> |> Class table structure is left up to the implementor. |> |> Encode/Decode |> ------------- |> |> These merely create the relevant structures for sending/receiving ASN.1 |> data relevant to the protocol stack in use. (We use PEPSY for ISODE) |> I think what said above is not enough. The function om_encode must encode an OM object such that its peer can decode it and its peer can use different stack. Thus, the encoding must be based on ASN.1 syntax understood by both sides. ______________________________________________________________________________ Tai Nguyen Email: ...!bae.bellcore.com!tain Bell Communication Research Phone: (908) 699-7934 444 Hoes Lane Room RRC 1B210 Piscataway NJ, 08854
Re: XOM and XDS - more info
Author: Brian May
Date: Thu, 15 Oct 1992 22:56
Date: Thu, 15 Oct 1992 22:56
42 lines
1934 bytes
1934 bytes
In article <1992Oct14.195612.9110@walter.bellcore.com>, tain@wrench.bae.bellcore.com (Tai Nguyen) writes: |> In article <1992Oct13.020901.3410@mel.dit.csiro.au>, brian@mel.dit.csiro.au (Brian May) writes: |> |> ... Stuff deleted |> |> |> |> |> OIDs and Class Tables |> |> --------------------- |> |> |> |> XOM holds a _static_ class table containing all the OIDs it knows about. |> |> If you want to dynamically use/create a new object, it'll have to be |> |> re-compiled into XOM's class tables. |> |> |> |> Class table structure is left up to the implementor. |> |> |> |> Encode/Decode |> |> ------------- |> |> |> |> These merely create the relevant structures for sending/receiving ASN.1 |> |> data relevant to the protocol stack in use. (We use PEPSY for ISODE) |> |> clarification: These merely create the relevant structures, encoders and decoders for sending/receiving ASN.1 data relevant to the protocol stack in use. (We use PEPSY for ISODE) |> it and its peer can use different stack. Thus, the encoding must be based on |> ASN.1 syntax understood by both sides. It is. regards, brian -- | Brian.May@mel.dit.csiro.au | Open Systems Program | | CSIRO/DIT, 723 Swanston st | TEL +61 3 282 2613 -- FAX +61 3 282 2600 | |Carlton, VIC 3053, Australia| Experimental Scientist |
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads