Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4910

Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)

Pages: 80
Experimental
Part 4 of 4 – Pages 60 to 80
First   Prev   None

Top   ToC   RFC4910 - Page 60   prevText

6.9. Open Type

A value of an open type denoted by an ObjectClassFieldType [X.681] is translated according to the specific Type of the value. If the specific Type of the value is directly or indirectly the Markup type, then the enclosing element item MUST be self-contained. For a non-canonical RXER encoding, if the translation of the value does not generate an attribute item with the [local name] "type" and the [namespace name] "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type) and the specific Type of the value is a
Top   ToC   RFC4910 - Page 61
   namespace-qualified reference (Section 5), then an attribute item
   with the [local name] "type" and the [namespace name]
   "http://www.w3.org/2001/XMLSchema-instance" (i.e., xsi:type) MAY be
   added to the [attributes] of the enclosing element item.  The
   [normalized value] of this attribute item is a qualified name for the
   expanded name of the referenced type, with the namespace prefix
   determined as specified in Section 6.7.11.1.

      Aside: The xsi:type attribute is added by RXER encoders for the
      benefit of XML Schema validators.  This attribute tells an
      XML Schema validator which type definition in a compatible
      XML Schema translation of the ASN.1 specification it should use
      for validating the content and attributes of the enclosing
      element.  For an RXER decoder, the actual type in an open type
      value is generally determined by an associated component relation
      constraint [X.682], so the xsi:type attribute can be ignored.

   Example

      The content and attributes of the following <value> element are
      the RXER encoding of an open type value containing a BOOLEAN
      value:

         <value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                xsi:type="asnx:BOOLEAN"> true </value>

   If the ObjectClassFieldType denoting an open type is not constrained
   by a TableConstraint, or is constrained by a TableConstraint where
   the constraining object set is extensible, then an application MUST
   accept and be prepared to re-encode (using the same encoding rules)
   any value of the open type where the specific Type of the value is
   unknown.  In such cases, the enclosing element item is treated like
   an unknown element item in the value of an extensible combining ASN.1
   type (see Section 6.8.8.1).

6.10. Markup

Conceptually, a value of the Markup type holds the [prefix], [attributes], [namespace attributes], and [children] of an element item. The Infoset translation of a value of the Markup type initially simply sets the [prefix], [attributes], [namespace attributes], and [children] of the enclosing element item to the corresponding properties represented by the Markup value. Recall that the enclosing element item for the translation of a Markup value is required to be self-contained (Section 4.1.1).
Top   ToC   RFC4910 - Page 62
   If the enclosing element item is not the [document element] of the
   document item, and the [in-scope namespaces] property of the
   enclosing element item's [parent] contains a namespace item for the
   default namespace, and the [namespace attributes] property
   represented by the Markup value does not contain a namespace item
   declaring or undeclaring the default namespace, then a namespace
   declaration attribute item that undeclares the default namespace
   SHALL be added to the enclosing element item's
   [namespace attributes].

   It is not necessary to populate the [in-scope namespaces] of the
   enclosing element item for encoding purposes (though it may be
   warranted for other purposes).

   An element item nested in the [children] is potentially the Infoset
   translation of a value of a top-level NamedType (as allowed by
   Section 6.4), and the entire Markup value can represent the content
   and attributes of an element item that is the translation of a value
   of a top-level NamedType.

      Aside: The latter case arises when an ELEMENT-REF encoding
      instruction references a top-level NamedType.

   The content and attributes of an element item nested in the
   [children] of a Markup value are potentially the Infoset translation
   of an abstract value of an ASN.1 type (as allowed by Section 6.4),
   and the entire Markup value can represent the translation of a single
   abstract value.

      Aside: The latter case arises when a TYPE-REF encoding instruction
      references an ASN.1 type.

   For a non-canonical RXER encoding, any element item, at any level of
   nesting (including the enclosing element item itself), that
   corresponds to the value of a top-level NamedType MAY be replaced
   with any valid translation of that value.

   For a non-canonical RXER encoding, any element item, at any level of
   nesting (including the enclosing element item itself), with content
   and attributes that correspond to an abstract value of an ASN.1 type
   MAY have that content and those attributes replaced with any valid
   translation of that abstract value.  If the content and attributes
   are replaced, then the [prefix], [in-scope namespaces], and
   [namespace attributes] of the element item are constructed as
   specified in Sections 6.2.2.1 and 6.2.2.2.  The enclosing element
   item for the Markup value is still required to be self-contained.
