diff options
Diffstat (limited to 'doc/rfc/rfc4911.txt')
| -rw-r--r-- | doc/rfc/rfc4911.txt | 5099 |
1 files changed, 5099 insertions, 0 deletions
diff --git a/doc/rfc/rfc4911.txt b/doc/rfc/rfc4911.txt new file mode 100644 index 0000000..1acd27d --- /dev/null +++ b/doc/rfc/rfc4911.txt @@ -0,0 +1,5099 @@ + + + + + + +Network Working Group S. Legg +Request for Comments: 4911 eB2Bcom +Category: Experimental July 2007 + + + Encoding Instructions for the + Robust XML Encoding Rules (RXER) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document defines encoding instructions that may be used in an + Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 + 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 value 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 Abstract Syntax Notation X (ASN.X) specification. Encoding + instructions that allow an ASN.1 specification to reference + definitions in other XML schema languages are also defined. + + + + + + + + + + + + + + + + + + + + +Legg Experimental [Page 1] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions .....................................................3 + 3. Definitions .....................................................4 + 4. Notation for RXER Encoding Instructions .........................4 + 5. Component Encoding Instructions .................................6 + 6. Reference Encoding Instructions .................................8 + 7. Expanded Names of Components ...................................10 + 8. The ATTRIBUTE Encoding Instruction .............................11 + 9. The ATTRIBUTE-REF Encoding Instruction .........................12 + 10. The COMPONENT-REF Encoding Instruction ........................13 + 11. The ELEMENT-REF Encoding Instruction ..........................16 + 12. The LIST Encoding Instruction .................................17 + 13. The NAME Encoding Instruction .................................19 + 14. The REF-AS-ELEMENT Encoding Instruction .......................19 + 15. The REF-AS-TYPE Encoding Instruction ..........................20 + 16. The SCHEMA-IDENTITY Encoding Instruction ......................22 + 17. The SIMPLE-CONTENT Encoding Instruction .......................22 + 18. The TARGET-NAMESPACE Encoding Instruction .....................23 + 19. The TYPE-AS-VERSION Encoding Instruction ......................24 + 20. The TYPE-REF Encoding Instruction .............................25 + 21. The UNION Encoding Instruction ................................26 + 22. The VALUES Encoding Instruction ...............................27 + 23. Insertion Encoding Instructions ...............................29 + 24. The VERSION-INDICATOR Encoding Instruction ....................32 + 25. The GROUP Encoding Instruction ................................34 + 25.1. Unambiguous Encodings ....................................36 + 25.1.1. Grammar Construction ..............................37 + 25.1.2. Unique Component Attribution ......................47 + 25.1.3. Deterministic Grammars ............................52 + 25.1.4. Attributes in Unknown Extensions ..................54 + 26. Security Considerations .......................................56 + 27. References ....................................................56 + 27.1. Normative References .....................................56 + 27.2. Informative References ...................................57 + Appendix A. GROUP Encoding Instruction Examples ...................58 + Appendix B. Insertion Encoding Instruction Examples ...............74 + Appendix C. Extension and Versioning Examples .....................87 + + + + + + + + + + + + +Legg Experimental [Page 2] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +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 ASN.1 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 value as an + Extensible Markup Language (XML) [XML10] attribute rather than as a + child element. Some of these encoding instructions also affect how + an ASN.1 specification is translated into an Abstract Syntax Notation + X (ASN.X) specification [ASN.X]. + + This document also defines encoding instructions that allow an ASN.1 + 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 XML document type + definition (DTD) [XML10] 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.X [ASN.X], 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 "xsi:" to stand for the + namespace name [XMLNS10] "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". + + + + + +Legg Experimental [Page 3] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +3. Definitions + + The following definition of base type is used in specifying a number + of encoding instructions. + + Definition (base type): If a type, T, is a constrained type, then the + base type of T is the base type of the type that is constrained; else + if T is a prefixed type, then the base type of T is the base type of + the type that is prefixed; else if T is a type notation that + references or denotes another type (i.e., DefinedType, + ObjectClassFieldType, SelectionType, TypeFromObject, or + ValueSetFromObjects), then the base type of T is the base type of the + type that is referenced or denoted; otherwise, the base type of T is + T itself. + + Aside: A tagged type is a special case of a prefixed type. + +4. 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 + 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 is defined as follows, using the + conventions of the ASN.1 basic notation: + + + + + + + + +Legg Experimental [Page 4] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + EncodingInstruction ::= + AttributeInstruction | + AttributeRefInstruction | + ComponentRefInstruction | + ElementRefInstruction | + GroupInstruction | + InsertionsInstruction | + ListInstruction | + NameInstruction | + RefAsElementInstruction | + RefAsTypeInstruction | + SimpleContentInstruction | + TypeAsVersionInstruction | + TypeRefInstruction | + UnionInstruction | + ValuesInstruction | + VersionIndicatorInstruction + + In the context of the RXER encoding reference, the + EncodingInstructionAssignmentList production (which only appears in + an encoding control section) is defined as follows: + + EncodingInstructionAssignmentList ::= + SchemaIdentityInstruction ? + TargetNamespaceInstruction ? + TopLevelComponents ? + + TopLevelComponents ::= TopLevelComponent TopLevelComponents ? + + TopLevelComponent ::= "COMPONENT" NamedType + + Definition (top-level NamedType): A NamedType is a top-level + NamedType (equivalently, a top-level component) if and only if it is + the NamedType in a TopLevelComponent. A NamedType nested within the + Type of the NamedType of a TopLevelComponent is not itself a + top-level NamedType. + + Aside: Specification writers should note that non-trivial types + defined within a top-level NamedType will not be visible to ASN.1 + tools that do not understand RXER. + + Although a top-level NamedType only appears in an RXER encoding + control section, the default encoding reference for the module + [X.680-1] still applies when parsing a top-level NamedType. + + Each top-level NamedType within a module SHALL have a distinct + identifier. + + + + +Legg Experimental [Page 5] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The NamedType production is 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 + + The Value production is defined by the ASN.1 basic notation. + + The governing type for the Value in an NCNameValue is the NCName type + from the AdditionalBasicDefinitions module [RXER]. + + The governing type for the Value in an AnyURIValue is the AnyURI type + from the AdditionalBasicDefinitions module. + + The governing type for the Value in a QNameValue is the QName type + from the AdditionalBasicDefinitions module. + + The governing type for the Value in a NameValue is the Name type from + the AdditionalBasicDefinitions module. + + The Value in an NCNameValue, AnyURIValue, QNameValue, or NameValue + SHALL NOT be a DummyReference [X.683] and SHALL NOT textually contain + a nested DummyReference. + + Aside: Thus, encoding instructions are not permitted to be + parameterized in any way. This restriction will become important + if a future specification for ASN.X explicitly represents + parameterized definitions and parameterized references instead of + expanding out parameterized references as in the current + specification. A parameterized definition could not be directly + translated into ASN.X if it contained encoding instructions that + were not fully specified. + +5. Component Encoding Instructions + + Certain of the RXER encoding instructions are categorized as + component encoding instructions. The component encoding instructions + are the ATTRIBUTE, ATTRIBUTE-REF, COMPONENT-REF, GROUP, ELEMENT-REF, + NAME, REF-AS-ELEMENT, SIMPLE-CONTENT, TYPE-AS-VERSION, and + VERSION-INDICATOR encoding instructions (whose notations are + described respectively by AttributeInstruction, + AttributeRefInstruction, ComponentRefInstruction, GroupInstruction, + + + +Legg Experimental [Page 6] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + ElementRefInstruction, NameInstruction, RefAsElementInstruction, + SimpleContentInstruction, TypeAsVersionInstruction, and + VersionIndicatorInstruction). + + The Type in the EncodingPrefixedType for a component encoding + instruction SHALL be either: + + (1) the Type in a NamedType, or + + (2) the Type in an EncodingPrefixedType in a PrefixedType in a + BuiltinType in a Type that is one of (1) to (4), or + + (3) the Type in an TaggedType in a PrefixedType in a BuiltinType in a + Type that is one of (1) to (4), or + + (4) the Type in a ConstrainedType (excluding a TypeWithConstraint) in + a Type that is one of (1) to (4). + + Aside: The effect of this condition is to force the component + encoding instructions to be textually within the NamedType to + which they apply. Only case (2) can be true on the first + iteration as the Type belongs to an EncodingPrefixedType; however, + any of (1) to (4) can be true on subsequent iterations. + + Case (4) is not permitted when the encoding instruction is the + ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, or REF-AS-ELEMENT encoding + instruction. + + The NamedType in case (1) is said to be "subject to" the component + encoding instruction. + + A top-level NamedType SHALL NOT be subject to an ATTRIBUTE-REF, + COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, or SIMPLE-CONTENT + encoding instruction. + + Aside: This condition does not preclude these encoding + instructions being used on a nested NamedType. + + A NamedType 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, COMPONENT-REF, GROUP, ELEMENT-REF, + REF-AS-ELEMENT, SIMPLE-CONTENT, and TYPE-AS-VERSION encoding + instructions are mutually exclusive. The NAME, ATTRIBUTE-REF, + COMPONENT-REF, ELEMENT-REF, and REF-AS-ELEMENT encoding instructions + are mutually exclusive. A NamedType SHALL NOT be subject to two or + more encoding instructions that are mutually exclusive. + + + +Legg Experimental [Page 7] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + A SelectionType [X.680] SHALL NOT be used to select the Type from a + NamedType that is subject to an ATTRIBUTE-REF, COMPONENT-REF, + ELEMENT-REF or REF-AS-ELEMENT encoding instruction. The other + component encoding instructions are not inherited by the type denoted + by a SelectionType. + + Definition (attribute component): An attribute component is a + NamedType that is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding + instruction, or subject to a COMPONENT-REF encoding instruction that + references a top-level NamedType that is subject to an ATTRIBUTE + encoding instruction. + + Definition (element component): An element component is a NamedType + that is not subject to an ATTRIBUTE, ATTRIBUTE-REF, GROUP, or + SIMPLE-CONTENT encoding instruction, and not subject to a + COMPONENT-REF encoding instruction that references a top-level + NamedType that is subject to an ATTRIBUTE encoding instruction. + + Aside: A NamedType subject to a GROUP or SIMPLE-CONTENT encoding + instruction is neither an attribute component nor an element + component. + +6. Reference Encoding Instructions + + Certain of the RXER encoding instructions are categorized as + reference encoding instructions. The reference encoding instructions + are the ATTRIBUTE-REF, COMPONENT-REF, ELEMENT-REF, REF-AS-ELEMENT, + REF-AS-TYPE, and TYPE-REF encoding instructions (whose notations are + described respectively by AttributeRefInstruction, + ComponentRefInstruction, ElementRefInstruction, + RefAsElementInstruction, RefAsTypeInstruction, and + TypeRefInstruction). These encoding instructions (except + COMPONENT-REF) 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 Markup ASN.1 type from + the AdditionalBasicDefinitions module [RXER] (for ELEMENT-REF, + REF-AS-ELEMENT, REF-AS-TYPE, and TYPE-REF) or the UTF8String type + (for ATTRIBUTE-REF). References to XML Schema [XSD1] types, + elements, and attributes, RELAX NG [RNG] named patterns and elements, + and XML document type definition (DTD) [XML10] element types are + supported. References to ASN.1 types and top-level components are + also permitted. The COMPONENT-REF encoding instruction provides a + more direct method of referencing a top-level component. + + The Type in the EncodingPrefixedType for an ELEMENT-REF, + REF-AS-ELEMENT, REF-AS-TYPE, or TYPE-REF encoding instruction SHALL + be either: + + + +Legg Experimental [Page 8] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (1) a ReferencedType that is a DefinedType that is a typereference + (not a DummyReference) or ExternalTypeReference that references + the Markup ASN.1 type from the AdditionalBasicDefinitions module + [RXER], or + + (2) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (3), or + + (3) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (3) and the EncodingPrefix in the + EncodingPrefixedType does not contain a reference encoding + instruction. + + Aside: Case (3) and similar cases for the ATTRIBUTE-REF and + COMPONENT-REF encoding instructions have the effect of making the + reference encoding instructions mutually exclusive as well as + singly occurring. + + With respect to the REF-AS-TYPE and TYPE-REF encoding instructions, + the DefinedType in case (1) is said to be "subject to" the encoding + instruction. + + The restrictions on the Type in the EncodingPrefixedType for an + ATTRIBUTE-REF encoding instruction are specified in Section 9. The + restrictions on the Type in the EncodingPrefixedType for a + COMPONENT-REF encoding instruction are specified in Section 10. + + The reference encoding instructions make use of a common production + defined as follows: + + RefParameters ::= ContextParameter ? + + ContextParameter ::= "CONTEXT" AnyURIValue + + A RefParameters instance provides extra information about a reference + to a definition. A ContextParameter is used when a reference is + ambiguous, i.e., refers to definitions in more than one schema + document or external DTD subset. This situation would occur, for + example, when importing types with the same name from independently + developed XML Schemas defined without a target namespace [XSD1]. + When used in conjunction with a reference to an element type in an + external DTD subset, the AnyURIValue in the ContextParameter is the + system identifier (a Uniform Resource Identifier or URI [URI]) of the + external DTD subset; otherwise, the AnyURIValue is a URI that + indicates the intended schema document, either an XML Schema + specification, a RELAX NG specification, or an ASN.1 or ASN.X + specification. + + + +Legg Experimental [Page 9] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +7. Expanded Names of Components + + Each NamedType has an associated expanded name [XMLNS10], determined + as follows: + + (1) if the NamedType is subject to a NAME encoding instruction, then + the local name of the expanded name is the character string + specified by the NCNameValue of the NAME encoding instruction, + + (2) else if the NamedType is subject to a COMPONENT-REF encoding + instruction, then the expanded name is the same as the expanded + name of the referenced top-level NamedType, + + (3) else if the NamedType is subject to an ATTRIBUTE-REF or + ELEMENT-REF encoding instruction, then the namespace name of the + expanded name is equal to the namespace-name component of the + QNameValue of the encoding instruction, and the local name is + equal to the local-name component of the QNameValue, + + (4) else if the NamedType is subject to a REF-AS-ELEMENT encoding + instruction, then the local name of the expanded name is the + LocalPart [XMLNS10] of the qualified name specified by the + NameValue of the encoding instruction, + + (5) otherwise, the local name of the expanded name is the identifier + of the NamedType. + + In cases (1) and (5), if the NamedType is a top-level NamedType and + the module containing the NamedType has a TARGET-NAMESPACE encoding + instruction, then the namespace name of the expanded name is the + character string specified by the AnyURIValue of the TARGET-NAMESPACE + encoding instruction; otherwise, the namespace name has no value. + + Aside: Thus, the TARGET-NAMESPACE encoding instruction applies to + a top-level NamedType but not to any other NamedType. + + In case (4), if the encoding instruction contains a Namespace, then + the namespace name of the expanded name is the character string + specified by the AnyURIValue of the Namespace; otherwise, the + namespace name has no value. + + The expanded names for the attribute components of a CHOICE, + SEQUENCE, or SET type MUST be distinct. The expanded names for the + components of a CHOICE, SEQUENCE, or SET type that are not attribute + components MUST be distinct. These tests are applied after the + COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680]. + + + + + +Legg Experimental [Page 10] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Aside: Two components of the same CHOICE, SEQUENCE, or SET type + may have the same expanded name if one of them is an attribute + component and the other is not. Note that the "not" case includes + components that are subject to a GROUP or SIMPLE-CONTENT encoding + instruction. + + The expanded name of a top-level NamedType subject to an ATTRIBUTE + encoding instruction MUST be distinct from the expanded name of every + other top-level NamedType subject to an ATTRIBUTE encoding + instruction in the same module. + + The expanded name of a top-level NamedType not subject to an + ATTRIBUTE encoding instruction MUST be distinct from the expanded + name of every other top-level NamedType not subject to an ATTRIBUTE + encoding instruction in the same module. + + Aside: Two top-level components may have the same expanded name if + one of them is an attribute component and the other is not. + +8. The ATTRIBUTE Encoding Instruction + + The ATTRIBUTE encoding instruction causes an RXER encoder to encode a + value of 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 base type of the type of a NamedType that is subject to an + ATTRIBUTE encoding instruction SHALL NOT be: + + (1) a CHOICE, SET, or SET OF type, or + + (2) a SEQUENCE type other than the one defining the QName type from + the AdditionalBasicDefinitions module [RXER] (i.e., QName is + allowed), or + + (3) a SEQUENCE OF type where the SequenceOfType is not subject to a + LIST encoding instruction, or + + (4) an open type. + + + + + + + + +Legg Experimental [Page 11] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Example + + PersonalDetails ::= SEQUENCE { + firstName [ATTRIBUTE] UTF8String, + middleName [ATTRIBUTE] UTF8String, + surname [ATTRIBUTE] UTF8String + } + +9. The ATTRIBUTE-REF Encoding Instruction + + The ATTRIBUTE-REF encoding instruction causes an RXER encoder to + encode a value of the component to which it is applied as an XML + attribute instead of as a child element, where the attribute's name + is a qualified name of the attribute declaration referenced by the + encoding instruction. In addition, the ATTRIBUTE-REF encoding + instruction causes values of the UTF8String type to be restricted to + conform to the type of the attribute declaration. + + The notation for an ATTRIBUTE-REF encoding instruction is defined as + follows: + + AttributeRefInstruction ::= + "ATTRIBUTE-REF" QNameValue RefParameters + + Taken together, the QNameValue and the ContextParameter in the + RefParameters (if present) MUST reference an XML Schema attribute + declaration or a top-level NamedType that is subject to an ATTRIBUTE + encoding instruction. + + The type of a referenced XML Schema attribute declaration SHALL NOT + be, either directly or by derivation, the XML Schema type QName, + NOTATION, ENTITY, ENTITIES, or anySimpleType. + + Aside: Values of these types require information from the context + of the attribute for interpretation. Because an ATTRIBUTE-REF + encoding instruction is restricted to prefixing the ASN.1 + UTF8String type, there is no mechanism to capture such context. + + The type of a referenced top-level NamedType SHALL NOT be, either + directly or by subtyping, the QName type from the + AdditionalBasicDefinitions module [RXER]. + + The Type in the EncodingPrefixedType for an ATTRIBUTE-REF encoding + instruction SHALL be either: + + (1) the UTF8String type, or + + + + + +Legg Experimental [Page 12] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (2) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (3), or + + (3) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (3) and the EncodingPrefix in the + EncodingPrefixedType does not contain a reference encoding + instruction. + + The identifier of a NamedType subject to an ATTRIBUTE-REF encoding + instruction does not contribute to the name of attributes in an RXER + encoding. For the sake of consistency, the identifier SHOULD, where + possible, be the same as the local name of the referenced attribute + declaration. + +10. The COMPONENT-REF Encoding Instruction + + The ASN.1 basic notation does not have a concept of a top-level + NamedType and therefore does not have a mechanism to reference a + top-level NamedType. The COMPONENT-REF encoding instruction provides + a way to specify that a NamedType within a combining type definition + is equivalent to a referenced top-level NamedType. + + The notation for a COMPONENT-REF encoding instruction is defined as + follows: + + ComponentRefInstruction ::= "COMPONENT-REF" ComponentReference + + ComponentReference ::= + InternalComponentReference | + ExternalComponentReference + + InternalComponentReference ::= identifier FromModule ? + + FromModule ::= "FROM" GlobalModuleReference + + ExternalComponentReference ::= modulereference "." identifier + + The GlobalModuleReference production is defined by the ASN.1 basic + notation [X.680]. If the GlobalModuleReference is absent from an + InternalComponentReference, then the identifier MUST be the + identifier of a top-level NamedType in the same module. If the + GlobalModuleReference is present in an InternalComponentReference, + then the identifier MUST be the identifier of a top-level NamedType + in the referenced module. + + + + + + +Legg Experimental [Page 13] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The modulereference in an ExternalComponentReference is used in the + same way as a modulereference in an ExternalTypeReference. The + identifier in an ExternalComponentReference MUST be the identifier of + a top-level NamedType in the referenced module. + + The Type in the EncodingPrefixedType for a COMPONENT-REF encoding + instruction SHALL be either: + + (1) a ReferencedType that is a DefinedType that is a typereference + (not a DummyReference) or an ExternalTypeReference, or + + (2) a BuiltinType or ReferencedType that is one of the productions in + Table 1 in Section 5 of the specification for RXER [RXER], or + + (3) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (4), or + + (4) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (4) and the EncodingPrefix in the + EncodingPrefixedType does not contain a reference encoding + instruction. + + The restrictions on the use of RXER encoding instructions are such + that no other RXER encoding instruction is permitted within a + NamedType if the NamedType is subject to a COMPONENT-REF encoding + instruction. + + The Type in the top-level NamedType referenced by the COMPONENT-REF + encoding instruction MUST be either: + + (a) if the preceding case (1) is used, a ReferencedType that is a + DefinedType that is a typereference or ExternalTypeReference that + references the same type as the DefinedType in case (1), or + + (b) if the preceding case (2) is used, a BuiltinType or + ReferencedType that is the same as the BuiltinType or + ReferencedType in case (2), or + + (c) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (a) to (c), and the EncodingPrefix in the + EncodingPrefixedType contains an RXER encoding instruction. + + In principle, the COMPONENT-REF encoding instruction creates a + notional NamedType where the expanded name is that of the referenced + top-level NamedType and the Type in case (1) or (2) is substituted by + the Type of the referenced top-level NamedType. + + + +Legg Experimental [Page 14] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + In practice, it is sufficient for non-RXER encoders and decoders to + use the original NamedType rather than the notional NamedType because + the Type in case (1) or (2) can only differ from the Type of the + referenced top-level NamedType by having fewer RXER encoding + instructions, and RXER encoding instructions are ignored by non-RXER + encoders and decoders. + + Although any prefixes for the Type in case (1) or (2) would be + bypassed, it is sufficient for RXER encoders and decoders to use the + referenced top-level NamedType instead of the notional NamedType + because these prefixes cannot be RXER encoding instructions (except, + of course, for the COMPONENT-REF encoding instruction) and can have + no effect on an RXER encoding. + + Example + + Modules ::= SEQUENCE OF + module [COMPONENT-REF module + FROM AbstractSyntaxNotation-X + { 1 3 6 1 4 1 21472 1 0 1 }] + ModuleDefinition + + Note that the "module" top-level NamedType in the + AbstractSyntaxNotation-X module is defined like so: + + COMPONENT module ModuleDefinition + + The ASN.X translation of the SEQUENCE OF type definition provides + a more natural representation: + + <namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx" + name="Modules"> + <sequenceOf> + <element ref="asnx:module"/> + </sequenceOf> + </namedType> + + Aside: The <namedType> element in ASN.X corresponds to a + TypeAssignment, not a NamedType. + + The identifier of a NamedType subject to a COMPONENT-REF encoding + instruction does not contribute to an RXER encoding. For the sake of + consistency with other encoding rules, the identifier SHOULD be the + same as the identifier in the ComponentRefInstruction. + + + + + + + +Legg Experimental [Page 15] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +11. The ELEMENT-REF Encoding Instruction + + The ELEMENT-REF encoding instruction causes an RXER encoder to encode + a value of the component to which it is applied as an element where + the element's name is a qualified name of the element declaration + referenced by the encoding instruction. In addition, the ELEMENT-REF + encoding instruction causes values of the Markup ASN.1 type to be + restricted to conform to the type of the element declaration. + + The notation for an ELEMENT-REF encoding instruction is defined as + follows: + + ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParameters + + Taken together, the QNameValue and the ContextParameter in the + RefParameters (if present) MUST reference an XML Schema element + declaration, a RELAX NG element definition, or a top-level NamedType + that is not subject to an ATTRIBUTE encoding instruction. + + A referenced XML Schema element declaration MUST NOT have a type that + requires the presence of values for the XML Schema ENTITY or ENTITIES + types. + + Aside: Entity declarations are not supported by CRXER. + + Example + + AnySchema ::= CHOICE { + module [ELEMENT-REF { + namespace-name + "urn:ietf:params:xml:ns:asnx", + local-name "module" }] + Markup, + schema [ELEMENT-REF { + namespace-name + "http://www.w3.org/2001/XMLSchema", + local-name "schema" }] + Markup, + grammar [ELEMENT-REF { + namespace-name + "http://relaxng.org/ns/structure/1.0", + local-name "grammar" }] + Markup + } + + The ASN.X translation of the choice type definition provides a + more natural representation: + + + + +Legg Experimental [Page 16] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + <namedType xmlns:asnx="urn:ietf:params:xml:ns:asnx" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:rng="http://relaxng.org/ns/structure/1.0" + name="AnySchema"> + <choice> + <element ref="asnx:module" embedded="true"/> + <element ref="xs:schema" embedded="true"/> + <element ref="rng:grammar" embedded="true"/> + </choice> + </namedType> + + The identifier of a NamedType subject to an ELEMENT-REF encoding + instruction does not contribute to the name of an element in an RXER + encoding. For the sake of consistency, the identifier SHOULD, where + possible, be the same as the local name of the referenced element + declaration. + +12. 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 for a LIST encoding instruction + SHALL be either: + + (1) a BuiltinType that is a SequenceOfType of the + "SEQUENCE OF NamedType" form, or + + (2) a ConstrainedType that is a TypeWithConstraint of the + "SEQUENCE Constraint OF NamedType" form or + "SEQUENCE SizeConstraint OF NamedType" form, or + + (3) a ConstrainedType that is not a TypeWithConstraint where the Type + in the ConstrainedType is one of (1) to (5), or + + (4) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (5), or + + (5) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (5). + + + + + +Legg Experimental [Page 17] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The effect of this condition is to force the LIST encoding + 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 (1) and the TypeWithConstraint in case (2) + 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 base type of the component type of a SequenceOfType or + TypeWithConstraint that is subject to a LIST encoding instruction + MUST be one of the following: + + (1) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER, + RELATIVE-OID, GeneralizedTime, or UTCTime type, or + + (2) the NCName, AnyURI, Name, or QName type from the + AdditionalBasicDefinitions module [RXER]. + + 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, COMPONENT-REF, GROUP, ELEMENT-REF, + REF-AS-ELEMENT, SIMPLE-CONTENT, or TYPE-AS-VERSION encoding + instruction. + + Example + + UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime + + + + + + + + + +Legg Experimental [Page 18] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +13. 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 "Foo"] INTEGER + } + +14. The REF-AS-ELEMENT Encoding Instruction + + The REF-AS-ELEMENT encoding instruction causes an RXER encoder to + encode a value of 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 Markup ASN.1 type to be restricted to conform to the content and + attributes permitted by that element type declaration and its + associated attribute-list declarations. + + The notation for a REF-AS-ELEMENT encoding instruction is defined as + follows: + + RefAsElementInstruction ::= + "REF-AS-ELEMENT" NameValue Namespace ? RefParameters + + Namespace ::= "NAMESPACE" AnyURIValue + + Taken together, the NameValue and the ContextParameter in the + RefParameters (if present) MUST reference an element type declaration + in an external DTD subset that is conformant with Namespaces in XML + 1.0 [XMLNS10]. + + The Namespace is present if and only if the Name of the referenced + element type declaration conforms to a PrefixedName (a QName) + [XMLNS10], in which case the Namespace specifies the namespace name + to be associated with the Prefix of the PrefixedName. + + + + + +Legg Experimental [Page 19] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The referenced element type declaration MUST NOT require the presence + of attributes of type ENTITY or ENTITIES. + + Aside: Entity declarations are not supported by CRXER. + + Example + + Suppose that the following external DTD subset has been defined + with a system identifier of "http://www.example.com/inventory": + + <?xml version='1.0'?> + <!ELEMENT product EMPTY> + <!ATTLIST product + name CDATA #IMPLIED + partNumber CDATA #REQUIRED + quantity CDATA #REQUIRED > + + The product element type declaration can be referenced as an + element in an ASN.1 type definition: + + CHOICE { + product [REF-AS-ELEMENT "product" + CONTEXT "http://www.example.com/inventory"] + Markup + } + + Here is the ASN.X translation of this ASN.1 type definition: + + <type> + <choice> + <element elementType="product" + context="http://www.example.com/inventory"/> + </choice> + </type> + + The identifier of a NamedType subject to a REF-AS-ELEMENT encoding + instruction does not contribute to the name of an element in an RXER + encoding. For the sake of consistency, the identifier SHOULD, where + possible, be the same as the Name of the referenced element type + declaration (or the LocalPart if the Name conforms to a + PrefixedName). + +15. The REF-AS-TYPE Encoding Instruction + + The REF-AS-TYPE encoding instruction causes values of the Markup + ASN.1 type to be restricted to conform to the content and attributes + permitted by a nominated element type declaration and its associated + attribute-list declarations in an external DTD subset. + + + +Legg Experimental [Page 20] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The notation for a REF-AS-TYPE encoding instruction is defined as + follows: + + RefAsTypeInstruction ::= "REF-AS-TYPE" NameValue RefParameters + + Taken together, the NameValue and the ContextParameter of the + RefParameters (if present) MUST reference an element type declaration + in an external DTD subset that is conformant with Namespaces in XML + 1.0 [XMLNS10]. + + The referenced element type declaration MUST NOT require the presence + of attributes of type ENTITY or ENTITIES. + + Aside: Entity declarations are not supported by CRXER. + + Example + + The product element type declaration can be referenced as a type + in an ASN.1 definition: + + SEQUENCE OF + inventoryItem + [REF-AS-TYPE "product" + CONTEXT "http://www.example.com/inventory"] + Markup + + Here is the ASN.X translation of this definition: + + <sequenceOf> + <element name="inventoryItem"> + <type elementType="product" + context="http://www.example.com/inventory"/> + </element> + </sequenceOf> + + 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: + + <inventoryItem name="hammer" partNumber="1543" quantity="29"/> + + + + + + + + + +Legg Experimental [Page 21] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +16. The SCHEMA-IDENTITY Encoding Instruction + + The SCHEMA-IDENTITY encoding instruction associates a unique + identifier, a 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.X representation. + + The notation for a SCHEMA-IDENTITY encoding instruction is defined as + follows: + + SchemaIdentityInstruction ::= "SCHEMA-IDENTITY" AnyURIValue + + The character string specified by the AnyURIValue of each + SCHEMA-IDENTITY encoding instruction MUST be distinct. In + particular, successive versions of an ASN.1 module must each have a + different schema identity URI value. + +17. The SIMPLE-CONTENT Encoding Instruction + + The SIMPLE-CONTENT encoding instruction causes an RXER encoder to + encode a value of a component of a SEQUENCE or SET type without + encapsulation in a child element. + + The notation for a SIMPLE-CONTENT encoding instruction is defined as + follows: + + SimpleContentInstruction ::= "SIMPLE-CONTENT" + + A NamedType subject to a SIMPLE-CONTENT encoding instruction SHALL be + in a ComponentType in a ComponentTypeList in a RootComponentTypeList. + At most one such NamedType of a SEQUENCE or SET type is permitted to + be subject to a SIMPLE-CONTENT encoding instruction. If any + component is subject to a SIMPLE-CONTENT encoding instruction, then + all other components in the same SEQUENCE or SET type definition MUST + be attribute components. These tests are applied after the + COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680]. + + Aside: Child elements and simple content are mutually exclusive. + Specification writers should note that use of the SIMPLE-CONTENT + encoding instruction on a component of an extensible SEQUENCE or + SET type means that all future extensions to the SEQUENCE or SET + type are restricted to being attribute components with the limited + set of types that are permitted for attribute components. Using + an ATTRIBUTE encoding instruction instead of a SIMPLE-CONTENT + encoding instruction avoids this limitation. + + + + + +Legg Experimental [Page 22] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The base type of the type of a NamedType that is subject to a + SIMPLE-CONTENT encoding instruction SHALL NOT be: + + (1) a SET or SET OF type, or + + (2) a CHOICE type where the ChoiceType is not subject to a UNION + encoding instruction, or + + (3) a SEQUENCE type other than the one defining the QName type from + the AdditionalBasicDefinitions module [RXER] (i.e., QName is + allowed), or + + (4) a SEQUENCE OF type where the SequenceOfType is not subject to a + LIST encoding instruction, or + + (5) an open type. + + If the type of a NamedType subject to a SIMPLE-CONTENT encoding + instruction has abstract values with an empty character data + translation [RXER] (i.e., an empty encoding), then the NamedType + SHALL NOT be marked OPTIONAL or DEFAULT. + + Example + + SEQUENCE { + units [ATTRIBUTE] UTF8String, + amount [SIMPLE-CONTENT] INTEGER + } + +18. The TARGET-NAMESPACE Encoding Instruction + + The TARGET-NAMESPACE encoding instruction associates an XML namespace + name [XMLNS10], 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 top-level NamedType in the RXER encoding + control section. + + The notation for a TARGET-NAMESPACE encoding instruction is defined + as follows: + + TargetNamespaceInstruction ::= + "TARGET-NAMESPACE" AnyURIValue Prefix ? + + Prefix ::= "PREFIX" NCNameValue + + The AnyURIValue SHALL NOT specify an empty string. + + + + +Legg Experimental [Page 23] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Definition (target namespace): If an ASN.1 module contains a + TARGET-NAMESPACE encoding instruction, then the target namespace of + the module is the character string specified by the AnyURIValue of + the TARGET-NAMESPACE encoding instruction; otherwise, the target + namespace of the module is said to be absent. + + Two or more ASN.1 modules MAY have the same non-absent target + namespace if and only if the expanded names of the top-level + attribute components are distinct across all those modules, the + expanded names of the top-level element components are distinct + across all those modules, and the defined type, object class, value, + object, and object set references are distinct in their category + across all those modules. + + The Prefix, if present, suggests an NCName to use as the namespace + prefix in namespace declarations involving the target namespace. An + RXER encoder is not obligated to use the nominated namespace prefix. + + If there are no top-level components, 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. + +19. 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 a value of the + component to which the encoding instruction is applied. This + attribute allows an XML Schema [XSD1] validator to select, if + available, the appropriate XML Schema translation for the version of + the ASN.1 specification used to create the encoding. + + 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. Any + incompatibilities between these translations can be accommodated + if each version uses a different target namespace. The target + namespace will be evident in the value of the xsi:type attribute + and will cause an XML Schema validator to use the appropriate + version. This mechanism also accommodates an ASN.1 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" + + + + + +Legg Experimental [Page 24] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The Type in a NamedType that is subject to a TYPE-AS-VERSION encoding + instruction MUST be a namespace-qualified reference [RXER]. + + The addition of a TYPE-AS-VERSION encoding instruction does not + affect the backward compatibility of RXER encodings. + + Aside: In a translation of an ASN.1 specification into XML Schema, + any Type in a NamedType that is subject to a TYPE-AS-VERSION + encoding instruction is expected to be translated into the + XML Schema anyType so that the xsi:type attribute acts as a switch + to select the appropriate version. + +20. The TYPE-REF Encoding Instruction + + The TYPE-REF encoding instruction causes values of the Markup 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: Referencing an ASN.1 type in a TYPE-REF encoding + instruction does not have the effect of imposing a requirement to + preserve the Infoset [INFOSET] representation of the RXER encoding + of an abstract value of the type. It is still sufficient to + preserve just the abstract value. + + The notation for a TYPE-REF encoding instruction is defined as + follows: + + TypeRefInstruction ::= "TYPE-REF" QNameValue RefParameters + + Taken together, the QNameValue and the ContextParameter of the + RefParameters (if present) MUST reference an XML Schema named type, a + RELAX NG named pattern, or an ASN.1 defined type. + + A referenced XML Schema type MUST NOT require the presence of values + for the XML Schema ENTITY or ENTITIES types. + + Aside: Entity declarations are not supported by CRXER. + + 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]. + + + + +Legg Experimental [Page 25] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Example + + MyDecimal ::= + [TYPE-REF { + namespace-name "http://www.w3.org/2001/XMLSchema", + local-name "decimal" }] + Markup + + Note that the ASN.X translation of this ASN.1 type definition + provides a more natural way to reference the XML Schema decimal + type: + + <namedType xmlns:xs="http://www.w3.org/2001/XMLSchema" + name="MyDecimal"> + <type ref="xs:decimal" embedded="true"/> + </namedType> + +21. The UNION Encoding Instruction + + The UNION encoding instruction causes an RXER encoder to encode the + value of an alternative of a CHOICE type without encapsulation in a + child element. The chosen alternative is optionally indicated with a + member 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 member attribute). + + The notation for a UNION encoding instruction is defined as follows: + + UnionInstruction ::= "UNION" AlternativesPrecedence ? + + AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList + + PrecedenceList ::= identifier PrecedenceList ? + + The Type in the EncodingPrefixedType for a UNION encoding instruction + SHALL be either: + + (1) a BuiltinType that is a ChoiceType, or + + (2) a ConstrainedType that is not a TypeWithConstraint where the Type + in the ConstrainedType is one of (1) to (4), or + + (3) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (4), or + + + + + +Legg Experimental [Page 26] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (4) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (4). + + The ChoiceType in case (1) is said to be "subject to" the UNION + encoding instruction. + + The base type of the type of each alternative of a ChoiceType that is + subject to a UNION encoding instruction SHALL NOT be: + + (1) a CHOICE, SET, or SET OF type, or + + (2) a SEQUENCE type other than the one defining the QName type from + the AdditionalBasicDefinitions module [RXER] (i.e., QName is + allowed), or + + (3) a SEQUENCE OF type where the SequenceOfType is not subject to a + LIST encoding instruction, or + + (4) an open type. + + Each identifier in the PrecedenceList MUST be the identifier of a + NamedType in the ChoiceType. + + A particular identifier SHALL NOT appear more than once in the same + PrecedenceList. + + Every NamedType in a ChoiceType that is subject to a UNION encoding + instruction MUST NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF, + COMPONENT-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT, SIMPLE-CONTENT, or + TYPE-AS-VERSION encoding instruction. + + Example + + [UNION PRECEDENCE basicName] CHOICE { + extendedName UTF8String, + basicName PrintableString + } + +22. 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. + + + + + + +Legg Experimental [Page 27] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + 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 ValueMappingList ? + + ValueMapping ::= "," identifier "AS" NCNameValue + + The Type in the EncodingPrefixedType for a VALUES encoding + instruction SHALL be either: + + (1) a BuiltinType that is a BitStringType with a NamedBitList, or + + (2) a BuiltinType that is an EnumeratedType, or + + (3) a BuiltinType that is an IntegerType with a NamedNumberList, or + + (4) a ConstrainedType that is not a TypeWithConstraint where the Type + in the ConstrainedType is one of (1) to (6), or + + (5) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (6), or + + (6) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (6). + + 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 case (1), (2), + or (3), 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, as the case may + be. + + + +Legg Experimental [Page 28] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The identifier in a ValueMapping SHALL NOT be the same as the + identifier in any other ValueMapping for the same ValueMappingList. + + Definition (replacement name): 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; else if + AllCapitalized is used, then the replacement name is the identifier + with the first character uppercased; else 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, -- Replacement name is RED. + amber, -- Replacement name is Amber. + green -- Replacement name is Green. + } + +23. Insertion Encoding Instructions + + Certain of the RXER encoding instructions are categorized as + insertion encoding instructions. The insertion encoding instructions + are the NO-INSERTIONS, HOLLOW-INSERTIONS, SINGULAR-INSERTIONS, + UNIFORM-INSERTIONS, and MULTIFORM-INSERTIONS encoding instructions + (whose notations are described respectively by + NoInsertionsInstruction, HollowInsertionsInstruction, + SingularInsertionsInstruction, UniformInsertionsInstruction, and + MultiformInsertionsInstruction). + + The notation for the insertion encoding instructions is defined as + follows: + + + + + + + +Legg Experimental [Page 29] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + InsertionsInstruction ::= + NoInsertionsInstruction | + HollowInsertionsInstruction | + SingularInsertionsInstruction | + UniformInsertionsInstruction | + MultiformInsertionsInstruction + + NoInsertionsInstruction ::= "NO-INSERTIONS" + + HollowInsertionsInstruction ::= "HOLLOW-INSERTIONS" + + SingularInsertionsInstruction ::= "SINGULAR-INSERTIONS" + + UniformInsertionsInstruction ::= "UNIFORM-INSERTIONS" + + MultiformInsertionsInstruction ::= "MULTIFORM-INSERTIONS" + + Using the GROUP encoding instruction on components with extensible + types can lead to situations where an unknown extension could be + associated with more than one extension insertion point. The + insertion encoding instructions remove this ambiguity by limiting the + form that extensions can take. That is, the insertion encoding + instructions indicate what extensions can be made to an ASN.1 + specification without breaking forward compatibility for RXER + encodings. + + Aside: Forward compatibility means the ability for a decoder to + successfully decode an encoding containing extensions introduced + into a version of the specification that is more recent than the + one used by the decoder. + + In the most general case, an extension to a CHOICE, SET, or SEQUENCE + type will generate zero or more attributes and zero or more elements, + due to the potential use of the GROUP and ATTRIBUTE encoding + instructions by the extension. + + The MULTIFORM-INSERTIONS encoding instruction indicates that the RXER + encodings produced by forward-compatible extensions to a type will + always consist of one or more elements and zero or more attributes. + No restriction is placed on the names of the elements. + + Aside: Of necessity, the names of the attributes will all be + different in any given encoding. + + The UNIFORM-INSERTIONS encoding instruction indicates that the RXER + encodings produced by forward-compatible extensions to a type will + always consist of one or more elements having the same expanded name, + and zero or more attributes. The expanded name shared by the + + + +Legg Experimental [Page 30] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + elements in one particular encoding is not required to be the same as + the expanded name shared by the elements in any other encoding of the + extension. For example, in one encoding of the extension the + elements might all be called "foo", while in another encoding of the + extension they might all be called "bar". + + The SINGULAR-INSERTIONS encoding instruction indicates that the RXER + encodings produced by forward-compatible extensions to a type will + always consist of a single element and zero or more attributes. The + name of the single element is not required to be the same in every + possible encoding of the extension. + + The HOLLOW-INSERTIONS encoding instruction indicates that the RXER + encodings produced by forward-compatible extensions to a type will + always consist of zero elements and zero or more attributes. + + The NO-INSERTIONS encoding instruction indicates that no forward- + compatible extensions can be made to a type. + + Examples of forward-compatible extensions are provided in Appendix C. + + The Type in the EncodingPrefixedType for an insertion encoding + instruction SHALL be either: + + (1) a BuiltinType that is a ChoiceType where the ChoiceType is not + subject to a UNION encoding instruction, or + + (2) a BuiltinType that is a SequenceType or SetType, or + + (3) a ConstrainedType that is not a TypeWithConstraint where the Type + in the ConstrainedType is one of (1) to (5), or + + (4) a BuiltinType that is a PrefixedType that is a TaggedType where + the Type in the TaggedType is one of (1) to (5), or + + (5) a BuiltinType that is a PrefixedType that is an + EncodingPrefixedType where the Type in the EncodingPrefixedType + is one of (1) to (5). + + Case (2) is not permitted when the insertion encoding instruction is + the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS + encoding instruction. + + + + + + + + + +Legg Experimental [Page 31] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Aside: Because extensions to a SET or SEQUENCE type are serial and + effectively optional, the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, + and MULTIFORM-INSERTIONS encoding instructions offer no advantage + over unrestricted extensions (for a SET or SEQUENCE). For + example, an optional series of singular insertions generates zero + or more elements and zero or more attributes, just like an + unrestricted extension. + + The Type in case (1) or case (2) is said to be "subject to" the + insertion encoding instruction. + + The Type in case (1) or case (2) MUST be extensible, either + explicitly or by default. + + A Type SHALL NOT be subject to more than one insertion encoding + instruction. + + The insertion encoding instructions indicate what kinds of extensions + can be made to a type without breaking forward compatibility, but + they do not prohibit extensions that do break forward compatibility. + That is, it is not an error for a type's base type to contain + extensions that do not satisfy an insertion encoding instruction + affecting the type. However, if any such extensions are made, then a + new value SHOULD be introduced into the extensible set of permitted + values for a version indicator attribute, or attributes (see + Section 24), whose scope encompasses the extensions. An example is + provided in Appendix C. + +24. The VERSION-INDICATOR Encoding Instruction + + The VERSION-INDICATOR encoding instruction provides a mechanism for + RXER decoders to be alerted that an encoding contains extensions that + break forward compatibility (see the preceding section). + + The notation for a VERSION-INDICATOR encoding instruction is defined + as follows: + + VersionIndicatorInstruction ::= "VERSION-INDICATOR" + + A NamedType that is subject to a VERSION-INDICATOR encoding + instruction MUST also be subject to an ATTRIBUTE encoding + instruction. + + The type of the NamedType that is subject to the VERSION-INDICATOR + encoding instruction MUST be directly or indirectly a constrained + type where the set of permitted values is defined to be extensible. + Each value represents a different version of the ASN.1 specification. + Ordinarily, an application will set the value of a version indicator + + + +Legg Experimental [Page 32] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + attribute to be the last of these permitted values. An application + MAY set the value of the version indicator attribute to the value + corresponding to an earlier version of the specification if it has + not used any of the extensions added in a subsequent version. + + If an RXER decoder encounters a value of the type that is not one of + the root values or extension additions (but that is still allowed + since the set of permitted values is extensible), then this indicates + that the decoder is using a version of the ASN.1 specification that + is not compatible with the version used to produce the encoding. In + such cases, the decoder SHOULD treat the element containing the + attribute as having an unknown ASN.1 type. + + Aside: A version indicator attribute only indicates an + incompatibility with respect to RXER encodings. Other encodings + are not affected because the GROUP encoding instruction does not + apply to them. + + Examples + + In this first example, the decoder is using an incompatible older + version if the value of the version attribute in a received RXER + encoding is not 1, 2, or 3. + + SEQUENCE { + version [ATTRIBUTE] [VERSION-INDICATOR] + INTEGER (1, ..., 2..3), + message MessageType + } + + In this second example, the decoder is using an incompatible older + version if the value of the format attribute in a received RXER + encoding is not "1.0", "1.1", or "2.0". + + SEQUENCE { + format [ATTRIBUTE] [VERSION-INDICATOR] + UTF8String ("1.0", ..., "1.1" | "2.0"), + message MessageType + } + + An extensive example is provided in Appendix C. + + It is not necessary for every extensible type to have its own version + indicator attribute. It would be typical for only the types of + top-level element components to include a version indicator + attribute, which would serve as the version indicator for all of the + nested components. + + + + +Legg Experimental [Page 33] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +25. The GROUP Encoding Instruction + + The GROUP encoding instruction causes an RXER encoder to encode a + value of 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 GROUP encoding instruction is defined as follows: + + GroupInstruction ::= "GROUP" + + The base type of the type of a NamedType that is subject to a GROUP + encoding instruction SHALL be either: + + (1) a SEQUENCE, SET, or SET OF type, or + + (2) a CHOICE type where the ChoiceType is not subject to a UNION + encoding instruction, or + + (3) a SEQUENCE OF type where the SequenceOfType is not subject to a + LIST encoding instruction. + + The SEQUENCE type in case (1) SHALL NOT be the associated type for a + built-in type, SHALL NOT be a type from the + AdditionalBasicDefinitions module [RXER], and SHALL NOT contain a + component that is subject to a SIMPLE-CONTENT encoding instruction. + + Aside: Thus, the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL, + and QName types are excluded. + + The CHOICE type in case (2) SHALL NOT be a type from the + AdditionalBasicDefinitions module. + + Aside: Thus, the Markup type is excluded. + + Definition (visible component): Ignoring all type constraints, the + visible components 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 components of the combining type definition + plus, for each NamedType (of the combining type definition) that is + subject to a GROUP encoding instruction, the visible components for + the type of the NamedType. The visible components are determined + after the COMPONENTS OF transformation specified in X.680, Clause + 24.4 [X.680]. + + + + + + + +Legg Experimental [Page 34] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Aside: The set of visible attribute and element components for a + type is the set of all the 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. + + A GROUP encoding instruction MUST NOT be used where it would cause a + NamedType to be a visible component of the type of that same + NamedType (which is only possible if the type definition is + recursive). + + Aside: Components subject to a GROUP encoding instruction might be + translated into a compatible XML Schema [XSD1] as group + definitions. A NamedType that is visible to its own type is + analogous to a circular group, which XML Schema disallows. + + Section 25.1 imposes additional conditions on the use of the GROUP + encoding instruction. + + In any use of the GROUP encoding instruction, there is a type, the + including type, that contains the component subject to the GROUP + encoding instruction, and a type, the included type, that is the base + type of that component. Either type can have an extensible content + model, either by directly using ASN.1 extensibility or by including + through another GROUP encoding instruction some other type that is + extensible. + + The including and included types may be defined in different ASN.1 + modules, in which case the owner of the including type, i.e., the + person or organization having the authority to add extensions to the + including type's definition, may be different from the owner of the + included type. + + If the owner of the including type is not using the most recent + version of the included type's definition, then the owner of the + including type might add an extension to the including type that is + valid with respect to the older version of the included type, but is + later found to be invalid when the latest versions of the including + and included type definitions are brought together (perhaps by a + third party). Although the owner of the including type must + necessarily be aware of the existence of the included type, the + reverse is not necessarily true. The owner of the included type + could add an extension to the included type without realizing that it + invalidates someone else's including type. + + + + + + + + +Legg Experimental [Page 35] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + To avoid these problems, a GROUP encoding instruction MUST NOT be + used if: + + (1) the included type is defined in a different module from the + including type, and + + (2) the included type has an extensible content model, and + + (3) changes to the included type are not coordinated with the owner + of the including type. + + Changes in the included type are coordinated with the owner of the + including type if: + + (1) the owner of the included type is also the owner of the including + type, or + + (2) the owner of the including type is collaborating with the owner + of the included type, or + + (3) all changes will be vetted by a common third party before being + approved and published. + +25.1. Unambiguous Encodings + + Unregulated use of the GROUP encoding instruction can easily lead to + specifications in which distinct abstract values have + indistinguishable RXER encodings, i.e., ambiguous encodings. This + section imposes restrictions on the use of the GROUP 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 expanded + 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 25.1.1 describes the procedure for recasting as a grammar a + type definition containing components subject to the GROUP encoding + instruction. Sections 25.1.2 and 25.1.3 specify conditions that the + + + + +Legg Experimental [Page 36] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + grammar must satisfy for the type definition to be valid. Section + 25.1.4 describes how unrecognized attributes are accepted by the + grammar for an extensible type. + + Appendices A and B have extensive examples. + +25.1.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 + beginning 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. The final + sequence of terminals is achieved when there are no remaining + non-terminals to replace. + + Aside: X.680 describes the ASN.1 basic notation using a + context-free grammar. + + Each NamedType has an associated primary and secondary non-terminal. + + Aside: The secondary non-terminal for a NamedType is used when the + base type of the type in the NamedType is a SEQUENCE OF type or + SET OF type. + + Each ExtensionAddition and ExtensionAdditionAlternative has an + associated non-terminal. There is a non-terminal associated with the + extension insertion point of each extensible type. There is also a + primary start non-terminal (this is the start symbol) and a secondary + start non-terminal. The exact nature of the non-terminals is not + important, however all the non-terminals MUST be mutually distinct. + + It is adequate for most of the examples in this document (though not + in the most general case) for the primary non-terminal for a + NamedType to be the identifier of the NamedType, for the primary + start non-terminal to be S, for the non-terminals for the instances + of ExtensionAddition and ExtensionAdditionAlternative to be E1, E2, + E3, and so on, and for the non-terminals for the extension insertion + points to be I1, I2, I3, and so on. The secondary non-terminals are + labelled by appending a "'" character to the primary non-terminal + label, e.g., the primary and secondary start non-terminals are S and + S', respectively. + + + +Legg Experimental [Page 37] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Each NamedType and extension insertion point has an associated + terminal. There exists a terminal called the general extension + terminal that is not associated with any specific notation. The + general extension terminal and the terminals for the extension + insertion points are used to represent elements in unknown + extensions. The exact nature of the terminals is not important; + however, the aforementioned terminals MUST be mutually distinct. The + terminals are further categorized as either element terminals or + attribute terminals. A terminal for a NamedType is an attribute + terminal if its associated NamedType is an attribute component; + otherwise, it is an element terminal. The general extension terminal + and the terminals for the extension insertion points are categorized + as element terminals. + + Terminals for attributes in unknown extensions are not explicitly + provided in the grammar. Certain productions in the grammar are + categorized as insertion point productions, and their role in + accepting unknown attributes is described in Section 25.1.4. + + In the examples in this document, the terminal for a component other + than an attribute component will be represented as the local name of + the expanded name of the component enclosed in double quotes, and the + terminal for an attribute component will be represented as the local + name of the expanded name of the component prefixed by the '@' + character and enclosed in double quotes. The general extension + terminal will be represented as "*" and the terminals for the + extension insertion points will be represented as "*1", "*2", "*3", + and so on. + + The productions generated from a NamedType depend on the base type of + 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. + + A grammar is constructed after the COMPONENTS OF transformation + specified in X.680, Clause 24.4 [X.680]. + + Given a primary non-terminal, N, and a type where the base type is 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: + + + + +Legg Experimental [Page 38] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (1) If an initial RootComponentTypeList is present in the base type, + then the sequence of primary non-terminals for the components + nested in that RootComponentTypeList are appended to the right- + hand side in the order of their definition. + + (2) If an ExtensionAdditions instance is present in the base type and + not empty, then the non-terminal for the first ExtensionAddition + nested in the ExtensionAdditions instance is appended to the + right-hand side. + + (3) If an ExtensionAdditions instance is empty or not present in the + base type, and the base type is extensible (explicitly or by + default), and the base type is not subject to a NO-INSERTIONS or + HOLLOW-INSERTIONS encoding instruction, then the non-terminal for + the extension insertion point of the base type is appended to the + right-hand side. + + (4) If a final RootComponentTypeList is present in the base type, + then the primary non-terminals for the components nested in that + RootComponentTypeList are appended to the right-hand side in the + order of their definition. + + The production is an insertion point production if an + ExtensionAdditions instance is empty or not present in the base type, + and the base type is extensible (explicitly or by default), and the + base type is not subject to a NO-INSERTIONS encoding instruction. + + If a component in a ComponentTypeList (in either a + RootComponentTypeList or an ExtensionAdditionGroup) is marked + OPTIONAL or DEFAULT, then a production with the primary non-terminal + of the component 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 GROUP encoding instruction, then one or more + productions constructed according to the component's type are added + to the grammar. Each of these productions has the primary + non-terminal of the component as the left-hand side. + + If a component (regardless of the ASN.1 combining type containing it) + is not subject to a GROUP encoding instruction, then a production is + added to the grammar with the primary non-terminal of the component + as the left-hand side and the terminal of the component as the + right-hand side. + + + + + + + +Legg Experimental [Page 39] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Example + + Consider the following ASN.1 type definition: + + SEQUENCE { + -- Start of initial RootComponentTypeList. + one [ATTRIBUTE] UTF8String, + two BOOLEAN OPTIONAL, + three INTEGER + -- End of initial RootComponentTypeList. + } + + Here is the grammar derived from this type: + + S ::= one two three + one ::= "@one" + two ::= "two" + two ::= + three ::= "three" + + For each ExtensionAddition (of a SEQUENCE or SET base type), 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 + initially empty. If the ExtensionAddition is a ComponentType, then + the primary non-terminal for the NamedType in the ComponentType is + appended to the right-hand side; otherwise (an + ExtensionAdditionGroup), the sequence of primary non-terminals for + the components nested in the ComponentTypeList in the + ExtensionAdditionGroup are appended to the right-hand side in the + order of their definition. If the ExtensionAddition is followed by + another ExtensionAddition, then the non-terminal for the next + ExtensionAddition is appended to the right-hand side; otherwise, if + the base type is not subject to a NO-INSERTIONS or HOLLOW-INSERTIONS + encoding instruction, then the non-terminal for the extension + insertion point of the base type is appended to the right-hand side. + If the ExtensionAddition is not followed by another ExtensionAddition + and the base type is not subject to a NO-INSERTIONS encoding + instruction, then the production is an insertion point production. + If the empty sequence of terminals cannot be generated from the + 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. + + + +Legg Experimental [Page 40] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + 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 a SEQUENCE or SET base type is extensible (explicitly or by + default) and is not subject to a NO-INSERTIONS or HOLLOW-INSERTIONS + encoding instruction, then: + + (1) a production is added to the grammar where the left-hand side is + the non-terminal for the extension insertion point of the base + type and the right-hand side is the general extension terminal + followed by the non-terminal for the extension insertion point, + and + + (2) a production is added to the grammar where the left-hand side is + the non-terminal for the extension insertion point and the + right-hand side is empty. + + Example + + Consider the following 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. + -- The extension insertion point is here (I1). + ..., + -- Start of final RootComponentTypeList. + three INTEGER + } + + Here is the grammar derived from this type: + + S ::= one two E1 three + + E1 ::= four E2 + E1 ::= + + + +Legg Experimental [Page 41] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + E2 ::= five E3 + E3 ::= six seven I1 + E3 ::= + + I1 ::= "*" I1 + I1 ::= + + one ::= "one" + two ::= "two" + two ::= + three ::= "three" + four ::= "four" + five ::= "five" + five ::= + six ::= "six" + seven ::= "seven" + seven ::= + + If the SEQUENCE type were subject to a NO-INSERTIONS or + HOLLOW-INSERTIONS encoding instruction, then the productions for + I1 would not appear, and the first production for E3 would be: + + E3 ::= six seven + + Given a primary non-terminal, N, and a type where the base type is a + CHOICE type: + + (1) A production is added to the grammar for each NamedType nested in + the RootAlternativeTypeList of the base type, where the left-hand + side is N and the right-hand side is the primary non-terminal for + the NamedType. + + (2) A production is added to the grammar for each + ExtensionAdditionAlternative of the base type, where the left- + hand side is N and the right-hand side is the non-terminal for + the ExtensionAdditionAlternative. + + (3) If the base type is extensible (explicitly or by default) and the + base type is not subject to an insertion encoding instruction, + then: + + (a) A production is added to the grammar where the left-hand side + is N and the right-hand side is the non-terminal for the + extension insertion point of the base type. This production + is an insertion point production. + + + + + + +Legg Experimental [Page 42] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (b) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is the general extension + terminal followed by the non-terminal for the extension + insertion point. + + (c) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is empty. + + (4) If the base type is subject to a HOLLOW-INSERTIONS encoding + instruction, then a production is added to the grammar where the + left-hand side is N and the right-hand side is empty. This + production is an insertion point production. + + (5) If the base type is subject to a SINGULAR-INSERTIONS encoding + instruction, then a production is added to the grammar where the + left-hand side is N and the right-hand side is the general + extension terminal. This production is an insertion point + production. + + (6) If the base type is subject to a UNIFORM-INSERTIONS encoding + instruction, then: + + (a) A production is added to the grammar where the left-hand side + is N and the right-hand side is the general extension + terminal. + + Aside: This production is used to verify the correctness + of an ASN.1 type definition, but would not be used in the + implementation of an RXER decoder. The next production + takes precedence over it for accepting an unknown element. + + (b) A production is added to the grammar where the left-hand side + is N and the right-hand side is the terminal for the + extension insertion point of the base type followed by the + non-terminal for the extension insertion point. This + production is an insertion point production. + + (c) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is the terminal for the + extension insertion point followed by the non-terminal for + the extension insertion point. + + (d) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is empty. + + + +Legg Experimental [Page 43] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (7) If the base type is subject to a MULTIFORM-INSERTIONS encoding + instruction, then: + + (a) A production is added to the grammar where the left-hand side + is N and the right-hand side is the general extension + terminal followed by the non-terminal for the extension + insertion point of the base type. This production is an + insertion point production. + + (b) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is the general extension + terminal followed by the non-terminal for the extension + insertion point. + + (c) A production is added to the grammar where the left-hand side + is the non-terminal for the extension insertion point of the + base type and the right-hand side is empty. + + 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 + primary non-terminal for the NamedType. + + If an ExtensionAdditionAlternative is an + ExtensionAdditionAlternativesGroup, then a production is added to the + grammar for each NamedType nested in the + ExtensionAdditionAlternativesGroup, where the left-hand side is the + non-terminal for the ExtensionAdditionAlternative and the right-hand + side is the primary non-terminal for the NamedType. + + + + + + + + + + + + + + + + + + + + + +Legg Experimental [Page 44] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Example + + Consider the following 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). + -- The extension insertion point is here (I1). + } + + Here is the grammar derived from this type: + + S ::= one + S ::= two + S ::= E1 + S ::= E2 + S ::= I1 + + I1 ::= "*" I1 + I1 ::= + + E1 ::= three + E2 ::= four + E2 ::= five + + one ::= "one" + two ::= "two" + three ::= "three" + four ::= "four" + five ::= "five" + + If the CHOICE type were subject to a NO-INSERTIONS encoding + instruction, then the fifth, sixth, and seventh productions would + be removed. + + If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding + instruction, then the fifth, sixth, and seventh productions would + be replaced by: + + + + +Legg Experimental [Page 45] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + S ::= + + If the CHOICE type were subject to a SINGULAR-INSERTIONS encoding + instruction, then the fifth, sixth, and seventh productions would + be replaced by: + + S ::= "*" + + If the CHOICE type were subject to a UNIFORM-INSERTIONS encoding + instruction, then the fifth and sixth productions would be + replaced by: + + S ::= "*" + S ::= "*1" I1 + + I1 ::= "*1" I1 + + If the CHOICE type were subject to a MULTIFORM-INSERTIONS encoding + instruction, then the fifth production would be replaced by: + + S ::= "*" I1 + + 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 type that has a SEQUENCE OF or + SET OF base type and that permits a value of size zero (i.e., an + empty sequence or 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 base 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, N', and a + type that has a SEQUENCE OF or SET OF base type and that does not + permit a value of size zero: + + + + + + + +Legg Experimental [Page 46] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (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 base 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 the primary + non-terminal for the NamedType of the component of the + SEQUENCE OF or SET OF base type, followed by N', and + + (3) a production is added to the grammar where the left-hand side of + the production is N' and the right-hand side is empty. + + Example + + Consider the following ASN.1 type definition: + + SEQUENCE SIZE(1..MAX) OF number INTEGER + + Here is the grammar derived from this type: + + S ::= number S' + S' ::= number S' + S' ::= + + number ::= "number" + + All inner subtyping (InnerTypeContraints) is ignored for the purposes + of deciding whether a value of size zero is permitted by a + SEQUENCE OF or SET OF type. + + This completes the description of the transformation of ASN.1 + combining type definitions into a grammar. + +25.1.2. Unique Component Attribution + + This section describes conditions that the grammar must satisfy so + that each element and attribute in a received RXER encoding can be + uniquely associated with an ASN.1 component definition. + + Definition (used by the grammar): A non-terminal, N, is used by the + grammar if: + + (1) N is the start symbol or + + (2) N appears on the right-hand side of a production where the + non-terminal on the left-hand side is used by the grammar. + + + + +Legg Experimental [Page 47] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Definition (multiple derivation paths): A non-terminal, N, has + multiple derivation paths if: + + (1) N appears on the right-hand side of a production where the + non-terminal on the left-hand side has multiple derivation paths, + or + + (2) N appears on the right-hand side of more than one production + where the non-terminal on the left-hand side is used by the + grammar, or + + (3) N is the start symbol and it appears on the right-hand side of a + production where the non-terminal on the left-hand side is used + by the grammar. + + For every ASN.1 type with a base type containing components that are + subject to a GROUP encoding instruction, the grammar derived by the + method described in this document MUST NOT have: + + (1) two or more primary non-terminals that are used by the grammar + and are associated with element components having the same + expanded name, or + + (2) two or more primary non-terminals that are used by the grammar + and are associated with attribute components having the same + expanded name, or + + (3) a primary non-terminal that has multiple derivation paths and is + associated with an attribute component. + + Aside: Case (1) is in response to component referencing notations + that are evaluated with respect to the XML encoding of an abstract + value. Case (1) guarantees, without having to do extensive + testing (which would necessarily have to take account of encoding + instructions for all other encoding rules), that all sibling + elements with the same expanded name 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 and encoding instructions apply. + + Cases (2) and (3) ensure that an attribute name is always uniquely + associated with one component that can occur at most once and is + always nested in the same part of an abstract value. + + + + + + + +Legg Experimental [Page 48] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Example + + The following example types illustrate various uses and misuses of + the GROUP encoding instruction with respect to unique component + attribution: + + TA ::= SEQUENCE { + a [GROUP] TB, + b [GROUP] CHOICE { + a [GROUP] TB, + b [NAME AS "c"] [ATTRIBUTE] INTEGER, + c INTEGER, + d TB, + e [GROUP] TD, + f [ATTRIBUTE] UTF8String + }, + c [ATTRIBUTE] INTEGER, + d [GROUP] SEQUENCE OF + a [GROUP] SEQUENCE { + a [ATTRIBUTE] OBJECT IDENTIFIER, + b INTEGER + }, + e [NAME AS "c"] INTEGER, + COMPONENTS OF TD + } + + TB ::= SEQUENCE { + a INTEGER, + b [ATTRIBUTE] BOOLEAN, + COMPONENTS OF TC + } + + TC ::= SEQUENCE { + f OBJECT IDENTIFIER + } + + TD ::= SEQUENCE { + g OBJECT IDENTIFIER + } + + The grammar for TA is constructed after performing the + COMPONENTS OF transformation. The result of this transformation + is shown next. This example will depart from the usual convention + of using just the identifier of a NamedType to represent the + primary non-terminal for that NamedType. A label relative to the + outermost type will be used instead to better illustrate unique + component attribution. The labels used for the non-terminals are + shown down the right-hand side. + + + +Legg Experimental [Page 49] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + TA ::= SEQUENCE { + a [GROUP] TB, -- TA.a + b [GROUP] CHOICE { -- TA.b + a [GROUP] TB, -- TA.b.a + b [NAME AS "c"] [ATTRIBUTE] INTEGER, -- TA.b.b + c INTEGER, -- TA.b.c + d TB, -- TA.b.d + e [GROUP] TD, -- TA.b.e + f [ATTRIBUTE] UTF8String -- TA.b.f + }, + c [ATTRIBUTE] INTEGER, -- TA.c + d [GROUP] SEQUENCE OF -- TA.d + a [GROUP] SEQUENCE { -- TA.d.a + a [ATTRIBUTE] OBJECT IDENTIFIER, -- TA.d.a.a + b INTEGER -- TA.d.a.b + }, + e [NAME AS "c"] INTEGER, -- TA.e + g OBJECT IDENTIFIER -- TA.g + } + + TB ::= SEQUENCE { + a INTEGER, -- TB.a + b [ATTRIBUTE] BOOLEAN, -- TB.b + f OBJECT IDENTIFIER -- TB.f + } + + -- Type TC is no longer of interest. -- + + TD ::= SEQUENCE { + g OBJECT IDENTIFIER -- TD.g + } + + The associated grammar is: + + S ::= TA.a TA.b TA.c TA.d TA.e TA.g + + TA.a ::= TB.a TB.b TB.f + + TB.a ::= "a" + TB.b ::= "@b" + TB.f ::= "f" + + TA.b ::= TA.b.a + TA.b ::= TA.b.b + TA.b ::= TA.b.c + TA.b ::= TA.b.d + TA.b ::= TA.b.e + TA.b ::= TA.b.f + + + +Legg Experimental [Page 50] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + TA.b.a ::= TB.a TB.b TB.f + TA.b.b ::= "@c" + TA.b.c ::= "c" + TA.b.d ::= "d" + TA.b.e ::= TD.g + TA.b.f ::= "@f" + + TD.g ::= "g" + + TA.c ::= "@c" + + TA.d ::= TA.d.a TA.d + TA.d ::= + + TA.d.a ::= TA.d.a.a TA.d.a.b + + TA.d.a.a := "@a" + TA.d.a.b ::= "b" + + TA.e ::= "c" + + TA.g ::= "g" + + All the non-terminals are used by the grammar. + + The type definition for TA is invalid because there are two + instances where two or more primary non-terminals are associated + with element components having the same expanded name: + + (1) TA.b.c and TA.e (both generate the terminal "c"), and + + (2) TD.g and TA.g (both generate the terminal "g"). + + In case (2), TD.g and TA.g are derived from the same instance of + NamedType notation, but become distinct components following the + COMPONENTS OF transformation. AUTOMATIC tagging is applied after + the COMPONENTS OF transformation, which means that the types of + the components corresponding to TD.g and TA.g will end up with + different tags, and therefore the types will not be equivalent. + + The type definition for TA is also invalid because there is one + instance where two or more primary non-terminals are associated + with attribute components having the same expanded name: TA.b.b + and TA.c (both generate the terminal "@c"). + + + + + + + +Legg Experimental [Page 51] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The non-terminals with multiple derivation paths are: TA.d, + TA.d.a, TA.d.a.a, TA.d.a.b, TB.a, TB.b, and TB.f. The type + definition for TA is also invalid because TA.d.a.a and TB.b are + primary non-terminals that are associated with an attribute + component. + +25.1.3. Deterministic Grammars + + Let the First Set of a production P, denoted First(P), be the set of + all element terminals T where T is the first element terminal in a + sequence of terminals that can be generated from the right-hand side + of P. There can be any number of leading attribute terminals before + T. + + Let the Follow Set of a non-terminal N, denoted Follow(N), be the set + of all element terminals T where T is the first element terminal + following N in a sequence of non-terminals and terminals that can be + generated from the grammar. There can be any number of attribute + terminals between N and T. 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 "$". + + Aside: If N does not appear on the right-hand side of any + production, then Follow(N) will be empty. + + For a production P, let the predicate Empty(P) be true if and only if + the empty sequence of terminals can be generated from P. Otherwise, + Empty(P) is false. + + Definition (base grammar): The base grammar is a rewriting of the + grammar in which the non-terminals for every ExtensionAddition and + ExtensionAdditionAlternative are removed from the right-hand side of + all productions. + + For a production P, let the predicate Preselected(P) be true if and + only if every sequence of terminals that can be generated from the + right-hand side of P using only the base grammar contains at least + one attribute terminal. Otherwise, Preselected(P) is false. + + The Select Set of a production P, denoted Select(P), is empty if + Preselected(P) is true; otherwise, it contains First(P). Let N be + the non-terminal on the left-hand side of P. If Empty(P) is true, + then Select(P) also contains Follow(N). + + + + + + + +Legg Experimental [Page 52] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + 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 Sets and + Follow Sets. However, the attribute terminals are important in + composing the Select Sets because they can preselect a production + and can prevent a production from being able to generate an empty + sequence of terminals. In real terms, this corresponds to an RXER + decoder using the attributes to determine the presence or absence + of optional components and to select between the alternatives of a + CHOICE, even before considering the child elements. + + An attribute appearing in an extension isn't used to preselect a + production since, in general, a decoder using an earlier version + of the specification would not be able to associate the attribute + with any particular extension insertion point. + + Let the Reach Set of a non-terminal N, denoted Reach(N), be the set + of all element terminals T where T appears in a sequence of terminals + that can be generated from N. + + 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, or the evaluation of the Preselected and + Empty predicates. + + A grammar is deterministic (for the purposes of an RXER decoder) if + and only if: + + (1) there do 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 that decoder) extension with a known component following the + extension. + + + + +Legg Experimental [Page 53] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Aside: In the absence of any attribute components, case (1) is the + test for an LL(1) grammar. + + For every ASN.1 type with a base type containing components that are + subject to a GROUP encoding instruction, the grammar derived by the + method described in this document MUST be deterministic. + +25.1.4. Attributes in Unknown Extensions + + An insertion point production is able to accept unknown attributes if + the non-terminal on the left-hand side of the production does not + have multiple derivation paths. + + Aside: If the non-terminal has multiple derivation paths, then any + future extension cannot possibly contain an attribute component + because that would violate the requirements of Section 25.1.2. + + For a deterministic grammar, there is only one possible way to + construct a sequence of element terminals matching the element + content of an element in a correctly formed RXER encoding. Any + unknown attributes of the element are accepted if at least one + insertion point production that is able to accept unknown attributes + is used in that construction. + + Example + + Consider this type definition: + + CHOICE { + one UTF8String, + two [GROUP] SEQUENCE { + three INTEGER, + ... + } + } + + The associated grammar is: + + S ::= one + S ::= two + + two ::= three I1 + + I1 ::= "*" I1 + I1 ::= + + one ::= "one" + three ::= "three" + + + +Legg Experimental [Page 54] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The third production is an insertion point production, and it is + able to accept unknown attributes. + + When decoding a value of this type, if the element content + contains a <one> child element, then any unrecognized attribute + would be illegal as the insertion point production would not be + used to recognize the input (the "one" alternative does not admit + an extension insertion point). If the element content contains a + <three> element, then an unrecognized attribute would be accepted + because the insertion point production would be used to recognize + the input (the "two" alternative that generates the <three> + element has an extensible type). + + If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding + instruction, then the third, fourth, and fifth productions would + be replaced by: + + two ::= three + + With this change, any unrecognized attribute would be illegal for + the "two" alternative also, since the replacement production is + not an insertion point production. + + If more than one insertion point production that is able to accept + unknown attributes is used in constructing a matching sequence of + element terminals, then a decoder is free to associate an + unrecognized attribute with any one of the extension insertion points + corresponding to those insertion point productions. 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 unrecognized attribute regardless of which extension + insertion point it might be ascribed to. + + + + + + +Legg Experimental [Page 55] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + (2) Even if there is a single extension insertion point, an unknown + extension could still be the encoding of a value of any one of an + infinite number of valid type definitions. For example, an + attribute or element component could be nested to any arbitrary + depth within CHOICEs whose components are subject to GROUP + encoding instructions. + + Aside: A similar series of nested CHOICEs could describe an + unknown extension in a Basic Encoding Rules (BER) encoding + [X.690]. + +26. Security Considerations + + ASN.1 compiler implementors should take special care to be thorough + in checking that the GROUP encoding instruction has been correctly + used; otherwise, ASN.1 specifications with ambiguous RXER encodings + could be deployed. + + 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 than that embodied in the + original abstract value. + +27. References + +27.1. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER) + for Abstract Syntax Notation One (ASN.1)", RFC 4910, July + 2007. + + [ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", RFC 4912, + July 2007. + + + + +Legg Experimental [Page 56] + +RFC 4911 Encoding Instructions for RXER 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.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. + + [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. + + [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. + + [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. + + [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. + + [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. + +27.2. Informative References + + [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. + + [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). + + + +Legg Experimental [Page 57] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +Appendix A. GROUP Encoding Instruction Examples + + This appendix is non-normative. + + This appendix contains examples of both correct and incorrect use of + the GROUP encoding instruction, determined with respect to the + grammars derived from the example type definitions. The productions + of the grammars are labeled for convenience. Sets and predicates for + non-terminals with only one production will be omitted from the + examples since they never indicate non-determinism. + + The requirements of Section 25.1.2 ("Unique Component Attribution") + are satisfied by all the examples in this appendix and the appendices + that follow it. + +A.1. Example 1 + + Consider this type definition: + + SEQUENCE { + one [GROUP] 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 and predicates: + + First(P2) = { "two" } + First(P3) = { } + Preselected(P2) = Preselected(P3) = false + Empty(P2) = Empty(P3) = true + Follow(one) = { "three" } + Select(P2) = First(P2) + Follow(one) = { "two", "three" } + Select(P3) = First(P3) + Follow(one) = { "three" } + + + + + + +Legg Experimental [Page 58] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + First(P4) = { "two" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(two) = { "three" } + Select(P4) = First(P4) = { "two" } + Select(P5) = First(P5) + Follow(two) = { "three" } + + The intersection of Select(P2) and Select(P3) is not empty; hence, + the grammar is not deterministic, and the type definition is not + valid. If the RXER encoding of a value of the type does not have a + child element <two>, 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 [GROUP] 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 and predicates: + + First(P2) = { "two" } + First(P3) = { } + Preselected(P3) = Empty(P2) = false + Preselected(P2) = Empty(P3) = true + Follow(one) = { "three" } + Select(P2) = { } + Select(P3) = First(P3) + Follow(one) = { "three" } + + + + +Legg Experimental [Page 59] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + First(P4) = { "two" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(two) = { "three" } + Select(P4) = First(P4) = { "two" } + Select(P5) = First(P5) + Follow(two) = { "three" } + + First(P7) = { } + First(P8) = { } + Preselected(P8) = Empty(P7) = false + Preselected(P7) = Empty(P8) = true + Follow(five) = { "three" } + Select(P7) = { } + Select(P8) = First(P8) + Follow(five) = { "three" } + + 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 "one" + component will be present if and only if the "four" attribute is + present. + +A.2. Example 2 + + Consider this type definition: + + CHOICE { + one [GROUP] SEQUENCE { + two [ATTRIBUTE] BOOLEAN OPTIONAL + }, + three INTEGER, + four [GROUP] 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" + + + +Legg Experimental [Page 60] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + P10: five ::= + + This grammar leads to the following sets and predicates: + + First(P1) = { } + First(P2) = { "three" } + First(P3) = { "five" } + Preselected(P1) = Preselected(P2) = Preselected(P3) = false + Empty(P2) = false + Empty(P1) = Empty(P3) = true + Follow(S) = { "$" } + Select(P1) = First(P1) + Follow(S) = { "$" } + Select(P2) = First(P2) = { "three" } + Select(P3) = First(P3) + Follow(S) = { "five", "$" } + + First(P5) = { } + First(P6) = { } + Preselected(P6) = Empty(P5) = false + Preselected(P5) = Empty(P6) = true + Follow(two) = { "$" } + Select(P5) = { } + Select(P6) = First(P6) + Follow(two) = { "$" } + + First(P9) = { "five" } + First(P10) = { } + Preselected(P9) = Preselected(P10) = Empty(P9) = false + Empty(P10) = true + Follow(five) = { "$" } + Select(P9) = First(P9) = { "five" } + Select(P10) = First(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. 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 [GROUP] SEQUENCE { + two [ATTRIBUTE] BOOLEAN + }, + three INTEGER, + four [GROUP] SEQUENCE { + five BOOLEAN OPTIONAL + } + } + + + +Legg Experimental [Page 61] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + 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 and predicates: + + First(P1) = { } + First(P2) = { "three" } + First(P3) = { "five" } + Preselected(P2) = Preselected(P3) = false + Empty(P1) = Empty(P2) = false + Preselected(P1) = Empty(P3) = true + Follow(S) = { "$" } + Select(P1) = { } + Select(P2) = First(P2) = { "three" } + Select(P3) = First(P3) + Follow(S) = { "five", "$" } + + First(P8) = { "five" } + First(P9) = { } + Preselected(P8) = Preselected(P9) = Empty(P8) = false + Empty(P9) = true + Follow(five) = { "$" } + Select(P8) = First(P8) = { "five" } + Select(P9) = First(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. + + + + + + + + + + + +Legg Experimental [Page 62] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +A.3. Example 3 + + Consider this type definition: + + SEQUENCE { + one [GROUP] CHOICE { + two [ATTRIBUTE] BOOLEAN, + three [GROUP] 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 and predicates: + + First(P2) = { } + First(P3) = { "number" } + First(P4) = { } + Preselected(P3) = Preselected(P4) = Empty(P2) = false + Preselected(P2) = Empty(P3) = Empty(P4) = true + Follow(one) = { "$" } + Select(P2) = { } + Select(P3) = First(P3) + Follow(one) = { "number", "$" } + Select(P4) = First(P4) + Follow(one) = { "$" } + + First(P6) = { "number" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + Follow(three) = { "$" } + Select(P6) = First(P6) = { "number" } + Select(P7) = First(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. If the RXER encoding of a value of the type is empty, then it + is not possible to determine whether the "one" component is absent or + the empty "three" alternative has been chosen. + + + + +Legg Experimental [Page 63] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +A.4. Example 4 + + Consider this type definition: + + SEQUENCE { + one [GROUP] 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 and predicates: + + First(P2) = { } + First(P3) = { } + First(P4) = { } + Preselected(P4) = Empty(P2) = Empty(P3) = false + Preselected(P2) = Preselected(P3) = Empty(P4) = true + Follow(one) = { "$" } + Select(P2) = { } + Select(P3) = { } + Select(P4) = First(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 [GROUP] SEQUENCE OF number INTEGER OPTIONAL + } + + + + + + + +Legg Experimental [Page 64] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The associated grammar is: + + P1: S ::= one + P2: one ::= number one + P3: one ::= + P4: one ::= + 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 and predicates: + + First(P2) = { "number" } + First(P3) = { } + First(P4) = { } + Preselected(P2) = Preselected(P3) = Preselected(P4) = false + Empty(P2) = false + Empty(P3) = Empty(P4) = true + Follow(one) = { "$" } + Select(P2) = First(P2) = { "number" } + Select(P3) = First(P3) + Follow(one) = { "$" } + Select(P4) = First(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. If the RXER encoding of a value of the type does not have any + <number> 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 [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL + } + + The associated grammar is: + + P1: S ::= one + P2: one ::= number one' + P3: one' ::= number one' + P4: one' ::= + P5: one ::= + P6: number ::= "number" + + + + + + + +Legg Experimental [Page 65] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + This grammar leads to the following sets and predicates: + + First(P2) = { "number" } + First(P5) = { } + Preselected(P2) = Preselected(P5) = Empty(P2) = false + Empty(P5) = true + Follow(one) = { "$" } + Select(P2) = First(P2) = { "number" } + Select(P5) = First(P5) + Follow(one) = { "$" } + + First(P3) = { "number" } + First(P4) = { } + Preselected(P3) = Preselected(P4) = Empty(P3) = false + Empty(P4) = true + Follow(one') = { "$" } + Select(P3) = First(P3) = { "number" } + Select(P4) = First(P4) + Follow(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 + <number> child elements, then the "one" component is necessarily + absent and there is no ambiguity. + +A.6. Example 6 + + Consider this type definition: + + SEQUENCE { + beginning [GROUP] List, + middle UTF8String OPTIONAL, + end [GROUP] 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" + + + + + +Legg Experimental [Page 66] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + This grammar leads to the following sets and predicates: + + First(P2) = { "string" } + First(P3) = { } + Preselected(P2) = Preselected(P3) = Empty(P2) = false + Empty(P3) = true + Follow(beginning) = { "middle", "string", "$" } + Select(P2) = First(P2) = { "string" } + Select(P3) = First(P3) + Follow(beginning) + = { "middle", "string", "$" } + + First(P4) = { "middle" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(middle) = { "string", "$" } + Select(P4) = First(P4) = { "middle" } + Select(P5) = First(P5) + Follow(middle) = { "string", "$" } + + First(P6) = { "string" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + Follow(end) = { "$" } + Select(P6) = First(P6) = { "string" } + Select(P7) = First(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 [GROUP] List, + middleAndEnd [GROUP] SEQUENCE { + middle UTF8String, + end [GROUP] List + } OPTIONAL + } + + The associated grammar is: + + P1: S ::= beginning middleAndEnd + P2: beginning ::= string beginning + P3: beginning ::= + P4: middleAndEnd ::= middle end + P5: middleAndEnd ::= + + + +Legg Experimental [Page 67] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + P6: middle ::= "middle" + P7: end ::= string end + P8: end ::= + P9: string ::= "string" + + This grammar leads to the following sets and predicates: + + First(P2) = { "string" } + First(P3) = { } + Preselected(P2) = Preselected(P3) = Empty(P2) = false + Empty(P3) = true + Follow(beginning) = { "middle", "$" } + Select(P2) = First(P2) = { "string" } + Select(P3) = First(P3) + Follow(beginning) = { "middle", "$" } + + First(P4) = { "middle" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(middleAndEnd) = { "$" } + Select(P4) = First(P4) = { "middle" } + Select(P5) = First(P5) + Follow(middleAndEnd) = { "$" } + + First(P7) = { "string" } + First(P8) = { } + Preselected(P7) = Preselected(P8) = Empty(P7) = false + Empty(P8) = true + Follow(end) = { "$" } + Select(P7) = First(P7) = { "string" } + Select(P8) = First(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 [GROUP] SEQUENCE { + two INTEGER OPTIONAL + } + + + + + + + +Legg Experimental [Page 68] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The associated grammar is: + + P1: S ::= one S' + P2: S' ::= one S' + P3: S' ::= + P4: one ::= two + P5: two ::= "two" + P6: two ::= + + This grammar leads to the following sets and predicates: + + First(P2) = { "two" } + First(P3) = { } + Preselected(P2) = Preselected(P3) = false + Empty(P2) = Empty(P3) = true + Follow(S') = { "$" } + Select(P2) = First(P2) + Follow(S') = { "two", "$" } + Select(P3) = First(P3) + Follow(S') = { "$" } + + First(P5) = { "two" } + First(P6) = { } + Preselected(P5) = Preselected(P6) = Empty(P5) = false + Empty(P6) = true + Follow(two) = { "two", "$" } + Select(P5) = First(P5) = { "two" } + Select(P6) = First(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 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 [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER + + The associated grammar is: + + P1: S ::= list S + P2: S ::= + P3: list ::= number list' + P4: list' ::= number list' + P5: list' ::= + P6: number ::= "number" + + + +Legg Experimental [Page 69] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + This grammar leads to the following sets and predicates: + + First(P1) = { "number" } + First(P2) = { } + Preselected(P1) = Preselected(P2) = Empty(P1) = false + Empty(P2) = true + Follow(S) = { "$" } + Select(P1) = First(P1) = { "number" } + Select(P2) = First(P2) + Follow(S) = { "$" } + + First(P4) = { "number" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(list') = { "number", "$" } + Select(P4) = First(P4) = { "number" } + Select(P5) = First(P5) + Follow(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 type describes a list of lists, but it is not possible + for a decoder to determine where the outer lists begin and end. + +A.9. Example 9 + + Consider the following type definition: + + SEQUENCE OF item [GROUP] SEQUENCE { + before [GROUP] OneAndTwo, + core UTF8String, + after [GROUP] 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 ::= + + + + +Legg Experimental [Page 70] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + This grammar leads to the following sets and predicates: + + First(P1) = { "non-core" } + First(P2) = { } + Preselected(P1) = Preselected(P2) = Empty(P1) = false + Empty(P2) = true + Follow(S) = { "$" } + Select(P1) = First(P1) = { "non-core" } + Select(P2) = First(P2) + Follow(S) = { "$" } + + First(P7) = { "non-core" } + First(P8) = { } + Preselected(P7) = Preselected(P8) = Empty(P7) = false + Empty(P8) = true + Follow(after) = { "non-core", "$" } + Select(P7) = First(P7) = { "non-core" } + Select(P8) = First(P8) + Follow(after) = { "non-core", "$" } + + The intersection of Select(P7) and Select(P8) 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 <non-core> element belongs with the + preceding or following <core> element. + +A.10. Example 10 + + Consider the following type definition: + + CHOICE { + one [GROUP] List, + two [GROUP] SEQUENCE { + three [ATTRIBUTE] UTF8String, + four [GROUP] List + } + } + + List ::= SEQUENCE OF string UTF8String + + The associated grammar is: + + P1: S ::= one + P2: S ::= two + P3: one ::= string one + P4: one ::= + P5: two ::= three four + P6: three ::= "@three" + P7: four ::= string four + + + +Legg Experimental [Page 71] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + P8: four ::= + P9: string ::= "string" + + This grammar leads to the following sets and predicates: + + First(P1) = { "string" } + First(P2) = { "string" } + Preselected(P1) = Empty(P2) = false + Preselected(P2) = Empty(P1) = true + Follow(S) = { "$" } + Select(P1) = First(P1) + Follow(S) = { "string", "$" } + Select(P2) = { } + + First(P3) = { "string" } + First(P4) = { } + Preselected(P3) = Preselected(P4) = Empty(P3) = false + Empty(P4) = true + Follow(one) = { "$" } + Select(P3) = First(P3) = { "string" } + Select(P4) = First(P4) + Follow(one) = { "$" } + + First(P7) = { "string" } + First(P8) = { } + Preselected(P7) = Preselected(P8) = Empty(P7) = false + Empty(P8) = true + Follow(four) = { "$" } + Select(P7) = First(P7) = { "string" } + Select(P8) = First(P8) + Follow(four) = { "$" } + + The intersection of Select(P1) and Select(P2) is empty, as is the + intersection of Select(P3) and Select(P4) and the intersection of + Select(P7) and Select(P8); hence, the grammar is deterministic, and + the type definition is valid. Although both alternatives of the + CHOICE can begin with a <string> element, an RXER decoder would use + the presence of a "three" attribute to decide whether to select or + disregard the "two" alternative. + + However, an attribute in an extension cannot be used to select + between alternatives. Consider the following type definition: + + + + + + + + + + + + +Legg Experimental [Page 72] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + [SINGULAR-INSERTIONS] CHOICE { + one [GROUP] List, + ..., + two [GROUP] SEQUENCE { + three [ATTRIBUTE] UTF8String, + four [GROUP] List + } -- ExtensionAdditionAlternative (E1). + -- The extension insertion point is here (I1). + } + + List ::= SEQUENCE OF string UTF8String + + The associated grammar is: + + P1: S ::= one + P10: S ::= E1 + P11: S ::= "*" + P12: E1 ::= two + P3: one ::= string one + P4: one ::= + P5: two ::= three four + P6: three ::= "@three" + P7: four ::= string four + P8: four ::= + P9: string ::= "string" + + This grammar leads to the following sets and predicates for P1, P10 + and P11: + + First(P1) = { "string" } + First(P10) = { "string" } + First(P11) = { "*" } + Preselected(P1) = Preselected(P10) = Preselected(P11) = false + Empty(P10) = Empty(P11) = false + Empty(P1) = true + Follow(S) = { "$" } + Select(P1) = First(P1) + Follow(S) = { "string", "$" } + Select(P10) = First(P10) = { "string" } + Select(P11) = First(P11) = { "*" } + + Preselected(P10) evaluates to false because Preselected(P10) is + evaluated on the base grammar, wherein P10 is rewritten as: + + P10: S ::= + + + + + + + +Legg Experimental [Page 73] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The intersection of Select(P1) and Select(P10) is not empty; hence, + the grammar is not deterministic, and the type definition is not + valid. An RXER decoder using the original, unextended version of the + definition would not know that the "three" attribute selects between + the "one" alternative and the extension. + +Appendix B. Insertion Encoding Instruction Examples + + This appendix is non-normative. + + This appendix contains examples showing the use of insertion encoding + instructions to remove extension ambiguity arising from use of the + GROUP encoding instruction. + +B.1. Example 1 + + Consider the following type definition: + + SEQUENCE { + one [GROUP] SEQUENCE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three INTEGER OPTIONAL, + ... -- Extension insertion point (I2). + } + + The associated grammar is: + + P1: S ::= one three I2 + P2: one ::= two I1 + P3: two ::= "two" + P4: I1 ::= "*" I1 + P5: I1 ::= + P6: three ::= "three" + P7: three ::= + P8: I2 ::= "*" I2 + P9: I2 ::= + + This grammar leads to the following sets and predicates: + + First(P4) = { "*" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(I1) = { "three", "*", "$" } + Select(P4) = First(P4) = { "*" } + Select(P5) = First(P5) + Follow(I1) = { "three", "*", "$" } + + + +Legg Experimental [Page 74] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + First(P6) = { "three" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + Follow(three) = { "*", "$" } + Select(P6) = First(P6) = { "three" } + Select(P7) = First(P7) + Follow(three) = { "*", "$" } + + First(P8) = { "*" } + First(P9) = { } + Preselected(P8) = Preselected(P9) = Empty(P8) = false + Empty(P9) = true + Follow(I2) = { "$" } + Select(P8) = First(P8) = { "*" } + Select(P9) = First(P9) + Follow(I2) = { "$" } + + The intersection of Select(P4) and Select(P5) is not empty; hence, + the grammar is not deterministic, and the type definition is not + valid. If an RXER decoder encounters an unrecognized element + immediately after a <two> element, then it will not know whether to + associate it with extension insertion point I1 or I2. + + The non-determinism can be resolved with either a NO-INSERTIONS or + HOLLOW-INSERTIONS encoding instruction. Consider this revised type + definition: + + SEQUENCE { + one [GROUP] [HOLLOW-INSERTIONS] SEQUENCE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three INTEGER OPTIONAL, + ... -- Extension insertion point (I2). + } + + The associated grammar is: + + P1: S ::= one three I2 + P10: one ::= two + P3: two ::= "two" + P6: three ::= "three" + P7: three ::= + P8: I2 ::= "*" I2 + P9: I2 ::= + + With the addition of the HOLLOW-INSERTIONS encoding instruction, the + P4 and P5 productions are no longer generated, and the conflict + between Select(P4) and Select(P5) no longer exists. The Select Sets + + + +Legg Experimental [Page 75] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + for P6, P7, P8, and P9 are unchanged. A decoder will now assume that + an unrecognized element is to be associated with extension insertion + point I2. It is still free to associate an unrecognized attribute + with either extension insertion point. If a NO-INSERTIONS encoding + instruction had been used, then an unrecognized attribute could only + be associated with extension insertion point I2. + + The non-determinism could also be resolved by adding a NO-INSERTIONS + or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE: + + [HOLLOW-INSERTIONS] SEQUENCE { + one [GROUP] SEQUENCE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three INTEGER OPTIONAL, + ... -- Extension insertion point (I2). + } + + The associated grammar is: + + P11: S ::= one three + P2: one ::= two I1 + P3: two ::= "two" + P4: I1 ::= "*" I1 + P5: I1 ::= + P6: three ::= "three" + P7: three ::= + + This grammar leads to the following sets and predicates: + + First(P4) = { "*" } + First(P5) = { } + Preselected(P4) = Preselected(P5) = Empty(P4) = false + Empty(P5) = true + Follow(I1) = { "three", "$" } + Select(P4) = First(P4) = { "*" } + Select(P5) = First(P5) + Follow(I1) = { "three", "$" } + + First(P6) = { "three" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + Follow(three) = { "$" } + Select(P6) = First(P6) = { "three" } + Select(P7) = First(P7) + Follow(three) = { "$" } + + + + + +Legg Experimental [Page 76] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The intersection of Select(P4) and Select(P5) is empty, as is the + intersection of Select(P6) and Select(P7); hence, the grammar is + deterministic, and the type definition is valid. A decoder will now + assume that an unrecognized element is to be associated with + extension insertion point I1. It is still free to associate an + unrecognized attribute with either extension insertion point. If a + NO-INSERTIONS encoding instruction had been used, then an + unrecognized attribute could only be associated with extension + insertion point I1. + +B.2. Example 2 + + Consider the following type definition: + + SEQUENCE { + one [GROUP] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + } OPTIONAL + } + + The associated grammar is: + + P1: S ::= one + P2: one ::= two + P3: one ::= I1 + P4: one ::= + P5: two ::= "two" + P6: I1 ::= "*" I1 + P7: I1 ::= + + This grammar leads to the following sets and predicates: + + First(P2) = { "two" } + First(P3) = { "*" } + First(P4) = { } + Preselected(P2) = Preselected(P3) = Preselected(P4) = false + Empty(P2) = false + Empty(P3) = Empty(P4) = true + Follow(one) = { "$" } + Select(P2) = First(P2) = { "two" } + Select(P3) = First(P3) + Follow(one) = { "*", "$" } + Select(P4) = First(P4) + Follow(one) = { "$" } + + First(P6) = { "*" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + + + +Legg Experimental [Page 77] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Follow(I1) = { "$" } + Select(P6) = First(P6) = { "*" } + Select(P7) = First(P7) + Follow(I1) = { "$" } + + The intersection of Select(P3) and Select(P4) is not empty; hence, + the grammar is not deterministic, and the type definition is not + valid. If the <two> element is not present, then a decoder cannot + determine whether the "one" alternative is absent, or present with an + unknown extension that generates no elements. + + The non-determinism can be resolved with either a + SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS + encoding instruction. The MULTIFORM-INSERTIONS encoding instruction + is the least restrictive. Consider this revised type definition: + + SEQUENCE { + one [GROUP] [MULTIFORM-INSERTIONS] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + } OPTIONAL + } + + The associated grammar is: + + P1: S ::= one + P2: one ::= two + P8: one ::= "*" I1 + P4: one ::= + P5: two ::= "two" + P6: I1 ::= "*" I1 + P7: I1 ::= + + This grammar leads to the following sets and predicates: + + First(P2) = { "two" } + First(P8) = { "*" } + First(P4) = { } + Preselected(P2) = Preselected(P8) = Preselected(P4) = false + Empty(P2) = Empty(P8) = false + Empty(P4) = true + Follow(one) = { "$" } + Select(P2) = First(P2) = { "two" } + Select(P8) = First(P8) = { "*" } + Select(P4) = First(P4) + Follow(one) = { "$" } + + First(P6) = { "*" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + + + +Legg Experimental [Page 78] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Empty(P7) = true + Follow(I1) = { "$" } + Select(P6) = First(P6) = { "*" } + Select(P7) = First(P7) + Follow(I1) = { "$" } + + The intersection of Select(P2) and Select(P8) is empty, as is the + intersection of Select(P2) and Select(P4), the intersection of + Select(P8) and Select(P4), and the intersection of Select(P6) and + Select(P7); hence, the grammar is deterministic, and the type + definition is valid. A decoder will now assume the "one" alternative + is present if it sees at least one unrecognized element, and absent + otherwise. + +B.3. Example 3 + + Consider the following type definition: + + SEQUENCE { + one [GROUP] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three [GROUP] CHOICE { + four UTF8String, + ... -- Extension insertion point (I2). + } + } + + The associated grammar is: + + P1: S ::= one three + P2: one ::= two + P3: one ::= I1 + P4: two ::= "two" + P5: I1 ::= "*" I1 + P6: I1 ::= + P7: three ::= four + P8: three ::= I2 + P9: four ::= "four" + P10: I2 ::= "*" I2 + P11: I2 ::= + + This grammar leads to the following sets and predicates: + + First(P2) = { "two" } + First(P3) = { "*" } + Preselected(P2) = Preselected(P3) = Empty(P2) = false + Empty(P3) = true + + + +Legg Experimental [Page 79] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Follow(one) = { "four", "*", "$" } + Select(P2) = First(P2) = { "two" } + Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" } + + First(P5) = { "*" } + First(P6) = { } + Preselected(P5) = Preselected(P6) = Empty(P5) = false + Empty(P6) = true + Follow(I1) = { "four", "*", "$" } + Select(P5) = First(P5) = { "*" } + Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" } + + First(P7) = { "four" } + First(P8) = { "*" } + Preselected(P7) = Preselected(P8) = Empty(P7) = false + Empty(P8) = true + Follow(three) = { "$" } + Select(P7) = First(P7) = { "four" } + Select(P8) = First(P8) + Follow(three) = { "*", "$" } + + First(P10) = { "*" } + First(P11) = { } + Preselected(P10) = Preselected(P11) = Empty(P10) = false + Empty(P11) = true + Follow(I2) = { "$" } + Select(P10) = First(P10) = { "*" } + Select(P11) = First(P11) + Follow(I2) = { "$" } + + The intersection of Select(P5) and Select(P6) is not empty; hence, + the grammar is not deterministic, and the type definition is not + valid. If the first child element is an unrecognized element, then a + decoder cannot determine whether to associate it with extension + insertion point I1, or to associate it with extension insertion point + I2 by assuming that the "one" component has an unknown extension that + generates no elements. + + The non-determinism can be resolved with either a SINGULAR-INSERTIONS + or UNIFORM-INSERTIONS encoding instruction. Consider this revised + type definition using the SINGULAR-INSERTIONS encoding instruction: + + + + + + + + + + + + +Legg Experimental [Page 80] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + SEQUENCE { + one [GROUP] [SINGULAR-INSERTIONS] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three [GROUP] CHOICE { + four UTF8String, + ... -- Extension insertion point (I2). + } + } + + The associated grammar is: + + P1: S ::= one three + P2: one ::= two + P12: one ::= "*" + P4: two ::= "two" + P7: three ::= four + P8: three ::= I2 + P9: four ::= "four" + P10: I2 ::= "*" I2 + P11: I2 ::= + + With the addition of the SINGULAR-INSERTIONS encoding instruction, + the P5 and P6 productions are no longer generated. The grammar leads + to the following sets and predicates for the P2 and P12 productions: + + First(P2) = { "two" } + First(P12) = { "*" } + Preselected(P2) = Preselected(P12) = false + Empty(P2) = Empty(P12) = false + Follow(one) = { "four", "*", "$" } + Select(P2) = First(P2) = { "two" } + Select(P12) = First(P12) = { "*" } + + The sets for P5 and P6 are no longer generated, and the remaining + sets are unchanged. + + The intersection of Select(P2) and Select(P12) is empty, as is the + intersection of Select(P7) and Select(P8) and the intersection of + Select(P10) and Select(P11); hence, the grammar is deterministic, and + the type definition is valid. If the first child element is an + unrecognized element, then a decoder will now assume that it is + associated with extension insertion point I1. Whatever follows, + possibly including another unrecognized element, will belong to the + "three" component. + + + + + +Legg Experimental [Page 81] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + Now consider the type definition using the UNIFORM-INSERTIONS + encoding instruction instead: + + SEQUENCE { + one [GROUP] [UNIFORM-INSERTIONS] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + }, + three [GROUP] CHOICE { + four UTF8String, + ... -- Extension insertion point (I2). + } + } + + The associated grammar is: + + P1: S ::= one three + P2: one ::= two + P13: one ::= "*" + P14: one ::= "*1" I1 + P4: two ::= "two" + P15: I1 ::= "*1" I1 + P6: I1 ::= + P7: three ::= four + P8: three ::= I2 + P9: four ::= "four" + P10: I2 ::= "*" I2 + P11: I2 ::= + + This grammar leads to the following sets and predicates for the P2, + P13, P14, P15, and P6 productions: + + First(P2) = { "two" } + First(P13) = { "*" } + First(P14) = { "*1" } + Preselected(P2) = Preselected(P13) = Preselected(P14) = false + Empty(P2) = Empty(P13) = Empty(P14) = false + Follow(one) = { "four", "*", "$" } + Select(P2) = First(P2) = { "two" } + Select(P13) = First(P13) = { "*" } + Select(P14) = First(P14) = { "*1" } + + + + + + + + + + +Legg Experimental [Page 82] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + First(P15) = { "*1" } + First(P6) = { } + Preselected(P15) = Preselected(P6) = Empty(P15) = false + Empty(P6) = true + Follow(I1) = { "four", "*", "$" } + Select(P15) = First(P15) = { "*1" } + Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" } + + The remaining sets are unchanged. + + The intersection of Select(P2) and Select(P13) is empty, as is the + intersection of Select(P2) and Select(P14), the intersection of + Select(P13) and Select(P14) and the intersection of Select(P15) and + Select(P6); hence, the grammar is deterministic, and the type + definition is valid. If the first child element is an unrecognized + element, then a decoder will now assume that it and every subsequent + unrecognized element with the same name are associated with I1. + Whatever follows, possibly including another unrecognized element + with a different name, will belong to the "three" component. + + A consequence of using the UNIFORM-INSERTIONS encoding instruction is + that any future extension to the "three" component will be required + to generate elements with names that are different from the names of + the elements generated by the "one" component. With the + SINGULAR-INSERTIONS encoding instruction, extensions to the "three" + component are permitted to generate elements with names that are the + same as the names of the elements generated by the "one" component. + +B.4. Example 4 + + Consider the following type definition: + + SEQUENCE OF one [GROUP] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + } + + The associated grammar is: + + P1: S ::= one S + P2: S ::= + P3: one ::= two + P4: one ::= I1 + P5: two ::= "two" + P6: I1 ::= "*" I1 + P7: I1 ::= + + + + + +Legg Experimental [Page 83] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + This grammar leads to the following sets and predicates: + + First(P1) = { "two", "*" } + First(P2) = { } + Preselected(P1) = Preselected(P2) = false + Empty(P1) = Empty(P2) = true + Follow(S) = { "$" } + Select(P1) = First(P1) + Follow(S) = { "two", "*", "$" } + Select(P2) = First(P2) + Follow(S) = { "$" } + + First(P3) = { "two" } + First(P4) = { "*" } + Preselected(P3) = Preselected(P4) = Empty(P3) = false + Empty(P4) = true + Follow(one) = { "two", "*", "$" } + Select(P3) = First(P3) = { "two" } + Select(P4) = First(P4) + Follow(one) = { "*", "two", "$" } + + First(P6) = { "*" } + First(P7) = { } + Preselected(P6) = Preselected(P7) = Empty(P6) = false + Empty(P7) = true + Follow(I1) = { "two", "*", "$" } + Select(P6) = First(P6) = { "*" } + Select(P7) = First(P7) + Follow(I1) = { "two", "*", "$" } + + The intersection of Select(P1) and Select(P2) is not empty, as is the + intersection of Select(P3) and Select(P4) and the intersection of + Select(P6) and Select(P7); hence, the grammar is not deterministic, + and the type definition is not valid. If a decoder encounters two or + more unrecognized elements in a row, then it cannot determine whether + this represents one instance or more than one instance of the "one" + component. Even without unrecognized elements, there is still a + problem that an encoding could contain an indeterminate number of + "one" components using an extension that generates no elements. + + The non-determinism cannot be resolved with a UNIFORM-INSERTIONS + encoding instruction. Consider this revised type definition using + the UNIFORM-INSERTIONS encoding instruction: + + SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + } + + + + + + + +Legg Experimental [Page 84] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The associated grammar is: + + P1: S ::= one S + P2: S ::= + P3: one ::= two + P8: one ::= "*" + P9: one ::= "*1" I1 + P5: two ::= "two" + P10: I1 ::= "*1" I1 + P7: I1 ::= + + This grammar leads to the following sets and predicates: + + First(P1) = { "two", "*", "*1" } + First(P2) = { } + Preselected(P1) = Preselected(P2) = Empty(P1) = false + Empty(P2) = true + Follow(S) = { "$" } + Select(P1) = First(P1) = { "two", "*", "*1" } + Select(P2) = First(P2) + Follow(S) = { "$" } + + First(P3) = { "two" } + First(P8) = { "*" } + First(P9) = { "*1" } + Preselected(P3) = Preselected(P8) = Preselected(P9) = false + Empty(P3) = Empty(P8) = Empty(P9) = false + Follow(one) = { "two", "*", "*1", "$" } + Select(P3) = First(P3) = { "two" } + Select(P8) = First(P8) = { "*" } + Select(P9) = First(P9) = { "*1" } + + First(P10) = { "*1" } + First(P7) = { } + Preselected(P10) = Preselected(P7) = Empty(P10) = false + Empty(P7) = true + Follow(I1) = { "two", "*", "*1", "$" } + Select(P10) = First(P10) = { "*1" } + Select(P7) = First(P7) + Follow(I1) = { "two", "*", "*1", "$" } + + The intersection of Select(P1) and Select(P2) is now empty, but the + intersection of Select(P10) and Select(P7) is not; hence, the grammar + is not deterministic, and the type definition is not valid. The + problem of an indeterminate number of "one" components from an + extension that generates no elements has been solved. However, if a + decoder encounters a series of elements with the same name, it cannot + determine whether this represents one instance or more than one + instance of the "one" component. + + + + +Legg Experimental [Page 85] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The non-determinism can be fully resolved with a SINGULAR-INSERTIONS + encoding instruction. Consider this revised type definition: + + SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE { + two UTF8String, + ... -- Extension insertion point (I1). + } + + The associated grammar is: + + P1: S ::= one S + P2: S ::= + P3: one ::= two + P8: one ::= "*" + P5: two ::= "two" + + This grammar leads to the following sets and predicates: + + First(P1) = { "two", "*" } + First(P2) = { } + Preselected(P1) = Preselected(P2) = Empty(P1) = false + Empty(P2) = true + Follow(S) = { "$" } + Select(P1) = First(P1) = { "two", "*" } + Select(P2) = First(P2) + Follow(S) = { "$" } + + First(P3) = { "two" } + First(P8) = { "*" } + Preselected(P3) = Preselected(P8) = false + Empty(P3) = Empty(P8) = false + Follow(one) = { "two", "*", "$" } + Select(P3) = First(P3) = { "two" } + Select(P8) = First(P8) = { "*" } + + The intersection of Select(P1) and Select(P2) is empty, as is the + intersection of Select(P3) and Select(P8); hence, the grammar is + deterministic, and the type definition is valid. A decoder now knows + that every extension to the "one" component will generate a single + element, so the correct number of "one" components will be decoded. + + + + + + + + + + + + +Legg Experimental [Page 86] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +Appendix C. Extension and Versioning Examples + + This appendix is non-normative. + +C.1. Valid Extensions for Insertion Encoding Instructions + + The first example shows extensions that satisfy the HOLLOW-INSERTIONS + encoding instruction. + + [HOLLOW-INSERTIONS] CHOICE { + one BOOLEAN, + ..., + two [ATTRIBUTE] INTEGER, + three [GROUP] SEQUENCE { + four [ATTRIBUTE] UTF8String, + five [ATTRIBUTE] INTEGER OPTIONAL, + ... + }, + six [GROUP] CHOICE { + seven [ATTRIBUTE] BOOLEAN, + eight [ATTRIBUTE] INTEGER + } + } + + The "two" and "six" components generate only attributes. + + The "three" component in its current form does not generate elements. + Any extension to the "three" component will need to do likewise to + avoid breaking forward compatibility. + + The second example shows extensions that satisfy the + SINGULAR-INSERTIONS encoding instruction. + + [SINGULAR-INSERTIONS] CHOICE { + one BOOLEAN, + ..., + two INTEGER, + three [GROUP] SEQUENCE { + four [ATTRIBUTE] UTF8String, + five INTEGER + }, + six [GROUP] CHOICE { + seven BOOLEAN, + eight INTEGER + } + } + + + + + +Legg Experimental [Page 87] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + The "two" component will always generate a single <two> element. + + The "three" component will always generate a single <five> element. + It will also generate a "four" attribute, but any number of + attributes is allowed by the SINGULAR-INSERTIONS encoding + instruction. + + The "six" component will either generate a single <seven> element or + a single <eight> element. Either case will satisfy the requirement + that there will be a single element in any given encoding of the + extension. + + The third example shows extensions that satisfy the + UNIFORM-INSERTIONS encoding instruction. + + [UNIFORM-INSERTIONS] CHOICE { + one BOOLEAN, + ..., + two INTEGER, + three [GROUP] SEQUENCE SIZE(1..MAX) OF four INTEGER, + five [GROUP] SEQUENCE { + six [ATTRIBUTE] UTF8String OPTIONAL, + seven INTEGER + }, + eight [GROUP] CHOICE { + nine BOOLEAN, + ten [GROUP] SEQUENCE SIZE(1..MAX) OF eleven INTEGER + } + } + + The "two" component will always generate a single <two> element. + + The "three" component will always generate one or more <four> + elements. + + The "five" component will always generate a single <seven> element. + It may also generate a "six" attribute, but any number of attributes + is allowed by the UNIFORM-INSERTIONS encoding instruction. + + The "eight" component will either generate a single <nine> element or + one or more <eleven> elements. Either case will satisfy the + requirement that there must be one or more elements with the same + name in any given encoding of the extension. + + + + + + + + +Legg Experimental [Page 88] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +C.2. Versioning Example + + Making extensions that are not forward compatible is permitted + provided that the incompatibility is signalled with a version + indicator attribute. + + Suppose that version 1.0 of a specification contains the following + type definition: + + MyMessageType ::= SEQUENCE { + version [ATTRIBUTE] [VERSION-INDICATOR] + UTF8String ("1.0", ...) DEFAULT "1.0", + one [GROUP] [SINGULAR-INSERTIONS] CHOICE { + two BOOLEAN, + ... + }, + ... + } + + An attribute is to be added to the CHOICE for version 1.1. This + change is not forward compatible since it does not satisfy the + SINGULAR-INSERTIONS encoding instruction. Therefore, the version + indicator attribute must be updated at the same time (or added if it + wasn't already present). This results in the following new type + definition for version 1.1: + + MyMessageType ::= SEQUENCE { + version [ATTRIBUTE] [VERSION-INDICATOR] + UTF8String ("1.0", ..., "1.1") DEFAULT "1.0", + one [GROUP] [SINGULAR-INSERTIONS] CHOICE { + two BOOLEAN, + ..., + three [ATTRIBUTE] INTEGER -- Added in Version 1.1 + }, + ... + } + + If a version 1.1 conformant application hasn't used the version 1.1 + extension in a value of MyMessageType, then it is allowed to set the + value of the version attribute to "1.0". + + A pair of elements is added to the CHOICE for version 1.2. Again the + change does not satisfy the SINGULAR-INSERTIONS encoding instruction. + The type definition for version 1.2 is: + + + + + + + +Legg Experimental [Page 89] + +RFC 4911 Encoding Instructions for RXER July 2007 + + + MyMessageType ::= SEQUENCE { + version [ATTRIBUTE] [VERSION-INDICATOR] + UTF8String ("1.0", ..., "1.1" | "1.2") + DEFAULT "1.0", + one [GROUP] [SINGULAR-INSERTIONS] CHOICE { + two BOOLEAN, + ..., + three [ATTRIBUTE] INTEGER, -- Added in Version 1.1 + four [GROUP] SEQUENCE { + five UTF8String, + six GeneralizedTime + } -- Added in version 1.2 + }, + ... + } + + If a version 1.2 conformant application hasn't used the version 1.2 + extension in a value of MyMessageType, then it is allowed to set the + value of the version attribute to "1.1". If it hasn't used either of + the extensions, then it is allowed to set the value of the version + attribute to "1.0". + +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 + + + + + + + + + + + + + + + + + +Legg Experimental [Page 90] + +RFC 4911 Encoding Instructions for RXER July 2007 + + +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. + + + + + + + +Legg Experimental [Page 91] + |