Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.24/text0009.txt

Text File | 1991-09-03 | 1.8 KB | 42 lines

Submitted-by: [e-mail] (Andrew Hume)

    The latest login; has three (!) reports on the january 1991
meeting of P1003.17 and P1224. In particular, I was
interested in the object management PAR and the controversy
that aroused two additional articles.
    The problem is that I can't quite figure out what the problem
really is. Perhaps if I go through what I think is going on, then
someone will correct me.

    XDS and X.400 defines objects and their encodings via ASN.1.
(This latter means that the BNF-like specifications of the objects
is written in the ASN.1 syntax and that there is a corresponding
well defined encoding into a byte stream.) There is some grouping
of these objects into ``packages'' (I don't know what this means
or implies). XDS and X.400 define an interface for accessing
these objects. That is, a byte level encoding of commands
mixed with objects.

    I think the 1003.17 work is about defining multiple
``versions'' of these interfaces, with the idea that each version
might be a value-added or extended interface. so far, so good.
Scott complains (rightly) that it sucks that vendors can extend
these packages and that users can't. Enzo doesn't say whether he
agrees but says that it seems technically infeasible.

    Could someone comment whether this is a fair summary?
My initial take on this is that it may be technically infeasible
to dynamically support new objects but this should have been a goal
of the work until conclusively shown to be infeasible. (It actually
isn't anyway; it is easy to see how new objects could be handled
as long as you were willing to pay a performance hit for the new objects.
It can be done by analyzing the byte stream interpretively rather than
with compiled code; again, just for the new objects).

    andrew hume
    [e-mail]


Volume-Number: Volume 24, Number 11