Top   ToC   RFC4910 - Page 63
      Aside: Insofar as a Markup value represents ASN.1 abstract values,
      it is sufficient for the RXER encoding of the Markup value to
      preserve the abstract values rather than preserve the exact
      Infoset representation.

   For a CRXER encoding, any element item, at any level of nesting
   (including the enclosing element item itself), that corresponds to a
   value of a top-level NamedType MUST be replaced with the CRXER
   translation of that value.

   For a CRXER encoding, any element item, at any level of nesting
   (including the enclosing element item itself), with content and
   attributes that correspond to an abstract value of an ASN.1 type MUST
   have that content and those attributes replaced with the CRXER
   translation of that abstract value.  The [prefix],
   [in-scope namespaces], and [namespace attributes] of the element item
   are constructed as specified in Sections 6.2.2.1 and 6.2.2.2.

   If the [attributes] property of the enclosing element item from a
   received RXER encoding contains an attribute item with the
   [local name] "context" and [namespace name]
   "urn:ietf:params:xml:ns:asnx" (i.e., asnx:context), then this
   attribute item MUST be omitted from the [attributes] represented by
   the Markup value, and each namespace declaration attribute item with
   a [local name] matching an NCName in the [normalized value] of the
   attribute item MUST be omitted from the [namespace attributes]
   represented by the Markup value.

6.11. Namespace Prefixes for CRXER

The final step in translating the value of a top-level NamedType for a CRXER encoding, or an abstract value for a Standalone CRXER Encoding, is the replacement of the arbitrarily chosen namespace prefixes with algorithmically determined canonical namespace prefixes. This procedure for prefix replacement applies to each element item where the [namespace attributes] have been constructed according to Section 6.2.2.1. This includes any element item corresponding to a value of a top-level NamedType, or with content and attributes that correspond to an abstract value of an ASN.1 type, that is nested in a value of the Markup type. For each element item where prefix replacement applies, the following sequence of steps is repeated until there are no more eligible attribute items to select in step (1):
Top   ToC   RFC4910 - Page 64
   (1) Select the attribute item with the least [normalized value] from
       amongst the attribute items of the [namespace attributes] that
       have a [local name] that is not a canonical namespace prefix
       (i.e., select from the namespace declaration attribute items that
       have not already been processed).  A [normalized value] is less
       than another [normalized value] if the former appears before the
       latter in an ordering of the values determined by comparing the
       ISO 10646 code points [UCS] of their characters, from first to
       last.  A shorter string of characters is ordered before a longer
       string of characters that is identical up to the length of the
       shorter string.

          Aside: Note that when a namespace declaration (other than for
          the default namespace) is represented as an attribute item in
          the [namespace attributes], the attribute's [prefix] is
          "xmlns", its [local name] is the namespace prefix, and its
          [normalized value] is the namespace name.

   (2) A canonical namespace prefix is unused if it is not currently the
       [prefix] of any namespace item in the [in-scope namespaces] of
       the element item.  Replace the [local name] of the selected
       attribute item with the unused canonical namespace prefix that
       has the non-negative number string with the least integer value
       (e.g., n2 is less than n10).

   (3) The selected attribute item has a corresponding namespace item in
       the [in-scope namespaces] of the element.  Replace the [prefix]
       of this corresponding namespace item with the canonical namespace
       prefix determined in step (2).

   (4) The element item and its [attributes] property, and descendent
       element items and their [attributes] properties, may depend on
       the selected attribute item to determine the binding between
       their [prefix] and [namespace name].  Replace the [prefix] of any
       such dependent element items and attribute items with the
       canonical namespace prefix determined in step (2).

       Note that a namespace prefix can be redeclared (reused).
       Replacement of the prefix does not apply to an element item
       wherein the prefix is redeclared, or to the descendants of such
       an element item.

   (5) The character data translations for values of the QName ASN.1
       type may depend on the selected attribute item to determine the
       binding between their namespace prefix and namespace name.
       Replace the namespace prefix of any such dependent character data
       translation with the canonical namespace prefix determined in
       step (2).
