XML encoding rules (XER) for ASN.1

The XML value notation for ASN.1 types makes it possible to define values using XML markup in which the element tags are derived from the ASN.1 type names and identifiers present in an ASN.1 specification.

Instances of XML value notation can appear in an ASN.1 module and are suitable for display in an XML-enabled browser. This feature has been added as a new value notation for ASN.1 types in the 2002 edition of the base ASN.1 standard (ITU-T X.680 | ISO/IEC 8824-1 ).

The XML value notation is also the base for a new set of encoding rules for ASN.1, the "XML Encoding Rules" (XER), published as a new standard (ITU-T X.693 | ISO/IEC 8825-4). Except for a few minor differences (such as the addition of a prolog), the XML produced by the XML Encoding Rules is the same as the XML value notation. Both a canonical (called CXER and used, e.g., for digital signatures) and a non-canonical variant of the XML Encoding Rules have been defined.

To vary the XML encoding produced by default by a Basic-XER tool, XER encoding instructions can be added to the ASN.1 modules in two forms: either as prefix notation in front of types (in the same way as BER encoding instructions are added as tags in front of types) or as an encoding control section at the end of the ASN.1 module. The encoding is then called EXTENDED-XER or E-XER.

There are XER encoding instructions for:

• attributes vs. elements;
• mixed content;
• variable-order sequences (those marked with "*" in an XML Schema and consisting in a group of elements whose order in the instance doesn't matter);
• removing wrappers around multiple occurrences of things;
• CHOICEs corresponding to XSD type derivation hierarchies;
• CHOICEs corresponding to XSD element substitution groups;
• CHOICEs corresponding to XSD unions;
• SEQUENCE OFs corresponding to XSD lists;
• support of wildcards;
• and so on.

All these features are supported by an XER-specific notation in the ASN.1 schema, which affects EXTENDED-XER encodings but does not affect BER/DER/PER encodings.

One of the main objectives of this XML-related work is to allow ASN.1 specifications (modules) to be used as ASN.1 schemas against which XML documents can be validated. As a result, the ASN.1 language now competes with other XML schema languages such as XML Schema and RELAX NG , but it has some additional benefits over them.

ASN.1 is seen as a notation that has significant advantages over other XML schema notations in both the simplicity of the notation and the ease of mapping it to C, C++ and Java data structures that can enable the rapid implementations of applications to support (XML and other) communications defined using that notation.

The ease of such mappings is due to its clear specification of the abstract values that ASN.1-defined messages can contain, rather than concern solely with the syntactic (XML or binary) form of such messages, which other schema definition notations (or use of ABNF) are primarily concerned with.

Protocols specified in ASN.1 can take advantage of the compact standardized ASN.1 encodings (such as the Packed Encoding Rules) to exchange messages over bandwidth-constrained links, but the same abstract data can be encoded in XML with no effort and sent to an XML-enabled browser for display (possibly using style sheets).

BER- or PER-generated messages described by ASN.1 are a small fraction of the size of XML messages. This enables content-rich Web pages, video and other data-intensive messages to travel where it might not otherwise be able to go, namely, the narrow confines of wireless broadband.

The application of security functions to ASN.1-defined data is well-established, and the lack of repetitive text sequences, and avoidance of redundancy and general text orientation in its Packed Encoding Rules (PER) make non-disclosure functions much less vulnerable to attack than direct encryption of XML text.