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