Top   ToC   RFC4910 - Page 65
       Note that a character data translation can appear in the
       [normalized value] of an attribute item, or as a sequence of
       character items in the [children] of an element item.

6.12. Serialization

The final RXER encoding is produced by serializing the Infoset translation as an XML document. An implementation MUST serialize the Infoset translation as an XML document in such a way that the Infoset of the resulting XML document matches the Infoset translation, after ignoring the following properties: (1) all properties of the document item except the [document element], (2) the [base URI] of any item, (3) the [element content whitespace] of character items, (4) the [notation] of processing instruction items, (5) the [in-scope namespaces] of element items. Aside: The [in-scope namespaces] of a parent element item are only selectively inherited by its child element items in the Infoset translations of ASN.1 values. This means that the Infoset reconstructed by parsing the XML document serialization of the original Infoset will generally have more namespace items in its [in-scope namespaces], but these extra namespace items will not be significant. Aside: A consequence of case (1) is that comments and PIs before and after the document element are permitted. In general, there is more than one possible serialization for any given Infoset translation. Section 6.12.1 highlights some important considerations in producing a correct serialization and discusses some of the serialization options. Section 6.12.2 applies to CRXER encodings and limits the serialization options so that each distinct Infoset has only one possible serialization.

6.12.1. Non-Canonical Serialization

This section discusses aspects of Infoset serialization for non-canonical RXER encodings, but is not an exhaustive list of the options for non-canonical serialization.
Top   ToC   RFC4910 - Page 66
   If one or more character items have a [character code] in the range
   U+0001 to U+0008, U+000B to U+000C, or U+000E to U+001F, or one or
   more characters in any attribute's [normalized value] are in the
   range U+0001 to U+0008, U+000B to U+000C, or U+000E to U+001F, then
   the Infoset translation MUST be serialized as an XML version 1.1
   document; otherwise, the Infoset translation is serialized as either
   an XML version 1.0 or version 1.1 document.

   A non-canonical RXER encoding may use any of the allowed character
   encoding schemes for XML.  RXER encoders and decoders MUST support
   the UTF-8 character encoding.

   An element item may be serialized as an empty-element tag if it has
   no items in its [children].

   Attributes of an element can appear in any order since the
   [attributes] and [namespace attributes] of an element item are
   unordered.

   Ampersand ('&', U+0026) and open angle bracket ('<', U+003C)
   characters in the [normalized value] of an attribute item must be
   escaped appropriately [XML10][XML11] (with a character reference or a
   predefined entity reference).  Double quote (U+0022) and single quote
   (U+0027) characters in an attribute item's [normalized value] may
   also need to be escaped.  Character items with the [character code]
   U+0026 (ampersand, '&') or U+003C (open angle bracket, '<') must be
   escaped appropriately (with a character reference, a predefined
   entity reference or a CDATA section).

   Line break normalization by XML processors allows some freedom in how
   a character item for a line feed character (U+000A) is serialized:

   (1) If XML version 1.0 is selected, then a character item with the
       [character code] U+000A (line feed) is serialized as either a
       line feed character (U+000A), a carriage return character
       (U+000D) followed by a line feed character (U+000A), or just a
       carriage return character (U+000D) provided the next item is not
       a character item that is serialized as a line feed character
       (U+000A).

   (2) If XML version 1.1 is selected, then a character item with the
       [character code] U+000A (line feed) is serialized as either a
       line feed character (U+000A), a next line character (U+0085), a
       line separator character (U+2028), a carriage return character
       (U+000D) followed by a line feed character (U+000A), a carriage
       return character (U+000D) followed by a next line character
