One document matched: draft-legg-xed-rxer-ei-03.txt
Differences from draft-legg-xed-rxer-ei-02.txt
INTERNET-DRAFT S. Legg
draft-legg-xed-rxer-ei-03.txt eB2Bcom
Intended Category: Standards Track October 23, 2006
Encoding Instructions for the
Robust XML Encoding Rules (RXER)
Copyright (C) The Internet Society (2006).
Status of This Memo
By submitting this Internet-draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Technical discussion of this document should take place on the XED
developers mailing list <xeddev@eb2bcom.com>. Please send editorial
comments directly to the editor <steven.legg@eb2bcom.com>. Further
information is available on the XED website: www.xmled.info.
This Internet-Draft expires on 23 April 2007.
Abstract
This document defines encoding instructions that may be used in an
Abstract Syntax Notation One (ASN.1) specification to alter how
values are encoded by the Robust XML Encoding Rules (RXER) and
Canonical Robust XML Encoding Rules (CRXER), for example, to encode a
component of an ASN.1 type as an Extensible Markup Language (XML)
Legg Expires 23 April 2007 [Page 1]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 Expires 23 April 2007 [Page 2]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Table of Contents
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Definitions .....................................................4
4. Notation for RXER Encoding Instructions .........................5
5. Component Encoding Instructions .................................7
6. Reference Encoding Instructions .................................9
7. Effective Names of Components ..................................10
8. The ATTRIBUTE Encoding Instruction .............................12
9. The ATTRIBUTE-REF Encoding Instruction .........................12
10. The COMPONENT-REF Encoding Instruction ........................14
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 ..........................21
16. The SCHEMA-IDENTITY Encoding Instruction ......................22
17. The SIMPLE-CONTENT Encoding Instruction .......................22
18. The TARGET-NAMESPACE Encoding Instruction .....................24
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 ...............................28
23. Insertion Encoding Instructions ...............................29
24. The VERSION-INDICATOR Encoding Instruction ....................32
25. The GROUP Encoding Instruction ................................33
25.1. Unambiguous Encodings ....................................36
25.1.1. Grammar Construction .............................36
25.1.2. Unique Component Attribution .....................45
25.1.3. Deterministic Grammars ...........................49
25.1.4. Attributes in Unknown Extensions .................51
26. Security Considerations .......................................53
27. IANA Considerations ...........................................53
28. References ....................................................53
28.1. Normative References .....................................53
28.2. Informative References ...................................55
Appendix A. GROUP Encoding Instruction Examples ...................55
Appendix B. Insertion Encoding Instruction Examples ...............70
Appendix C. Extension and Versioning Examples .....................83
1. Introduction
This document defines encoding instructions [X.680-1] that may be
used in an Abstract Syntax Notation One (ASN.1) [X.680] specification
to alter how values are encoded by the Robust XML Encoding Rules
(RXER) [RXER] and Canonical Robust XML Encoding Rules (CRXER) [RXER],
for example, to encode a component of an ASN.1 type as an Extensible
Legg Expires 23 April 2007 [Page 3]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 "http://www.w3.org/2001/XMLSchema-instance".
Example ASN.1 definitions in this document are assumed to be defined
in an ASN.1 module with a TagDefault of "AUTOMATIC TAGS" and an
EncodingReferenceDefault [X.680-1] of "RXER INSTRUCTIONS".
3. Definitions
The following definition of base type is used in specifying a number
of encoding instructions.
If a type, T, is a constrained type, then the base type of T is the
base type of the type that is constrained, otherwise if T is a
prefixed type, then the base type of T is the base type of the type
Legg Expires 23 April 2007 [Page 4]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
that is prefixed, otherwise if T is a type notation that references
or denotes another type (i.e., DefinedType, ObjectClassFieldType,
SelectionType, TypeFromObject, 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:
EncodingInstruction ::=
AttributeInstruction |
AttributeRefInstruction |
ComponentRefInstruction |
ElementRefInstruction |
GroupInstruction |
InsertionsInstruction |
ListInstruction |
NameInstruction |
RefAsElementInstruction |
RefAsTypeInstruction |
SimpleContentInstruction |
TypeAsVersionInstruction |
Legg Expires 23 April 2007 [Page 5]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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, using the
conventions of the ASN.1 basic notation:
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 of 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.
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
Legg Expires 23 April 2007 [Page 6]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
The Value production is defined by the ASN.1 basic notation.
The governing type for the Value of an NCNameValue is the NCName type
from the AdditionalBasicDefinitions module [RXER].
The governing type for the Value of an AnyURIValue is the AnyURI type
from the AdditionalBasicDefinitions module.
The governing type for the Value of a QNameValue is the QName type
from the AdditionalBasicDefinitions module.
The governing type for the Value of a NameValue is the Name type from
the AdditionalBasicDefinitions module.
The 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,
ElementRefInstruction, NameInstruction, RefAsElementInstruction,
SimpleContentInstruction, TypeAsVersionInstruction and
VersionIndicatorInstruction).
The Type in the EncodingPrefixedType for a component encoding
instruction SHALL be either:
(a) the Type in a NamedType, or
(b) the Type in an EncodingPrefixedType in a PrefixedType in a
BuiltinType in a Type that is one of (a) to (d), or
Legg Expires 23 April 2007 [Page 7]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(c) the Type in an TaggedType in a PrefixedType in a BuiltinType in a
Type that is one of (a) to (d), or
(d) the Type in a ConstrainedType (excluding a TypeWithConstraint) in
a Type that is one of (a) to (d).
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 (b) can be true on the first
iteration as the Type belongs to an EncodingPrefixedType, however
any of (a) to (d) can be true on subsequent iterations.
Case (d) 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 (a) 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.
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.
Legg Expires 23 April 2007 [Page 8]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
(a) a ReferencedType that is a DefinedType that is a typereference
(not a DummyReference) or ExternalTypeReference that references
the AnyType ASN.1 type from the AdditionalBasicDefinitions module
[RXER], or
(b) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (c), 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
Legg Expires 23 April 2007 [Page 9]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
EncodingPrefixedType does not contain a reference encoding
instruction.
Aside: Case (c) 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 (a) 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 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. 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.
7. Effective Names of Components
Definition (effective name): The effective name for a NamedType is a
value of the QName ASN.1 type from the AdditionalBasicDefinitions
module [RXER], representing the qualified name of the component in an
RXER encoding.
The effective name for a NamedType is determined as follows:
Legg Expires 23 April 2007 [Page 10]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(a) if the NamedType is subject to a NAME encoding instruction, then
the value of the local-name component of the effective name is
the character string specified by the NCNameValue of the NAME
encoding instruction,
(b) otherwise, if the NamedType is subject to a COMPONENT-REF
encoding instruction, then the effective name is the same as the
effective name of the referenced top-level NamedType,
(c) otherwise, if the NamedType is subject to an ATTRIBUTE-REF or
ELEMENT-REF encoding instruction, then the effective name is the
QNameValue of the encoding instruction,
(d) otherwise, if the NamedType is subject to a REF-AS-ELEMENT
encoding instruction, then the value of the local-name component
of the effective name is the LocalPart [XMLNS10] of the qualified
name specified by the NameValue of the encoding instruction,
(e) otherwise, the value of the local-name component of the effective
name is the identifier of the NamedType.
In case (a) and (e), if the NamedType is a top-level NamedType and
the module containing the NamedType has a TARGET-NAMESPACE encoding
instruction, then the namespace-name component of the effective name
is the character string specified by the AnyURIValue of the
TARGET-NAMESPACE encoding instruction, otherwise it is absent.
Aside: Thus the TARGET-NAMESPACE encoding instruction applies to a
top-level NamedType but not to any other NamedType.
In case (d), if the encoding instruction contains a Namespace, then
the namespace-name component of the effective name is the character
string specified by the AnyURIValue of the Namespace, otherwise it is
absent.
Two effective names are distinct if they are different abstract
values of the QName ASN.1 type.
The effective names for the attribute components of a CHOICE,
SEQUENCE or SET type MUST be distinct. The effective 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].
Aside: Two components of the same CHOICE, SEQUENCE or SET type may
have the same effective 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
Legg Expires 23 April 2007 [Page 11]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
instruction.
The effective name of a top-level NamedType subject to an ATTRIBUTE
encoding instruction MUST be distinct from the effective name of
every other top-level NamedType subject to an ATTRIBUTE encoding
instruction in the same module.
The effective name of a top-level NamedType not subject to an
ATTRIBUTE encoding instruction MUST be distinct from the effective
name of every other top-level NamedType not subject to an ATTRIBUTE
encoding instruction in the same module.
8. The ATTRIBUTE Encoding Instruction
The ATTRIBUTE encoding instruction causes an RXER encoder to encode
the component to which it is applied as an XML attribute instead of
as a child element.
The notation for an ATTRIBUTE encoding instruction is defined as
follows:
AttributeInstruction ::= "ATTRIBUTE"
The base type of the type of a NamedType that is subject to an
ATTRIBUTE encoding instruction SHALL NOT be:
(a) a CHOICE, SET or SET OF type, or
(b) a SEQUENCE type other than the one defining the QName type from
the AdditionalBasicDefinitions module [RXER] (i.e., QName is
allowed), or
(c) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
(d) an open type.
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
Legg Expires 23 April 2007 [Page 12]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
encode the component to which it is applied as an XML attribute
instead of as a child element, where the attribute's name is the
qualified name of the attribute definition referenced by the encoding
instruction. In addition, the ATTRIBUTE-REF encoding instruction
causes values of the UTF8String type to be restricted to conform to
the type of the attribute definition.
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
definition or a top-level NamedType that is subject to an ATTRIBUTE
encoding instruction.
The type of a referenced XML Schema attribute definition 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:
(a) the UTF8String type, or
(b) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (c), 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 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 the RXER
encoding. For the sake of consistency, the identifier SHOULD, where
Legg Expires 23 April 2007 [Page 13]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
possible, be the same as local part of the name of the referenced
attribute definition.
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.
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.
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:
(a) a ReferencedType that is a DefinedType that is a typereference
(not a DummyReference) or ExternalTypeReference, or
(b) a BuiltinType or ReferencedType comprising one of the productions
in Table 1 in Section 6.3 of the specification for ASN.X [ASN.X],
or
(c) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (d), or
Legg Expires 23 April 2007 [Page 14]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(d) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (d) and the EncodingPrefix in the
EncodingPrefixedType does not contain a reference encoding
instruction.
The Type in the top-level NamedType referenced by the COMPONENT-REF
encoding instruction MUST be either:
(i) if case (a) is used, a ReferencedType that is a DefinedType
that is a typereference or ExternalTypeReference that
references the same type as the DefinedType in case (a), or
(ii) if case (b) is used, a BuiltinType or ReferencedType that is
the same as the BuiltinType or ReferencedType in case (b), or
(iii) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (i) to (iii) and the EncodingPrefix in the
EncodingPrefixedType contains an RXER 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.
In principle, the COMPONENT-REF encoding instruction creates a
notional NamedType where the effective name is that of the referenced
top-level NamedType and the Type in case (a) or (b) is substituted by
the Type of the referenced top-level NamedType.
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 (a) or (b) 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 (a) or (b) 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
Legg Expires 23 April 2007 [Page 15]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
11. The ELEMENT-REF Encoding Instruction
The ELEMENT-REF encoding instruction causes an RXER encoder to encode
the component to which it is applied as an element where the
element's name is the qualified name of the element definition
referenced by the encoding instruction. In addition, the ELEMENT-REF
encoding instruction causes values of the Markup ASN.1 type to be
restricted to conform to the type of the element definition.
The notation for an ELEMENT-REF encoding instruction is defined as
follows:
ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParameters
Taken together, the QNameValue and the ContextParameter in the
RefParameters (if present) MUST reference an XML Schema element
definition, a RELAX NG element definition, or a top-level NamedType
that is not subject to an ATTRIBUTE encoding instruction.
A referenced XML Schema element definition MUST NOT have a type that
Legg Expires 23 April 2007 [Page 16]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
<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 the RXER
encoding. For the sake of consistency, the identifier SHOULD, where
possible, be the same as the local part of the name of the referenced
element definition.
12. The LIST Encoding Instruction
The LIST encoding instruction causes an RXER encoder to encode a
Legg Expires 23 April 2007 [Page 17]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
value of a SEQUENCE OF type as a white space separated list of the
component values.
The notation for a LIST encoding instruction is defined as follows:
ListInstruction ::= "LIST"
The Type in an EncodingPrefixedType specifying a LIST encoding
instruction SHALL be:
(a) a BuiltinType that is a SequenceOfType of the
"SEQUENCE OF NamedType" form, or
(b) a ConstrainedType that is a TypeWithConstraint of the
"SEQUENCE Constraint OF NamedType" form or
"SEQUENCE SizeConstraint OF NamedType" form, or
(c) a ConstrainedType, other than a TypeWithConstraint, where the
Type in the ConstrainedType is one of (a) to (e), or
(d) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (e), or
(e) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (e).
The effect of this condition is to force the LIST encoding
instruction to be textually co-located with the SequenceOfType or
TypeWithConstraint to which it applies.
Aside: This makes it clear to a reader that the encoding
instruction applies to every use of the type no matter how it
might be referenced.
The SequenceOfType in case (a) and the TypeWithConstraint in case (b)
are said to be "subject to" the LIST encoding instruction.
A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more
than one LIST encoding instruction.
The 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:
(a) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER,
RELATIVE-OID, GeneralizedTime or UTCTime type, or
Legg Expires 23 April 2007 [Page 18]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(b) 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
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 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
Legg Expires 23 April 2007 [Page 19]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
[XMLNS10].
If the Name of the element type declaration conforms to a QName with
a Prefix [XMLNS10], then the optional Namespace in the
RefAsElementInstruction specifies the namespace name associated with
that Prefix.
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:
Legg Expires 23 April 2007 [Page 20]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
<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 the RXER
encoding. For the sake of consistency, the identifier SHOULD, where
possible, be the same as the Name of the referenced element type
declaration.
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.
The notation for a REF-AS-TYPE encoding instruction is defined as
follows:
RefAsTypeInstruction ::=
"REF-AS-TYPE" NameValue Namespace ? 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
[XMLNS10].
If the Name of the elementType declaration conforms to a QName with a
Prefix [XMLNS10], then the optional Namespace in the
RefAsTypeInstruction specifies the namespace name associated with
that Prefix.
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
Legg Expires 23 April 2007 [Page 21]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
[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"/>
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 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:
Legg Expires 23 April 2007 [Page 22]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
NOT be element components and MUST NOT be subject to a GROUP encoding
instruction. 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.
The base type of the type of a NamedType that is subject to a
SIMPLE-CONTENT encoding instruction SHALL NOT be:
(a) a SET or SET OF type, or
(b) a CHOICE type where the ChoiceType is not subject to a UNION
encoding instruction, or
(c) a SEQUENCE type other than the one defining the QName type from
the AdditionalBasicDefinitions module [RXER] (i.e., QName is
allowed), or
(d) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
(d) 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
Legg Expires 23 April 2007 [Page 23]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
}
18. The TARGET-NAMESPACE Encoding Instruction
The TARGET-NAMESPACE encoding instruction associates an XML namespace
name, a URI [URI], with the type, object class, value, object and
object set references defined in the ASN.1 module containing the
encoding instruction. In addition, it associates the namespace name
with each 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
Two or more ASN.1 modules MAY have TARGET-NAMESPACE encoding
instructions where the AnyURIValue specifies the same character
string if and only if the effective names of the top-level attribute
components are distinct across all those modules, the effective 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 mutually distinct across all those modules.
The Prefix, if present, suggests an NCName to use as the namespace
prefix in namespace declarations involving the namespace name
specified by the AnyURIValue. 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 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
Legg Expires 23 April 2007 [Page 24]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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"
The Type in a NamedType that is subject to a TYPE-AS-VERSION encoding
instruction MUST be a Type that has a Qualified Reference Name
[RXER].
The addition of a TYPE-AS-VERSION encoding instruction does not
affect the backward compatibility of RXER encodings.
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 [ISET] representation of the RXER encoding of
abstract values of the type. It is still sufficient to preserve
just the abstract values.
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.
Legg Expires 23 April 2007 [Page 25]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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].
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
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 ?
Legg Expires 23 April 2007 [Page 26]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
The Type in the EncodingPrefixedType for a UNION encoding instruction
SHALL be:
(a) a BuiltinType that is a ChoiceType, or
(b) a ConstrainedType, other than a TypeWithConstraint, where the
Type in the ConstrainedType is one of (a) to (d), or
(c) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (d), or
(d) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (d).
The ChoiceType in case (a) is said to be "subject to" the UNION
encoding instruction.
The base type of the type of each alternative of a ChoiceType that is
subject to a UNION encoding instruction SHALL NOT be:
(a) a CHOICE, SET or SET OF type, or
(b) a SEQUENCE type other than the one defining the QName type from
the AdditionalBasicDefinitions module [RXER] (i.e., QName is
allowed), or
(c) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction, or
(d) an open type.
Each identifier in the PrecedenceList MUST be the identifier of a
component (i.e., a NamedType) of the ChoiceType.
A particular identifier SHALL NOT appear more than once in the same
PrecedenceList.
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
Legg Expires 23 April 2007 [Page 27]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
}
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.
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:
(a) a BuiltinType that is a BitStringType with a NamedBitList, or
(b) a BuiltinType that is an EnumeratedType, or
(c) a BuiltinType that is an IntegerType with a NamedNumberList, or
(d) a ConstrainedType, other than a TypeWithConstraint, where the
Type in the ConstrainedType is one of (a) to (f), or
(e) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (f), or
(f) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (f).
The effect of this condition is to force the VALUES encoding
instruction to be textually co-located with the type definition to
which it applies.
The BitStringType, EnumeratedType or IntegerType in case (a), (b) or
Legg Expires 23 April 2007 [Page 28]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(c) (respectively) is said to be "subject to" the VALUES encoding
instruction.
A BitStringType, EnumeratedType or IntegerType SHALL NOT be subject
to more than one VALUES encoding instruction.
Each identifier in a ValueMapping MUST be an identifier appearing in
the NamedBitList, Enumerations or NamedNumberList, as the case may
be.
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, otherwise if
AllCapitalized is used, then the replacement name is the identifier
with the first character uppercased, otherwise if AllUppercased is
used, then the replacement name is the identifier with all its
characters uppercased, otherwise, the replacement name is the
identifier.
The replacement names for the identifiers in a BitStringType subject
to a VALUES encoding instruction MUST be distinct.
The replacement names for the identifiers in an EnumeratedType
subject to a VALUES encoding instruction MUST be distinct.
The replacement names for the identifiers in an IntegerType subject
to a VALUES encoding instruction MUST be distinct.
Example
Traffic-Light ::= [VALUES ALL CAPITALIZED, red AS "RED"]
ENUMERATED {
red, -- 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
Legg Expires 23 April 2007 [Page 29]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(whose notations are described respectively by
NoInsertionsInstruction, HollowInsertionsInstruction,
SingularInsertionsInstruction, UniformInsertionsInstruction and
MultiformInsertionsInstruction).
The notation for the insertion encoding instructions is defined as
follows:
InsertionsInstruction ::=
NoInsertionsInstruction |
HollowInsertionsInstruction |
SingularInsertionsInstruction |
UniformInsertionsInstruction |
MultiformInsertionsInstruction
NoInsertionsInstruction ::= "NO-INSERTIONS"
HollowInsertionsInstruction ::= "HOLLOW-INSERTIONS"
SingularInsertionsInstruction ::= "SINGULAR-INSERTIONS"
UniformInsertionsInstruction ::= "UNIFORM-INSERTIONS"
MultiformInsertionsInstruction ::= "MULTIFORM-INSERTIONS"
The insertion encoding instructions serve two purposes. Firstly, to
remove the ambiguity that can arise from use of the GROUP encoding
instruction over which extension insertion point to use for unknown
extensions. Secondly, to 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 for use of the GROUP and ATTRIBUTE encoding
instructions by the extensions.
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
Legg Expires 23 April 2007 [Page 30]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 name, and zero
or more attributes. The name shared by the element items in any
given encoding is not required to be the same across all possible
encodings of the extension.
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 across all
possible encodings 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:
(a) a BuiltinType that is a ChoiceType where the ChoiceType is not
subject to a UNION encoding instruction, or
(b) a BuiltinType that is a SequenceType or SetType, or
(c) a ConstrainedType, other than a TypeWithConstraint, where the
Type in the ConstrainedType is one of (a) to (e), or
(d) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (e), or
(e) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (e).
Case (b) is not permitted when the insertion encoding instruction is
the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS or MULTIFORM-INSERTIONS
encoding instruction.
Aside: Because extensions to a SET or SEQUENCE type are serial and
effectively optional, the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS
Legg Expires 23 April 2007 [Page 31]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 (a) or case (b) is said to be "subject to" the
insertion encoding instruction.
The Type in case (a) or case (b) 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.
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.
If an RXER decoder encounters a value of the type that is not one of
the root values or extension additions (but still allowed since the
set of permitted values is extensible), then this indicates that the
Legg Expires 23 April 2007 [Page 32]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
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.
25. The GROUP Encoding Instruction
The GROUP encoding instruction causes an RXER encoder to encode the
component to which it is applied without encapsulation as an element.
It allows the construction of non-trivial content models for element
content.
The notation for a GROUP encoding instruction is defined as follows:
Legg Expires 23 April 2007 [Page 33]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
GroupInstruction ::= "GROUP"
The base type of the type of a NamedType that is subject to a GROUP
encoding instruction SHALL be:
(a) a SEQUENCE, SET or SET OF type, or
(b) a CHOICE type where the ChoiceType is not subject to a UNION
encoding instruction, or
(c) a SEQUENCE OF type where the SequenceOfType is not subject to a
LIST encoding instruction.
The SEQUENCE type in case (a) SHALL NOT be the associated type for a
built-in type, SHALL NOT be from the AdditionalBasicDefinitions
module [RXER] and SHALL NOT contain a component that is subject to a
SIMPLE-CONTENT encoding instruction. Thus this condition excludes
the CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL and QName types.
The CHOICE type in case (b) SHALL NOT be from the
AdditionalBasicDefinitions module. Thus this condition excludes the
Markup type.
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].
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.
Legg Expires 23 April 2007 [Page 34]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 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 which 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.
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
Legg Expires 23 April 2007 [Page 35]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
(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. If the
original abstract value cannot be reliably decoded, then a canonical
encoding of the original abstract value (using some other set of
encoding rules) cannot be reliably reproduced, among other problems.
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 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 a type
definition containing components subject to the GROUP encoding
instruction as a grammar. Sections 25.1.2 and 25.1.3 specify
conditions that the grammar must satisfy for the type definition to
be valid. 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
Legg Expires 23 April 2007 [Page 36]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
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.
In the examples in this document the terminal for a component other
than an attribute component will be represented as the effective name
of the component enclosed in quotes, and the terminal for an
attribute component will be represented as the effective name of the
component prefixed by the @ character and enclosed in quotes. The
Legg Expires 23 April 2007 [Page 37]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
(1) If the initial RootComponentTypeList is present in the base type,
then the sequence of primary non-terminals for the components in
that RootComponentTypeList are appended to the right hand side in
the order of their definition.
(2) If the ExtensionAdditions is present in the base type, then the
non-terminal for the first ExtensionAddition is appended to the
right hand side.
(3) If the ExtensionAdditions is 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 primary non-terminal corresponding
to the extension insertion point for the type is appended to the
right hand side.
(4) If the final RootComponentTypeList is present in the base type,
then the primary non-terminals for the components in that
RootComponentTypeList are appended to the right hand side in the
order of their definition.
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
Legg Expires 23 April 2007 [Page 38]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 are added to the grammar with the primary non-terminal of
the component as the left hand side and the right hand sides
constructed according to the component's type.
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.
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 of the ComponentType is
appended to the right hand side, otherwise (an
ExtensionAdditionGroup) the sequence of primary non-terminals for the
components in the ComponentTypeList of 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
Legg Expires 23 April 2007 [Page 39]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
appended to the right hand side. If the empty sequence of terminals
cannot be generated from this production (it may be necessary to wait
until the grammar is otherwise complete before making this
determination), then another production is added to the grammar where
the left hand side is the non-terminal for the ExtensionAddition and
the right hand side is empty.
Aside: An extension is always effectively optional since a sender
may be using an earlier version of the ASN.1 specification where
none, or only some, of the extensions have been defined.
Aside: The grammar generated for ExtensionAdditions is structured
to take account of the condition that an extension can only be
used if all the earlier extensions are also used [X.680].
For each extension insertion point 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 extension insertion point and the right hand
side is the general extension terminal followed by the the
non-terminal for the extension insertion point. Another 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 annotated 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:
Legg Expires 23 April 2007 [Page 40]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
S ::= one two E1 three
E1 ::= four E2
E1 ::=
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 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 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 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.
(4) If the base type is subject to a HOLLOW-INSERTIONS encoding
Legg Expires 23 April 2007 [Page 41]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
instruction, then a production is added to the grammar where the
left hand side is N and the right hand side is empty.
(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.
(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.
(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.
(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.
(7) If the base type is subject to a MULTIFORM-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 followed by the non-terminal for the extension
insertion point of the base type.
(8) If the base type is extensible (explicitly or by default), then 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 in the AlternativeTypeList for the
ExtensionAdditionAlternativesGroup, where the left hand side is the
non-terminal for the ExtensionAdditionAlternative and the right hand
side is the primary non-terminal for the NamedType.
Legg Expires 23 April 2007 [Page 42]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Example
Consider the following annotated 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 production would be removed.
If the CHOICE type were subject to a HOLLOW-INSERTIONS encoding
instruction, then the fifth production would be replaced by:
S ::=
Legg Expires 23 April 2007 [Page 43]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
If the CHOICE type were subject to a SINGULAR-INSERTIONS encoding
instruction, then the fifth production 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 (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:
(1) a production is added to the grammar where the left hand side of
the production is N and the right hand side is the non-terminal
for the NamedType of the component of the SEQUENCE OF or SET OF
base type, followed by N', and
(2) a production is added to the grammar where the left hand side of
Legg Expires 23 April 2007 [Page 44]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
the production is N' and the right hand side is the non-terminal
for the NamedType of the component of the SEQUENCE OF or SET OF
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"
Inner subtyping (InnerTypeContraints) is ignored for the purposes of
deciding whether a value of size zero is permitted.
This completes the description of the transformation of ASN.1
combining type definitions into a grammar.
25.1.2. Unique Component Attribution
Definition (used by the grammar): A non-terminal N is used by the
grammar if:
(a) N is the start symbol or
(b) N appears on the right hand side of a production where the
non-terminal on the left hand side is used by the grammar.
Definition (multiple usage paths): A non-terminal N has multiple
usage paths if:
(a) N appears on the right hand side of a production where the
non-terminal on the left hand side has multiple usage paths, or
(b) 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
(c) N is the start symbol and it appears on the right hand side of a
Legg Expires 23 April 2007 [Page 45]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
(a) two or more primary non-terminals that are used by the grammar
and are associated with element components having the same
effective name, or
(b) two or more primary non-terminals that are used by the grammar
and are associated with attribute components having the same
effective name, or
(c) a primary non-terminal that has multiple usage paths and is
associated with an attribute component.
Aside: Case (a) is in response to component referencing notations
that are evaluated with respect to the XML encoding of an abstract
value. Case (a) guarantees, without having to do extensive
testing (which would necessarily have to take account of encoding
instructions for all other encoding rules), that all child
elements with a particular name in an RXER encoding will be
associated with equivalent type definitions. Such equivalence
allows a component referenced by element name to be re-encoded
using a different set of ASN.1 encoding rules without ambiguity as
to which type definition and encoding instructions apply.
Cases (b) and (c) 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 place.
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
Legg Expires 23 April 2007 [Page 46]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
},
c [ATTRIBUTE] INTEGER,
d [GROUP] SEQUENCE OF
a [GROUP] SEQUENCE {
a [ATTRIBUTE] OBJECT IDENTIFIER,
b INTEGER
},
e [NAME AS "c"] INTEGER,
f [GROUP] SEQUENCE OF
h TB,
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 which 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.
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
Legg Expires 23 April 2007 [Page 47]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
f [GROUP] SEQUENCE OF -- TA.f
h TB, -- TA.f.h
g OBJECT IDENTIFIER -- TA.g
}
TB ::= SEQUENCE {
a INTEGER, -- TB.a
b [ATTRIBUTE] BOOLEAN, -- TB.b
f OBJECT IDENTIFIER -- TB.f
}
TD ::= SEQUENCE {
g OBJECT IDENTIFIER -- TD.g
}
The associated grammar is:
S ::= TA.a TA.b TA.c TA.d TA.e TA.f 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
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"
Legg Expires 23 April 2007 [Page 48]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.f ::= TA.f.h TA.f
TA.f ::=
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 effective 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 effective name: TA.b.b
and TA.c (both generate the terminal "@c").
The non-terminals with multiple usage paths are: TA.d, TA.d.a,
TA.d.a.a, TA.d.a.b, TA.f, TA.f.h, 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
Legg Expires 23 April 2007 [Page 49]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
all element terminals T for which a sequence of terminals can be
generated from the right hand side of P where T is the first element
terminal, i.e., there can be any number of leading attribute
terminals.
Let the Follow Set of a non-terminal N, denoted Follow(N), be the set
of all element terminals T for which a sequence of non-terminals and
terminals can be generated from the grammar where T is the first
element terminal following N, i.e., there can be any number of
intervening attribute terminals. If a sequence of non-terminals and
terminals can be generated from the grammar where N is not followed
by any element terminals, then Follow(N) also contains a special end
terminal, denoted by "$".
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).
Aside: It may appear somewhat dubious to include the attribute
components in the grammar because in reality attributes appear
unordered within the start tag of an element, and not interspersed
with the child elements as the grammar would suggest. This is why
attribute terminals are ignored in composing the First and Follow
Sets. However the attribute terminals are important in composing
the Select Sets because they can 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.
Legg Expires 23 April 2007 [Page 50]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 for which a sequence of terminals
including T 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:
(a) 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
(b) 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 (a), 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 (b), 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.
Aside: In the absence of any attribute components, case (a) 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 unrecognized attribute is accepted by an RXER decoder if there is
at least one available extension insertion point in the element
content being decoded.
Legg Expires 23 April 2007 [Page 51]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
In terms of the grammar, an extension insertion point is available
for accepting unrecognized attributes if the non-terminal for the
extension insertion point is used by the grammar and does not have
multiple usage paths (see Section 25.1.2).
In particular, if a type has an extensible base type but is affected
by a NO-INSERTIONS encoding instruction, then the extension insertion
point for the base type is not available for accepting an
unrecognized attribute. The other insertion encoding instructions
permit unrecognized attributes. Note that an extensible type can be
the base type for types which are affected by different insertion
encoding instructions, so the extension insertion point for the base
type will sometimes permit unrecognized attributes, and sometimes
not, depending on the context in which it is used.
Example
Consider this type definition:
CHOICE {
one UTF8String,
two [GROUP] SEQUENCE {
three INTEGER,
...
}
}
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 "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 "two" alternative that generates the <three> element
has an extensible type.
If the SEQUENCE type were prefixed by a NO-INSERTIONS encoding
instruction, then any unrecognized attribute would be illegal for
the "two" alternative also.
If there are two or more available extension insertion points, then a
decoder is free to associate an unrecognized attribute with any one
of those extension insertion points. 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
Legg Expires 23 April 2007 [Page 52]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
(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 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 to that embodied in the
original abstract value.
27. IANA Considerations
This document has no actions for IANA.
28. References
28.1. Normative References
Legg Expires 23 April 2007 [Page 53]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
[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)",
draft-legg-xed-rxer-xx.txt, a work in progress, October
2006.
[ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)",
draft-legg-xed-asd-xx.txt, a work in progress, October
2006.
[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.V. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/,
October 2004.
Legg Expires 23 April 2007 [Page 54]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
[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.
28.2. Informative References
[ISET] 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).
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
Legg Expires 23 April 2007 [Page 55]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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" }
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"
Legg Expires 23 April 2007 [Page 56]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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" }
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,
Legg Expires 23 April 2007 [Page 57]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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"
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
Legg Expires 23 April 2007 [Page 58]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
}
}
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" }
Legg Expires 23 April 2007 [Page 59]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
A.3. Example 3
Consider this type definition:
SEQUENCE {
one 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
Legg Expires 23 April 2007 [Page 60]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
A.4. Example 4
Consider this type definition:
SEQUENCE {
one CHOICE {
two [ATTRIBUTE] BOOLEAN,
three [ATTRIBUTE] BOOLEAN
} OPTIONAL
}
The associated grammar is:
P1: S ::= one
P2: one ::= two
P3: one ::= three
P4: one ::=
P5: two ::= "@two"
P6: three ::= "@three"
This grammar leads to the following sets 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
Legg Expires 23 April 2007 [Page 61]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Consider this type definition:
SEQUENCE {
one [GROUP] SEQUENCE OF number INTEGER OPTIONAL
}
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' ::=
Legg Expires 23 April 2007 [Page 62]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
P5: one ::=
P6: number ::= "number"
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 ::=
Legg Expires 23 April 2007 [Page 63]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
P8: 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", "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
Legg Expires 23 April 2007 [Page 64]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
P5: middleAndEnd ::=
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
}
The associated grammar is:
Legg Expires 23 April 2007 [Page 65]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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) = false
Empty(P5) = Empty(P6) = true
Follow(two) = { "two" }
Select(P5) = First(P5) + Follow(two) = { "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"
This grammar leads to the following sets and predicates:
Legg Expires 23 April 2007 [Page 66]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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 ::=
This grammar leads to the following sets and predicates:
Legg Expires 23 April 2007 [Page 67]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
P8: four ::=
P9: string ::= "string"
Legg Expires 23 April 2007 [Page 68]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
[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
Legg Expires 23 April 2007 [Page 69]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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(P12) = First(P12) = { "*" }
Preselected(P10) evaluates to false because Preselected(P10) is
evaluated on the base grammar, wherein P10 is rewritten to:
P10: S ::=
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.
Legg Expires 23 April 2007 [Page 70]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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", "*", "$" }
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) = { "$" }
Legg Expires 23 April 2007 [Page 71]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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"
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) = { }
Select(P4) = First(P4) = { "*" }
Select(P5) = First(P5) + Follow(I1) = { }
The remaining sets are unchanged.
Since I1 is no longer used, Follow(I1) becomes empty and the conflict
Legg Expires 23 April 2007 [Page 72]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
between Select(P4) and Select(P5) is removed. 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.
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 ::=
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", "$" }
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) = { "*" }
Legg Expires 23 April 2007 [Page 73]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
First(P9) = { }
Preselected(P8) = Preselected(P9) = Empty(P8) = false
Empty(P9) = true
Follow(I2) = { }
Select(P8) = First(P8) = { "*" }
Select(P9) = First(P9) + Follow(I2) = { }
Since I2 is no longer used, "*" is removed from Follow(I1) and the
conflict between Select(P4) and Select(P5) is removed. 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.
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) = { "*" }
Legg Expires 23 April 2007 [Page 74]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
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) = { "$" }
Legg Expires 23 April 2007 [Page 75]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
First(P6) = { "*" }
First(P7) = { }
Preselected(P6) = Preselected(P7) = Empty(P6) = false
Empty(P7) = true
Follow(I1) = { "$" }
Select(P6) = First(P6) = { "*" }
Select(P7) = First(P7) + Follow(I1) = { "$" }
The intersection of Select(P2), Select(P8) and Select(P4) 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 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
Legg Expires 23 April 2007 [Page 76]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Empty(P3) = true
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 I1 or to associate it
with 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:
SEQUENCE {
one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
two UTF8String,
... -- Extension insertion point (I1).
},
three [GROUP] CHOICE {
four UTF8String,
... -- Extension insertion point (I2).
Legg Expires 23 April 2007 [Page 77]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
}
}
The associated grammar is:
P1: S ::= one three
P2: one ::= two
P12: one ::= "*"
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(P12) = { "*" }
Preselected(P2) = Preselected(P12) = false
Empty(P2) = Empty(P12) = false
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P12) = First(P12) = { "*" }
First(P5) = { "*" }
First(P6) = { }
Preselected(P5) = Preselected(P6) = Empty(P5) = false
Empty(P6) = true
Follow(I1) = { "$" }
Select(P5) = First(P5) = { "*" }
Select(P6) = First(P6) + Follow(I1) = { "$" }
The remaining sets are unchanged.
Since I1 is no longer used, Follow(I1) becomes empty and the conflict
between Select(P5) and Select(P6) is removed. If the first child
element is an unrecognized element, then a decoder will now assume
that it is associated with I1. Whatever follows, possibly including
another unrecognized element, will belong to the "three" component.
The productions for non-terminals that are no longer used will be
discarded in the remaining examples in this appendix.
Now consider the type definition using the UNIFORM-INSERTIONS
Legg Expires 23 April 2007 [Page 78]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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
P3: one ::= "*"
P12: one ::= "*1" I1
P13: I1 ::= "*1" I1
P14: I1 ::=
P4: two ::= "two"
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) = { "*" }
First(P12) = { "*1" }
Preselected(P2) = Preselected(P3) = Preselected(P12) = false
Empty(P2) = Empty(P3) = Empty(P12) = false
Follow(one) = { "four", "*", "$" }
Select(P2) = First(P2) = { "two" }
Select(P3) = First(P3) = { "*" }
Select(P12) = First(P12) = { "*1" }
First(P13) = { "*1" }
First(P14) = { }
Preselected(P13) = Preselected(P14) = Empty(P13) = false
Empty(P14) = true
Follow(I1) = { "four", "*", "$" }
Select(P13) = First(P13) = { "*1" }
Legg Expires 23 April 2007 [Page 79]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Select(P14) = First(P14) + Follow(I1) = { "four", "*", "$" }
The remaining sets are unchanged.
The intersection of Select(P2), Select(P3) and Select(P12) is empty,
as is the intersection of Select(P13) and Select(P14), 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, 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 the same elements as 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 ::=
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", "*", "$" }
Legg Expires 23 April 2007 [Page 80]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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).
}
The associated grammar is:
P1: S ::= one S
P2: S ::=
P3: one ::= two
P8: one ::= "*"
P9: one ::= "*1" I1
P10: I1 ::= "*1" I1
P11: I1 ::=
P5: two ::= "two"
Legg Expires 23 April 2007 [Page 81]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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(P11) = { }
Preselected(P10) = Preselected(P11) = Empty(P10) = false
Empty(P11) = true
Follow(I1) = { "two", "*", "*1", "$" }
Select(P10) = First(P10) = { "*1" }
Select(P11) = First(P11) + Follow(I1) = { "two", "*", "*1", "$" }
The intersection of Select(P1) and Select(P2) is now empty. The
intersection of Select(P3), Select(P8) and Select(P9) is also empty,
but the intersection of Select(P10) and Select(P11) 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.
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:
Legg Expires 23 April 2007 [Page 82]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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.
Appendix C. Extension and Versioning Examples
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 [GROUP] SEQUENCE {
five [ATTRIBUTE] UTF8String OPTIONAL,
six [ATTRIBUTE] INTEGER OPTIONAL
},
seven [GROUP] CHOICE {
Legg Expires 23 April 2007 [Page 83]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
eight [ATTRIBUTE] BOOLEAN,
nine [ATTRIBUTE] INTEGER
}
}
The "two" component will never generate an element; only an attribute
that is irrelevant to the HOLLOW-INSERTIONS encoding instruction.
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 "four" and "seven"
components generate only attributes.
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
}
}
The "two" component will always generate a single <two> element. The
"three" component will always generate a single <five> element, and a
"four" attribute that is irrelevant to 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,
seven INTEGER
Legg Expires 23 April 2007 [Page 84]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
},
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,
and a "six" attribute that is irrelevant to 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.
C.2. Versioning Example
It is permitted to make extensions that are not forward compatible
provided 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 "one" component in 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,
...,
Legg Expires 23 April 2007 [Page 85]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
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:
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 Expires 23 April 2007 [Page 86]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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.
Note to the RFC Editor: the remainder of this document is to be removed
before final publication.
Changes in Draft 01
The GROUP encoding instruction is no longer permitted in situations
that would cause a recursive group definition.
Legg Expires 23 April 2007 [Page 87]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
TopLevelNamedType has been replaced by an unrestricted NamedType.
This makes manipulation of top-level components easier to both
specify and implement.
RefParametersValue (a governed Value) has been replaced by specific
notation, i.e., the RefParameters production. The RefParameters
ASN.1 type is no longer used.
Parameterized encoding instructions have been disallowed.
A selection type is not permitted to select the Type from a NamedType
that is subject to an ATTRIBUTE-REF, ELEMENT-REF or REF-AS-ELEMENT
encoding instruction. Also, a selection type does not inherit
component encoding instructions.
The ATTRIBUTE encoding instruction is permitted to be applied to the
QName type and LIST types.
The descriptions of the SCHEMA-IDENTITY and TARGET-NAMESPACE encoding
instructions have been expanded.
Changes in Draft 02
The prefixed type for the ATTRIBUTE-REF encoding instruction has been
reduced to a UTF8String and restrictions have been placed on the type
of referenced attribute definitions. These changes have been made to
overcome difficulties in producing a canonical encoding for foreign
attribute definitions.
References to foreign definitions dependent on the XML Schema ENTITY
and ENTITIES types have been disallowed.
CanonicalizationParameter has been removed from the grammar for
RefParameters. Preservation of the Infoset representation of a value
of Markup is sufficient for the purposes of CRXER.
References to AnySimpleType have been removed.
The type of an alternative of a ChoiceType that is subject to a UNION
encoding instruction is not permitted to be an open type.
The CONTENT encoding instruction has been renamed to GROUP.
The conditions for unique component attribution have been
reformulated in terms of the grammar for a type definition, but the
effects are the same.
Unknown extensions are now handled explicitly in the grammars
Legg Expires 23 April 2007 [Page 88]
INTERNET-DRAFT Encoding Instructions for RXER October 23, 2006
generated from type definitions. The insertion encoding instructions
have been added to resolve non-determinism with respect to extension
insertion points. Examples using insertion encoding instructions
have been added as Appendices B and C.
Changes in Draft 03
The BIT STRING type is no longer permitted to be the component type
of a LIST type.
The SIMPLE-CONTENT and COMPONENT-REF encoding instructions have been
added.
An optional Prefix specification has been added to the
TARGET-NAMESPACE encoding instruction.
The AS keyword in the NAME encoding instruction has been made
optional.
The syntax of the VALUES encoding instruction has been changed
slightly.
The VersionIndicator parameter of the ATTRIBUTE encoding instruction
has been pulled out as a separate VERSION-INDICATOR encoding
instruction.
The AnyType ASN.1 type has been renamed to Markup.
The insertions encoding instructions have been simplified by forcing
them to be co-located with the type they affect.
With regard to the TYPE-REF encoding instruction, it is no longer
necessary to preserve the exact Infoset [ISET] representation of
abstract values of an ASN.1 type embedded in a Markup value.
The URL for the ASN.1 namespace has been replaced. A permanent URN
will be requested from IANA.
Legg Expires 23 April 2007 [Page 89]
| PAFTECH AB 2003-2026 | 2026-04-24 05:50:26 |