6.7.  Character Data Translations

   For the majority of ASN.1 built-in types, encodings of values of
   those types never have element content.  The encoding of a value of
   an ASN.1 combining type (except a UNION or LIST type) typically has
   element content.

   For those types that do not produce element content, the translation
   of an abstract value is described as a character string of ISO 10646
   characters [UCS].  This character data translation will be destined
   to become either part of the [normalized value] of an attribute item,
   or a series of character items in the [children] of an element item
   (which becomes the [parent] for the character items).  The case that
   applies is determined in accordance with Section 6.2.

   For a non-canonical RXER encoding, if the type of the abstract value
   is not directly or indirectly a restricted character string type, the
   NULL type, or a UNION type, then leading and/or trailing white space
   characters MAY be added to the character data translation.

      Aside: White space characters are significant in the encoding of a
      value of a restricted character string type, and a restricted
      character string type can be a member type of a UNION type.  The
      encoding of a NULL value produces no character data.

      Aside: Optional white space characters are not permitted in a
      CRXER encoding.

   For a non-canonical RXER encoding, if the type of the abstract value
   is directly or indirectly the AnyURI, NCName, or Name type, then
   leading and trailing white space characters MAY be added to the
   character data translation.

      Aside: These types are indirectly a restricted character string
      type (UTF8String); however, their definitions exclude white space
      characters, so any white space characters appearing in an encoding
      are not part of the abstract value and can be safely ignored.
      This exception does not apply to other subtypes of a restricted
      character string type that happen to exclude white space
      characters.

6.7.1.  Restricted Character String Types

   The character data translation of a value of a restricted character
   string type is the sequence of characters in the string.

   Depending on the ASN.1 string type, and an application's internal
   representation of that string type, a character may need to be
   translated to or from the equivalent ISO 10646 character code [UCS].
   The NumericString, PrintableString, IA5String, VisibleString
   (ISO646String), BMPString, UniversalString, and UTF8String character
   encodings use the same character codes as ISO 10646.  For the
   remaining string types (GeneralString, GraphicString, TeletexString,
   T61String, and VideotexString), see X.680 [X.680].

   The null character (U+0000) is not a legal character for XML.  It is
   omitted from the character data translation of a string value.

   Certain other control characters are legal for XML version 1.1, but
   not for version 1.0.  If any string value contains these characters,
   then the RXER encoding must use XML version 1.1 (see Section 6.12).

   All white space characters in the RXER encoding of a value of a
   restricted character string type (excluding the AnyURI, NCName, and
   Name subtypes) are significant, i.e., part of the abstract value.

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of an IA5String value:

         <value> Don't run with scissors! </value>

         <value>Markup (e.g., &lt;value&gt;) has to be escaped.</value>

         <value>Markup (e.g., <![CDATA[<value>]]>)
         has to be escaped. </value>

6.7.2.  BIT STRING

   The character data translation of a value of the BIT STRING type is
   either a binary digit string, a hexadecimal digit string, or a list
   of bit names.

   A binary digit string is a sequence of zero, one, or more of the
   binary digit characters '0' and '1' (i.e., U+0030 and U+0031).  Each
   bit in the BIT STRING value is encoded as a binary digit in order
   from the first bit to the last bit.

   For a non-canonical RXER encoding, if the BIT STRING type has a
   NamedBitList, then trailing zero bits MAY be omitted from a binary
   digit string.

   A hexadecimal digit string is permitted if and only if the number of
   bits in the BIT STRING value is zero or a multiple of eight and the
   character data translation is destined for the [children] of an
   element item.

   A hexadecimal digit string is a sequence of zero, one, or more pairs
   of the hexadecimal digit characters '0'-'9', 'A'-'F', and 'a'-'f'
   (i.e., U+0030-U+0039, U+0041-U+0046 and U+0061-U+0066).  Each group
   of eight bits in the BIT STRING value is encoded as a pair of
   hexadecimal digits where the first bit is the most significant.  An
   odd number of hexadecimal digits is not permitted.  The characters
   'a'-'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding
   of a BIT STRING value.  If a hexadecimal digit string is used, then
   the enclosing element's [attributes] MUST contain an attribute item
   with the [local name] "format", the [namespace name]
   "urn:ietf:params:xml:ns:asnx", and the [normalized value] "hex"
   (i.e., asnx:format="hex").  The [prefix] of the attribute item is
   determined as specified in Section 6.2.3.1.

      Aside: The hexadecimal digit string is intended to conform to the
      lexical representation of the XML Schema [XSD2] hexBinary data
      type.

   For a non-canonical RXER encoding, if the preconditions for using a
   hexadecimal digit string are satisfied, then a hexadecimal digit
   string MAY be used.

   A list of bit names is permitted if and only if the BIT STRING type
   has a NamedBitList and each '1' bit in the BIT STRING value has a
   corresponding identifier in the NamedBitList.

      Aside: ASN.1 does not require that an identifier be assigned for
      every bit.

   A list of bit names is a sequence of names for the '1' bits in the
   BIT STRING value, in any order, each separated from the next by at
   least one white space character.  If the BitStringType is not subject
   to a VALUES encoding instruction, then each '1' bit in the BIT STRING
   value is represented by its corresponding identifier from the
   NamedBitList.  If the BitStringType is subject to a VALUES encoding
   instruction, then each '1' bit in the BIT STRING value is represented
   by the replacement name [RXEREI] for its corresponding identifier.

   For a CRXER encoding, if the BIT STRING type has a NamedBitList, then
   a binary digit string MUST be used, and trailing zero bits MUST be
   omitted from the binary digit string; else if the number of bits in
   the BIT STRING value is greater than or equal to 64, and the
   preconditions for using a hexadecimal digit string are satisfied,
   then a hexadecimal digit string MUST be used; otherwise, a binary
   digit string MUST be used.

      Aside: Because the asnx:format attribute adds an overhead to a
      hexadecimal encoding (including a namespace declaration for the
      "asnx" prefix), a bit string of less than 64 bits is more
      compactly encoded as a binary digit string.

   Examples

      Consider this type definition:

         BIT STRING { black(0), red(1), orange(2), yellow(3),
             green(4), blue(5), indigo(6), violet(7) }

      The content and attributes of each of the following <value>
      elements are an RXER encoding of the same abstract value:

         <value>  green violet  orange</value>

         <value> 001<!--Orange-->01001 </value>

         <value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                asnx:format="hex">
          29
         </value>

         <value>00101001</value>

      The final case contains the CRXER encoding of the abstract value.