Top   ToC   RFC4910 - Page 67
       (U+0085), or just a carriage return character (U+000D) provided
       the next item is not a character item that is serialized as a
       line feed (U+000A) or next line (U+0085) character.

         Aside: All these sequences will be normalized to a line feed
         character (U+000A) during decoding.

   A character item with the [character code] U+000D (carriage return),
   U+0085 (next line), or U+2028 (line separator) must be serialized as
   a character reference to protect the character from line break
   normalization during decoding.

   The attribute value normalization performed by XML processors allows
   some freedom in how a space character (U+0020) is serialized:

   (1) If XML version 1.0 is selected, then a space character (U+0020)
       in an attribute item's [normalized value] is serialized as either
       a space character (U+0020), a tab character (U+0009), a carriage
       return character (U+000D), a line feed character (U+000A), a
       carriage return character (U+000D) followed by a line feed
       character (U+000A), or just a carriage return character (U+000D)
       provided the next character in the [normalized value] is not
       serialized as a line feed character (U+000A).

   (2) If XML version 1.1 is selected, then a space character (U+0020)
       in an attribute item's [normalized value] is serialized as either
       a space character (U+0020), a tab character (U+0009), a carriage
       return character (U+000D), a line feed character (U+000A), a next
       line character (U+0085), a line separator character (U+2028), a
       carriage return character (U+000D) followed by a line feed
       character (U+000A), a carriage return character (U+000D) followed
       by a next line character (U+0085), or just a carriage return
       character (U+000D) provided the next character in the
       [normalized value] is not serialized as a line feed (U+000A) or
       next line (U+0085) character.

          Aside: All these sequences will be normalized to a space
          character (U+0020) during decoding, through a combination of
          line break normalization and attribute value normalization.

   Each tab (U+0009), line feed (U+000A), or carriage return (U+000D)
   character in an attribute item's [normalized value] must be
   serialized as a character reference to protect the character from
   attribute value normalization during decoding.  In addition, if XML
   version 1.1 is selected, then each next line (U+0085) or line
   separator (U+2028) character must be serialized as a character
   reference.
Top   ToC   RFC4910 - Page 68
   Parsed entity references may be used (unless the environment in which
   the RXER encoding is used disallows entity references).  If entity
   references to other than the predefined entities are used, then the
   XML document containing the RXER encoding must necessarily contain a
   document type declaration, and the internal or external subset of the
   document type definition must contain entity declarations for those
   entities.

6.12.2. Canonical Serialization

This section discusses Infoset serialization for CRXER encodings. The serialization of an Infoset for a CRXER encoding is restricted so that each distinct Infoset has only one possible serialization as an XML document. Aside: These restrictions have been chosen so as to be consistent with Canonical XML [CXML], where possible. The document SHALL be encoded in UTF-8 without a leading Byte Order Mark [UCS]. The XMLDecl of the document SHALL be <?xml version="1.1"?>. A document type declaration (doctypedecl) SHALL NOT be used. Aside: This has the effect of excluding entity references, except those for the predefined entities (e.g., &amp;). A single line feed character (U+000A) MUST be inserted immediately before the document element. No other white space characters are permitted before or after the document element. There SHALL NOT be any PIs or comments before or after the document element. An element item MUST NOT be serialized as an empty-element tag. Aside: If an element item has no items in its [children], then it is serialized as a start-tag followed by an end-tag. There SHALL NOT be any white space characters immediately before the closing '>' of an element's start-tag and end-tag. The white space preceding each attribute SHALL be exactly one space character (U+0020). There SHALL NOT be any white space characters immediately before or after the equals sign (U+003D) in an attribute.
Top   ToC   RFC4910 - Page 69
   The delimiter for attribute values SHALL be the double quote
   character (U+0022).

   Namespace declaration attributes MUST appear before any other
   attributes of an element.  A namespace declaration for the default
   namespace, if present, MUST appear as the first attribute.  The
   remaining namespace declaration attributes MUST appear in
   lexicographic order based on [local name].

      Aside: In particular, this means that xmlns:n10 comes before
      xmlns:n2.

   The attributes that are not namespace declarations MUST be
   lexicographically ordered on [namespace name] as the primary key and
   [local name] as the secondary key.

   CDATA sections SHALL NOT be used.

   Each ampersand character ('&', U+0026) in an attribute item's
   [normalized value] MUST be serialized as the entity reference &amp;.
   Each open angle bracket character ('<', U+003C) in an attribute
   item's [normalized value] MUST be serialized as the entity reference
   &lt;.  Each double quote character (U+0022) in an attribute item's
   [normalized value] MUST be serialized as the entity reference &quot;.
   Each character in the range U+0001 to U+001F or U+007F to U+009F in
   an attribute item's [normalized value] MUST be serialized as a
   character reference.  No other character in a [normalized value] is
   permitted to be serialized as an entity reference or character
   reference.

   Each character item with the [character code] U+0026 (the ampersand
   character) MUST be serialized as the entity reference &amp;.  Each
   character item with the [character code] U+003C (the open angle
   bracket character) MUST be serialized as the entity reference &lt;.
   Each character item with the [character code] U+003E (the closing
   angle bracket character) MUST be serialized as the entity reference
   &gt;.  Each character item with a [character code] in the range
   U+0001 to U+0008, U+000B to U+001F, or U+007F to U+009F MUST be
   serialized as a character reference.  No other character item is
   permitted to be serialized as an entity reference or character
   reference.

   Character references, where they are permitted, SHALL use uppercase
   hexadecimal with no leading zeroes.  For example, the carriage return
   character is represented as &#xD;.

   A space character (U+0020) in an attribute item's [normalized value]
   MUST be serialized as a single U+0020 character.
