INTERNET-DRAFT S. Legg draft-legg-xed-rxer-ei-00.txt eB2Bcom Intended Category: Standards Track February 11, 2005 Encoding Instructions for the Robust XML Encoding Rules (RXER) Copyright (C) The Internet Society (2005). All Rights Reserved. Status of this Memo By submitting this Internet-draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-draft, I accept the provisions of Section 3 of RFC 3667. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Technical discussion of this document should take place on the XED developers mailing list . Please send editorial comments directly to the editor . This Internet-Draft expires on 11 August 2005. Abstract This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how Legg Expires 11 August 2005 [Page 1] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 type as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an ASN.1 Schema document. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. Legg Expires 11 August 2005 [Page 2] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Notation for RXER Encoding Instructions. . . . . . . . . . . . 4 4. Component Encoding Instructions. . . . . . . . . . . . . . . . 7 5. Reference Encoding Instructions. . . . . . . . . . . . . . . . 8 6. Effective Names of Components. . . . . . . . . . . . . . . . . 9 7. The ATTRIBUTE Encoding Instruction . . . . . . . . . . . . . . 11 8. The ATTRIBUTE-REF Encoding Instruction . . . . . . . . . . . . 11 9. The ELEMENT-REF Encoding Instruction . . . . . . . . . . . . . 12 10. The LIST Encoding Instruction. . . . . . . . . . . . . . . . . 13 11. The NAME Encoding Instruction. . . . . . . . . . . . . . . . . 15 12. The REF-AS-ELEMENT Encoding Instruction. . . . . . . . . . . . 15 13. The REF-AS-TYPE Encoding Instruction . . . . . . . . . . . . . 16 14. The SCHEMA-IDENTITY Encoding Instruction . . . . . . . . . . . 17 15. The TARGET-NAMESPACE Encoding Instruction. . . . . . . . . . . 17 16. The TYPE-AS-VERSION Encoding Instruction . . . . . . . . . . . 18 17. The TYPE-REF Encoding Instruction. . . . . . . . . . . . . . . 18 18. The UNION Encoding Instruction . . . . . . . . . . . . . . . . 19 19. The VALUES Encoding Instruction. . . . . . . . . . . . . . . . 21 20. The CONTENT Encoding Instruction . . . . . . . . . . . . . . . 23 20.1. Unique Component Attribution. . . . . . . . . . . . . . 23 20.2. Unambiguous Encodings . . . . . . . . . . . . . . . . . 26 20.2.1. Grammar Construction . . . . . . . . . . . . . 27 20.2.1.1. Future Extensions . . . . . . . . . 32 20.2.2. Deterministic Grammars . . . . . . . . . . . . 34 21. Security Considerations. . . . . . . . . . . . . . . . . . . . 35 22. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. CONTENT Encoding Instruction Examples . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . . . . 46 Informative References . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 48 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction This document defines encoding instructions [X.680-1] that may be used in an Abstract Syntax Notation One (ASN.1) [X.680] specification to alter how values are encoded by the Robust XML Encoding Rules (RXER) [RXER] and Canonical Robust XML Encoding Rules (CRXER) [RXER], for example, to encode a component of an ASN.1 type as an Extensible Markup Language (XML) [XML] attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an ASN.1 Schema document [ASD]. This document also defines encoding instructions that allow an ASN.1 Legg Expires 11 August 2005 [Page 3] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 specification to incorporate the definitions of types, elements and attributes in specifications written in other XML schema languages. References to XML Schema [XSD1] types, elements and attributes, RELAX NG [RNG] named patterns and elements, and Document Type Declaration (DTD) [XML] element types are supported. In most cases, the effect of an encoding instruction is only briefly mentioned in this document. The precise effects of these encoding instructions are described fully in the specifications for RXER [RXER] and ASN.1 Schema [ASD], at the points where they apply. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning. Throughout this document "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 abstract value, unless qualified otherwise. A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to text in an ASN.1 specification corresponding to that production. Throughout this document, "component" is synonymous with NamedType. This document uses the namespace prefix [XMLNS] "asn1:" to stand for the namespace name "http://xmled.info/ns/ASN.1" and uses the namespace prefix "xsi:" to stand for the namespace name "http://www.w3.org/2001/XMLSchema-instance". Example ASN.1 definitions in this document are assumed to be defined in an ASN.1 module with a TagDefault of "AUTOMATIC TAGS" and an EncodingReferenceDefault [X.680-1] of "RXER INSTRUCTIONS". 3. Notation for RXER Encoding Instructions The grammar of ASN.1 permits the application of encoding instructions [X.680-1], through type prefixes and encoding control sections, that modify how abstract values are encoded by nominated encoding rules. The generic notation for type prefixes and encoding control sections is defined by the ASN.1 basic notation [X.680] [X.680-1], and includes an encoding reference to identify the specific encoding rules that are affected by the encoding instruction. The encoding reference that identifies the Robust XML Encoding rules Legg Expires 11 August 2005 [Page 4] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 is literally RXER. An RXER encoding instruction applies equally to both RXER and CRXER encodings. The specific notation for an encoding instruction for a specific set of encoding rules is left to the specification of those encoding rules. Consequently, this companion document to the RXER specification [RXER] defines the notation for RXER encoding instructions. Specifically, it elaborates the EncodingInstruction and EncodingInstructionAssignmentList placeholder productions of the ASN.1 basic notation. In the context of the RXER encoding reference the EncodingInstruction production (which only appears in a type prefix) is defined as follows, using the conventions of the ASN.1 basic notation: EncodingInstruction ::= AttributeInstruction | AttributeRefInstruction | ContentInstruction | ElementRefInstruction | ListInstruction | NameInstruction | RefAsTypeInstruction | RefAsElementInstruction | TypeAsVersionInstruction | TypeRefInstruction | UnionInstruction | ValuesInstruction In the context of the RXER encoding reference the EncodingInstructionAssignmentList production (which only appears in an encoding control section) is defined as follows, using the conventions of the ASN.1 basic notation: EncodingInstructionAssignmentList ::= SchemaIdentityInstruction ? TargetNamespaceInstruction ? TopLevelComponents ? TopLevelComponents ::= TopLevelComponent TopLevelComponents ? TopLevelComponent ::= "COMPONENT" TopLevelNamedType TopLevelNamedType ::= identifier Instructions ? TopLevelType Instructions ::= "[" TopLevelEncodingInstruction "]" Instructions ? TopLevelEncodingInstruction ::= Legg Expires 11 August 2005 [Page 5] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 AttributeInstruction | NameInstruction | RefAsTypeInstruction | TypeAsVersionInstruction | TypeRefInstruction | TopLevelType ::= typereference | ExternalTypeReference | BooleanType | CharacterStringType | EmbeddedPDVType | ExternalType | NullType | ObjectIdentifierType | OctetStringType | RealType | RelativeOIDType | TopLevelBitStringType | TopLevelIntegerType | UsefulType TopLevelBitStringType ::= "BIT" "STRING" TopLevelIntegerType ::= "INTEGER" The TopLevelNamedType is a heavily restricted subset of a NamedType and is generally treated in the same way as a NamedType. It is restricted so as to prevent the definition of non-trivial types in an RXER encoding control section. Such types would not be visible to ASN.1 tools that do not understand RXER. Each TopLevelNamedType within a TopLevelComponents SHALL have a distinct identifier. The productions for the alternatives of TopLevelType except for TopLevelBitStringType and TopLevelIntegerType are defined by the ASN.1 basic notation. The other productions are described in subsequent sections and make use of the following productions: NCNameValue ::= Value AnyURIValue ::= Value QNameValue ::= Value NameValue ::= Value Legg Expires 11 August 2005 [Page 6] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 RefParametersValue ::= Value The Value production is defined by the ASN.1 basic notation. The governing type for the Value of an NCNameValue is the NCName type from the AdditionalBasicDefinitions module [RXER]. The governing type for the Value of an AnyURIValue is the AnyURI type from the AdditionalBasicDefinitions module. The governing type for the Value of a QNameValue is the QName type from the AdditionalBasicDefinitions module. The governing type for the Value of a NameValue is the Name type from the AdditionalBasicDefinitions module. The governing type for the Value of a RefParametersValue is the RefParameters type from the AdditionalBasicDefinitions module. 4. Component Encoding Instructions Certain of the RXER encoding instructions are categorized as component encoding instructions. The component encoding instructions are the ATTRIBUTE, ATTRIBUTE-REF, CONTENT, ELEMENT-REF, NAME, REF-AS-ELEMENT, and TYPE-AS-VERSION encoding instructions (whose notations are described respectively by AttributeInstruction, AttributeRefInstruction, ContentInstruction, ElementRefInstruction, NameInstruction, RefAsElementInstruction and TypeAsVersionInstruction). When a component encoding instruction is used in a type prefix the Type in the EncodingPrefixedType SHALL be either: (a) the Type in a NamedType, or (b) the Type in an EncodingPrefixedType in a PrefixedType in a BuiltinType in a Type that is one of (a) to (d), or (c) the Type in a ConstrainedType (excluding a TypeWithConstraint) in a Type that is one of (a) to (d), or (d) the Type in an TaggedType in a PrefixedType in a BuiltinType in a Type that is one of (a) to (d). ASIDE: Only case (b) can be true on the first iteration as the Type belongs to an EncodingPrefixedType, however any of (a) to (d) can be true on subsequent iterations. Legg Expires 11 August 2005 [Page 7] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 The effect of this condition is to force the component encoding instructions to be textually within the NamedType to which they apply. The NamedType in case (a) is said to be "subject to" the component encoding instruction. The component encoding instructions may also appear in an RXER encoding control section as permitted by the grammar, i.e., textually within a TopLevelNamedType. The TopLevelNamedType is said to be "subject to" the component encoding instruction. Note that the ATTRIBUTE-REF, CONTENT, ELEMENT-REF and REF-AS-ELEMENT encoding instructions are deliberately excluded from an encoding control section. A NamedType or TopLevelNamedType SHALL NOT be subject to two or more component encoding instructions of the same kind, e.g., a NamedType is not permitted to be subject to two NAME encoding instructions. The ATTRIBUTE, ATTRIBUTE-REF, CONTENT, ELEMENT-REF, REF-AS-ELEMENT and TYPE-AS-VERSION encoding instructions are mutually exclusive. The NAME, ATTRIBUTE-REF, ELEMENT-REF and REF-AS-ELEMENT encoding instructions are mutually exclusive. A NamedType or TopLevelNamedType SHALL NOT be subject to two or more of the mutually exclusive encoding instructions. Definition: An attribute component is a NamedType that is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction. Definition: An element component is a NamedType that is not subject to an ATTRIBUTE, ATTRIBUTE-REF or CONTENT encoding instruction. 5. Reference Encoding Instructions Certain of the RXER encoding instructions are categorized as reference encoding instructions. The reference encoding instructions are the ATTRIBUTE-REF, ELEMENT-REF, REF-AS-ELEMENT, REF-AS-TYPE and TYPE-REF encoding instructions (whose notations are described respectively by AttributeRefInstruction, ElementRefInstruction, RefAsElementInstruction, RefAsTypeInstruction and TypeRefInstruction). These encoding instructions allow an ASN.1 specification to incorporate the definitions of types, elements and attributes in specifications written in other XML schema languages, through implied constraints on the markup that may appear in values of the AnyType ASN.1 type from the AdditionalBasicDefinitions module [RXER]. References to XML Schema [XSD1] types, elements and attributes, RELAX NG [RNG] named patterns and elements, and Document Type Declaration (DTD) [XML] element types are supported. The Type in the EncodingPrefixedType for an ATTRIBUTE-REF, Legg Expires 11 August 2005 [Page 8] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 ELEMENT-REF, REF-AS-ELEMENT, REF-AS-TYPE or TYPE-REF encoding instruction SHALL be: (a) a ReferencedType that is a DefinedType that is a typereference (not a DummyReference) or ExternalTypeReference that references the AnyType ASN.1 type from the AdditionalBasicDefinitions module [RXER], or (b) a ConstrainedType, other than a TypeWithConstraint, where the Type in the ConstrainedType is one of (a) to (d), or (c) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (a) to (d), or (d) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (d) and the EncodingPrefix in the EncodingPrefixedType does not contain a reference encoding instruction. ASIDE: Case (d) has the effect of making the reference encoding instructions mutually exclusive as well as singly occurring. 6. Effective Names of Components Definition: The effective name for a NamedType or TopLevelNamedType is a value of the QName ASN.1 type from the AdditionalBasicDefinitions module [RXER], representing the qualified name of the component in an RXER encoding. The effective name for a NamedType is determined as follows: (a) if the NamedType is subject to a NAME encoding instruction then the value of the local-name component of the effective name is the character string specified by the NCNameValue of the NAME encoding instruction and the prefix and namespace-name components of the effective name are absent, (b) otherwise, if the NamedType is subject to an ATTRIBUTE-REF or ELEMENT-REF encoding instruction then the effective name is the QNameValue of the encoding instruction, (c) otherwise, if the NamedType is subject to a REF-AS-ELEMENT encoding instruction then the values of the prefix and local-name components of the effective name are the Prefix and LocalPart respectively [XMLNS] of the qualified name specified by the NameValue of the encoding instruction and the namespace-name component of the effective name is absent, Legg Expires 11 August 2005 [Page 9] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 (d) otherwise, the value of the local-name component of the effective name is the identifier of the NamedType and the prefix and namespace-name components of the effective name are absent. The effective name for a TopLevelNamedType is determined as follows: (a) If the TopLevelNamedType is subject to a NAME encoding instruction then the local-name component of the effective name is the character string specified by the NCNameValue of the NAME encoding instruction, otherwise it is the identifier of the TopLevelNamedType. (b) If the module containing the TopLevelNamedType has a TARGET-NAMESPACE encoding instruction then the namespace-name component of the effective name is the character string specified by the AnyURIValue of the TARGET-NAMESPACE encoding instruction, otherwise it is absent. (c) The prefix component of the effective name is absent. Two effective names are distinct if they are different abstract values of the QName ASN.1 type. The effective names for the components (i.e., instances of NamedType) of a CHOICE type that are subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction MUST be distinct. The effective names for the components of a CHOICE type that are not subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction MUST be distinct. ASIDE: Two components may have the same effective name if one of them is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction and the other is not. The effective names for the components of a SEQUENCE or SET type that are subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction MUST be distinct. The effective names for the components of a SEQUENCE or SET type that are not subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction MUST be distinct. These tests are applied after the COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680]. The effective name of a TopLevelNamedType subject to an ATTRIBUTE encoding instruction MUST be distinct from the effective name of every other TopLevelNamedType subject to an ATTRIBUTE encoding instruction within the same TopLevelComponents. The effective name of a TopLevelNamedType not subject to an ATTRIBUTE encoding instruction MUST be distinct from the effective name of Legg Expires 11 August 2005 [Page 10] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 every other TopLevelNamedType not subject to an ATTRIBUTE encoding instruction within the same TopLevelComponents. 7. The ATTRIBUTE Encoding Instruction The ATTRIBUTE encoding instruction causes an RXER encoder to encode the component to which it is applied as an XML attribute instead of as a child element. The notation for an ATTRIBUTE encoding instruction is defined as follows: AttributeInstruction ::= "ATTRIBUTE" The type of a NamedType or TopLevelNamedType that is subject to an ATTRIBUTE encoding instruction SHALL NOT be: (a) a CHOICE, SEQUENCE, SET, SEQUENCE OF or SET OF type, or (b) a type notation that references a type that is one of (a) to (d), or (c) a constrained type where the type that is constrained is one of (a) to (d), or (d) a prefixed type where the type that is prefixed is one of (a) to (d). ASIDE: A tagged type is a special case of a prefixed type. Example PersonalDetails ::= SEQUENCE { firstName [ATTRIBUTE] UTF8String, middleName [ATTRIBUTE] UTF8String, surname [ATTRIBUTE] UTF8String } 8. The ATTRIBUTE-REF Encoding Instruction The ATTRIBUTE-REF encoding instruction causes an RXER encoder to encode the component to which it is applied as an XML attribute instead of as a child element, where the attribute's name is the qualified name of the attribute definition referenced by the encoding instruction. In addition, the ATTRIBUTE-REF encoding instruction causes values of the AnyType ASN.1 type to be restricted to conform to the type of the attribute definition. Legg Expires 11 August 2005 [Page 11] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 The notation for an ATTRIBUTE-REF encoding instruction is defined as follows: AttributeRefInstruction ::= "ATTRIBUTE-REF" QNameValue RefParametersValue ? Taken together, the QNameValue and the context component of the RefParametersValue (if present) MUST reference an XML Schema attribute definition or a TopLevelNamedType that is subject to an ATTRIBUTE encoding instruction. 9. The ELEMENT-REF Encoding Instruction The ELEMENT-REF encoding instruction causes an RXER encoder to encode the component to which it is applied as an element where the element's name is the qualified name of the element definition referenced by the encoding instruction. In addition, the ELEMENT-REF encoding instruction causes values of the AnyType ASN.1 type to be restricted to conform to the type of the element definition. The notation for an ELEMENT-REF encoding instruction is defined as follows: ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParametersValue ? Taken together, the QNameValue and the context component of the RefParametersValue (if present) MUST reference an XML Schema element definition, a RELAX NG element definition, or a TopLevelNamedType that is not subject to an ATTRIBUTE encoding instruction. Example AnySchema ::= CHOICE { asd [ELEMENT-REF { namespace-name "http://xmled.info/ns/ASN.1", local-name "schema" }] AnyType, xsd [ELEMENT-REF { namespace-name "http://www.w3.org/2001/XMLSchema", local-name "schema" }] AnyType, rng [ELEMENT-REF { namespace-name "http://relaxng.org/ns/structure/1.0", local-name "grammar" }] AnyType } Legg Expires 11 August 2005 [Page 12] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Note that the ASN.1 Schema [ASD] translation of this ASN.1 type definition provides a more natural representation: ASIDE: The element in ASN.1 Schema corresponds to a TypeAssignment, not a NamedType. 10. The LIST Encoding Instruction The LIST encoding instruction causes an RXER encoder to encode a value of a SEQUENCE OF type as a white space separated list of the component values. The notation for a LIST encoding instruction is defined as follows: ListInstruction ::= "LIST" The Type in an EncodingPrefixedType specifying a LIST encoding instruction SHALL be: (a) a BuiltinType that is a SequenceOfType of the "SEQUENCE OF NamedType" form, or (b) a ConstrainedType that is a TypeWithConstraint of the "SEQUENCE Constraint OF NamedType" form or "SEQUENCE SizeConstraint OF NamedType" form, or (c) a ConstrainedType, other than a TypeWithConstraint, where the Type in the ConstrainedType is one of (a) to (e), or (d) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (a) to (e), or (e) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (e). The effect of this condition is to force the LIST encoding Legg Expires 11 August 2005 [Page 13] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 instruction to be textually co-located with the SequenceOfType or TypeWithConstraint to which it applies. ASIDE: This makes it clear to a reader that the encoding instruction applies to every use of the type no matter how it might be referenced. The SequenceOfType in case (a) and the TypeWithConstraint in case (b) are said to be "subject to" the LIST encoding instruction. A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more than one LIST encoding instruction. The component type of a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST be one of the following: (a) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER, RELATIVE-OID, GeneralizedTime or UTCTime type, or (b) the BIT STRING type without a named bit list, or (c) the NCName, AnyURI, Name or QName type from the AdditionalBasicDefinitions module [RXER], or (d) a type notation that references a type that is one of (a) to (f), or (e) a constrained type where the type that is constrained is one of (a) to (f), or (f) a prefixed type where the type that is prefixed is one of (a) to (f). ASIDE: While it would be feasible to allow the component type to also be any character string type that is constrained such that all its abstract values have a length greater than zero and none of its abstract values contain any white space characters, testing whether this condition is satisfied can be quite involved. For the sake of simplicity, only certain immediately useful constrained UTF8String types, which are known to be suitable, are permitted (i.e., NCName, AnyURI and Name). The NamedType in a SequenceOfType or TypeWithConstraint that is subject to a LIST encoding instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, CONTENT, ELEMENT-REF, REF-AS-ELEMENT or TYPE-AS-VERSION encoding instruction. Example Legg Expires 11 August 2005 [Page 14] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime 11. The NAME Encoding Instruction The NAME encoding instruction causes an RXER encoder to use a nominated character string instead of a component's identifier wherever that identifier would otherwise appear in the encoding (e.g., as an element or attribute name). The notation for a NAME encoding instruction is defined as follows: NameInstruction ::= "NAME" "AS" NCNameValue Example CHOICE { foo-att [ATTRIBUTE] [NAME AS "Foo"] INTEGER, foo-elem [NAME AS "Foo"] INTEGER } 12. The REF-AS-ELEMENT Encoding Instruction The REF-AS-ELEMENT encoding instruction causes an RXER encoder to encode the component to which it is applied as an element where the element's name is the name of the external DTD subset element type declaration referenced by the encoding instruction. In addition, the REF-AS-ELEMENT encoding instruction causes values of the AnyType ASN.1 type to be restricted to conform to the content permitted by that element type declaration. The notation for a REF-AS-ELEMENT encoding instruction is defined as follows: RefAsElementInstruction ::= "REF-AS-ELEMENT" NameValue RefParametersValue ? Taken together, the NameValue and the context component of the RefParametersValue (if present) MUST reference an element type declaration in an external DTD subset that is conformant with Namespaces in XML [XMLNS]. Example Suppose that the following external DTD subset has been defined with a system identifier of "http://www.example.com/inventory": Legg Expires 11 August 2005 [Page 15] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 The product element type declaration can be referenced as an element in an ASN.1 type definition: CHOICE { item [REF-AS-ELEMENT "product" { context "http://www.example.com/inventory" }] AnyType } Here is the ASN.1 Schema [ASD] translation of this ASN.1 type definition: 13. The REF-AS-TYPE Encoding Instruction The REF-AS-TYPE encoding instruction causes values of the AnyType ASN.1 type to be restricted to conform to the content permitted by a nominated element type declaration in an external DTD subset. The notation for a REF-AS-TYPE encoding instruction is defined as follows: RefAsTypeInstruction ::= "REF-AS-TYPE" NameValue RefParametersValue ? Taken together, the NameValue and the context component of the RefParametersValue (if present) MUST reference an element type declaration in an external DTD subset that is conformant with Namespaces in XML [XMLNS]. Example The product element type declaration can be referenced as a type in an ASN.1 definition: SEQUENCE OF Legg Expires 11 August 2005 [Page 16] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 inventoryItem [REF-AS-TYPE "product" { context "http://www.example.com/inventory" }] AnyType Here is the ASN.1 Schema [ASD] translation of this definition: Note that when an element type declaration is referenced as a type, the Name of the element type declaration does not contribute to RXER encodings. For example, child elements in the RXER encoding of values of the above SEQUENCE OF type would resemble the following: 14. The SCHEMA-IDENTITY Encoding Instruction The SCHEMA-IDENTITY encoding instruction associates a unique identifier, a Uniform Resource Identifier (URI) [URI], with the ASN.1 module containing the encoding instruction. This encoding instruction has no effect on an RXER encoder but does have an effect on the translation of an ASN.1 specification into an ASN.1 Schema [ASD] representation. The notation for a SCHEMA-IDENTITY encoding instruction is defined as follows: SchemaIdentityInstruction ::= "SCHEMA-IDENTITY" AnyURIValue 15. The TARGET-NAMESPACE Encoding Instruction The TARGET-NAMESPACE encoding instruction associates an XML namespace name, a URI [URI], with the type, object class, value, object and object set references defined in the ASN.1 module containing the encoding instruction. In addition, it associates the namespace name with each TopLevelNamedType in the RXER encoding control section. The notation for a TARGET-NAMESPACE encoding instruction is defined as follows: TargetNamespaceInstruction ::= "TARGET-NAMESPACE" AnyURIValue Legg Expires 11 August 2005 [Page 17] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 If there are no TopLevelComponents then the RXER encodings produced using a module with a TARGET-NAMESPACE encoding instruction are backward compatible with the RXER encodings produced by the same module without the TARGET-NAMESPACE encoding instruction. 16. The TYPE-AS-VERSION Encoding Instruction The TYPE-AS-VERSION encoding instruction causes an RXER encoder to include an xsi:type attribute in the encoding of the component to which the encoding instruction is applied. This attribute allows an XML Schema [XSD1] validator to discriminate which version of the ASN.1 specification is being used so that the appropriate translation of the ASN.1 specification into XML Schema [CXSD] can be used. ASIDE: Translations of an ASN.1 specification into a compatible XML Schema are expected to be slightly different across versions because of progressive extensions to the ASN.1 specification. Each version should have a different target namespace, which will be evident in the value of the xsi:type attribute. This mechanism also accommodates a component type that is renamed in a later version of the ASN.1 specification. The notation for a TYPE-AS-VERSION encoding instruction is defined as follows: TypeAsVersionInstruction ::= "TYPE-AS-VERSION" The Type in a NamedType that is subject to a TYPE-AS-VERSION encoding instruction MUST be a Type that has a Qualified Reference Name [RXER]. The addition of a TYPE-AS-VERSION encoding instruction does not affect the backward compatibility of RXER encodings. 17. The TYPE-REF Encoding Instruction The TYPE-REF encoding instruction causes values of the AnyType ASN.1 type to be restricted to conform to a specific XML Schema named type, RELAX NG named pattern or an ASN.1 defined type. ASIDE: Normally one would reference an ASN.1 type directly, however, if there is a desire to preserve the exact RXER encoding of values of the type (e.g., an ASN.1 Schema document [ASD]), or if there is a desire to apply alternative canonicalization rules, then values of AnyType can be restricted to conform to a specific ASN.1 type. The notation for a TYPE-REF encoding instruction is defined as Legg Expires 11 August 2005 [Page 18] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 follows: TypeRefInstruction ::= "TYPE-REF" QNameValue RefParametersValue ? Taken together, the QNameValue and the context component of the RefParametersValue (if present) MUST reference an XML Schema named type, a RELAX NG named pattern, or an ASN.1 defined type. The QNameValue SHALL NOT be a direct reference to the XML Schema NOTATION type [XSD2] (i.e., the namespace name "http://www.w3.org/2001/XMLSchema" and local name "NOTATION"), however a reference to an XML Schema type derived from the NOTATION type is permitted. ASIDE: This restriction is to ensure that the lexical space [XSD2] of the referenced type is actually populated with the names of notations [XSD1]. Example MyDecimal ::= [TYPE-REF { namespace-name "http://www.w3.org/2001/XMLSchema", local-name "decimal" } ] AnyType Note that the ASN.1 Schema [ASD] translation of this ASN.1 type definition provides a more natural way to reference the XML Schema decimal type: 18. The UNION Encoding Instruction The UNION encoding instruction causes an RXER encoder to encode the alternative of a CHOICE type without encapsulation in a child element. The chosen alternative is optionally indicated with an asn1:format attribute. The optional PrecedenceList also allows a specification writer to alter the order in which an RXER decoder will consider the alternatives of the CHOICE as it determines which alternative has been used (if the actual alternative has not been specified through the asn1:format attribute). The notation for a UNION encoding instruction is defined as follows: Legg Expires 11 August 2005 [Page 19] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 UnionInstruction ::= "UNION" AlternativesPrecedence ? AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList PrecedenceList ::= identifier PrecedenceList | identifier The Type in the EncodingPrefixedType for a UNION encoding instruction SHALL be: (a) a BuiltinType that is a ChoiceType, or (b) a ConstrainedType, other than a TypeWithConstraint, where the Type in the ConstrainedType is one of (a) to (d), or (c) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (a) to (d), or (d) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (d). The ChoiceType in case (a) is said to be "subject to" the UNION encoding instruction. The type of each alternative of a ChoiceType that is subject to a UNION encoding instruction SHALL NOT be: (a) a CHOICE, SEQUENCE, SET, SEQUENCE OF or SET OF type, or (b) a type notation that references a type that is one of (a) to (d), excepting a reference to the QName type in the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed as an alternative of the ChoiceType), or (c) a constrained type where the type that is constrained is one of (a) to (d), or (d) a prefixed type where the type that is prefixed is one of (a) to (d). Each identifier in the PrecedenceList MUST be the identifier of a component (i.e., a NamedType) of the ChoiceType. A particular identifier SHALL NOT appear more than once in the same PrecedenceList. Legg Expires 11 August 2005 [Page 20] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Every NamedType in a ChoiceType that is subject to a UNION encoding instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, CONTENT, ELEMENT-REF, REF-AS-ELEMENT or TYPE-AS-VERSION encoding instruction. Example [UNION PRECEDENCE extendedName] CHOICE { basicName PrintableString, extendedName UTF8String } 19. The VALUES Encoding Instruction The VALUES encoding instruction causes an RXER encoder to use nominated names instead of the identifiers that would otherwise appear in the encoding of a value of a BIT STRING, ENUMERATED or INTEGER type. The notation for a VALUES encoding instruction is defined as follows: ValuesInstruction ::= "VALUES" AllValuesMapped ? ValueMappingList ? AllValuesMapped ::= AllCapitalized | AllUppercased AllCapitalized ::= "ALL" "CAPITALIZED" AllUppercased ::= "ALL" "UPPERCASED" ValueMappingList ::= ValueMapping "," + ValueMapping ::= identifier "AS" NCNameValue The Type in the EncodingPrefixedType for a VALUES encoding instruction SHALL be: (a) a BuiltinType that is a BitStringType with a NamedBitList, or (b) a BuiltinType that is an EnumeratedType, or (c) a BuiltinType that is an IntegerType with a NamedNumberList, or (d) a ConstrainedType, other than a TypeWithConstraint, where the Type in the ConstrainedType is one of (a) to (f), or (e) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (a) to (f), or Legg Expires 11 August 2005 [Page 21] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 (f) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (f). The effect of this condition is to force the VALUES encoding instruction to be textually co-located with the type definition to which it applies. The BitStringType, EnumeratedType or IntegerType in cases (a) to (c) (respectively) is said to be "subject to" the VALUES encoding instruction. A BitStringType, EnumeratedType or IntegerType SHALL NOT be subject to more than one VALUES encoding instruction. Each identifier in a ValueMapping MUST be an identifier appearing in the NamedBitList, Enumerations or NamedNumberList (whichever is appropriate for the case). The identifier in a ValueMapping SHALL NOT be the same as the identifier in any other ValueMapping for the same ValueMappingList. Definition: Each identifier in a BitStringType, EnumeratedType or IntegerType subject to a VALUES encoding instruction has a replacement name. If there is a ValueMapping for the identifier then the replacement name is the character string specified by the NCNameValue in the ValueMapping, otherwise, if AllCapitalized is used then the replacement name is the identifier with the first character uppercased, otherwise, if AllUppercased is used then the replacement name is the identifier with all its characters uppercased, otherwise, the replacement name is the identifier. The replacement names for the identifiers in a BitStringType subject to a VALUES encoding instruction MUST be distinct. The replacement names for the identifiers in an EnumeratedType subject to a VALUES encoding instruction MUST be distinct. The replacement names for the identifiers in an IntegerType subject to a VALUES encoding instruction MUST be distinct. Example Traffic-Light ::= [VALUES ALL CAPITALIZED red AS "RED"] ENUMERATED { red, -- effectively "RED" amber, -- effectively "Amber" green -- effectively "Green" Legg Expires 11 August 2005 [Page 22] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 } 20. The CONTENT Encoding Instruction The CONTENT encoding instruction causes an RXER encoder to encode the component to which it is applied without encapsulation as an element. It allows the construction of non-trivial content models for element content. The notation for a CONTENT encoding instruction is defined as follows: ContentInstruction ::= "CONTENT" The type of a NamedType that is subject to a CONTENT encoding instruction SHALL be: (a) a SEQUENCE, SET or SET OF type, or (b) a CHOICE type where the ChoiceType is not subject to a UNION encoding instruction, or (c) a SEQUENCE OF type where the SequenceOfType is not subject to a LIST encoding instruction, or (d) a type notation that references a type that is one of (a) to (f), or (e) a constrained type where the type that is constrained is one of (a) to (f), or (f) a prefixed type where the type that is prefixed is one of (a) to (f). The SEQUENCE type in case (a) SHALL NOT be the associated type for a built-in type and SHALL NOT be from the AdditionalBasicDefinitions module [RXER]. Thus this condition excludes the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL, QName and RefParameters types. The CHOICE type in case (a) SHALL NOT be from the AdditionalBasicDefinitions module. Thus this condition excludes the AnyType type. Sections 20.1 and 20.2 impose additional conditions on the use of the CONTENT encoding instruction. 20.1. Unique Component Attribution Legg Expires 11 August 2005 [Page 23] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Definition: Ignoring all type constraints, the component reference list for a type that is directly or indirectly a combining ASN.1 type (i.e., SEQUENCE, SET, CHOICE, SEQUENCE OF or SET OF) is the set of all possible component references [CMR] for the attribute and element components of the combining type definition plus, for each NamedType (of the combining type definition) subject to a CONTENT encoding instruction, the component reference list for the type of the NamedType. Component reference lists are constructed after the COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680]. ASIDE: The component reference list for a type is a list of all the distinct components of the type, and any nested types, that describe attributes and child elements appearing in the RXER encodings of values of the outer type. Note that the component of a SEQUENCE OF or SET OF type can be referenced multiple times as instance 1, 2, 3, and so on (also collectively using *). Since constraints are ignored, this means that the component reference list is, in principle, infinite, when SEQUENCE OF and SET OF types are involved. However in practice, it is sufficient to just consider instances 1 and 2. The component reference list can also be infinite if a type definition is recursive. In practice, it is sufficient to consider the type and one nested recursive reference to itself. If two or more references in the component reference list for a type identify element components with the same effective name (see Section 6) then they MUST be references to the same instance of NamedType notation (it is not sufficient for the NamedType notations to be equivalent), and they SHOULD be associated with the same final XER encoding instructions [X.693][X.693-1]. ASIDE: This condition is in response to component referencing notations that are evaluated with respect to the XML encoding of an abstract value. For all the ASN.1 encoding rules except EXTENDED-XER [X.693-1], the requirement to reference the same instance of NamedType notation guarantees, without having to do extensive testing, that all child elements with a particular name in an RXER encoding will be associated with equivalent type definitions. Such equivalence allows a component referenced by element name to be re-encoded using a different set of ASN.1 encoding rules without ambiguity as to which type definition applies. Testing for equivalence with respect to EXTENDED-XER is not mandatory as it is thought unlikely that anyone would reference a component by element name in an RXER encoding and then re-encode the component value using EXTENDED-XER. The component reference list MUST NOT contain two or more references Legg Expires 11 August 2005 [Page 24] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 that identify attribute components with the same effective name (regardless of whether they reference the same instance of NamedType notation). ASIDE: This condition ensures that an attribute name is always uniquely associated with one component, possibly nested, that can occur at most once. Example The following example type illustrates various uses and misuses of the CONTENT encoding instruction. TypeA ::= SEQUENCE { a [CONTENT] TypeB, b [CONTENT] CHOICE { a [CONTENT] TypeB, b [ATTRIBUTE] [NAME AS "c"] INTEGER, c INTEGER, d TypeB, e [CONTENT] TypeD, f [ATTRIBUTE] UTF8String }, c [ATTRIBUTE] INTEGER, d [CONTENT] SEQUENCE OF a [CONTENT] SEQUENCE { a [ATTRIBUTE] OBJECT IDENTIFIER, b INTEGER }, e [NAME AS "c"] INTEGER, f [CONTENT] SEQUENCE OF h TypeB, COMPONENTS OF TypeD } TypeB ::= SEQUENCE { a INTEGER, b [ATTRIBUTE] BOOLEAN, COMPONENTS OF TypeC } TypeC ::= SEQUENCE { f OBJECT IDENTIFIER } TypeD ::= SEQUENCE { g OBJECT IDENTIFIER } The component references of the component reference list for TypeA Legg Expires 11 August 2005 [Page 25] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 are given in the left hand column of the following table, grouped by effective name and component kind, with an indication of whether there has been a violation of the conditions for correct usage of the CONTENT encoding instruction. +-----------+-----------+-----------+------------+--------+ | Component | Effective | Component | Same | Valid? | | Reference | Name | Kind | NamedType? | | +-----------+-----------+-----------+------------+--------+ | a.a | "a" | element | Yes | Yes | | b.a.a | | | | | +-----------+-----------+-----------+------------+--------+ | a.b | "b" | attribute | Yes | No | | b.a.b | | | | | +-----------+-----------+-----------+------------+--------+ | d.1.a | "a" | attribute | Yes | No | | d.2.a | | | | | +-----------+-----------+-----------+------------+--------+ | d.1.b | "b" | element | Yes | Yes | | d.2.b | | | | | +-----------+-----------+-----------+------------+--------+ | b.b | "c" | attribute | No | No | | c | | | | | +-----------+-----------+-----------+------------+--------+ | b.c | "c" | element | No | No | | e | | | | | +-----------+-----------+-----------+------------+--------+ | b.d | "d" | element | N/A | Yes | +-----------+-----------+-----------+------------+--------+ | a.f | "f" | element | Yes | Yes | | b.a.f | | | | | +-----------+-----------+-----------+------------+--------+ | b.f | "f" | attribute | N/A | Yes | +-----------+-----------+-----------+------------+--------+ | b.e.g | "g" | element | No | No | | g | | | | | +-----------+-----------+-----------+------------+--------+ | f.1 | "h" | element | Yes | Yes | | f.2 | | | | | +-----------+-----------+-----------+------------+--------+ 20.2. Unambiguous Encodings Unregulated use of the CONTENT encoding instruction can easily lead to specifications in which distinct abstract values have indistinguishable RXER encodings, i.e., ambiguous encodings. If the original abstract value cannot be reliably decoded then a canonical Legg Expires 11 August 2005 [Page 26] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 encoding of the original abstract value (using some other set of encoding rules) cannot be reliably reproduced either. This section imposes restrictions on the use of the CONTENT encoding instruction to ensure that distinct abstract values have distinct RXER encodings. In addition, these restrictions ensure that an abstract value can be easily decoded in a single pass without back-tracking. An RXER decoder for an ASN.1 type can be abstracted as a recognizer for a notional language, consisting of element and attribute names, where the type definition describes the grammar for that language (in fact it is a context-free grammar). The restrictions on a type definition to ensure easy, unambiguous decoding are more conveniently, completely and simply expressed as conditions on this associated grammar. Implementations are not expected to verify type definitions exactly in the manner to be described, however the procedure used MUST produce the same result. Section 20.2.1 describes the procedure for recasting a type definition containing components subject to the CONTENT encoding instruction as a grammar. Section 20.2.2 specifies the conditions that the grammar must satisfy for the type definition to be valid. Appendix A has extensive examples. 20.2.1. Grammar Construction A grammar consists of a collection of productions. A production has a left hand side and a right hand side, (in this document, separated by the "::=" symbol). The left hand side (in a context-free grammar) is a single non-terminal symbol. The right hand side is a sequence of non-terminal and terminal symbols. The terminal symbols are the lexical items of the language that the grammar describes. One of the non-terminals is nominated to be the start symbol. A valid sequence of terminals for the language can be generated from the grammar by starting with the start symbol and repeatedly replacing any non-terminal with the right hand side of one of the productions where that non-terminal is on the production's left hand side. ASIDE: X.680 describes the ASN.1 basic notation using a context-free grammar. Each NamedType has an associated primary and secondary non-terminal (a secondary non-terminal is only used when the type in the NamedType is a SEQUENCE OF type or SET OF type). Each ExtensionAddition and each ExtensionAdditionAlternative has an associated non-terminal. The exact nature of the non-terminals is not important however all the non-terminals MUST be distinct. There is also a primary start Legg Expires 11 August 2005 [Page 27] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 non-terminal (this is the start symbol) and a secondary start non-terminal, both of which are distinct from all other non-terminals. It is adequate for the examples in this document for the primary non-terminal for a NamedType to be the identifier of the NamedType with the first letter uppercased, for the secondary non-terminal to be primary non-terminal prefixed with "L-", for the primary start non-terminal to be S, for the secondary start non-terminal to be L-S, and for the non-terminals for the instances of ExtensionAddition and ExtensionAdditionAlternative to be E1, E2, E3 and so on, though such a naming scheme would not work in the most general case. Each NamedType has an associated terminal. Again, the exact nature of the terminals is not important however the terminals MUST be distinct for each NamedType. The terminals are further categorized as either element terminals or attribute terminals. A terminal is an attribute terminal if its associated NamedType is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction, otherwise it is an element terminal. In the examples in this document the terminal for a component other than an attribute component will be represented as the effective name of the component enclosed in quotes, and the terminal for an attribute component will be represented as the effective name of the component prefixed by the @ character and enclosed in quotes. The productions generated from a NamedType depend on the type of the NamedType. The productions for the start non-terminals depend on the combining type definition being tested. In either case, the procedure for generating productions takes a primary non-terminal, a secondary non-terminal (sometimes), and a type definition. The grammar is constructed beginning with the start non-terminals and the combining type definition being tested. Given a primary non-terminal, N, and a SEQUENCE or SET type, a production is added to the grammar with N as the left hand side. The right hand side is constructed from an initial empty state according to the following cases considered in order: (1) If the initial RootComponentTypeList is present then the sequence of primary non-terminals for the components in that RootComponentTypeList are appended to the right hand side in the order of their definition. (2) If the ExtensionAdditions is present then the non-terminal for the first ExtensionAddition is appended to the right hand side. Legg Expires 11 August 2005 [Page 28] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 (3) If the final RootComponentTypeList is present then the sequence of primary non-terminals for the components in that RootComponentTypeList are appended to the right hand side in the order of their definition. If an ExtensionAddition is a ComponentType then a production is added to the grammar where the left hand side is the non-terminal for the ExtensionAddition and the right hand side is the non-terminal for the NamedType of the ComponentType followed by the non-terminal for the next ExtensionAddition, if any. If the empty sequence of terminals cannot be generated from this production (it may be necessary to wait until the grammar is otherwise complete before making this determination) then another production is added to the grammar where the left hand side is the non-terminal for the ExtensionAddition and the right hand side is empty. ASIDE: An extension is always effectively optional since a sender may be using an earlier version of the ASN.1 specification where none, or only some, of the extensions have been defined. ASIDE: The grammar generated for ExtensionAdditions is structured to take account of the condition that an extension can only be used if all the earlier extensions are also used [X.680]. If an ExtensionAddition is an ExtensionAdditionGroup then a production is added to the grammar where the left hand side is the non-terminal for the ExtensionAddition and the right hand side is the sequence of primary non-terminals for the components in the ComponentTypeList of the ExtensionAdditionGroup, in the order of their definition, followed by the non-terminal for the next ExtensionAddition, if any. If the empty sequence of terminals cannot be generated from this production then another production is added to the grammar where the left hand side is the non-terminal for the ExtensionAddition and the right hand side is empty. If a component in a ComponentTypeList (in either a RootComponentTypeList or an ExtensionAdditionGroup) is OPTIONAL or DEFAULT then a production with the primary non-terminal as the left hand side and an empty right hand side is added to the grammar. If a component (regardless of the ASN.1 combining type containing it) is subject to a CONTENT encoding instruction then a production is added to the grammar with the non-terminal name of the component as the left hand side and a right hand side constructed according to the component's type. If a component (regardless of the ASN.1 combining type containing it) is not subject to a CONTENT encoding instruction then a production is Legg Expires 11 August 2005 [Page 29] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 added to the grammar with the non-terminal of the component as the left hand side and the terminal of the component as the right hand side. Example Consider the following commented ASN.1 type definition: SEQUENCE { -- start of initial RootComponentTypeList one BOOLEAN, two INTEGER OPTIONAL, -- end of initial RootComponentTypeList ..., -- start of ExtensionAdditions four INTEGER, -- first ExtensionAddition (E1) five BOOLEAN OPTIONAL, -- second ExtensionAddition (E2) [[ -- an ExtensionAdditionGroup six UTF8String, seven INTEGER OPTIONAL ]], -- third ExtensionAddition (E3) -- end of ExtensionAdditions ..., -- start of final RootComponentTypeList three INTEGER } Here is the grammar derived from this type: S ::= One Two E1 Three One ::= "one" Two ::= "two" Two ::= E1 ::= Four E2 E1 ::= Four ::= "four" E2 ::= Five E3 Five ::= "five" Five ::= E3 ::= Six Seven E3 ::= Six ::= "six" Seven ::= "seven" Seven ::= Three ::= "three" Given a primary non-terminal, N, and a CHOICE type: Legg Expires 11 August 2005 [Page 30] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 (1) a production is added to the grammar for each NamedType in the RootAlternativeTypeList of the CHOICE, where the left hand side is N and the right hand side is the primary non-terminal for the NamedType, and (2) a production is added to the grammar for each ExtensionAdditionAlternative, where the left hand side is N and the right hand side is the non-terminal for the ExtensionAdditionAlternative. If an ExtensionAdditionAlternative is a NamedType then a production is added to the grammar where the left hand side is the non-terminal for the ExtensionAdditionAlternative and the right hand side is the non-terminal for the NamedType. If an ExtensionAdditionAlternative is an ExtensionAdditionAlternativesGroup then a production is added to the grammar for each NamedType in the AlternativeTypeList for the ExtensionAdditionAlternativesGroup, where the left hand side is the non-terminal for the ExtensionAdditionAlternative and the right hand side is the non-terminal for the NamedType. Example Consider the following commented ASN.1 type definition: CHOICE { -- start of RootAlternativeTypeList one BOOLEAN, two INTEGER, -- end of RootAlternativeTypeList ..., -- start of ExtensionAdditionAlternatives three INTEGER, -- first ExtensionAdditionAlternative (E1) [[ -- an ExtensionAdditionAlternativesGroup four UTF8String, five INTEGER ]] -- second ExtensionAdditionAlternative (E2) } Here is the grammar derived from this type: S ::= One S ::= Two S ::= E1 S ::= E2 E1 ::= Three E2 ::= Four Legg Expires 11 August 2005 [Page 31] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 E2 ::= Five One ::= "one" Two ::= "two" Three ::= "three" Four ::= "four" Five ::= "five" Constraints on a SEQUENCE, SET or CHOICE type are ignored. They do not affect the grammar being generated. ASIDE: This avoids an awkward situation where values of a subtype have to be decoded differently from values of the parent type. It also simplifies the verification procedure. Given a primary non-terminal, N, and a possibly constrained SEQUENCE OF or SET OF type that permits a value of size zero (an empty set): (1) a production is added to the grammar where the left hand side of the production is N and the right hand side is the primary non-terminal for the NamedType of the component of the SEQUENCE OF or SET OF type, followed by N, and (2) a production is added to the grammar where the left hand side of the production is N and the right hand side is empty. Given a primary non-terminal, N, a secondary non-terminal, L, and a constrained SEQUENCE OF or SET OF type that does not permit a value of size zero: (1) a production is added to the grammar where the left hand side of the production is N and the right hand side is the non-terminal for the NamedType of the component of the SEQUENCE OF or SET OF type, followed by L, and (2) a production is added to the grammar where the left hand side of the production is L and the right hand side is the non-terminal for the NamedType of the component of the SEQUENCE OF or SET OF type, followed by L, and (3) a production is added to the grammar where the left hand side of the production is L and the right hand side is empty. This completes the description of the transformation of ASN.1 combining type definitions into a grammar. 20.2.1.1. Future Extensions Legg Expires 11 August 2005 [Page 32] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 The grammar constructed using the procedure in the previous section deliberately ignores potential ambiguity arising out of extensions yet to be defined. Consider the following ASN.1 type definition with extension markers: CHOICE { a [CONTENT] CHOICE { b INTEGER, ... }, c [CONTENT] CHOICE { d INTEGER, ... }, ... } The RXER encodings of values of this type will normally be a single element with the name "b" or "d", but suppose a sender using a revision of the specification encodes an element with the name "e". From the perspective of the receiver this unexpected element could be an extension to the outermost CHOICE, or to either of the inner CHOICEs. In effect, the encoding is ambiguous. To avoid this ambiguity the specification writer would have to eliminate the CONTENT encoding instructions or eliminate all but one of the extension markers. This example illustrates one of the various ways in which the CONTENT encoding instruction and extensibility are at odds. In order to not unduly restrict the utility of extensibility and the CONTENT encoding instruction, potential ambiguity with respect to future extensions is disregarded. The justification for doing so comes from the following two observations: (1) If the encoding of an abstract value contains an extension where the type of the extension is unknown to the receiver then it is generally impossible to re-encode the value using a different set of encoding rules, including the canonical variant of the received encoding. This is true no matter which encoding rules are being used. It is desirable for a decoder to be able to accept and store the raw encoding of an extension without raising an error, and to re-insert the raw encoding of the extension when re-encoding the abstract value using the same non-canonical encoding rules. However, there is little more that an application can do with an unknown extension. An application using RXER can successfully accept, store and re-encode an unknown extension regardless of which extension Legg Expires 11 August 2005 [Page 33] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 marker it might be ascribed to. (2) Even if there is a single extension marker, an unknown extension allowed by that marker could still be the encoding of a value of any one of an infinite number of valid type definitions. For example, the "e" element could be nested to any arbitrary depth within CHOICEs whose components are subject to CONTENT encoding instructions. ASIDE: A similar series of nested CHOICEs could describe an unknown extension in a BER encoding [X.690]. An application designer can always choose to remove ambiguity with respect to future extensions by the more judicious use of extension markers and CONTENT encoding instructions. To this end, ASN.1 compiler implementors should consider providing the option to issue warnings where such potential ambiguity exists in an ASN.1 specification. 20.2.2. Deterministic Grammars Let the First Set of a production P, denoted First(P), be the set of all element terminals T for which a sequence of terminals can be generated from the right hand side of P where T is the first element terminal, i.e., there can be any number of leading attribute terminals. Let the Follow Set of a non-terminal N, denoted Follow(N), be the set of all element terminals T for which a sequence of non-terminals and terminals can be generated from the grammar where T is the first element terminal following N, i.e., there can be any number of intervening attribute terminals. If a sequence of non-terminals and terminals can be generated from the grammar where N is not followed by any element terminals then Follow(N) also contains a special end terminal, denoted by the $ character. The Select Set of a production P, denoted Select(P), contains First(P). Let N be the non-terminal on the left hand side of P. If the empty sequence of terminals can be generated from P then Select(P) also contains Follow(N). ASIDE: It may appear somewhat dubious to include the attribute components in the grammar because in reality attributes appear unordered within the start tag of an element, and not interspersed with the child elements as the grammar would suggest. This is why attribute terminals are ignored in composing the First and Follow Sets. However the attribute terminals are important in composing the Select Sets because they can block a production from being Legg Expires 11 August 2005 [Page 34] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 able to generate an empty sequence of terminals. In real terms, this corresponds to an RXER decoder using the attributes (as well as the child elements) to determine the presence or absence of optional components and to select between the alternatives of a CHOICE. Let the Reach Set of a non-terminal N, denoted Reach(N), be the set of all element terminals T for which a sequence of terminals including T can be generated from the right hand side of P. ASIDE: It can be readily shown that all the optional attribute components and all but one of the mandatory attribute components of a SEQUENCE or SET type can be ignored in constructing the grammar because their omission does not alter the First, Follow, Select or Reach Sets. A grammar is deterministic (for the purposes of an RXER decoder) if and only if: (1) there does not exist two productions P and Q, with the same non- terminal on the left hand side, where the intersection of Select(P) and Select(Q) is not empty, and (2) there does not exist a non-terminal E for an ExtensionAddition or ExtensionAdditionAlternative where the intersection of Reach(E) and Follow(E) is not empty. ASIDE: In case (1), if the intersection is not empty then a decoder would have two or more possible ways to attempt to decode the input into an abstract value. In case (2), if the intersection is not empty then a decoder using an earlier version of the ASN.1 specification would confuse an element in an unknown (to the decoder) extension with a known component following the extension. ASIDE: In the absence of any attribute components, case (1) is the test for an LL(1) grammar. For every ASN.1 combining type containing components that are subject to a CONTENT encoding instruction, the grammar derived by the method described in this document MUST be deterministic. 21. Security Considerations ASN.1 compiler implementors should take special care to be thorough in checking that the CONTENT encoding instruction has been correctly used, otherwise ASN.1 specifications with ambiguous RXER encodings could be deployed. Legg Expires 11 August 2005 [Page 35] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Ambiguous encodings mean that the abstract value recovered by a decoder may differ from the original abstract value that was encoded. If that is the case then a digital signature generated with respect to the original abstract value (using a canonical encoding other than CRXER) will not be successfully verified by a receiver using the decoded abstract value. Also, an abstract value may have security- sensitive fields, and in particular fields used to grant or deny access. If the decoded abstract value differs from the encoded abstract value then a receiver using the decoded abstract value will be applying different security policy to that embodied in the original abstract value. 22. IANA Considerations This document has no actions for IANA. Appendix A. CONTENT Encoding Instruction Examples This appendix is non-normative. This appendix contains examples of both correct and incorrect use of the CONTENT encoding instruction, determined with respect to the grammars derived from the example type definitions. The productions of the grammars are labeled for convenience. A.1. Example 1 Consider this type definition: SEQUENCE { one [CONTENT] SEQUENCE { two UTF8String OPTIONAL, } OPTIONAL, three INTEGER } The associated grammar is: P1: S ::= One Three P2: One ::= Two P3: One ::= P4: Two ::= "two" P5: Two ::= P6: Three ::= "three" Select Sets have to be evaluated to test the validity of the type definition. The grammar leads to the following sets (noting that P2 can generate an empty sequence of terminals): Legg Expires 11 August 2005 [Page 36] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 First(P2) = { "two" } Select(P2) = { "two", "three" } First(P3) = { } Select(P3) = Follow(One) = { "three" } Select(P4) = First(P4) = { "two" } Select(P5) = Follow(Two) = { "three" } Select(P2) is the union of First(P2) and Follow(One). The intersection of Select(P2) and Select(P3) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type definition could be characterized like so: if the RXER encoding of a value of the type does not have a child element then it is not possible to determine whether the "one" component is present or absent in the value. Now consider this type definition with attributes in the "one" component: SEQUENCE { one [CONTENT] SEQUENCE { two UTF8String OPTIONAL, four [ATTRIBUTE] BOOLEAN, five [ATTRIBUTE] BOOLEAN OPTIONAL } OPTIONAL, three INTEGER } The associated grammar is: P1: S ::= One Three P2: One ::= Two Four Five P3: One ::= P4: Two ::= "two" P5: Two ::= P6: Four ::= "@four" P7: Five ::= "@five" P8: Five ::= P9: Three ::= "three" This grammar leads to the following sets: Select(P2) = First(P2) = { "two" } First(P3) = { } Select(P3) = Follow(One) = { "three" } Select(P4) = First(P4) = { "two" } Legg Expires 11 August 2005 [Page 37] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Select(P5) = Follow(Two) = { "three" } Select(P7) = First(P7) = { } Select(P8) = First(P8) = { } Follow(One) is not added to Select(P2) because P2 cannot generate an empty sequence of terminals. The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5), and the intersection of Select(P7) and Select(P8), hence the grammar is deterministic and the type definition is valid. In a correct RXER encoding the component "one" will be present if and only if the attribute "four" is present. A.2. Example 2 Consider this type definition: CHOICE { one [CONTENT] SEQUENCE { two [ATTRIBUTE] BOOLEAN OPTIONAL }, three INTEGER, four [CONTENT] SEQUENCE { five BOOLEAN OPTIONAL } } The associated grammar is: P1: S ::= One P2: S ::= Three P3: S ::= Four P4: One ::= Two P5: Two ::= "@two" P6: Two ::= P7: Three ::= "three" P8: Four ::= Five P9: Five ::= "five" P10: Five ::= This grammar leads to the following sets (noting that P1, P3, P4 and P8 can generate an empty sequence of terminals): First(P1) = { } Select(P1) = Follow(S) = { $ } Select(P2) = First(P2) = { "three" } First(P3) = { "five" } Legg Expires 11 August 2005 [Page 38] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Select(P3) = { "five", $ } Select(P5) = First(P5) = { } Select(P6) = Follow(Two) = { $ } Select(P9) = First(P9) = { "five" } Select(P10) = Follow(Five) = { $ } The intersection of Select(P1) and Select(P3) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type definition could be characterized like so: if the RXER encoding of a value of the type is empty then it is not possible to determine whether the "one" alternative or the "four" alternative has been chosen. Now consider this slightly different type definition: CHOICE { one [CONTENT] SEQUENCE { two [ATTRIBUTE] BOOLEAN }, three INTEGER, four [CONTENT] SEQUENCE { five BOOLEAN OPTIONAL } } The associated grammar is: P1: S ::= One P2: S ::= Three P3: S ::= Four P4: One ::= Two P5: Two ::= "@two" P6: Three ::= "three" P7: Four ::= Five P8: Five ::= "five" P9: Five ::= This grammar leads to the following sets (noting that P3 and P7 can generate an empty sequence of terminals): Select(P1) = First(P1) = { } Select(P2) = First(P2) = { "three" } First(P3) = { "five" } Select(P3) = { "five", $ } Select(P8) = First(P8) = { "five" } Legg Expires 11 August 2005 [Page 39] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Select(P9) = Follow(Five) = { $ } The intersection of Select(P1) and Select(P2) is empty, the intersection of Select(P1) and Select(P3) is empty, the intersection of Select(P2) and Select(P3) is empty, and the intersection of Select(P8) and Select(P9) is empty, hence the grammar is deterministic and the type definition is valid. The "one" and "four" alternatives can be distinguished because the "one" alternative has a mandatory attribute. A.3. Example 3 Consider this type definition: SEQUENCE { one CHOICE { two [ATTRIBUTE] BOOLEAN, three [CONTENT] SEQUENCE OF number INTEGER } OPTIONAL } The associated grammar is: P1: S ::= One P2: One ::= Two P3: One ::= Three P4: One ::= P5: Two ::= "@two" P6: Three ::= Number Three P7: Three ::= P8: Number ::= "number" This grammar leads to the following sets (noting that P1 and P3 can generate an empty sequence of terminals): Select(P2) = First(P2) = { } First(P3) = { "number" } Select(P3) = { "number", $ } Select(P4) = Follow(One) = { $ } Select(P6) = First(P6) = { "number" } First(P7) = { } Select(P7) = Follow(Three) = { $ } The intersection of Select(P3) and Select(P4) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type definition could be characterized like so: if the RXER encoding of a value of the type is empty then it is not Legg Expires 11 August 2005 [Page 40] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 possible to determine whether the "one" component is absent or the empty "three" alternative has been chosen. A.4. Example 4 Consider this type definition: SEQUENCE { one CHOICE { two [ATTRIBUTE] BOOLEAN, three [ATTRIBUTE] BOOLEAN, } OPTIONAL } The associated grammar is: P1: S ::= One P2: One ::= Two P3: One ::= Three P4: One ::= P5: Two ::= "@two" P6: Three ::= "@three" This grammar leads to the following sets: Select(P2) = First(P2) = { } Select(P3) = First(P3) = { } Select(P4) = Follow(One) = { $ } The intersection of Select(P2) and Select(P3) is empty, the intersection of Select(P2) and Select(P4) is empty, and the intersection of Select(P3) and Select(P4) is empty, hence the grammar is deterministic and the type definition is valid. A.5. Example 5 Consider this type definition: SEQUENCE { one [CONTENT] SEQUENCE OF number INTEGER OPTIONAL } The associated grammar is: P1: S ::= One P2: One ::= Number One P3: One ::= P4: One ::= Legg Expires 11 August 2005 [Page 41] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 P5: Number ::= "number" P3 is generated during the processing of the SEQUENCE OF type. P4 is generated because the "one" component is optional. This grammar leads to the following sets: Select(P2) = First(P2) = { "number" } First(P3) = First(P4) = { } Select(P3) = Select(P4) = Follow(One) = { $ } The intersection of Select(P3) and Select(P4) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type definition could be characterized like so: if the RXER encoding of a value of the type does not have any child elements then it is not possible to determine whether the "one" component is present or absent in the value. Consider this similar type definition with a SIZE constraint: SEQUENCE { one [CONTENT] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL } The associated grammar is: P1: S ::= One P2: One ::= Number L-One P3: L-One ::= Number L-One P4: L-One ::= P5: One ::= P6: Number ::= "number" This grammar leads to the following sets: Select(P2) = First(P2) = { "number" } Select(P5) = Follow(One) = { $ } Select(P3) = First(P3) = { "number" } Select(P4) = Follow(L-One) = { $ } The intersection of Select(P2) and Select(P5) is empty, as is the intersection of Select(P3) and Select(P4), hence the grammar is deterministic and the type definition is valid. If there are no child elements then the "one" component is necessarily absent, and there is no ambiguity. A.6. Example 6 Legg Expires 11 August 2005 [Page 42] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 Consider this type definition: SEQUENCE { beginning [CONTENT] List, middle UTF8String OPTIONAL, end [CONTENT] List } List ::= SEQUENCE OF string UTF8String The associated grammar is: P1: S ::= Beginning Middle End P2: Beginning ::= String Beginning P3: Beginning ::= P4: Middle ::= "middle" P5: Middle ::= P6: End ::= String End P7: End ::= P8: String ::= "string" This grammar leads to the following sets: Select(P2) = First(P2) = { "string" } First(P3) = { } Select(P3) = Follow(Beginning) = { "middle", "string", $ } Select(P4) = First(P4) = { "middle" } First(P5) = { } Select(P5) = Follow(Middle) = { "string", $ } Select(P6) = First(P6) = { "string" } First(P7) = { } Select(P7) = Follow(End) = { $ } The intersection of Select(P2) and Select(P3) is not empty, hence the grammar is not deterministic and the type definition is not valid. Now consider the following type definition: SEQUENCE { beginning [CONTENT] List, middleAndEnd [CONTENT] SEQUENCE { middle UTF8String, end [CONTENT] List } OPTIONAL } Legg Expires 11 August 2005 [Page 43] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 The associated grammar is: P1: S ::= Beginning MiddleAndEnd P2: Beginning ::= String Beginning P3: Beginning ::= P4: MiddleAndEnd ::= Middle End P5: MiddleAndEnd ::= P6: Middle ::= "middle" P7: End ::= String End P8: End ::= P9: String ::= "string" This grammar leads to the following sets: Select(P2) = First(P2) = { "string" } First(P3) = { } Select(P3) = Follow(Beginning) = { "middle", $ } Select(P4) = First(P4) = { "middle" } First(P5) = { } Select(P5) = Follow(MiddleAndEnd) = { $ } Select(P7) = First(P7) = { "string" } First(P8) = { } Select(P8) = Follow(End) = { $ } The intersection of Select(P2) and Select(P3) is empty, as is the intersection of Select(P4) and Select(P5), and the intersection of Select(P7) and Select(P8), hence the grammar is deterministic and the type definition is valid. A.7. Example 7 Consider the following type definition: SEQUENCE SIZE(1..MAX) OF one [CONTENT] SEQUENCE { two INTEGER OPTIONAL } The associated grammar is: P1: S ::= One L-S P2: L-S ::= One L-S P3: L-S ::= P4: One ::= Two P5: Two ::= "two" P6: Two ::= Legg Expires 11 August 2005 [Page 44] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 This grammar leads to the following sets (noting that all productions can generate an empty sequence of terminals): First(P2) = { "two" } Select(P2) = { "two", $ } First(P3) = { } Select(P3) = Follow(L-S) = { $ } Select(P5) = First(P5) = { "two" } First(P6) = { } Select(P6) = Follow(Two) = { "two" } The intersection of Select(P2) and Select(P3) is not empty, and the intersection of Select(P5) and Select(P6) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type could be characterized like so: the encoding of a value of the type contains an indeterminate number of empty instances of the component type. A.8. Example 8 Consider the following type definition: SEQUENCE OF list [CONTENT] SEQUENCE SIZE(1..MAX) OF number INTEGER The associated grammar is: P1: S ::= List S P2: S ::= P3: List ::= Number L-List P4: L-List ::= Number L-List P5: L-List ::= P6: Number ::= "number" This grammar leads to the following sets: Select(P1) = First(P1) = { "number" } First(P2) = { } Select(P2) = Follow(S) = { $ } Select(P4) = First(P4) = { "number" } First(P5) = { } Select(P5) = Follow(L-List) = { "number" } The intersection of Select(P4) and Select(P5) is not empty, hence the grammar is not deterministic and the type definition is not valid. The problem with the type could be characterized like so: the type Legg Expires 11 August 2005 [Page 45] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 describes a list of lists but it is not possible to determine where the outer lists begin and end. A.9. Example 9 Consider the following type definition: SEQUENCE OF item [CONTENT] SEQUENCE { before [CONTENT] OneAndTwo, core UTF8String, after [CONTENT] OneAndTwo OPTIONAL } OneAndTwo ::= SEQUENCE { non-core UTF8String } The associated grammar is: P1: S ::= Item S P2: S ::= P3: Item ::= Before Core After P4: Before ::= Non-Core P5: Non-Core ::= "non-core" P6: Core ::= "core" P7: After ::= Non-Core P8: After ::= This grammar leads to the following sets: Select(P1) = First(P1) = { "non-core" } Select(P2) = Follow(S) = { $ } Select(P7) = First(P7) = { "non-core" } Select(P8) = Follow(After) = Follow(Item) = { "non-core", $ } The intersection of Select(P2) and Select(P3) is not empty, hence the grammar is not deterministic and the type definition is not valid. There is ambiguity between the end of one item and the start of the next. Without looking ahead in an encoding, it is not possible to determine whether a element belongs with the preceding or following element. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Legg Expires 11 August 2005 [Page 46] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules", RFC 3687, February 2004. [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RXER] Legg, S., "Robust XML Encoding Rules for Abstract Syntax Notation One (ASN.1)", draft-legg-xed-rxer-xx.txt, a work in progress, February 2005. [ASD] Legg, S. and D. Prager, "ASN.1 Schema: An XML Representation for Abstract Syntax Notation One (ASN.1) Specifications", draft-legg-xed-asd-xx.txt, a work in progress, June 2004. [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] Amendment 1: to ITU-T Rec. X.680 | ISO/IEC 8824-1 [X.693] ITU-T Recommendation X.693 (12/01) | ISO/IEC 8825-4:2002, Information technology - ASN.1 encoding rules: XML encoding rules (XER) [X.693-1] Amendment 1: (to ITU-T Rec. X.693 | ISO/IEC 8825-4) XER encoding instructions and EXTENDED-XER [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation, http://www.w3.org/TR/2004/REC-xml-20040204, February 2004. [XMLNS] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999. [XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502, May 2001. [XSD2] Biron, P.V. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502, May 2001. Legg Expires 11 August 2005 [Page 47] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 [RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS Committee Specification, http://www.oasis- open.org/committees/relax-ng/tutorial-20011203.html, December 2001. Informative References [CXSD] Legg, S. and D. Prager, "Translation of ASN.1 Specifications into XML Schema", draft-legg-xed-xsd-xx.txt, a work in progress, to be published. [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). Author's Address 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 Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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 Legg Expires 11 August 2005 [Page 48] INTERNET-DRAFT Encoding Instructions for RXER February 11, 2005 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. Legg Expires 11 August 2005 [Page 49]