6.7.3.  BOOLEAN

   For a non-canonical RXER encoding, the character data translation of
   the BOOLEAN value TRUE is the string "true" or "1", at the encoder's
   discretion.  For a CRXER encoding, the character data translation of
   the BOOLEAN value TRUE is the string "true".

   For a non-canonical RXER encoding, the character data translation of
   the BOOLEAN value FALSE is the string "false" or "0", at the
   encoder's discretion.  For a CRXER encoding, the character data
   translation of the BOOLEAN value FALSE is the string "false".

      Aside: The RXER encoding of BOOLEAN values is intended to conform
      to the lexical representation of the XML Schema [XSD2] boolean
      data type.

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of a BOOLEAN value:

         <value>1</value>

         <value>
             false
         </value>

         <value> fal<!-- a pesky comment -->se </value>

6.7.4.  ENUMERATED

   The character data translation of a value of an ENUMERATED type where
   the EnumeratedType is not subject to a VALUES encoding instruction is
   the identifier corresponding to the actual value.

   Examples

      Consider this type definition:

         ENUMERATED { sunday, monday, tuesday,
             wednesday, thursday, friday, saturday }

      The content of both of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value>monday</value>

         <value>
             thursday
         </value>

   The character data translation of a value of an ENUMERATED type where
   the EnumeratedType is subject to a VALUES encoding instruction is the
   replacement name [RXEREI] for the identifier corresponding to the
   actual value.

   Examples

      Consider this type definition:

         [RXER:VALUES ALL CAPITALIZED,
                 sunday AS "SUNDAY", saturday AS "SATURDAY"]
             ENUMERATED { sunday, monday, tuesday,
                 wednesday, thursday, friday, saturday }

      The content of each of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value>SUNDAY</value>

         <value>
             Monday
         </value>

         <value> Tuesday </value>

6.7.5.  GeneralizedTime

   The character data translation of a value of the GeneralizedTime type
   is a date, the letter 'T' (U+0054), a time of day, optional
   fractional seconds, and an optional time zone.

   The date is two decimal digits representing the century, followed by
   two decimal digits representing the year, a hyphen ('-', U+002D), two
   decimal digits representing the month, a hyphen ('-', U+002D), and
   two decimal digits representing the day.

   The time of day is two decimal digits representing the hour, followed
   by a colon (':', U+003A), two decimal digits representing the
   minutes, a colon (':', U+003A), and two decimal digits representing
   the seconds.

   Note that the hours value "24" is disallowed [X.680].

   A GeneralizedTime value with fractional hours or minutes is first
   converted to the equivalent time with whole minutes and seconds and,
   if necessary, fractional seconds.

   The minutes are encoded as "00" if the GeneralizedTime value omits
   minutes.  The seconds are encoded as "00" if the GeneralizedTime
   value omits seconds.

   The fractional seconds part is a full stop ('.', U+002E) followed by
   zero, one, or more decimal digits (U+0030-U+0039).  For a CRXER
   encoding, trailing zero digits (U+0030) in the fractional seconds
   SHALL be omitted, and the full stop SHALL be omitted if there are no
   following digits.

   The time zone, if present, is either the letter 'Z' (U+005A) to
   indicate Coordinated Universal Time, a plus sign ('+', U+002B)
   followed by a time zone differential, or a minus sign ('-', U+002D)
   followed by a time zone differential.

   A time zone differential indicates the difference between local time
   (the time specified by the preceding date and time of day) and
   Coordinated Universal Time.  Coordinated Universal Time can be
   calculated from the local time by subtracting the differential.

   For a CRXER encoding, a GeneralizedTime value with a time zone
   differential SHALL be encoded as the equivalent Coordinated Universal
   Time, i.e., the time zone will be "Z".

   A local time GeneralizedTime value is not converted to Coordinated
   Universal Time for a CRXER encoding.  Other canonical ASN.1 encoding
   rules specify that local times must be encoded as Coordinated
   Universal Time but do not specify a method to convert a local time to
   a Coordinated Universal Time.  Consequently, canonicalization of
   local time values is unreliable and applications SHOULD NOT use local
   time.

   A time zone differential is encoded as two decimal digits
   representing hours, a colon (':', U+003A), and two decimal digits
   representing minutes.  The minutes are encoded as "00" if the
   GeneralizedTime value omits minutes from the time zone differential.

      Aside: The RXER encoding of GeneralizedTime values is intended to
      conform to the lexical representation of the XML Schema [XSD2]
      dateTime data type.

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of a GeneralizedTime value:

         <value>2004-06-15T12:00:00Z</value>

         <value> 2004-06-15T02:00:00+10:00 </value>

         <value>
             2004-06-15T12:00:00.5
         </value>