Top   ToC   RFC4910 - Page 70
   A character item with the [character code] U+000A MUST be serialized
   as a single U+000A character.

   The white space separating the [target] and [content] in the
   serialization of a processing instruction item SHALL be exactly one
   space character (U+0020).

      Aside: A processing instruction or comment can only appear in a
      CRXER encoding if it is embedded in a Markup value.

6.12.3. Unicode Normalization in XML Version 1.1

XML Version 1.1 recommends, but does not absolutely require, that text be normalized according to Unicode Normalization Form C [UNICODE]. ASN.1 has no similar requirement on abstract values of string types, and ASN.1 canonical encoding rules depend on the code points of characters being preserved. To accommodate both requirements, applications SHOULD normalize abstract values of ASN.1 character string types according to Unicode Normalization Form C at the time the values are created, but MUST NOT normalize a previously decoded abstract value of an ASN.1 character string type prior to re-encoding it. An application may, of course, normalize a decoded abstract value for other purposes, such as display to a user.

6.13. Syntax-Based Canonicalization

ASN.1 encoding rules are designed to preserve abstract values, but not to preserve every detail of each transfer syntax that is used. In the case of RXER, this means that the Infoset representation of an abstract value is not necessarily preserved when the abstract value is decoded and re-encoded (regardless of the encoding rules used). However, syntax-based canonicalization for XML documents (e.g., Canonical XML [CXML]) depends on the Infoset of an XML document being preserved. The Infoset representation of an XML document containing the RXER encoding of an ASN.1 abstract value potentially changes if that value is decoded and re-encoded, disrupting the Canonical XML representation. Extra normalization is required if RXER is to be usefully deployed in environments where syntax-based canonicalization is used. Prior to applying syntax-based canonicalization to an XML document, any element items in the Infoset representation of the document that correspond to the value of an ASN.1 top-level NamedType or have content and attributes that correspond to an ASN.1 abstract value MUST be replaced by the translation of the value according to CRXER.
Top   ToC   RFC4910 - Page 71
   If an application uses Canonical XML but has no knowledge of RXER,
   then it will not know to normalize RXER encodings.  If RXER is
   deployed into an environment containing such applications, then the
   Infoset translation for CRXER SHOULD be used for all RXER encodings.

7. Transfer Syntax Identifiers

7.1. RXER Transfer Syntax

The following OBJECT IDENTIFIER has been assigned by xmled.org to identify the Robust XML Encoding Rules, under an arc assigned to xmled.org by the Internet Assigned Numbers Authority (IANA): { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) asnx(1) encoding(1) rxer(0) } This OBJECT IDENTIFIER would be used, for example, to describe the transfer syntax for an RXER encoded data-value in an EMBEDDED PDV value.

