[February 28, 2002] "The ASN.1 Project from ITU-T is working (jointly with ISO) on two XML-related initiatives. The first one mainly focuses on existing protocols already defined in ASN.1 while the second is dedicated to XML-defined data... (1) The XML value notation for ASN.1 types (or 'ASN.1 Markup Language') makes it possible to define values using XML markup whose tags are derived from the ASN.1 type and identifier names. (2) With no loss of information, the 'Mapping from XML Schemas to ASN.1 modules' takes as input an XML Schema and translates it into equivalent ASN.1 types and subtype constraints (merged into a single ASN.1 module). This technique can be applied to any given XML application language. ASN.1 standardized encoding rules such as DER (a canonical encoding that allows digital signatures and encryption, for example) or PER (to very efficiently transmit data over a radio channel, for example) can then be used as well as associated ASN.1 tools, or even specific encoding rules that are described in ECN..." [web site introduction]
[February 28, 2001] In the context of a discussion on XML compression, Olivier Dubuisson has described an XML-based "ASN.1 Markup Language" now under development. According to the documentation, this new form of ASN.1 value notation "was created in Geneva during the January joint meeting of the SG 7 and SC 6 groups, and the format of this value notation is based on XML. This work allows ASN.1 values to be transferred or displayed in a variety of textual of binary formats (PER BER HTML XML plain text, etc.); users can leverage browsers for XML display and still have efficient binary transfer in BER..." ASN.1 [Abstract Syntax Notation One] is "a formal notation used for describing data transmitted by telecommunications protocols, regardless of language implementation and physical representation of these data."
Description of the 'ASN.1 Markup Language' can be found on the France Telecom R&D web site and in a document "ASN.1 use of XML, Encoding Control Notation, Tools and books on ASN.1" (T1M1.5/2001-034). From the latter:
"The ASN.1 standards group has made much progress in enhancing ASN.1 to allow its use in support of legacy applications, and to allow XML browsers to be used to easily display values of types defined using ASN.1. Work is also underway to allow messages described using XML to be converted to ASN.1, thereby circumventing the verbosity of XML encodings and allowing them to be encoded very compactly. In conjunction with this work, ASN.1 tools are under development to support these new notations."
Displaying ASN.1 messages using XML browsers. The ASN.1 standard is being enhanced to provide a standard mapping of values of types defined using ASN.1 into XML markup format, making it possible for such values to be easily displayed using common XML browsers regardless of which encoding rules (e.g., BER, PER) such messages were encoded in. This is being achieved by using ASN.1 as the schema of the messages, and XML markup as the display format. In addition to the enhancements to the ASN.1 standard, a new encoding rules document, ITU-T Rec. X.693 | ISO/IEC 8825-4, titled "Encoding using XML or basic ASN.1 value notation", is being created. This document specifies how to encode values of ASN.1 types in XML markup format for the purpose of transmission (as opposed to using XML markup as value notation within an ASN.1 module). Also specified in this document is how to encode values of ASN.1 types using ordinary ASN.1 value notation for the purposes of transmission. Some benefits of this work are:
- Applications will be able to easily display BER-encoded or PER-encoded messages (for example) using XML browsers.
- It makes possible the creation of tools that allow applications to encode messages in XML markup format, BER format, PER format, etc., without the need to know the details of how to encode values in any of these formats.
- It will be possible for application protocols to exploit the ASN.1 value notation as an ordinary set of encoding rules in those cases where textual encodings are desired but there is no interest in using XML markup.
- Used in conjunction with the ECN support (explained in Section 3), this also enables legacy protocols to have their values displayed using XML.
Encoding XML-defined messages using ASN.1. An additional encoding rules document, ITU-T Rec. X.694 | ISO/IEC 8825-5, titled "Encoding XML-defined data using ASN.1", is being created. This document specifies a standard mapping of XML Schemas into ASN.1, exploiting ASN.1 to produce much more compact messages than what is produced by XML markups. The main benefit of this is that applications such as WAP, SyncML, VoiceXML, etc, that use XML to describe their messages will be able to encode them much more compactly than is possible with current binary XML encodings.
Use of ASN.1 to support legacy protocols. A new notation defined in ITU-T Rec. X.692 | ISO/IEC 8825-3, titled "Specification of Encoding Control Notation (ECN)", has been defined to:
Since both ASN.1 and ECN specifications are machine processable, encoders and decoders can be automatically generated from them. This is a significant factor in reducing both the amount of work and the possibility of errors in making interoperable systems. Another advantage is the ability to provide automatic tool support for testing.
- allow ASN.1 types to be defined for established ("legacy") protocols where the encoding is already determined and differs from any standardized encoding rules (e.g., BER, PER), and
- allow protocol specifiers to create encodings that are minor variations on standardized encoding rules.
Some "potential application domains for the ASN.1 Markup Language in the mapping from XML Schemas to ASN.1 modules): [1] WML (Wireless Markup Language, for WAP phones) In this case, for example, the PER encoding rules of ASN.1 would give a much more efficient (compressed) encoding than the ad-hoc Binary XML; [2] HDML (Handheld Device Markup Language) for mobile phones and PDAs; [3] SyncML (Synchronisation Markup Language); [4] VoiceXML; [5] tML (telecommunications Markup Language); [6] IPDR (Internet Protocol Detail Record)."
From Phil Griffin's presentation (see below)
"ASN.1 is a schema, which allows users to define the gross structure of messages. SEQUENCE, SET, CHOICE, etc. ASN.1 data types (INTEGER, BIT STRING, etc.) allow users to choose distinct sets of values for message components. ASN.1 constraints allow users to further restrict the sets of values in a given type to a valid subset of values. (Y or N) or (male or female) or (positive integers only)
"Every ASN.1 type definition can be represented using markup. Every ASN.1 type has a default markup notation. This default markup notation uses the ASN.1 defined type name and user specified indentifiers shown highlighted here. Given only the ASN.1 type definition of AnyName, tools on both ends of a wire can communicate values of type AnyName using the same default XML markup notation. Alternatively, they can display the XML value <AnyName> on both ends of the wire, and transfer (or store) the value in BER This value BER encodes in 19 bytes (14 PER). Using XML markup requires 96 bytes - 85 bytes just for tags. Notice that the markup does not contain: (1) any hint of the tags in the ASN.1 definition (2) any information on the data types used (3) any hint that the middle initial is optional (4) any restrictions on the size of the middle initial All of this additional information must be carried in the schema in the transfer (as in XML) or understood one time only (as in ASN.1) and assumed for all subsequent transfers."
References:
ITU-T Study Group 17 - Languages for Telecommunication Systems. Documents online.
ASN.1 Markup Language presentation by Phil Griffin, [cache, PPT]
"ASN.1 use of XML, Encoding Control Notation, Tools and books on ASN.1" T1M1.5/2001-034. See (derived) text and HTML version for unofficial text. [cache]
ASN.1/XML Mailing List - "send an email message to majordomo@oss.com with subscribe asn1xml your-name in the body.
See also: "XML Encoding Rules for ASN.1 (XER)" - Main reference page.
[April 01, 2003] "ASN1C Mapping of ASN.1 Syntax to XML Schema." White Paper. From Objective Systems, Inc. March 2003. 21 pages. "An effort is currently underway within the ITU-T to map World-Wide Web Consortium (W3C) XML Schema Definitions Language (XSD) to Abstract Syntax Notation 1 (ASN.1). But a parallel effort to provide a mapping in the other direction -- from ASN.1 to XSD -- is on hold. Given the currently popularity of XSD for defining new standards, it would seem reasonable that ASN.1 to XSD conversion would be of interest to the ASN.1 community. This paper presents such a mapping. It uses as a basis the T1 Standard's Committee Draft Standard -- tML Guidelines for Mapping ASN.1 Syntax and Modules to XML Schemas. The Objective Systems' ASN1C ASN.1 Compiler Tool v5.5 will have the capability of producing XML Schema that is consistent with these mappings..." [cache]
[December 16, 2002] "OSS Nokalva Announces XML Support." - "OSS Nokalva, Inc., the world's leading developer of ASN.1 software for building data communications applications, announced today the immediate availability of the OSS ASN.1 Tools for C and Java with XML support. A C++ beta version is also currently available. 'We are very excited because our new software allows ASN.1 application developers to effortlessly encode data in XML,' commented Bancroft Scott, President of OSS Nokalva. 'This creates an exciting opportunity for developers to maximize their return on investment in robust ASN.1 technology with the added benefits of XML. The addition of XML encoding enables XML to be used in places that are bandwidth constrained such as cell phones, PDAs and embedded systems. Developers can now view binary encoded data in human readable format using XML without sacrificing ASN.1's simple and efficient message description.' The OSS ASN.1 Tools support the XML addition to ASN.1 as described in ASN.1:2002. The tools generate fully XML-standards compliant XML encodings, giving developers a means of representing ASN.1 values using XML with the ASN.1 type definition as the schema. The generated XML is governed by the XML Encoding Rules (XER) and Canonical XML Encoding Rules (CXER), providing the user with control over the visual quality of the generated encoding. It also allows for the viewing and editing of the encoded data using any tools that recognize XML independent of ASN.1... The software completely shields the user from the intricacies of the encoding rules and complexities of manual coding and debugging. All software supports the full ASN.1 syntax as described by the ASN.1:1990, ASN.1:1997 and ASN.1:2002 standards and the following encoding rules: Basic Encoding Rules (BER), Packed Encoding Rules (PER) (aligned and unaligned), Distinguished Encoding Rules (DER), Canonical Encoding Rules (CER), Canonical XML Encoding Rules (CXER), and XML Encoding Rules (XER)..."
[December 16, 2002] "Intercommunication between XSD and ASN.1." By Paul Thorpe (OSS Nokalva, Inc). Abstract from the XML 2002 Conference presentation, Baltimore. December 2002. "The Joint ISO/IEC and ITU-T ASN.1 standards committee has produced a new encoding rule for ASN.1 called XML Encoding Rules (XER) and a canonical variant of this, CXER. This has been approved by the ITU-T as Recommendation X.693 and is currently undergoing FDIS balloting in ISO as the International Standard ISO/IEC 8825 4, with the ballot to be completed in November 2002. This International Standard specifies the rules for creating valid XML documents given any ASN.1 schema. However, the XML documents produced using XER or CXER do not provide access to some of the XML encoding facilities such as attributes and lists. The ASN.1 standards committee therefore began work on adding encoding instructions that could direct an XER encoder to vary the XML documents produced with an ASN.1 schema to provide any form of XML document that the designer might desire, including use of attributes and lists and arbitrary patterns of XML elements (such as are provided by RELAX NG). Along with these encoding instructions, the ASN.1 committee embarked on producing a new standard ITU-T Rec X.694 - ISO/IEC 8825-5, which defines the mapping from XSD to ASN.1. This enables an ASN.1 specification to define the same valid XML documents as the XSD specification, but with the advantage of providing for additional binary encodings and for mapping into C, C++ and Java datastructures. The ASN.1 September 2002 meeting in Paris finalized much of this work, and it is expected to be fully complete in the November 2002 meeting in Geneva..."
[September 25, 2002] "Canonical XML Encoding Rules (cXER) for Secure Messages. An ASN.1 Schema for Secure XML Markup." By Phil Griffin (Griffin Consulting). Presentation prepared for the RSA Conference 2002 Europe, October 7 - 10, 2002, Le Palais des Congrès de Paris, Paris, France. 19 pages. The ZIP package contains PPT format with additional notes. "ASN.1 is a schema for encoded values: Types describe general structure of abstract values; Each builtin type defines a class, a set of distinct values; Constraints restrict a class and the validity of values; Encoding rules define how abstract values are transferred... Encoded ASN.1 values are binary or text: [1] Binary and XML Canonical Forms (Distinguished Encoding Rules => DER, Canonical XML Encoding Rules => cXER) [2] Each DER encoding maps to a cXER value; The Canonical XML Encoding Rules (cXER) are defined in: ISO/IEC 8825-4 -- ITU-T X.693 ASN.1 XML Encoding Rules (XER). The same ASN.1 value is cXER encoded in one and only one way as a single long string containing no 'white-space' characters outside of data... ASN.1 XML Benefits: [1] A single schema for all values, Binary and text encodings are all based on ASN.1 types (Eliminates multiple schema mappings and Provides an efficient schema for XML values) [2] ASN.1 <=> XML communications (ASN.1 applications can send and receive XML values, Efficient transfer, simple signature processing)..." See: (1) OASIS XML Common Biometric Format (XCBF) TC; (2) the related paper "X9.84:2002: Biometric Information Management and Security." [ZIP source with included PPT, from Griffin Consulting]
[February 28, 2002] "Canonical XML Encoding Rules (CXER) for Secure Messages. An ASN.1 Schema for XML Markup." By Phillip R. Griffin. February 19, 2002. Based upon slides and speaker notes from a presentation given at the RSA Security Conference (McEnery Conference Center, San Jose, California). From a communiqué: "The presentation is entitled, 'Canonical XML Encoding Rules (CXER) for Secure Messages - An ASN.1 Schema for XML Markup'. It describes how to use ASN.1, the Abstract Syntax Notation One standards defined by ISO, IEC and ITU-T, as a schema for XML messages. The presentation will be given by Phillip H. Griffin. By using an ASN.1 schema, XML values can be transferred in a compact, efficient binary format. These same values can then be represented and used locally as verbose markup text. This capability allows XML to be used effectively in environments with constraints imposed by mobility and/or limited bandwidth (e.g., wireless communications with personal digital assistants), high volumes of transactions (e.g., Internet commerce), or limited storage capacity (e.g., smart cards)... ASN.1 is a schema for encoded values: Type definitions are based on the X.680-series notation; Types describe the expected general structure of values; Each builtin type defines a class, a set of distinct values; Constraints restrict a class and the validity of values... Using the Canonical XML Encoding Rules (CXER), the same ASN.1 XML Value Notation example can be encoded one and only one way as a single long string containing no 'white-space' characters outside of data..." A free copy of the presentation, including slides and speaker notes, is available online. [cache]
[August 08, 2001] "Group says ASN.1 can field XML, save bandwidth." By R. Colin Johnson. In EE Times August 07, 2001. "The ASN.1 Consortium will be launched later this summer to hawk Abstract Syntax Notation One as the preferred communications standard for achieving interoperability between computing platforms sharing the Extensible Markup Language (XML). As digital communications spreads from cell phones to wireless personal organizers and XML-powered information appliances, the consortium claims to have the interoperability 'Rosetta stone' in place. 'ASN.1 is already the enabling technology for cell phone messages, radio paging, streaming audio and video over the Internet, 800-number services, ISDN telephone services, digital certificates and secure e-mail,' said Bancroft Scott, founder and president of OSS Nokalava here. 'But with the ongoing work in the engineering community to deliver digital information with XML, we want to get the word out on how you go about getting these devices talking to one another.' ASN.1 was invented in 1984 and has become an international standard published jointly by the International Standards Organization, the International Electrotechnical Commission and the International Telecommunications Union. The telephone companies popularized it as a method of gluing together all the various computers that must route messages between handsets through a maze of diverse switches. Once a message is encoded in ASN.1's formal language, any other computing device along a telecommunications route can securely decode it -- whether it's a billion-dollar supercomputer or a $50 cell phone. In the '90s, ASN.1 tool kits were ported to nearly 100 computing platforms running C, C++, Java, Pascal and proprietary operating systems for embedded devices like cell phones. Despite its widespread use, ASN.1 is not widely recognized in the engineering community as a route to interoperability. In fact, the emergence of XML has begun to overshadow ASN.1 as the preferred universal data-formatting methodology. XML allows application developers to encode their data into HTML-like text files that encapsulate the information about the data -- its application-specific 'tags'-- along with its raw alphanumerical values. XML allows computers of all sizes -- from supercomputers to those embedded in cell phones -- to share the same data files, such as accessing an appointment calendar from a PC in the office or from a cell phone while on the road. The new consortium, however, argues that the venerable ASN.1 specification can be the preferred method of telecommunicating raw XML database information from device to device..."