6.7.6.  INTEGER

   For a CRXER encoding, the character data translation of a value of an
   IntegerType is a canonical number string representing the integer
   value.

   A canonical number string is either the digit character '0' (U+0030),
   or an optional minus sign ('-', U+002D) followed by a non-zero
   decimal digit character (U+0031-U+0039) followed by zero, one, or
   more of the decimal digit characters '0' to '9' (U+0030-U+0039).

   For a non-canonical RXER encoding, the character data translation of
   a value of the IntegerType without a NamedNumberList is a number
   string representing the integer value.

   A number string is a sequence of one or more of the decimal digit
   characters '0' to '9' (U+0030-U+0039), with an optional leading sign,
   either '+' (U+002B) or '-' (U+002D).  Leading zero digits are
   permitted in a number string for a non-canonical RXER encoding.

      Aside: The RXER encoding of values of the IntegerType without a
      NamedNumberList is intended to conform to the lexical
      representation of the XML Schema [XSD2] integer data type.

   For a non-canonical RXER encoding, if the IntegerType has a
   NamedNumberList, and the NamedNumberList defines an identifier for
   the actual value, and the IntegerType is not subject to a VALUES
   encoding instruction, then the character data translation of the
   value is either a number string or the identifier.

   Examples

      Consider this type definition:

         INTEGER { zero(0), one(1) }

      The content of each of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value>0</value>

         <value> zero </value>

         <value> 2 <!-- This number doesn't have a name. --> </value>

         <value>00167</value>

   For a non-canonical RXER encoding, if the IntegerType is subject to a
   VALUES encoding instruction (it necessarily must have a
   NamedNumberList) and the NamedNumberList defines an identifier for
   the actual value, then the character data translation of the value is
   either a number string or the replacement name [RXEREI] for the
   identifier.

   Examples

      Consider this type definition:

         [RXER:VALUES ALL UPPERCASED] INTEGER { zero(0), one(1) }

      The content of both of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value>0</value>

         <value> ZERO </value>

6.7.7.  NULL

   The character data translation of a value of the NULL type is an
   empty character string.

   Examples

      <value/>

      <value><!-- Comments don't matter. --></value>

      <value></value>

      The final case is the CRXER encoding.

6.7.8.  ObjectDescriptor

   A value of the ObjectDescriptor type is translated according to the
   GraphicString type.

6.7.9.  OBJECT IDENTIFIER and RELATIVE-OID

   The character data translation of a value of the OBJECT IDENTIFIER or
   RELATIVE-OID type is a full stop ('.', U+002E) separated list of the
   object identifier components of the value.

   Each object identifier component is translated as a non-negative
   number string.  A non-negative number string is either the digit
   character '0' (U+0030), or a non-zero decimal digit character
   (U+0031-U+0039) followed by zero, one, or more of the decimal digit
   characters '0' to '9' (U+0030-U+0039).

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of an OBJECT IDENTIFIER value:

         <value>2.5.6.0</value>

         <value>
             2.5.4.10
         </value>

         <value> 2.5.4.3 <!-- commonName --> </value>

6.7.10.  OCTET STRING

   The character data translation of a value of the OCTET STRING type is
   the hexadecimal digit string representation of the octets.

   The octets are encoded in order from the first octet to the last
   octet.  Each octet is encoded as a pair of the hexadecimal digit
   characters '0'-'9', 'A'-'F', and 'a'-'f' (i.e., U+0030-U+0039,
   U+0041-U+0046, and U+0061-U+0066) where the first digit in the pair
   corresponds to the four most significant bits of the octet.  An odd
   number of hexadecimal digits is not permitted.  The characters 'a'-
   'f' (i.e., U+0061-U+0066) SHALL NOT be used in the CRXER encoding of
   an OCTET STRING value.

      Aside: The RXER encoding of OCTET STRING values is intended to
      conform to the lexical representation of the XML Schema [XSD2]
      hexBinary data type.

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of an OCTET STRING value:

         <value>27F69A0300</value>

         <value>
             efA03bFF
         </value>

6.7.11.  QName

   The character data translation of a value of the QName type
   (Section 4.5) is a qualified name conforming to the QName production
   of Namespaces in XML 1.0 [XMLNS10].

   The local part (i.e., LocalPart) of the qualified name SHALL be the
   value of the local-name component of the QName value.

   If the namespace-name component of the QName value is absent, then
   the namespace prefix (i.e., Prefix) of the qualified name SHALL be
   absent; otherwise, the namespace prefix is determined as specified in
   Section 6.7.11.1 using the value of the namespace-name component of
   the QName value as the namespace name.