7.2. CRXER Transfer Syntax

The following OBJECT IDENTIFIER has been assigned by xmled.org to identify the Canonical Robust XML Encoding Rules, under an arc assigned to xmled.org by the IANA: { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) asnx(1) encoding(1) crxer(1) } This OBJECT IDENTIFIER would be used, for example, to describe the transfer syntax for a CRXER encoded data-value in an EMBEDDED PDV value.

8. Relationship to XER

The Robust XML Encoding Rules (RXER) and the XML Encoding Rules (XER) [X.693] are separate, distinctly different and incompatible ASN.1 encoding rules for producing XML markup from ASN.1 abstract values. RXER is therefore unrelated to the XML value notation of X.680 [X.680]. This section describes some of the major differences between RXER and XER.
Top   ToC   RFC4910 - Page 72
   There are essentially two varieties of XER:  BASIC-XER (with a
   canonical form called CANONICAL-XER) and EXTENDED-XER.  The
   significant difference between the two varieties is that XER encoding
   instructions are used by EXTENDED-XER, but are ignored by BASIC-XER
   (and therefore by CANONICAL-XER).  There isn't a canonical variant of
   EXTENDED-XER.  Characteristics that are common to BASIC-XER and
   EXTENDED-XER will simply be noted as being characteristics of XER.

   Elements and attributes are the fundamental discrete structures of an
   XML document.  Not surprisingly, schema languages for XML typically
   have the means to describe, name, and reference global (i.e.,
   top-level) elements and attributes.  Global type definitions are seen
   more as a convenience for defining the contents of elements and
   attributes.  Traditional ASN.1 has the means to define global types
   (and other global constructs that support the definition of types)
   but nothing akin to a global element or attribute definition.  The
   fundamental difference between RXER and XER is in how this omission
   is addressed.

   With XER, type definitions are also regarded as being element
   definitions by default, or as attribute definitions in the presence
   of an XER ATTRIBUTE encoding instruction.  In some circumstances an
   anonymous Type is required to define an element, which leads to
   element names like <BOOLEAN> and <SEQUENCE>.  NamedType notation also
   defines local elements, and there are some curious cases in
   EXTENDED-XER where NamedType notation can define a global type.  So
   under XER, types can be defined by either Type or NamedType notation,
   and elements and attributes can also be defined by either Type or
   NamedType notation.

   With RXER, types are only defined by Type notation and elements and
   attributes are only defined by NamedType notation.  Global element
   and attribute definitions are made possible by top-level NamedType
   notation in an RXER encoding control section.

   RXER, with its clean separation of Type notation for types and
   NamedType notation for elements and attributes, is a better basis
   than XER for translating an ASN.1 specification into an XML
   representation (i.e., ASN.X [ASN.X]) or a compatible XML Schema,
   where type, element, and attribute definitions are also distinctly
   separate constructs.

   There is usually a requirement on applications specified in ASN.1 to
   maintain backward compatibility with the encodings generated by
   previous versions.  The encodings in question are typically BER.
   Even with the backward-compatibility constraint there is still
   considerable leeway for specification writers to rewrite the earlier
   specification.  For example, they could rename types, factor out an
