ASN.1

[Charles Reitzel]

David Brownell wrote:
>Charles Reitzel wrote:
>> I would suggest to folks who need this level of data type reuse and/or
>> sophistication that they look into ASN.1 ...  Perhaps most important,
>> all datatypes defined using ASN.1 have a standard, unambiguous method of
>> encoding the data for transmission on the wire.  These rules are known as
>> the "Basic Encoding Rules", or BER, of ASN.1.
>
>A handful of points there.  First, ASN.1 is generally accepted to be far
>more complex than is justifiable for most applications.  Second, there
>are multiple syntaxes (the newer one is more cryptic than the original).
>Third, BER is not the only standardized encoding ... there's also DER, which
>is a bit more widely used.  (X.509 certs use BER, but most everything else
>uses DER ... think of BER as "canonical DER".)  Choices, choices.

Never heard of DER.  X.500, SSL, LDAP and SNMP all use BER.  BER is really
quite simple (or at least the subset needed by the above protocols).  Open
Source libs to encode/decode BER abound.  It boils down to defining a decent
set of primitive types and their respective on-the-wire images.  Complex
types are sequences of the primitive types.  Is that a bad thing?  Perhaps
not appropriate for some applications, hence XML.

>And fourth, DER and BER are examples of a philosophy of protocol development
>that's been largely discredited for mainstream applications:  "bitstuffing".
>It was a design principle that bit efficiency was more important than time
>spent to encode or decode ... perhaps understandable for systems using X.25
>networks where you more or less paid by the byte, but not on a LAN or even
>the Internet.  Many folk think DER/BER should be the first to be put against
>the wall when the revolution (XML?) comes; they're that unpleasant to use.

Never heard of bit stuffing either.  Philosophy is the least of my concerns.
Rather, I care about the ability to handle standard and custom data types in
a hetergeneous network of cooperating applications!

>> So, I would use ...
>> ASN.1 based private protocol for custom application work.
>
>At the risk of touching off a religious war, I'd not suggest anyone
>inflict ASN.1 on themselves, ever!  Unless they're plugging into an
>existing system based on it ... and even then, they should think about
>whether it's practical to replace/supplant that existing system.

Well reasonable people can agree to disagree.  Clearly, there are many
people who feel as you do.  No doubt the full blown ASN.1 is a bit of a
bear.  I don't think any one protocol uses all of it.  It has solved, in an
elegant way, some of the problems that remain ugly in XML (to whit FPI's and
namespaces, encoding of standard datatypes: numeric, date, time, etc.).
Anyone who can write Java or C++ will have no problem learning to write
ASN.1 statements.    I submit that it is an expiditious approach to
application protocol development.  

Bottom line, I'm saying leave that messy inheritance stuff out of XML
because it's already been done in a standard way by ASN.1.

Best regards,
Charles Reitzel


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)