6.7.11.1.  Namespace Prefixes for Qualified Names

   This section describes how the namespace prefix of a qualified name
   is determined given the namespace name to which the namespace prefix
   must map.

   For a CRXER encoding, the namespace prefix of the qualified name is
   any unused non-canonical namespace prefix unless the
   [in-scope namespaces] property of the enclosing element item contains
   a namespace item with a [namespace name] that matches the namespace
   name.  In that case, the [prefix] of that namespace item SHALL be
   used as the namespace prefix of the qualified name.

      Aside: If the qualified name appears in the [normalized value] of
      an attribute item, then the enclosing element item is the
      [owner element] for that attribute item.

   For a non-canonical RXER encoding, the namespace prefix of the
   qualified name is any unused namespace prefix unless the
   [in-scope namespaces] property of the enclosing element item contains
   a namespace item with the same [namespace name] as the element item.
   In that case, the [prefix] of that namespace item MAY be used as the

   namespace prefix of the qualified name.  Note that the [prefix] of a
   namespace item for the default namespace has no value.

   If the namespace prefix of the qualified name is an unused namespace
   prefix, then a namespace declaration attribute item associating the
   namespace prefix with the namespace name MUST be added to the
   [namespace attributes] of the enclosing element item, and a
   corresponding namespace item MUST be added to the
   [in-scope namespaces] of the enclosing element item.

6.7.12.  REAL

   The character data translation of a value of the REAL type is the
   character string "0" if the value is positive zero, the character
   string "-0" if the value is negative zero, the character string "INF"
   if the value is positive infinity, the character string "-INF" if the
   value is negative infinity, the character string "NaN" if the value
   is not a number, or a real number otherwise.

   A real number is the mantissa followed by either the character 'E'
   (U+0045) or 'e' (U+0065) and the exponent.  The character 'e' SHALL
   NOT be used for a CRXER encoding.  If the exponent is zero, then the
   'E' or 'e' and exponent MAY be omitted for a non-canonical RXER
   encoding.

   The mantissa is a decimal number with an optional leading sign,
   either '+' (U+002B) or '-' (U+002D).  A decimal number is a sequence
   of one or more of the decimal digit characters '0' to '9'
   (U+0030-U+0039) optionally partitioned by a single full stop
   character ('.', U+002E) representing the decimal point.  Multiple
   leading zero digits are permitted for a non-canonical RXER encoding.

   The exponent is encoded as a number string (see Section 6.7.6).

      Aside: The RXER encoding of REAL values is intended to be
      compatible with the lexical representation of the XML Schema
      [XSD2] double data type, but allows real values outside the set
      permitted by double.

   For a CRXER encoding:

   (1) The real number MUST be normalized so that the mantissa has a
       single non-zero digit immediately to the left of the decimal
       point.

   (2) Leading zero digits SHALL NOT be used.

   (3) A leading plus sign SHALL NOT be used in the mantissa or the
       exponent.

   (4) The fractional part of the mantissa (i.e., that part following
       the decimal point) MUST have at least one digit (which may be
       '0') and MUST NOT have any trailing zeroes after the first digit.

   (5) The exponent SHALL be present and SHALL be a canonical number
       string (see Section 6.7.6).

   Examples

      The content of each of the following <value> elements is the RXER
      encoding of a REAL value:

         <value>3.14159<!-- pi --></value>

         <value> 1.0e6 </value>

         <value> INF </value>

         <value>
             -01e-06
         </value>

6.7.13.  UTCTime

   The character data translation of a value of the UTCTime type is a
   date, the letter 'T' (U+0054), a time of day, and a time zone.

   The date is two decimal digits representing the year (no century), a
   hyphen ('-', U+002D), two decimal digits representing the month, a
   hyphen ('-', U+002D), and two decimal digits representing the day.

   The time of day is two decimal digits representing the hour, followed
   by a colon (':', U+003A), two decimal digits representing the
   minutes, a colon (':', U+003A), and two decimal digits representing
   the seconds.

   Note that the hours value "24" is disallowed [X.680].

   The seconds are encoded as "00" if the UTCTime value omits seconds.

   The time zone is either the letter 'Z' (U+005A) to indicate
   Coordinated Universal Time, a plus sign ('+', U+002B) followed by a
   time zone differential, or a minus sign ('-', U+002D) followed by a
   time zone differential.

   A time zone differential indicates the difference between local time
   (the time specified by the preceding date and time of day) and
   Coordinated Universal Time.  Coordinated Universal Time can be
   calculated from the local time by subtracting the differential.

   For a CRXER encoding, a UTCTime value with a time zone differential
   SHALL be encoded as the equivalent Coordinated Universal Time, i.e.,
   the time zone will be "Z".

   A time zone differential is encoded as two decimal digits
   representing hours, a colon (':', U+003A), and two decimal digits
   representing minutes.