Top   ToC   RFC4910 - Page 73
   in-line type definition as a defined type (or the reverse), or
   replace a type definition with an equivalent parameterized reference.
   These changes produce no change to BER, DER, CER [X.690], Packed
   Encoding Rules (PER) [X.691], or Generic String Encoding Rules (GSER)
   [GSER] encodings (so specification writers have felt free to make
   such changes to improve their specification), but can change the
   names of elements in the XER encoding because XER uses types as
   element definitions.  The RXER encoding is immune to this problem,
   thus RXER encodings are more stable than XER encodings over
   successive revisions of an ASN.1 specification (which explains the
   first 'R' in RXER).  This has an obvious benefit for
   interoperability.

   RXER has special provisions for encoding values of the QName and
   Markup types.  QName is used to hold qualified names and Markup can
   be used to hold arbitrary untyped markup.  XER doesn't recognize any
   special types like these, but it is possible to get the same effects
   as RXER's QName and Markup types by using XER encoding instructions.
   Since CANONICAL-XER ignores encoding instructions, this means that
   under XER an application can either support qualified names and
   untyped markup, or support canonical XML encodings, but not both.  In
   contrast, CRXER has canonicalization rules for qualified names and
   for Markup.  Furthermore, EXTENDED-XER does not address the issues of
   normalization of untyped data for other ASN.1 canonical encoding
   rules (e.g., for DER; see Section 4.1.2) or normalization of XML
   encodings for syntax-based canonicalization (e.g., for Canonical XML;
   see Section 6.13).

   Both EXTENDED-XER and RXER use encoding instructions to define
   attributes, union types, and list types, among other things.  Since
   CANONICAL-XER ignores encoding instructions, this means that under
   XER an application must choose between making use of attributes,
   union types, list types, etc., or supporting canonical XML encodings.
   In contrast, the canonicalization rules for CRXER encompass all the
   encoding instructions for RXER.

9. Security Considerations

RXER does not necessarily enable the exact BER octet encoding of values of the TeletexString, VideotexString, GraphicString, or GeneralString types to be reconstructed, so a transformation from DER to RXER and back to DER may not reproduce the original DER encoding. This is a result of inadequate normalization of values of these string types in DER. A character in a TeletexString value (for example) that corresponds to a specific ISO 10646 character can be encoded for BER in a variety of ways that are indistinguishable in an
Top   ToC   RFC4910 - Page 74
   RXER re-encoding of the TeletexString value.  DER does not mandate
   one of these possible character encodings in preference to all
   others.

   Because of the above, RXER MUST NOT be used to re-encode, whether for
   storage or transmission, ASN.1 abstract values whose original DER or
   CER encoding must be recoverable, and whose type definitions involve
   the TeletexString, VideotexString, GraphicString, or GeneralString
   type.  Such recovery is needed for the verification of digital
   signatures.  In such cases, protocols ought to use DER or a DER-
   reversible encoding.  In other cases where ASN.1 canonical encoding
   rules are used, values of the Markup type must be normalized as
   described in Section 4.1.2.

   A transformation from CRXER to BER and back to CRXER does reproduce
   the original CRXER encoding, therefore it is safe to use BER, DER, or
   CER to re-encode ASN.1 abstract values whose original CRXER encoding
   must be recoverable.

   Digital signatures may also be calculated on the Canonical XML
   representation of an XML document.  If RXER encodings appear in such
   documents, then applications must normalize the encodings as
   described in Section 6.13.

   The null character (U+0000) cannot be represented in XML and hence
   cannot be transmitted in an RXER encoding.  Null characters in
   abstract values of ASN.1 string types will be dropped if the values
   are RXER encoded; therefore, RXER MUST NOT be used by applications
   that attach significance to the null character.

   When interpreting security-sensitive fields, and in particular fields
   used to grant or deny access, implementations MUST ensure that any
   comparisons are done on the underlying abstract value, regardless of
   the particular encoding used.  Comparisons of Markup values MUST
   operate as though the values have been normalized as specified in
   Section 4.1.2.

10. Acknowledgements

The technology described in this document is the product of a research project begun jointly by Adacel Technologies Limited and Deakin University, and subsequently refined and completed by eB2Bcom.
Top   ToC   RFC4910 - Page 75

11. IANA Considerations

The IANA has registered a new XML namespace in accordance with RFC 3688 [XMLREG]. URI: urn:ietf:params:xml:ns:asnx Registrant Contact: Steven Legg <steven.legg@eb2bcom.com> XML: None

12. References

12.1. Normative References

