Slashdot Mirror

Quotes from that web site:

• Abstract Syntax Notation One (ASN.1) is a formal language for abstractly describing messages to be exchanged among an extensive range of applications....
• ASN.1 was first standardized in 1984 by the CCITT (International Telegraph and Telephone Consultative Committee, now called ITU-T, International Telecommunication Union - Telecommunication Standardization Sector) under the name "X.409 Recommendation".

In general you can think of the DARPA layers as completely pragmatic and somewhat modular. You can swap in different network modules, so long as it provides a packet based network to the internetwork layer. You can swap IPv4 with IPv6 (or even IPX. yuck) without breaking TCP and UDP (you may however break plenty of applications that run on them and make incorrect assumptions). Transport is also a block that can be replaced with compatible substitutes, but since there is very little use of anything but TCP or UDP, it's not terribly likely to happen.

With OSI/ISO on the other hand, physical and data link are heavily linked. If you want to replace the physical layer with a modem instead of ethernet, you also need to change the data link from CSMA/CD + Ethernet II framing to V.22bis (or hopefully better) + PPP. The Data Link layer is also over-populated because you almost always need more than one protocol in there (for example, with ethernet, you need both CSMA/CD signalling and Ethernet II framing to make it work). You often need to have two or more protocols in that layer in order to make it fit. On the other hand, the Session and Presentation layers are often completely unused by many protocols (like Telnet, etc), and perhaps shouldn't even exist since they're largely redundant.

The OSI protocols were highly overengineered, somewhat terrifying. A few bits of the OSI protocols still exist in internet protocols. ASN.1 is probably the most notable, since it's used in SNMP, LDAP and most anything that uses certificates with public key encryption. It's fared much better than the X.400 standard which spawned it.

Anyone has experience with ASN.1 http://asn1.elibel.tm.fr/en/? JSON seems to be aiming in the same direction but I don't quite understand what is it they want to do differently.

Can anyone explain this please?

I don't think so. Marked-up binary similar to what's in EBML has been around in the telecommunications industry for a while. There's ASN.1 (complete with standardised XML encoding), and also WBXML (oh, and this *is* a W3C standard). Still, their design is at odds with many of the principles behind XML, but they're extensible and contain tag-like metadata.

ASN.1 was a major pain to deal with, as I recall from my application-development days, and there was a dearth of freely-available tools for manipulating it (my projects always had to use expensive proprietary encoder/decoder libraries), despite being a supposedly open standard. In fact, you couldn't even download the standard itself; it cost fairly major bucks just to get the documents describing it.

PKIX / X.509 / PKCS (Public Key Cryptography)

Kerberos authentication

SNMP / CMIP

X.500 LDAP / DAP directory services

X.400 messaging

Voice over IP: H.323 T.38

The 3GPP specifications (GSM / UMTS mobile phones)

OSI layer 7 protocols (FTAM.. etc.)

RFID

In comparison to XML, ASN.1 is a huge bandwidth saver, in fact the PER (Packed Encoding Rules) were designed for saving bandwidth. There is even a way for encoding data in XML using the XER (XML Encoding Rules) specification.

Last but not least there is finally a worthwhile opensource ASN1 to C compiler out there: Get ASN1C here.

New to ASN.1?? Visit this site and be sure to pick up the excellent free book on ASN.1!

Yes, ASN.1 implements a lot of excellent ideas from the get go, such as

* being an "abstract" format, i.e. considering data to be independent from its actual byte-wise representation
* ability to define space-smart encodings
* supporting canonicalization from the get-go
* use of a well-defined ISO namespace
* modularity of grammar definitions

But take a close look at it and you will see that unfortunately, it is a standard that is very difficult to interpret, crippled with obsolete string formats, and in practice not very well implemented. As a result, useful implementations will even sometimes have to have the ability to break compliance to work with other broken implementations.

For example, ASN.1 is the underlying language of the X.509 certificate standard, which is in turn used by IETF's PKIX, SSL and HTTPS standards. Canonicalization is supposed to allow the decision of "object equality" in a well-defined manner and known time. However, a widespread HTTPS browser (not IE) did not implement canonicalization in some parts of their implementation. As a result, interoperation with that browser required the implementer to actually violate canonicalization rules so that the object would be properly understood by the browser (!)

Another sign that ASN.1 might be a little bit too complex is the fact that there are no fully compliant open-source implementations of ASN.1 parsers, parser generators, parsing libraries etc. Even the commercial offering itself is not that good and dearly priced.

What would be nice is a simpler, leaner version of ASN.1 keeping the main structural features and getting rid of the problematic / obsolete features.

For resources on ASN.1 and XML, including an XMLSchema-to-ASN.1 converter

Don't we already have ASN.1?

Its called asn.1 which, incidently, already has a defined mapping to and from xml Its binary encoding is designed to include as little redundant data as possible while retaining the benefits of tagged heirchaical data, and it is already used for storing and transmitting things like certificates in SSL.

Its called asn.1 which, incidently, already has a defined mapping to and from xml Its binary encoding is designed to include as little redundant data as possible while retaining the benefits of tagged heirchaical data, and it is already used for storing and transmitting things like certificates in SSL.

the article states that they will be able to easily convert to ASN.1, which appears to be made for this kind of thing.

The good point of XML is its unified syntax - you don't need a new parser each time, you already have one and you concentrate on semantics rather than syntax.

That's why there are such projects as XML representation of FlatCurry. Similar implementations I've met also in mail-lists about Mercury (BTW, they have also discussed S-exps as a basis of new syntax). Even ASN.1 goes to XML.

Again, I think XML tags are worse readable (and less compact) than Lisp S-expressions. Thast's why I believe that eventualy the market attraction of Lisp-like languages will tise again.

Hanging my head in shame, I'm one of those "still inventing his own application layer protocols". ASN.1 and RPC were also supposed to save me from doing this. Lately, I've found I've been implementing my own protocols using the concept of netstrings to suit my admittedly low-level needs better. Sadly, as XML and its derivatives mushroom in complexity, I find them less appealing.

A useful framework for some types of data it may be (specifically, markup data), but I feel that XML is too often used outside the scope of its main strengths. Specifically, object serialisation, transmission and other such protocols are handled more elegantly by ASN.1, Java serialisation (which can just as easily become a standard for other languages) or just rolling your own, program semantics by LISP syntax etc.

Far too often W3 encourage the blinkered approach that XML is the only way to express things. Stuffing base64-encoded strings into markup tags to be parsed at the other end is just not convenient and I think it can be done better.

The binary representation of ASN.1 is supposed to be quite good at representing XML.

If you have a schema for your data, then it can simplify the data by making assumptions about the order and format of the data.. at least that is my understanding.. and of coarse it's no longer verbose and human readable..

There is some interesting work going on with XML/ASN.1 translation. Essentially, one can create a 1-1 mapping between an ASN.1 module and an XML schema, and use whatever encoding you're comfortable with (i.e., XML encoding, or ASN.1 [DBP]ER). The advantage here is that the encoding rules for ASN.1 (especially the PER (Packed Encoding Rules)) are very space efficient. Thus, by re-encoding the XML data as ASN.1, one can achieve remarkable levels of compression.

This site has some useful information on the proposed standardization of this effort. There was also a /. post about a recent EE Times article on the subject.

Besides - ANS.1 is definitely an encoding scheme. (Click the link to look at the website about ANS.1)

If you'd ask me, ANS.1 is not meant for everyday internet traffic. Why EEtimes or Slashdot seem to suggest it is, is beyond me.