6.7.14.  CHOICE as UNION

   The chosen alternative of a value of a UNION type corresponds to some
   NamedType in the UNION type definition (a ChoiceType).

   The character data translation of a value of a UNION type is the
   character data translation of the value of the type of the chosen
   alternative, i.e., without any kind of encapsulation.

   Leading and trailing white space characters are not permitted to be
   added to the character data translation of a value of a UNION type
   (see Section 6.7); however, this does not preclude such white space
   being added to the character data translation of the value of the
   chosen alternative.

   The character data translation of a value of a UNION type is
   necessarily destined for the [children] of an enclosing element item.

      Aside: This is because the ATTRIBUTE encoding instruction cannot
      be applied to a NamedType with a type that is a UNION type.

   The chosen alternative can be identified by a member attribute item,
   i.e., an attribute item with the [local name] "member" and
   [namespace name] "urn:ietf:params:xml:ns:asnx", added to the
   [attributes] of the enclosing element item.  The [prefix] of this
   attribute item is determined as specified in Section 6.2.3.1.  The
   [normalized value] of the attribute item is a qualified name for the
   expanded name of the NamedType (see [RXEREI]) corresponding to the
   chosen alternative.

      Aside: It is not possible to associate a namespace name with a
      NamedType in a UNION type using the current specification for RXER
      encoding instructions.  Consequently, the [normalized value] of
      the member attribute item will always contain a qualified name
      without a namespace prefix.

   For a CRXER encoding, the member attribute item MUST be used, and the
   [normalized value] of the attribute item MUST be the CRXER
   translation of the QName value equal to the expanded name.

   In the absence of a member attribute item, an RXER decoder MUST
   determine the chosen alternative by considering the alternatives of
   the choice in the order prescribed below and accepting the first
   alternative for which the encoding is valid.

   If the UNION encoding instruction has a PrecedenceList, then the
   alternatives of the ChoiceType referenced by the PrecedenceList are
   considered in the order identified by that PrecedenceList, then the
   remaining alternatives are considered in the order of their
   definition in the ChoiceType.  If the UNION encoding instruction does
   not have a PrecedenceList, then all the alternatives of the
   ChoiceType are considered in the order of their definition in the
   ChoiceType.

   A non-canonical RXER encoder MUST use the member attribute item if an
   RXER decoder would determine the chosen alternative to be something
   other than the actual chosen alternative of the CHOICE value being
   translated; otherwise, the member attribute item MAY be used.

   Examples

      Consider this type definition:

         [RXER:UNION PRECEDENCE serialNumber] CHOICE {
             name          [0] IA5String,
             serialNumber  [1] INTEGER
         }

      In the absence of a member attribute, an RXER decoder would first
      consider whether the received encoding was a valid serialNumber
      (an INTEGER) before considering whether it was a valid name (an
      IA5String).

      The content and attributes of each of the following <value>
      elements are the RXER encoding of a value of the above type:

         <value>Bob</value>

         <value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                asnx:member="name">Alice</value>

         <value>
          <!-- Don't have a name for this one! --> 344
         </value>

         <value xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                asnx:member="name"><!-- A strange name. -->100</value>

      The member attribute is required in the final case to prevent the
      value being interpreted as a serialNumber.

   If the UNION (i.e., CHOICE) type is extensible [X.680], then an
   application MUST accept and be prepared to re-encode (using the same
   encoding rules) any unknown extension in received encoded values of
   the type.  An unknown extension in a value of a UNION type (an
   unknown alternative) takes the form of an unknown name in the
   [normalized value] of the member attribute and/or character data in
   the [children] of the enclosing element item that do not conform to
   any of the known alternatives.

   To enable re-encoding of an unknown alternative, it is necessary to
   retain the [normalized value] of the member attribute, if present,
   and the [children] property of the enclosing element item.

   The character data for an unknown alternative may contain qualified
   names that depend on the [in-scope namespaces] of the enclosing
   element item for their interpretation.  Therefore, semantically
   faithful re-encoding of an unknown alternative may require
   reproduction of at least some part of the [in-scope namespaces] of
   the enclosing element item.  The problem is deciding which of the
   namespace items are actually needed.  In the absence of type
   information, it is not possible to discern whether anything that
   syntactically resembles a qualified name in the character data of the
   enclosing element item actually is a qualified name.  The simplest
   approach is to retain all the namespace items from the
   [in-scope namespaces] of the enclosing element item and output them
   as namespace declaration attribute items in the
   [namespace attributes] of the enclosing element item when re-encoding
   the unknown alternative.  At best, an application can omit the
   namespace items that do not define the namespace prefix of any
   potential qualified name.

   An application MUST retain the namespace items in the
   [in-scope namespaces] of the enclosing element item that define the
   namespace prefixes of all the potential qualified names in the
   [children] of the enclosing element item.  Other namespace items in
   the [in-scope namespaces] of the enclosing element item MAY be
   retained.  The effect of these retained namespace items on the
   [namespace attributes] and [in-scope namespaces] of the enclosing
   element item when re-encoding is considered in Section 6.2.2.1.

      Aside: The context attribute (Section 6.8.8) is not added to the
      [attributes] of the enclosing element item when re-encoding an
      unknown alternative since the type of a NamedType in a UNION type
      cannot be the Markup type.

6.7.15.  SEQUENCE OF as LIST

   The character data translation of a value of a LIST type (a
   SEQUENCE OF NamedType) is the concatenation of the character data
   translations of the component values, i.e., the abstract values of
   the type of the NamedType, each separated from the next by at least
   one white space character.  For a CRXER encoding, separating white
   space MUST be exactly one space character (U+0020).

   Example

      Consider this type definition:

         [LIST] SEQUENCE OF timeStamp GeneralizedTime

      The content of the following <value> element is the RXER encoding
      of a value of the above type:

         <value>
             2004-06-15T12:14:56Z
             2004-06-15T12:18:13Z
             2004-06-15T01:00:25Z
         </value>