[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [XMLREG] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RXEREI] Legg, S., "Encoding Instructions for the Robust XML Encoding Rules (RXER)", RFC 4911, July 2007. [ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912, July 2007. [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) | ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER. [X.681] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification. [X.682] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3, Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification.
Top   ToC   RFC4910 - Page 76
   [X.683]    ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4,
              Information technology - Abstract Syntax Notation One
              (ASN.1):  Parameterization of ASN.1 specifications.

   [X.690]    ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).

   [UCS]      ISO/IEC 10646-1:2000, Information technology - Universal
              Multiple-Octet Coded Character Set (UCS) - Part 1:
              Architecture and Basic Multilingual Plane.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              4.0", Boston, MA, Addison-Wesley Developers Press, 2003.
              ISBN 0-321-18578-1.

   [XML10]    Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
              Edition)", W3C Recommendation,
              http://www.w3.org/TR/2006/REC-xml-20060816, August 2006.

   [XML11]    Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
              Yergeau, F., and J. Cowan, "Extensible Markup Language
              (XML) 1.1 (Second Edition)", W3C Recommendation,
              http://www.w3.org/TR/2006/REC-xml11-20060816, August 2006.

   [XMLNS10]  Bray, T., Hollander, D., Layman, A., and R. Tobin,
              "Namespaces in XML 1.0 (Second Edition)", W3C
              Recommendation,
              http://www.w3.org/TR/2006/REC-xml-names-20060816, August
              2006.

   [XMLNS11]  Bray, T., Hollander, D., Layman, A. and R. Tobin,
              "Namespaces in XML 1.1 (Second Edition)", W3C
              Recommendation,
              http://www.w3.org/TR/2006/REC-xml-names11-20060816, August
              2006.

   [INFOSET]  Cowan, J. and R. Tobin, "XML Information Set (Second
              Edition)", W3C Recommendation,
              http://www.w3.org/TR/2004/REC-xml-infoset-20040204,
              February 2004.
Top   ToC   RFC4910 - Page 77
   [XSD1]     Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition", W3C
              Recommendation,
              http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/,
              October 2004.

12.2. Informative References

[GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003. [X.691] ITU-T Recommendation X.691 (07/02) | ISO/IEC 8825-4:2002, Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). [X.693] ITU-T Recommendation X.693 (12/01) | ISO/IEC 8825-4:2002, Information technology - ASN.1 encoding rules: XML encoding rules (XER). [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, October 2004. [CXML] Boyer, J., "Canonical XML Version 1.0", W3C Recommendation, http://www.w3.org/TR/2001/REC-xml-c14n-20010315, March 2001.
Top   ToC   RFC4910 - Page 78

Appendix A. Additional Basic Definitions Module

This appendix is normative. AdditionalBasicDefinitions { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) asnx(1) module(0) basic(0) } -- Copyright (C) The IETF Trust (2007). This version of -- this ASN.1 module is part of RFC 4910; see the RFC itself -- for full legal notices. -- -- Regarding this ASN.1 module or any portion of it, the authors -- make no guarantees and are not responsible for any damage -- resulting from its use. The authors grant irrevocable permission -- to anyone to use, modify, and distribute it in any way that does -- not diminish the rights of anyone else to use, modify, and -- distribute it, provided that redistributed derivative works do -- not contain misleading author or version information. -- Derivative works need not be licensed under similar terms. DEFINITIONS RXER INSTRUCTIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::= BEGIN Markup ::= CHOICE { text SEQUENCE { prolog UTF8String (SIZE(1..MAX)) OPTIONAL, prefix NCName OPTIONAL, attributes UTF8String (SIZE(1..MAX)) OPTIONAL, content UTF8String (SIZE(1..MAX)) OPTIONAL } } AnyURI ::= UTF8String (CONSTRAINED BY { -- conforms to the format of a URI -- }) NCName ::= UTF8String (CONSTRAINED BY { -- conforms to the NCName production of -- Namespaces in XML 1.0 -- }) Name ::= UTF8String (CONSTRAINED BY { -- conforms to the Name production of XML -- })
Top   ToC   RFC4910 - Page 79
   QName ::= SEQUENCE {
       namespace-name  AnyURI OPTIONAL,
       local-name      NCName
   }

   ENCODING-CONTROL RXER

       TARGET-NAMESPACE "urn:ietf:params:xml:ns:asnx" PREFIX "asnx"

       COMPONENT context [ATTRIBUTE] [LIST] SEQUENCE OF prefix NCName

   END

Authors' Addresses

Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com Dr. Daniel Prager EMail: dap@austhink.com
Top   ToC   RFC4910 - Page 80
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.