RFC 4910
Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)
Pages: 80
Experimental
Experimental
Part 4 of 4 – Pages 60 to 80
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
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).
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.
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):
(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).
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.
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
(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.
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., &). 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.
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 &.
Each open angle bracket character ('<', U+003C) in an attribute
item's [normalized value] MUST be serialized as the entity reference
<. Each double quote character (U+0022) in an attribute item's
[normalized value] MUST be serialized as the entity reference ".
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 &. Each
character item with the [character code] U+003C (the open angle
bracket character) MUST be serialized as the entity reference <.
Each character item with the [character code] U+003E (the closing
angle bracket character) MUST be serialized as the entity reference
>. 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 
.
A space character (U+0020) in an attribute item's [normalized value]
MUST be serialized as a single U+0020 character.
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.
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.
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
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
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.
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: None12. 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.
[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.
[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.
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 -- })
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
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.