6.8.  Combining Types

   The encoding of a value of an ASN.1 combining type (except a UNION or
   LIST type) typically has element content.

   The Infoset translation of a value of a specific ASN.1 combining type
   (excluding a UNION or LIST type) contains zero or more attribute
   items to be added to the [attributes] of the enclosing element item
   and zero or more element items to be added to the [children] of the
   enclosing element item.  These translations are described in Sections
   6.8.1 to 6.8.7.

   For a non-canonical RXER encoding, white space character items MAY be
   added to the [children] of the enclosing element item (before or
   after any other items).

   For a CRXER encoding, a character item with the [character code]
   U+000A (a line feed) MUST be inserted immediately before each element
   item in the [children] of the enclosing element item.  No other white
   space character items are permitted to be added to the [children] of
   the enclosing element item.

      Aside: Without the single line feed character before each child
      element, a typical CRXER encoding would be a single, very long
      line.

6.8.1.  CHARACTER STRING

   A value of the unrestricted CHARACTER STRING type is translated
   according to the corresponding SEQUENCE type defined in Clause 40.5
   of X.680 [X.680].

6.8.2.  CHOICE

   The chosen alternative of a value of a CHOICE type corresponds to,
   and is a value of (see Section 6), some NamedType in the CHOICE type
   definition.

   The translation of a value of a CHOICE type other than the Markup
   type or a UNION type (see Section 6.7.14) is the translation of the
   value of the NamedType corresponding to the actual chosen
   alternative.

   Examples

      Consider this type definition:

         CHOICE {
             name          [0] IA5String,
             serialNumber  [1] INTEGER
         }

      The content of each of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value><name>Bob</name></value>

         <value>
          <name>Alice</name>
         </value>

         <value>
          <!-- Don't have a name for this one! -->
          <serialNumber>
           344
          </serialNumber>
         </value>

         <value>
          <!-- A strange name. -->
          <name>100</name>
         </value>

   If the CHOICE type is extensible [X.680], then an application MUST
   accept, and be prepared to re-encode (in RXER), any attribute item or
   child element item with a name that is not recognized (see
   Section 6.8.8).

6.8.3.  EMBEDDED PDV

   A value of the EMBEDDED PDV type is translated according to the
   corresponding SEQUENCE type defined in Clause 33.5 of X.680 [X.680].

6.8.4.  EXTERNAL

   A value of the EXTERNAL type is translated according to the
   corresponding SEQUENCE type defined in Clause 8.18.1 of X.690
   [X.690].

6.8.5.  INSTANCE OF

   A value of the INSTANCE OF type is translated according to the
   corresponding SEQUENCE type defined in Annex C of X.681 [X.681].

6.8.6.  SEQUENCE and SET

   Each component value of a value of a SEQUENCE or SET type corresponds
   to, and is a value of (see Section 6), some NamedType in the SEQUENCE
   or SET type definition.

   A value of a SEQUENCE or SET type, other than the QName type
   (Section 4.5), is translated by translating in turn each component
   value actually present in the SEQUENCE or SET value and adding the
   resulting attribute items and/or element items to the [attributes]
   and/or [children] of the enclosing element item.  Attribute items may
   be added to the [attributes] of the enclosing element item in any
   order.  Element items resulting from the translation of component

   values MUST be appended to the [children] of the enclosing element
   item in the order of the component values' corresponding NamedType
   definitions in the SEQUENCE or SET type definition.

      Aside: In the case of the SET type, this is a deliberate departure
      from BER [X.690], where the components of a SET can be encoded in
      any order.

   If a DEFAULT value is defined for a NamedType and the value of the
   NamedType is the same as the DEFAULT value, then the translation of
   the value of the NamedType SHALL be omitted for a CRXER encoding and
   MAY be omitted for a non-canonical RXER encoding.

   Examples

      Consider this type definition:

         SEQUENCE {
             name        [0] IA5String OPTIONAL,
             partNumber  [1] INTEGER,
             quantity    [2] INTEGER DEFAULT 0
         }

      The content of each of the following <value> elements is the RXER
      encoding of a value of the above type:

         <value>
          <partNumber>23</partNumber>
          <!-- The quantity defaults to zero. -->
         </value>

         <value>
          <name>chisel</name>
          <partNumber> 37 </partNumber>
          <quantity> 0 </quantity>
         </value>

         <value>
          <!-- The name component is optional. -->
          <partNumber>1543</partNumber>
          <quantity>29</quantity>
         </value>

   If the SEQUENCE or SET type is extensible [X.680], then an
   application MUST accept, and be prepared to re-encode (in RXER), any
   attribute item or child element item with a name that is not
   recognized (see Section 6.8.8).

