Hi Chris, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED]
> The following basic questions are nagging at my brain.... > > Q1: XML is a universal standard data format that is gaining > popularity fast. What is the role of > ASN.1 in a world with XML?? Is it a competing standard?? > Does it add any /more/ value? > > Q2: I read about ASN.1 specifying a binary format for data. > I think this may be the (only?) extra contribution ASN.1 has > that XML does not have. If so, why does ASN.1 also > specify an ASCII format??? Perhaps it would have been > more useful to /just/ make ASN.1 specify a standard > way to encode XML in binary? Let me put things into the right context first. ASN.1 is a language for describing the structure of data in abstract terms. The "A" in ASN.1 stands for "Abstract" after all. By itself an ASN.1 specification does not specify the concrete representation of the data in transmission or storage. The concrete representation is known as the transfer syntax in ASN.1 terms and is determined by the application of one of a set of encoding rules. Each set of rules has different properties with respect to space efficiency, time efficiency and readability (among other things) of the resulting transfer syntax. XML is essentially analogous to a transfer syntax. There are encoding rules for ASN.1 (e.g. XER and DXER) which format data as XML. XML is not in competition with ASN.1. Comparing XML to ASN.1 is like comparing concrete to architects' drawings. Rather, ASN.1 is analogous to, and in competition with, XML Schema, RELAX NG and DTDs. An obvious advantage of ASN.1 is that the same data (semantically) can be formatted in other ways (syntactically) by applying different encoding rules. For example, a very compact binary representation results from using PER. Currently the only "transfer syntax" for XML Schema or RELAX NG is XML. With respect to XML formatted data, ASN.1, XML Schema and RELAX NG are broadly similar in what they express although they differ in the details. Each of these languages has some features which have no equivalent in the other languages. For example, ASN.1 has a much richer repertoire for defining restricted types (constrained types) than the other languages. There is work in progress by the ITU-T and ISO to extend ASN.1 so that it has at least the expressibility of XML Schema. A notable feature of XML Schema and RELAX NG is that the syntax of the schema languages they define is also XML, whereas the syntax of ASN.1 specifications is unique. It does not correspond to a transfer syntax generated by any of the encoding rules. However there is an IETF draft of a specification for representing ASN.1 specifications in XML syntax called ASN.1 Schema. That specification brings to ASN.1 all the advantages attributed to XML Schema and RELAX NG in having an XML syntax. I note that RELAX NG specifications now have an non-XML compact representation. RELAX NG has followed the reverse path to ASN.1! To refine the analogies, an ASN.1 specification is analogous to the compact syntax for RELAX NG (there is no equivalent for XML Schema as far as I know) and an ASN.1 Schema document is analogous to an XML Schema document or RELAX NG grammar document. XML is just a transfer syntax. For most new XML-based applications it won't make much difference whether they are specified in ASN.1/ASN.1 Schema, XML Schema or RELAX NG. All three schema languages can do the job. Some applications will have particular requirements that can be best met by only one of these languages, which will make that language the best choice, though often the choice of schema language will come down to the application designers' prejudices and what they are familiar with. What makes ASN.1 important in the crowd is the body of prior art. There are numerous examples of existing, widely deployed, mature applications defined in terms of ASN.1. It seems to me that there are too many people seeking to redefine these applications from scratch just so that they can use XML when it makes much more sense to regard ASN.1 as an XML schema language and just apply a different set of encoding rules to the existing application. > Q3: Why do we /need/ a standard binary format?? The Transport Layer > of the TCP/IP network stack has been happily moving tons of > bits thru the Internet via sockets and port for years without > any need for a "standard way to represent ones and zeroes"!!! > > Granted it is true that there is no standardization of *how* > or *what* gets sent thru the Transport Layer. In the Application > Layer, applications make up their own standard.... FTP, SSH, > TELNET, HTTP each define their own protocol. I suppose we could > start making applications all use ASN.1 instead of reinventing > the wheel.... but why would that be useful? > > Q4: Many papers on ASN.1 define it's functionality in terms > of two upper layers of the *OSI* network model. Why is this > useful since the whole world uses the TCP/IP network model > instead? Historically ASN.1 grew out of work on the OSI model. That's why some papers still link ASN.1 to OSI, though ASN.1 stands on its own. It does not depend on OSI. There are applications, like LDAP, that are defined in ASN.1 but used exclusively with TCP/IP. Various people, myself included, are now working on moving ASN.1 even further from its roots to position it as an XML schema language as good as, and in various ways better than, the other offerings. Regards, Steven > > Thanks in advance. > > Chris Seberino > >
