Re: Abbreviated Tag Names (ASN.1)

[Olivier Dubuisson <Olivier.Dubuisson@francetelecom.com>]

"Thomas B. Passin" wrote:
> 
> Charles Reitzel wrote -
> 
> > Surely, ASN.1 is preferable to inventing a new set of binary encodings for
> > XML Schema data types.

200% agreed ;-)
BTW thanks to Charles and others for this thread on ASN.1 that now allow me to 
keep the xml-dev folks informed on what's going on with XML in the ASN.1 
working group!

> There are several drawbacks to using asn.1, though.
> 
> - There's not such a range of freely available tools - compilers and decoders,
> especially - in such a variety of languages, as best as I can tell.

I rarely take this as an argument, for I'm inclined to think that the domains 
where compression is required are managed by big companies which have a lot
of money, and which usually prefer to buy commercial tools because of the
associated maintenance :-)
Moreover this argument is a kind of dead circle: ASN.1 is not used in
*some* areas because no free tools are available, and no free tools are
available because ASN.1 is not used in the areas where people usually
write free tools. Anyway I think that things will change, for there are
a bunch of companies which are going to work together on the promotion of
ASN.1, and I agree with you that providing free tools is a good way to
promote a technology. (I give some more elements on this topic below.)

> - You almost can't check asn.1 by hand; it's certainly much harder than for
> xml documents.

What do you mean by "check" here? Decode?
If yes, then it depends on the encoding rules that are used:
	- for BER or DER, writing a decoder is the kind of project you
can give to a student;
	- for PER, I agree that writing *good* encoders/decoders is more
tricky, but there are anyway some free tools, see
http://asn1.elibel.tm.fr/links/#tools

> - There's no standard way to translate between asn.1 and xml, and their data
> models are not fully congruent.

Here I say: "not yet"!
The ASN.1 Project from ITU-T is actually working (jointly with ISO) on 2 
initiatives:
1. an XML value notation for ASN.1 types (or "ASN.1 Markup Language") that
allow to write values by way of an XML markup whose tags are derivated
from the ASN.1 type names.
Such an XML value notation can appear in an ASN.1 module, and can be
used to display ASN.1 values with an XML browser.
When appended with an XML document header and footer, this value notation
turns into what could be called "XML Encoding Rules for ASN.1". This will
be a standard named ITU-T Recommendation X.693 | ISO/IEC 8825-4.

2. an XML Schema to ASN.1 mapping that keeps all the information contained
in an XML Schema and translates it into equivalent ASN.1 types and subtype
constraints. You can then use ASN.1 standardized encoding rules such as
DER (that allow digital signatures and encryption, for example) or PER (to
very efficiently transmit data over a radio channel, for example), as well as
associated ASN.1 tools, for data that are defined in XML.
This will be a standard named ITU-T Recommendation X.694 | ISO/IEC 8825-5.

As far as timescales go, we are currently finishing a new standard called
Encoding Control Notation (a formal notation associated with ASN.1 to
define specialized encodings) that the UMTS folks are waiting for.
Our April meeting will be mostly dedicated to XML.
France Telecom and OSS Nokalva are currently working together to make
things happen very quickly. The above documents should be stabilized for
our August meeting. OSS Nokalva (http://www.oss.com) has announced a tool in 
the September 2001 timeframe. I don't know at the moment what other ASN.1
tool vendors are planning to do.
As far as free tools are concerned, France Telecom is willing to provide
free tools on its ASN.1 website (http://asn1.elibel.tm.fr); thus I hope
that we'll continue to go down this route, but cannot say more at the
moment.
Finally, to those who would say: "yes, but these standards are not going to be 
free", let me answer beforehand that there will be a means to have them for 
free, or that they will be packaged together for a small price.

> -A  DTD cannot specifiy enough restrictions to give you an exact literal
> translation of asn.1  You have to decide to give up something.  This may not
> matter too much for data that starts out as xml though.  Also, it looks like
> xml schemas will let you get very close to asn. in terms of describing data
> structures.

Correct.

> Just calling a standard compression library like zip would certainly be
> easier. 

An ASN.1 decoder gives the data back to the communication application through
a user-friendly interface, in the same way as XML tools do I guess.
Moreover our tests have showed that the PER encoding rules have a better
"compression rate" than zip, particularly for small documents like those
written in WML, for example.

> A lot depends on how important reducing the byte count in a message
> is.  Remember that the requirements for XML included the statement that
> "terseness" in XML markup is "of minimal importance."

True, but then people should avoid to use such a technology on low-bandwith 
channels. I think that what I've presented here keeps true the requirement
that terseness is of minimal importance on every kind of channels!
-- 
Olivier DUBUISSON (ITU-T ASN.1 Project Leader)
france telecom R&D
     _                 DTL/MSV - 22307 Lannion Cedex - France
    ( )           tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
    / \/               --------------------------------------
    \_/\               Site ASN.1 : http://asn1.elibel.tm.fr/