6.8.7.  SEQUENCE OF and SET OF

   Each component value of a value of a type that is a SET OF NamedType
   or a SEQUENCE OF NamedType corresponds to, and is a value of (see
   Section 6), the NamedType in the type definition.

   A value of a type that is a SET OF NamedType, or a
   SEQUENCE OF NamedType other than a LIST type (see Section 6.7.15), is
   translated by adding the translation of each value of the NamedType
   to the [children] of the enclosing element item.

      Aside: An ATTRIBUTE encoding instruction cannot appear in the
      component type for a SEQUENCE OF or SET OF type, so there are no
      attribute items to add to the [attributes] of the enclosing
      element item.

   If the type is a SEQUENCE OF NamedType, then the values of the
   NamedType are translated in the order in which they appear in the
   value of the type.

   For a non-canonical RXER encoding, if the type is a SET OF NamedType,
   then the values of the NamedType may be translated in any order.

   For a CRXER encoding, if the type is a SET OF NamedType, then the
   values of the NamedType MUST be translated in ascending order where
   the order is determined by comparing the octets of their CRXER
   encodings (which will be UTF-8 encoded character strings; see
   Section 6.12.2).  A shorter encoding is ordered before a longer
   encoding that is identical up to the length of the shorter encoding.

   Examples

      Consider this type definition:

         SEQUENCE OF timeStamp GeneralizedTime

      The content of the following <value> element is the RXER encoding
      of a value of the above type:

         <value>
             <timeStamp>2004-06-15T12:14:56Z</timeStamp>
             <timeStamp>2004-06-15T12:18:13Z</timeStamp>
             <timeStamp>
                 2004-06-15T01:00:25Z
             </timeStamp>
         </value>

      Consider this type definition (also see Section 6.6):

         SEQUENCE OF INTEGER

      The content of the following <value> element is the RXER encoding
      of a value of the above type:

         <value>
          <item>12</item>
          <item>
           9
          </item>
          <item> 7 <!-- A prime number. --></item>
         </value>

6.8.8.  Extensible Combining Types

   An application must accept and be prepared to re-encode (using the
   same encoding rules) any unknown extension appearing in the encoding
   of a value of an extensible CHOICE, SEQUENCE, or SET type.  An
   unknown extension in a value of an extensible combining type (except
   UNION types) takes the form of unknown element and/or attribute
   items.  Section 6.8.8.1 describes the processing of unknown element
   items and Section 6.8.8.2 describes the processing of unknown
   attribute items.

   An application cannot produce a canonical encoding if an abstract
   value contains unknown extensions.  However, the method for
   re-encoding unknown extensions does not prevent a receiving
   application with knowledge of the extension from producing the
   correct canonical encoding.

6.8.8.1.  Unknown Elements in Extensions

   To enable re-encoding of an unknown element item it is necessary to
   retain the [prefix], [local name], [attributes],
   [namespace attributes], and [children] properties of the element
   item.

   Definition (inherited namespace item):  An inherited namespace item
   is a namespace item in the [in-scope namespaces] of an element item
   for which there is no corresponding namespace declaration attribute
   item in the [namespace attributes] of the element item.

   The content and attributes of an unknown element item may contain
   qualified names whose interpretation depends on inherited namespace
   items.  Semantically faithful re-encoding of the unknown item may
   require reproduction of at least some of the inherited namespace

   items.  The problem is deciding which of the inherited namespace
   items are actually needed.  Qualified names as the names of elements
   and attributes are easily recognized, but in the absence of type
   information it is not possible to discern whether anything that
   syntactically resembles a qualified name in the value of an attribute
   or the character data of an element actually is a qualified name.

   The simplest approach is to retain all the inherited namespace items
   and output corresponding namespace declaration attribute items in the
   [namespace attributes] of the unknown element item when re-encoding
   the element item.  At best, an application can omit the inherited
   namespace items that do not define the namespace prefix of any
   definite or potential qualified name, though this requires examining
   the content and attributes of the unknown extension.

   Regardless of how clever an implementation tries to be, adding any
   namespace declaration attribute items to an unknown element item is
   harmful to canonicalization if the ASN.1 type for the element item
   turns out to be the Markup type.  To counter this problem, a special
   attribute is used to identify the namespace declaration attribute
   items added to an unknown element item so that they can be removed
   later, if it proves necessary.

   If the outermost element item in an unknown extension does not have
   an attribute item with the [local name] "context" and
   [namespace name] "urn:ietf:params:xml:ns:asnx" in its [attributes],
   then namespace declaration attribute items corresponding to the
   inherited namespace items that define the namespace prefixes of all
   the definite and potential qualified names in the content and
   attributes of the element item MUST be added to the retained
   [namespace attributes].  Other inherited namespace items MAY be added
   to the retained [namespace attributes].

   If there are one or more of these added namespace declaration
   attribute items, then an attribute item with the [local name]
   "context" and [namespace name] "urn:ietf:params:xml:ns:asnx" MUST be
   added to the retained [attributes].

   The [prefix] of the context attribute item is any namespace prefix
   that does not match the [local name] of any namespace declaration
   attribute item in the [namespace attributes] unless the
   [namespace attributes] property contains a namespace declaration
   attribute item with a non-empty [prefix] and a [normalized value] of
   "urn:ietf:params:xml:ns:asnx".  In that case, the [local name] of
   that namespace declaration attribute item MAY be used as the [prefix]
   of the context attribute item.

   If the [prefix] of the context attribute item does not match the
   [local name] of any namespace declaration attribute item, then an
   attribute item with the [prefix] "xmlns", [namespace name]
   "urn:ietf:params:xml:ns:asnx", and [local name] equal to the [prefix]
   of the context attribute item MUST be added to the retained
   [namespace attributes] of the element item.

   The [normalized value] of the context attribute is the white-space-
   separated unordered list of the [local names] of the added namespace
   declaration attribute items (i.e., a list of the namespace prefixes),
   including any namespace declaration attribute item added to define
   the [prefix] of the context attribute.  Note that the [local name]
   for a namespace declaration attribute item declaring the default
   namespace is "xmlns".

      Aside: A receiver that knows about the extension will use the
      context attribute to strip out the added namespace declaration
      attributes if the type of the associated NamedType is the Markup
      type (Section 6.10), and will discard the context attribute
      otherwise.  A receiver that does not know about the extension will
      re-encode the extension as is.

   Adding the required namespace declaration attribute items to an
   element item effectively makes the element item self-contained.  A
   received encoding has an encoding error if it contains an element
   item that is not self-contained but has a context attribute item in
   its [attributes].

   An RXER encoder MUST NOT add the context attribute item to an element
   item corresponding to a NamedType that is known to it.

   An RXER decoder MUST accept the context attribute item on an element
   item corresponding to a NamedType that does not appear to be an
   extension.

      Aside: It is not uncommon for extension markers to be neglected in
      specifications traditionally using only BER, since extension
      markers do not alter BER encodings.  Consequently, it is not
      immediately obvious in later versions of the specification which
      instances of NamedType belong to extensions of the original base
      specification.

   Example

      Suppose there are three applications, A, B, and C.  Suppose that
      Application A uses the first edition of an ASN.1 specification
      containing the following type definition:

         MyType ::= SEQUENCE {
                 field1  INTEGER,  -- present in first edition
                 ...
         }

      Suppose that Application B uses the second edition of the ASN.1
      specification:

         MyType ::= SEQUENCE {
                 field1  INTEGER,  -- present in first edition
                 ...,
                 field2  QName     -- added in second edition
         }

      Suppose that Application C uses the third edition of the ASN.1
      specification:

         MyType ::= SEQUENCE {
                 field1  INTEGER,  -- present in first edition
                 ...,
                 field2  QName,    -- added in second edition
                 field3  Markup    -- added in third edition
         }

      Application C produces the following RXER encoding and sends it to
      Application B:

         <value xmlns:p2="http://example.com/ns2">
          <field1> 100 </field1>
          <field2> p2:foobar </field2>
          <field3 xmlns:p1="http://example.com/ns1"> p1:foobar </field3>
         </value>

      Application B doesn't know about <field3>, so it adds the
      asnx:context attribute to <field3> when it re-encodes the abstract
      value to send to Application A:

         <value xmlns:p1="http://example.com/ns2">
          <!-- Application B knows the white space in field1 and
               field2 is optional and discards it. -->
          <field1>100</field1>
          <field2>p1:foobar</field2>
          <!-- Application B doesn't know about field3
               so it leaves the character data alone. -->
          <field3 asnx:context="asnx p2"
                  xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                  xmlns:p1="http://example.com/ns1"
                  xmlns:p2="http://example.com/ns2"> p1:foobar </field3>
         </value>

      Application A doesn't know about <field2> and <field3>, so it adds
      the asnx:context attribute to <field2> and leaves <field3> alone
      when it re-encodes the abstract value:

         <value>
          <!-- Application A knows about field1 and chooses
               to add some white space. -->
          <field1> 100 </field1>
          <!-- Application A doesn't know about field2 or field3
               so it leaves the character data alone. -->
          <field2 asnx:context="asnx p1"
                  xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                  xmlns:p1="http://example.com/ns2">p1:foobar</field2>
          <field3 asnx:context="asnx p2"
                  xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                  xmlns:p1="http://example.com/ns1"
                  xmlns:p2="http://example.com/ns2"> p1:foobar </field3>
         </value>

      If Application C receives this final encoding, it has sufficient
      information to discard the asnx:context, xmlns:asnx, and xmlns:p2
      attributes from the received Markup value of <field3> to recover
      the original value.  Application C knows about <field2>, so it
      uses the namespace declaration for p1 when decoding the QName
      value and ignores the other declarations.

