Re: Non-XML binary formats.

On Wed, 1 Dec 2004, David Ryan wrote:

> Paul Thorpe wrote:
>
> >>I've come from the direction of CORBA and other Remote Procedure Call
> >>architectures.  What I was looking for was a way of doing strong data
> >>type agreement between two systems that have not previously had any
> >>contact or been developed by the same parties.  This requires that the
> >>two systems are able to negotiate if they have the same data type
> >>formats dynamically; ensuring that their encodings also match.  This
> >>allows partial schema matching between two systems.  It requires that
> >>the schemas act more as dictionaries instead of schemas, or I believe
> >>the term in ASN.1 is modules.  It allows an individual application to
> >>build it's own vocabulary which meets its own needs, and then allows a
> >>client to discover if there is a match between its own vocabulary and
> >>the server's dynamically.  Argot was my solution for that problem.  If
> >>ASN.1 does allow such matching, I'd be interested in what part of
> >>specifications show this.
> >>
> >>
> >
> >ASN.1 supports this capability via what we call Extensible Information
> >Object Set.  You can constrain a particular portion of a message (an
> >Envelope message perhaps with some "hole" for open content) using an
> >Information Object Set (to indicate what that "hole" should contain).
> >That Information Object Set can be dynamically changed (by addition or
> >deletion) at runtime to alter the nature of the content permitted.
> >
> >
> >
> I went back to the standards page and had a closer look at the X.681
> Information Object Specification.  I assume this is the correct
> specification to review?  The specification while full of detail does
> look like it will require some heavy studying of the other ASN.1
> standards before I can fully understand its aims.  However from what I
> read, this doesn't exactly meet the needs I stated above.  It looks like
> an addition to ASN.1 and does not go to it's core.  This also doesn't
> seem to dictate how you would encode the information object
> specifications.  The aims for Argot and its Remote Procedure Call system
> was to allow the full data type vocabulary and encodings to be matched
> before communicating with them.

Please note that you do not "encode" information objects.  They are
"local" meta data used to indicate what actually goes across this line.
This "add on" has been part of ASN.1 since 1994 when a much less precise
MACRO notation was removed from the language.  Understanding the mechanism
is not too difficult.  A good explanation of it can be found in each of
the two ASN.1 books (available free from www.oss.com or for purchase from
amazon.com).

You might also look at the EMBEDDED PDV mechanism which more directly
supports peer-to-peer negotiation/agreement/identification on what is
being exchanged.

>
> The approach I took with Argot was to create a fully self referencing
> binary description format.  Each definition is fully described by other
> elements defined in the dictionary using a binary description.  This
> makes the description size small and more importantly the library size
> at the end points small.  By keeping every element self referencing a
> client/server interaction can bootstrap the conversation by ensuring
> that the description formats are the same.  I think using an ASN.1
> Information Object Specification based solution would not be able to
> reach the same elegance in deriving a solution, or meet the size
> requirements.
>
> Does ASN.1 allow the description of its types to be encoded using one of
> its encodings like BER?  From what I've read so far, the ASN.1 language
> is strictly a text based language.  I've found the benefit of having the
> type descriptions also in binary allows the client to require no text
> based parser.  This has resulted in a very small marshalling system.

I saw some work on this, but it has not officially been taking on by the
ASN.1 committee.  The ASN.1 committee has not seen high demand for this
thus far, but has listed it among its possible "future work" areas.

>
> >>I think you'll find that with VOIP and other technologies it might be a
> >>matter of those technologies just disapearing in a similar way as the
> >>printing industry has done over the last twenty years.  Standards don't
> >>generally get rewritten, they just get replaced and become obsolete.
> >>
> >>
> >
> >Are you saying you expect VoIP (which uses ASN.1) to disappear?  All
> >indications I see seem to indicate it is still expanding rather than
> >disappearing.
> >
> >
> >
> Maybe using a telecommunications example was a bad choice.  I agree that
> standards don't disapear, however, they do become less important. CORBA
> is another example.  It will continue to be used in systems now and in
> the future, however, I don't see many enterprise organisations picking
> it up for new integration projects.  This is also true of ASN.1.

Your view of the world is very different that mine here.  I continue to
learn of new areas in which ASN.1 is being used.

> The
> current flavour is XML and XML Schema.  If XBC WG put together a
> solution that satisfies the use cases stated that new standard is likely
> to become the new flavour of XML.  I think that will be the case for
> both the use cases stated and many other places text is used currently.
> Now, if ASN.1 is what XBC WG end up putting forward, then maybe there
> will be a big role for ASN.1 in the future.

Clearly the XBC WG group is not yet at a stage to make this kind of
decision.  There are several other technologies on the table there, and no
guarrantee that any one of them will be chosen, as opposed to recommending
that W3C create its own.

>
> >I am a member of the ASN.1 committee (which is joint work with ISO/IEC
> >and ITU-T), and am also a member of the W3C XML Binary Characterization
> >working group.  We are finishing gathering all of the background
> >information we need, and have yet get into the real heavy discussions
> >about which direction to recommend the W3C go on this.
> >
> >
> >
> Is this mailing list the best place to keep updated with the work of the
> XBC WG?  I'll be very interested to see which direction the working
> group take the specification and recommendations.

Yes, unless you actually become a part of the working group.  You would
then have access to the internal mailing list where the real discussions
take place.

Paul
----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: thorpe@oss.com                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023

Received on Wednesday, 1 December 2004 19:16:17 UTC