6.8.8.2.  Unknown Attributes in Extensions

   To enable re-encoding of an unknown attribute item it is necessary to
   retain at least the [local name], [namespace name], and
   [normalized value] properties of the attribute item.

   The [normalized value] of an unknown attribute item may contain
   qualified names whose interpretation depends on the
   [in-scope namespaces] of the [owner element].  Semantically faithful

   re-encoding of the unknown attribute item may require reproduction of
   at least some part of the [in-scope namespaces].  In the absence of
   type information, it is not possible to discern whether anything that
   syntactically resembles a qualified name in the [normalized value] of
   an unknown attribute item actually is a qualified name.

   The simplest approach is to retain all the namespace items of the
   [in-scope namespaces] and output corresponding namespace declaration
   attribute items in the [namespace attributes] of the [owner element]
   when re-encoding the extension.  At best, an application can omit the
   namespace items that do not define the namespace prefix of any
   potential qualified name in the [normalized value].

   An application MUST retain the namespace items in the
   [in-scope namespaces] of the [owner element] that define the
   namespace prefixes of all the potential qualified names in the
   [normalized value] of the unknown attribute item.  Other namespace
   items in the [in-scope namespaces] of the [owner element] MAY be
   retained.

      Aside: If the enclosing element item has more than one unknown
      attribute item, then it is sufficient to save the union of the
      retained namespace items with the element item, rather than saving
      the retained namespace items with each unknown attribute item.

   When the unknown attribute item is re-encoded, the retained namespace
   items affect the [namespace attributes] and [in-scope namespaces] of
   the enclosing element item as specified in Section 6.2.2.1, and the
   [prefix] of the attribute item is determined as specified in
   Section 6.2.3.1.

      Aside: The context attribute is not added to the [attributes] of
      the [owner element] when re-encoding an unknown attribute item
      because the type of a NamedType subject to an ATTRIBUTE or
      ATTRIBUTE-REF encoding instruction cannot be the Markup type.