view Side-By-Side changes

INTERNET-DRAFT                                                   S. Legg
draft-legg-xed-rxer-ei-02.txt
draft-legg-xed-rxer-ei-03.txt                                    eB2Bcom
Intended Category: Standards Track                      October 19, 2005 23, 2006


                     Encoding Instructions for the
                    Robust XML Encoding Rules (RXER)

               Copyright (C) The Internet Society (2005). (2006).

   Status of this 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 19 23 April 2006. 2007.


Abstract

   This document defines encoding instructions that may be used in an
   Abstract Syntax Notation One (ASN.1) specification to alter how



Legg                      Expires 19 April 2006                 [Page 1]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 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)



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) document. specification.  Encoding
   instructions that allow an ASN.1 specification to reference
   definitions in other XML schema languages are also defined.














































Legg                      Expires 19 23 April 2006 2007                 [Page 2]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 23, 2006


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................3
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  4 Conventions .....................................................4
   3.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  4 Definitions .....................................................4
   4. Notation for RXER Encoding Instructions. . . . . . . . . . . .  5 Instructions .........................5
   5. Component Encoding Instructions. . . . . . . . . . . . . . . .  7 Instructions .................................7
   6. Reference Encoding Instructions. . . . . . . . . . . . . . . .  8 Instructions .................................9
   7. Effective Names of Components. . . . . . . . . . . . . . . . . 10 Components ..................................10
   8. The ATTRIBUTE Encoding Instruction . . . . . . . . . . . . . . 11 .............................12
   9. The ATTRIBUTE-REF Encoding Instruction . . . . . . . . . . . . 13 .........................12
   10. The ELEMENT-REF COMPONENT-REF Encoding Instruction . . . . . . . . . . . . . 14 ........................14
   11. The LIST ELEMENT-REF Encoding Instruction. . . . . . . . . . . . . . . . . 15 Instruction ..........................16
   12. The NAME LIST Encoding Instruction. . . . . . . . . . . . . . . . . 17 Instruction .................................17
   13. The REF-AS-ELEMENT NAME Encoding Instruction. . . . . . . . . . . . 17 Instruction .................................19
   14. The REF-AS-TYPE REF-AS-ELEMENT Encoding Instruction . . . . . . . . . . . . . 18 .......................19
   15. The SCHEMA-IDENTITY REF-AS-TYPE Encoding Instruction . . . . . . . . . . . 19 ..........................21
   16. The TARGET-NAMESPACE SCHEMA-IDENTITY Encoding Instruction. . . . . . . . . . . 20 Instruction ......................22
   17. The TYPE-AS-VERSION SIMPLE-CONTENT Encoding Instruction . . . . . . . . . . . 20 .......................22
   18. The TYPE-REF TARGET-NAMESPACE Encoding Instruction. . . . . . . . . . . . . . . 21 Instruction .....................24
   19. The UNION TYPE-AS-VERSION Encoding Instruction . . . . . . . . . . . . . . . . 22 ......................24
   20. The VALUES TYPE-REF Encoding Instruction. . . . . . . . . . . . . . . . 24 Instruction .............................25
   21. Insertion The UNION Encoding Instructions. . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . 29
       22.1. ................................33
      25.1. Unambiguous Encodings . . . . . . . . . . . . . . . . . 30
              22.1.1. ....................................36
            25.1.1. Grammar Construction . . . . . . . . . . . . . 31
              22.1.2. .............................36
            25.1.2. Unique Component Attribution . . . . . . . . . 40
              22.1.3. .....................45
            25.1.3. Deterministic Grammars . . . . . . . . . . . . 45
              22.1.4. ...........................49
            25.1.4. Attributes in Unknown Extensions . . . . . . . 47
   23. .................51
   26. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
   24. Considerations .......................................53
   27. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49 Considerations ...........................................53
   28. References ....................................................53
      28.1. Normative References .....................................53
      28.2. Informative References ...................................55
   Appendix A. GROUP Encoding Instruction Examples . . . . . . . . . 49 ...................55
   Appendix B. Insertion Encoding Instruction Examples . . . . . . . 64 ...............70
   Appendix C. Extension and Versioning Examples . . . . . . . . . . 77
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 80
   Informative References . . . . . . . . . . . . . . . . . . . . . . 81
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 81
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 82 .....................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



Legg                      Expires 19 April 2006                 [Page 3]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   ASN.1 specification is translated into an Abstract Syntax Notation X
   (ASN.X) document 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 Document Type
   Declaration 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 type, then the base type of T is the
   base type of the type that is constrained, otherwise if T is a
   prefixed type 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,



Legg                      Expires 19 April 2006                 [Page 4]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   SelectionType, TypeFromObject, ValueSetFromObjects) 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:

      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 |
          TypeAsVersionInstruction |
          TypeRefInstruction
          SimpleContentInstruction |
          UnionInstruction
          TypeAsVersionInstruction |
          ValuesInstruction



Legg                      Expires 19 23 April 2006 2007                 [Page 5]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 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:

   Definition (top-level NamedType): A NamedType is a top level top-level
   NamedType (equivalently, a top
   level 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
   top-level NamedType.

      ASIDE:

      Aside: Specification writers should note that non-trivial types
      defined within a top level top-level NamedType will not be visible to ASN.1
      tools that do not understand RXER.

   Although a top level 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 top-level NamedType.

   Each top level 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



Legg                      Expires 19 April 2006                 [Page 6]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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:

      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, and SIMPLE-CONTENT, TYPE-AS-VERSION and
   VERSION-INDICATOR encoding instructions (whose notations are
   described respectively by AttributeInstruction,
   AttributeRefInstruction, ComponentRefInstruction, GroupInstruction,
   ElementRefInstruction, NameInstruction, RefAsElementInstruction RefAsElementInstruction,
   SimpleContentInstruction, TypeAsVersionInstruction and
   TypeAsVersionInstruction).

   When a component encoding instruction is used in a type prefix the
   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 ConstrainedType (excluding PrefixedType in a TypeWithConstraint) BuiltinType in a
       Type that is one of (a) to (d), or

   (d) the Type in an TaggedType in a PrefixedType in ConstrainedType (excluding a BuiltinType TypeWithConstraint) in
       a Type that is one of (a) to (d).

      ASIDE:

      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)



Legg                      Expires 19 April 2006                 [Page 7]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 can be true on subsequent iterations.

   The effect of this condition

   Case (d) is to force not permitted when the component encoding
   instructions to be textually within instruction is the NamedType to which they
   apply.
   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 top-level NamedType SHALL NOT be subject to an ATTRIBUTE-REF,
   COMPONENT-REF, GROUP, ELEMENT-REF or ELEMENT-REF, REF-AS-ELEMENT or SIMPLE-CONTENT
   encoding instruction.

      ASIDE:

      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
   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 of the mutually exclusive encoding
   instructions. 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.  Component  The other
   component encoding instructions are not inherited by the type denoted
   by a SelectionType.

   Definition:

   Definition (attribute component): An attribute component is a
   NamedType that is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding
   instruction, or subject to a COMPONENT-REF encoding instruction that
   references a top-level NamedType that is subject to an ATTRIBUTE
   encoding instruction.

   Definition:



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 or 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 AnyType Markup ASN.1 type from
   the AdditionalBasicDefinitions module



Legg                      Expires 19 April 2006                 [Page 8]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 [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 Document Type Declaration 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:

      Aside: Case (c) has 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 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 are specified in Section 9.  The
   restrictions on the Type in the EncodingPrefixedType
       is one of (a) to (c) and the EncodingPrefix in the
       EncodingPrefixedType does not contain for a reference
   COMPONENT-REF encoding
       instruction. instruction are specified in Section 10.

   The reference encoding instructions make use of a common production
   defined as follows:




Legg                      Expires 19 April 2006                 [Page 9]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

      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:

   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 instruction, then
       the value of the local-name component of the effective name is
       the character string specified by the NCNameValue of the NAME
       encoding instruction, and

   (b) otherwise, if the prefix component of NamedType is subject to a COMPONENT-REF
       encoding instruction, then the effective name is absent,

   (b) 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 instruction, then the effective name is the
       QNameValue of the encoding instruction,

   (c)

   (d) otherwise, if the NamedType is subject to a REF-AS-ELEMENT
       encoding instruction instruction, then the values value of the prefix and local-name
       components component
       of the effective name are is the Prefix and LocalPart
       respectively [XMLNS10] of the qualified
       name specified by the NameValue of the encoding instruction, and the namespace-name
       component of the effective name is absent,

   (d)

   (e) 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.




Legg                      Expires 19 April 2006                [Page 10]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 NamedType.

   In case (a) and (d), (e), if the NamedType is a top level top-level NamedType and
   the module containing the NamedType has a TARGET-NAMESPACE encoding
   instruction
   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:

      Aside: Thus the TARGET-NAMESPACE encoding instruction applies to a
      top level
      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 (i.e., instances of NamedType) of a CHOICE,
   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 CHOICE, SEQUENCE or SET type that are not subject to an ATTRIBUTE or ATTRIBUTE-REF encoding instruction attribute
   components MUST be distinct.  These tests are applied after the
   COMPONENTS OF transformation specified in X.680, Clause 24.4 [X.680].

      ASIDE:

      Aside: Two components of the same CHOICE, SEQUENCE or SET type may
      have the same effective name if one of them is subject to an ATTRIBUTE or ATTRIBUTE-REF encoding
      instruction attribute
      component and the other is not.

   The effective name  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 top-level NamedType subject to an ATTRIBUTE
   encoding instruction MUST be distinct from the effective name of
   every other top level top-level NamedType subject to an ATTRIBUTE encoding
   instruction in the same module.

   The effective name of a top level top-level NamedType not subject to an
   ATTRIBUTE encoding instruction MUST be distinct from the effective
   name of every other top level 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" VersionIndicator ?

      VersionIndicator ::= "VERSION-INDICATOR"

   The base type of the type of a NamedType that is subject to an



Legg                      Expires 19 April 2006                [Page 11]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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], [RXER] (i.e., QName is
       allowed), or

   (c) a SEQUENCE OF type where the SequenceOfType is not subject to a
       LIST encoding instruction. instruction, or

   (d) an open type.

   Example

      PersonalDetails ::= SEQUENCE {
          firstName   [ATTRIBUTE] UTF8String,
          middleName  [ATTRIBUTE] UTF8String,
          surname     [ATTRIBUTE] UTF8String
      }

   If

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 VersionIndicator parameter component to which it is applied as an XML attribute
   instead of as a child element, where the ATTRIBUTE attribute's name is the
   qualified name of the attribute definition referenced by the encoding
   instruction.  In addition, the ATTRIBUTE-REF encoding instruction is present then
   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 the an ATTRIBUTE
   encoding instruction MUST be instruction.

   The type of a referenced XML Schema attribute definition SHALL NOT
   be, either directly or indirectly
   a constrained by derivation, the XML Schema type where QName,
   NOTATION, ENTITY, ENTITIES or anySimpleType.

      Aside: Values of these types require information from the set context
      of permitted values the attribute for interpretation.  Because an ATTRIBUTE-REF
      encoding instruction is defined restricted to be
   extensible.

   If an RXER decoder encounters a value of prefixing the type that is not one ASN.1
      UTF8String type, there is no mechanism to capture such context.

   The type of
   the root values a referenced top-level NamedType SHALL NOT be, either
   directly or extension additions (but still allowed since by subtyping, the
   set of permitted values is extensible) then this indicates that QName type from the
   decoder
   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 using a version of the ASN.1 specification PrefixedType that is not
   compatible with a TaggedType where
       the version used Type in the TaggedType is one of (a) to produce (c), or

   (c) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the encoding.  In such
   cases Type in the decoder SHOULD treat EncodingPrefixedType
       is one of (a) to (c) and the element containing EncodingPrefix in the attribute
   as untyped markup.

      ASIDE: A version indicator attribute only indicates an
      incompatibility with respect
       EncodingPrefixedType does not contain a reference encoding
       instruction.

   The identifier of a NamedType subject to RXER encodings.  Other encodings
      are an ATTRIBUTE-REF encoding
   instruction does not affected.

   Examples

      In contribute to the first example, name of attributes in the decoder is using an incompatible older
      version if RXER
   encoding.  For the value sake of consistency, 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
         } identifier SHOULD, where



Legg                      Expires 19 23 April 2006 2007                [Page 12] 13]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      In the second example, 23, 2006


   possible, be the decoder is using an incompatible older
      version if same as local part of the value name of the format referenced
   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 definition.

10.  The COMPONENT-REF Encoding Instruction

   The ASN.1 basic notation does not necessary for every extensible type to have its own version
   indicator attribute.  It would be typical for only the types a concept of a top-level element components
   NamedType and therefore does not have a mechanism to include reference a version indicator
   attribute, which would serve as the version indicator for all of the
   nested components.

9.  The ATTRIBUTE-REF Encoding Instruction
   top-level NamedType.  The ATTRIBUTE-REF COMPONENT-REF encoding instruction causes an RXER encoder to
   encode the component provides
   a way to which it specify that a NamedType within a combining type definition
   is applied as an XML attribute
   instead of as equivalent to a child element, where the attribute's name 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
   qualified name of ASN.1 basic
   notation [X.680].  If the attribute definition referenced by GlobalModuleReference is absent from an
   InternalComponentReference, then the encoding
   instruction.  In addition, identifier MUST be the ATTRIBUTE-REF encoding instruction
   causes values
   identifier of a top-level NamedType in the UTF8String type to same module.  If the
   GlobalModuleReference is present in an InternalComponentReference,
   then the identifier MUST be restricted to conform to the type identifier of a top-level NamedType
   in the attribute definition. referenced module.

   The notation for modulereference in an ATTRIBUTE-REF encoding instruction ExternalComponentReference is defined as
   follows:

      AttributeRefInstruction ::=
          "ATTRIBUTE-REF" QNameValue RefParameters

   Taken together, the QNameValue and the ContextParameter used in the
   RefParameters (if present) MUST reference an XML Schema attribute
   definition or
   same way as a top level NamedType that is subject to modulereference in an ATTRIBUTE
   encoding instruction. ExternalTypeReference.  The type of a referenced XML Schema attribute definition
   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 NOT
   be, either directly be either:

   (a) a ReferencedType that is a DefinedType that is a typereference
       (not a DummyReference) or by derivation, the XML Schema type QName,
   NOTATION, ENTITY, ENTITIES ExternalTypeReference, or anySimpleType.

      ASIDE: Values

   (b) a BuiltinType or ReferencedType comprising one of these types require information from the context productions
       in Table 1 in Section 6.3 of the attribute specification for interpretation.  Because an ATTRIBUTE-REF
      encoding instruction ASN.X [ASN.X],
       or

   (c) a BuiltinType that is restricted to prefixing a PrefixedType that is a TaggedType where
       the ASN.1
      UTF8String type there Type in the TaggedType is no mechanism one of (a) to capture such context. (d), or



Legg                      Expires 19 23 April 2006 2007                [Page 13] 14]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   The type of 23, 2006


   (d) a referenced top level NamedType SHALL NOT be, either
   directly or by subtyping, the QName type from the
   AdditionalBasicDefinitions module [RXER].

   The identifier of BuiltinType that is a NamedType subject to PrefixedType that is an ATTRIBUTE-REF encoding
   instruction does not contribute to the name of attributes in the RXER
   encoding.  For the sake of human readability, the identifier SHOULD,
       EncodingPrefixedType where possible, be the same as local part of Type in the name EncodingPrefixedType
       is one of the
   referenced attribute definition.

10.  The ELEMENT-REF Encoding Instruction

   The ELEMENT-REF encoding instruction causes an RXER encoder to encode
   the component (a) to which it is applied as an element where (d) and the
   element's name is EncodingPrefix in the qualified name of
       EncodingPrefixedType does not contain a reference encoding
       instruction.

   The Type in the element definition top-level NamedType referenced by the encoding instruction.  In addition, the ELEMENT-REF COMPONENT-REF
   encoding instruction causes values of the AnyType ASN.1 type to MUST be
   restricted to conform to either:

   (i)   if case (a) is used, a ReferencedType that is a DefinedType
         that is a typereference or ExternalTypeReference that
         references the same 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 DefinedType in the
   RefParameters (if present) MUST reference an XML Schema element
   definition, a RELAX NG element definition, case (a), or a top level NamedType
   that

   (ii)  if case (b) is not subject to an ATTRIBUTE encoding instruction.

   A referenced XML Schema element definition MUST NOT have used, a type BuiltinType or ReferencedType that
   requires is
         the presence of values for same as the XML Schema ENTITY BuiltinType or ENTITIES
   types.

      ASIDE: Entity declarations are not supported by CRXER.

   A side-effect of referencing a top level NamedType from ReferencedType in case (b), or

   (iii) a module BuiltinType that
   does not have a TARGET-NAMESPACE encoding instruction is a PrefixedType that
   applications will be required to preserve is an
         EncodingPrefixedType where the Infoset [ISET]
   representation of Type in the RXER encoding of abstract values, instead EncodingPrefixedType
         is one of (i) to (iii) and the less restrictive requirement of preserving just EncodingPrefix in the abstract
   values.  Since this defeats one of
         EncodingPrefixedType contains an RXER encoding instruction.

   The restrictions on the primary advantages use of ASN.1,
   referencing a top level NamedType from a module RXER encoding instructions are such
   that does not have a
   TARGET-NAMESPACE no other RXER encoding instruction is NOT RECOMMENDED.

      ASIDE: It is perfectly reasonable to reference permitted within a top level
   NamedType from a module that does have if the NamedType is subject to a TARGET-NAMESPACE COMPONENT-REF encoding
   instruction.

   In these cases preservation of principle, the abstract value COMPONENT-REF encoding instruction creates a
   notional NamedType where the effective name is
      still sufficient.



Legg                      Expires 19 April 2006                [Page 14]

INTERNET-DRAFT       Encoding Instructions for 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     October 19, 2005 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

      AnySchema

      Modules ::= CHOICE {
          asd  [ELEMENT-REF {
                   namespace-name "http://xmled.info/ns/ASN.1",
                   local-name     "module" }]
               AnyType,
          xsd  [ELEMENT-REF {
                   namespace-name "http://www.w3.org/2001/XMLSchema",
                   local-name     "schema" }]
               AnyType,
          rng  [ELEMENT-REF 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
                         {
                   namespace-name "http://relaxng.org/ns/structure/1.0",
                   local-name     "grammar" 1 3 6 1 4 1 21472 1 0 1 }]
               AnyType
      }
                     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 this ASN.1 the SEQUENCE OF 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:module"/>
           <element ref="xs:schema"/> xmlns:asnx="urn:ietf:params:xml:ns:asnx"
                    name="Modules">
          <sequenceOf>
           <element ref="rng:grammar"/>
          </choice> ref="asnx:module"/>
          </sequenceOf>
         </namedType>

         ASIDE:

         Aside: The <namedType> element in ASN.X corresponds to a
         TypeAssignment, not a NamedType.

   The identifier of a NamedType subject to an ELEMENT-REF a COMPONENT-REF encoding
   instruction does not contribute to the name of elements in the an RXER encoding.  For the sake of human readability,
   consistency with other encoding rules, the identifier SHOULD,
   where possible, SHOULD be the
   same as the local part of the name of the
   referenced element definition.

      ASIDE: The previous example violates this condition so as to
      demonstrate that there is no link between the identifier and the
      name of in the referenced element definition. ComponentRefInstruction.

11.  The LIST ELEMENT-REF Encoding Instruction

   The LIST ELEMENT-REF encoding instruction causes an RXER encoder to encode a
   value of a SEQUENCE OF type as a white space separated list of
   the



Legg                      Expires 19 April 2006                [Page 15]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 component values.

   The notation for a LIST encoding instruction to which it is defined applied 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, element where the
       Type in the ConstrainedType is one of (a) to (e), or

   (d) a BuiltinType that is a PrefixedType that
   element's name is a TaggedType where the Type in the TaggedType is one qualified name of (a) to (e), or

   (e) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in element definition
   referenced by the EncodingPrefixedType
       is one of (a) to (e).

   The effect of this condition is to force encoding instruction.  In addition, the LIST ELEMENT-REF
   encoding instruction causes values of the Markup ASN.1 type to be textually co-located with the SequenceOfType or
   TypeWithConstraint
   restricted to which it applies.

      ASIDE: This makes it clear conform to a reader that the encoding
      instruction applies to every use type of the type no matter how it
      might be referenced. element definition.

   The SequenceOfType in case (a) notation for an ELEMENT-REF encoding instruction is defined as
   follows:

      ElementRefInstruction ::= "ELEMENT-REF" QNameValue RefParameters

   Taken together, the QNameValue and the TypeWithConstraint ContextParameter 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
   RefParameters (if present) MUST reference an XML Schema element
   definition, a SequenceOfType RELAX NG element definition, or
   TypeWithConstraint a top-level NamedType
   that is not subject to a LIST an ATTRIBUTE encoding instruction instruction.

   A referenced XML Schema element definition 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 NOT have a named bit list, or type that



Legg                      Expires 19 23 April 2006 2007                [Page 16]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   (c) 23, 2006


   requires the NCName, AnyURI, Name or QName type from presence of values for the
       AdditionalBasicDefinitions XML Schema ENTITY or ENTITIES
   types.

      Aside: Entity declarations are not supported by CRXER.

   Example

      AnySchema ::= CHOICE {
          module [RXER].

      ASIDE: While it would be feasible to allow   [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 component type to
      also be any character string choice type that is constrained such that
      all its abstract values have definition provides 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).
      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 NamedType in identifier of a SequenceOfType or TypeWithConstraint that is NamedType subject to a LIST an ELEMENT-REF encoding
   instruction MUST NOT be subject does not contribute to the name of an
   ATTRIBUTE, ATTRIBUTE-REF, GROUP, ELEMENT-REF, REF-AS-ELEMENT or
   TYPE-AS-VERSION encoding instruction.

   Example

      UpdateTimes ::= [LIST] SEQUENCE OF updateTime GeneralizedTime

12.  The NAME Encoding Instruction

   The NAME encoding instruction causes an element in the RXER encoder to use a
   nominated character string instead
   encoding.  For the sake of a component's identifier
   wherever that consistency, the identifier would otherwise appear in SHOULD, where
   possible, be the encoding
   (e.g., same as an the local part of the name of the referenced
   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
      }

13. definition.

12.  The REF-AS-ELEMENT LIST Encoding Instruction

   The REF-AS-ELEMENT LIST 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. a



Legg                      Expires 19 23 April 2006 2007                [Page 17]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 23, 2006


   value of a SEQUENCE OF type as a white space separated list of the
   component values.

   The notation for a REF-AS-ELEMENT LIST encoding instruction is defined as follows:

      RefAsElementInstruction

      ListInstruction ::=
          "REF-AS-ELEMENT" NameValue RefParameters

   Taken together, the NameValue and the ContextParameter in the
   RefParameters (if present) MUST reference an element type declaration "LIST"

   The Type in an external DTD subset EncodingPrefixedType specifying a LIST encoding
   instruction SHALL be:

   (a) a BuiltinType that is conformant with Namespaces in XML
   [XMLNS10].

   The referenced element type declaration MUST NOT require the presence
   of attributes a SequenceOfType 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
       "SEQUENCE OF NamedType" form, or

   (b) a system identifier ConstrainedType that is a TypeWithConstraint 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 the
       "SEQUENCE Constraint OF NamedType" form or
       "SEQUENCE SizeConstraint OF NamedType" form, or

   (c) a ConstrainedType, other than a TypeWithConstraint, where the
       Type in an ASN.1 type definition:

         CHOICE {
             item  [REF-AS-ELEMENT "product"
                       CONTEXT "http://www.example.com/inventory"]
                   AnyType
         }

      Here the ConstrainedType is one of (a) to (e), or

   (d) a BuiltinType that is a PrefixedType that is a TaggedType where
       the ASN.X translation Type in the TaggedType is one of this ASN.1 type definition:

         <type>
          <choice>
           <element elementType="product"
                    context="http://www.example.com/inventory"
                    identifier="item"/>
          </choice>
         </type>

14.  The REF-AS-TYPE Encoding Instruction



Legg                      Expires 19 April 2006                [Page 18]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 (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 REF-AS-TYPE encoding instruction causes values effect of this condition is to force the AnyType
   ASN.1 type LIST encoding
   instruction to be restricted textually co-located with the SequenceOfType or
   TypeWithConstraint to conform which it applies.

      Aside: This makes it clear to the content permitted by a
   nominated element type declaration in an external DTD subset.

   The notation for a REF-AS-TYPE reader that the encoding
      instruction is defined as
   follows:

      RefAsTypeInstruction ::= "REF-AS-TYPE" NameValue RefParameters

   Taken together, the NameValue and the ContextParameter applies to every use of the
   RefParameters (if present) MUST reference an element type declaration
   in an external DTD subset that is conformant with Namespaces in XML
   [XMLNS10]. no matter how it
      might be referenced.

   The referenced element type declaration MUST NOT require SequenceOfType in case (a) and the presence
   of attributes of type ENTITY or ENTITIES.

      ASIDE: Entity declarations TypeWithConstraint in case (b)
   are not supported by CRXER.

   Example

      The product element type declaration can said to 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 "subject to" 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 LIST encoding instruction.

   A SequenceOfType or TypeWithConstraint SHALL NOT be subject to more
   than one LIST encoding instruction.

   The base type declaration is referenced as a
      type, the Name of the element component type declaration does not contribute of a SequenceOfType or
   TypeWithConstraint that is subject to RXER encodings.  For example, child elements in the RXER a LIST encoding instruction
   MUST be one of values of the above SEQUENCE OF type would resemble the following:

         <inventoryItem name="hammer" partNumber="1543" quantity="29"/>

15.  The SCHEMA-IDENTITY Encoding Instruction

   (a) the BOOLEAN, INTEGER, ENUMERATED, REAL, OBJECT IDENTIFIER,
       RELATIVE-OID, GeneralizedTime or UTCTime type, or




Legg                      Expires 19 23 April 2006 2007                [Page 19] 18]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   The SCHEMA-IDENTITY encoding instruction associates a unique
   identifier, a URI [URI], with 23, 2006


   (b) the ASN.1 NCName, AnyURI, Name or QName type from the
       AdditionalBasicDefinitions module containing [RXER].

      Aside: While it would be feasible to allow the
   encoding instruction.  This encoding instruction has no effect on an
   RXER encoder but does component type to
      also be any character string type that is constrained such that
      all its abstract values have an effect on the translation of an ASN.1
   specification into an ASN.X representation.

   The notation for a SCHEMA-IDENTITY encoding instruction length greater than zero and none
      of its abstract values contain any white space characters, testing
      whether this condition is defined as
   follows:

      SchemaIdentityInstruction ::= "SCHEMA-IDENTITY" AnyURIValue

   The character string specified by satisfied can be quite involved.  For
      the AnyURIValue sake of each
   SCHEMA-IDENTITY 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 distinct.

16. 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 TARGET-NAMESPACE NAME Encoding Instruction

   The TARGET-NAMESPACE NAME encoding instruction associates causes an XML namespace
   name, RXER encoder to use 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
   nominated character string instead of a component's identifier
   wherever that identifier would otherwise appear in the RXER encoding control section.
   (e.g., as an element or attribute name).

   The notation for a TARGET-NAMESPACE NAME encoding instruction is defined as follows:

      TargetNamespaceInstruction

      NameInstruction ::= "TARGET-NAMESPACE" AnyURIValue

   Two or more ASN.1 modules MAY have TARGET-NAMESPACE "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
   instructions where instruction causes an RXER encoder to
   encode the AnyURIValue specifies component to which it is applied as an element where the same character
   string if and only if
   element's name is the effective names name 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 external DTD subset element type
   declaration referenced by the same
   module without the TARGET-NAMESPACE encoding instruction.

17.  The TYPE-AS-VERSION Encoding Instruction

   The TYPE-AS-VERSION  In addition, the
   REF-AS-ELEMENT encoding instruction causes an RXER encoder to
   include an xsi:type attribute in the encoding values of the component Markup ASN.1
   type to
   which the encoding instruction is applied.  This attribute allows an
   XML Schema [XSD1] validator be restricted to conform 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. content and attributes



Legg                      Expires 19 23 April 2006 2007                [Page 20] 19]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      ASIDE: Translations of an ASN.1 specification into a compatible
      XML Schema are expected to be slightly different across versions
      because of progressive extensions to the ASN.1 specification.
      Each version should have a different target namespace, which will
      be evident in the value of the xsi:type attribute.  This mechanism
      also accommodates a component type 23, 2006


   permitted by that is renamed in a later
      version of the ASN.1 specification. element type declaration and its associated
   attribute-list declarations.

   The notation for a TYPE-AS-VERSION REF-AS-ELEMENT encoding instruction is defined as
   follows:

      TypeAsVersionInstruction

      RefAsElementInstruction ::= "TYPE-AS-VERSION"

   The Type
          "REF-AS-ELEMENT" NameValue Namespace ? RefParameters

      Namespace ::= "NAMESPACE" AnyURIValue

   Taken together, the NameValue and the ContextParameter in a NamedType the
   RefParameters (if present) MUST reference an element type declaration
   in an external DTD subset that is subject conformant with Namespaces in XML
   [XMLNS10].

   If the Name of the element type declaration conforms to a TYPE-AS-VERSION encoding
   instruction MUST be QName with
   a Type 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 Qualified Reference Name
   [RXER]. 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 addition 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 TYPE-AS-VERSION NamedType subject to a REF-AS-ELEMENT encoding
   instruction does not
   affect contribute to the backward compatibility name of an element in the RXER encodings.

18.
   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 TYPE-REF REF-AS-TYPE Encoding Instruction

   The TYPE-REF REF-AS-TYPE encoding instruction causes values of the AnyType Markup
   ASN.1 type to be restricted to conform to the content and attributes
   permitted by a specific XML Schema named type,
   RELAX NG named pattern or an ASN.1 defined type.

   A side-effect of referencing an ASN.1 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 that applications will
   be required to preserve defined as
   follows:

      RefAsTypeInstruction ::=
          "REF-AS-TYPE" NameValue Namespace ? RefParameters

   Taken together, the Infoset [ISET] representation of NameValue and the RXER
   encoding of abstract values of the type, instead of the less
   restrictive requirement of preserving just the abstract values.
   Since this defeats one of the primary advantages of ASN.1,
   referencing an ASN.1 defined type is NOT RECOMMENDED.

   The notation for a TYPE-REF encoding instruction is defined as
   follows:

      TypeRefInstruction ::= "TYPE-REF" QNameValue RefParameters

   Taken together, the QNameValue and the ContextParameter ContextParameter of the
   RefParameters (if present) MUST reference an element type declaration
   in an external DTD subset that is conformant with Namespaces in XML Schema named type,
   [XMLNS10].

   If the Name of the elementType declaration conforms to a
   RELAX NG named pattern, or an ASN.1 defined type.

   A QName with a
   Prefix [XMLNS10], then the optional Namespace in the
   RefAsTypeInstruction specifies the namespace name associated with
   that Prefix.

   The referenced XML Schema element type declaration MUST NOT require the presence
   of values
   for the XML Schema attributes of type ENTITY or ENTITIES types.

      ASIDE: ENTITIES.

      Aside: Entity declarations are not supported by CRXER.

   Example

      The QNameValue SHALL NOT product element type declaration can be referenced as a direct reference to the XML Schema type
      in an ASN.1 definition:

         SEQUENCE OF
             inventoryItem



Legg                      Expires 19 23 April 2006 2007                [Page 21]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   NOTATION type [XSD2] (i.e., 23, 2006


                 [REF-AS-TYPE "product"
                     CONTEXT "http://www.example.com/inventory"]
                 Markup

      Here is the namespace name
   "http://www.w3.org/2001/XMLSchema" and local name "NOTATION"),
   however a reference to 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 XML Schema type derived from the NOTATION element type declaration is permitted.

      ASIDE: This restriction is to ensure that referenced as a
      type, the lexical space [XSD2] Name of the referenced element type is actually populated with declaration does not contribute
      to RXER encodings.  For example, child elements in the names RXER
      encoding of
      notations [XSD1].

   Example

      MyDecimal ::=
          [TYPE-REF {
              namespace-name "http://www.w3.org/2001/XMLSchema",
              local-name     "decimal" }]
          AnyType

      Note that the ASN.X translation values 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>

19. above SEQUENCE OF type would resemble
      the following:

         <inventoryItem name="hammer" partNumber="1543" quantity="29"/>

16.  The UNION SCHEMA-IDENTITY Encoding Instruction

   The UNION SCHEMA-IDENTITY encoding instruction causes an RXER encoder to encode the
   alternative of associates a CHOICE type without encapsulation in unique
   identifier, a child
   element.  The chosen alternative is optionally indicated URI [URI], with a
   member attribute.  The optional PrecedenceList also allows a
   specification writer to alter the order in which ASN.1 module containing the
   encoding instruction.  This encoding instruction has no effect on an
   RXER decoder will
   consider encoder but does have an effect on the alternatives translation of the CHOICE as it determines which
   alternative has been used (if the actual alternative has not been
   specified through the member attribute). an ASN.1
   specification into an ASN.X representation.

   The notation for a UNION SCHEMA-IDENTITY encoding instruction is defined as
   follows:

      UnionInstruction ::= "UNION" AlternativesPrecedence ?

      AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList

      PrecedenceList

      SchemaIdentityInstruction ::= identifier PrecedenceList ? "SCHEMA-IDENTITY" AnyURIValue

   The Type in character string specified by the EncodingPrefixedType 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 UNION SIMPLE-CONTENT encoding instruction
   SHALL be: is defined as
   follows:




Legg                      Expires 19 23 April 2006 2007                [Page 22]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   (a) a BuiltinType that is 23, 2006


      SimpleContentInstruction ::= "SIMPLE-CONTENT"

   A NamedType subject to a ChoiceType, or

   (b) SIMPLE-CONTENT encoding instruction SHALL be
   in a ConstrainedType, other than ComponentType in a TypeWithConstraint, where the
       Type ComponentTypeList in the ConstrainedType is a RootComponentTypeList.
   At most one such NamedType of (a) to (d), or

   (c) a BuiltinType that is a PrefixedType that SEQUENCE or SET type is permitted to
   be subject to a TaggedType where
       the Type in the TaggedType SIMPLE-CONTENT encoding instruction.  If any
   component is one of (a) subject to (d), or

   (d) a BuiltinType that is 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 PrefixedType that is an
       EncodingPrefixedType where GROUP encoding
   instruction.  These tests are applied after the Type 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 EncodingPrefixedType
       is one SIMPLE-CONTENT
      encoding instruction on a component of (a) an extensible SEQUENCE or
      SET type means that all future extensions to (d).

   The ChoiceType in case (a) is said the SEQUENCE or SET
      type are restricted to be "subject to" being attribute components with the UNION limited
      set of types that are permitted for attribute components.  Using
      an ATTRIBUTE encoding instruction. instruction instead of a SIMPLE-CONTENT
      encoding instruction avoids this limitation.

   The base type of each alternative the type of a ChoiceType NamedType that is subject to a
   UNION
   SIMPLE-CONTENT encoding instruction SHALL NOT be:

   (a) a CHOICE, SEQUENCE, SET, SEQUENCE OF SET or SET OF type, or

   (b) an open type, or

   (c) a type notation that references a CHOICE type that where the ChoiceType is one of (a) not subject to (e),
       excepting a reference to UNION
       encoding instruction, or

   (c) a SEQUENCE type other than the one defining the QName type in from
       the AdditionalBasicDefinitions module [RXER] (i.e., QName is allowed
       as an alternative of the ChoiceType),
       allowed), or

   (d) a constrained SEQUENCE OF type where the type that is constrained SequenceOfType is one of
       (a) not subject to (e), or

   (e) a prefixed type where
       LIST encoding instruction, or

   (d) an open type.

   If the type that is prefixed is one of (a) a NamedType subject to
       (e).

   Each identifier in the PrecedenceList MUST be the identifier of a
   component SIMPLE-CONTENT encoding
   instruction has abstract values with an empty character data
   translation [RXER] (i.e., a NamedType) of the ChoiceType.

   A particular identifier SHALL NOT appear more than once in an empty encoding), then the same
   PrecedenceList.

   Every NamedType in a ChoiceType that is subject to a UNION encoding
   instruction MUST
   SHALL NOT be subject to an ATTRIBUTE, ATTRIBUTE-REF,
   GROUP, ELEMENT-REF, REF-AS-ELEMENT marked OPTIONAL or TYPE-AS-VERSION encoding
   instruction. DEFAULT.

   Example

      [UNION PRECEDENCE extendedName] CHOICE

      SEQUENCE {
          basicName     PrintableString,
          units   [ATTRIBUTE] UTF8String,
          amount  [SIMPLE-CONTENT] INTEGER



Legg                      Expires 19 23 April 2006 2007                [Page 23]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


          extendedName  UTF8String 23, 2006


      }

20.

18.  The VALUES TARGET-NAMESPACE Encoding Instruction

   The VALUES TARGET-NAMESPACE encoding instruction causes associates an RXER encoder to use
   nominated names instead of XML namespace
   name, a URI [URI], with the identifiers that would otherwise
   appear type, object class, value, object and
   object set references defined in the ASN.1 module containing the
   encoding of a value of a BIT STRING, ENUMERATED or
   INTEGER type. instruction.  In addition, it associates the namespace name
   with each top-level NamedType in the RXER encoding control section.

   The notation for a VALUES TARGET-NAMESPACE encoding instruction is defined
   as follows:

      ValuesInstruction

      TargetNamespaceInstruction ::=
          "VALUES" AllValuesMapped ? ValueMappingList
          "TARGET-NAMESPACE" AnyURIValue Prefix ?

      AllValuesMapped ::= AllCapitalized | AllUppercased

      AllCapitalized ::= "ALL" "CAPITALIZED"

      AllUppercased ::= "ALL" "UPPERCASED"

      ValueMappingList ::= ValueMapping "," +

      ValueMapping

      Prefix ::= identifier "AS" "PREFIX" 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,

   Two or

   (d) a ConstrainedType, other than a TypeWithConstraint, more ASN.1 modules MAY have TARGET-NAMESPACE encoding
   instructions where the
       Type in AnyURIValue specifies the ConstrainedType is one same character
   string if and only if the effective names of (a) to (f), or

   (e) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in top-level attribute
   components are distinct across all those modules, the TaggedType is one effective names
   of (a) to (f), or

   (f) a BuiltinType that is a PrefixedType that is 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
       EncodingPrefixedType where NCName to use as the Type namespace
   prefix in namespace declarations involving the EncodingPrefixedType namespace name
   specified by the AnyURIValue.  An RXER encoder is one of (a) not obligated to (f).
   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 effect 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 this condition is the component to force
   which the VALUES encoding instruction is applied.  This attribute allows an
   XML Schema [XSD1] validator to be textually co-located with select, if available, the type definition appropriate
   XML Schema translation for the version of the ASN.1 specification
   used to
   which it applies. 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 19 23 April 2006 2007                [Page 24]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 23, 2006


      incompatibilities between these translations can be accommodated
      if each version uses a different target namespace.  The BitStringType, EnumeratedType or IntegerType target
      namespace will be evident in cases (a) to (c)
   (respectively) is said to be "subject to" the VALUES encoding
   instruction.

   A BitStringType, EnumeratedType or IntegerType SHALL NOT be subject
   to more than one VALUES encoding instruction.

   Each identifier in a ValueMapping MUST be value of the xsi:type attribute
      and will cause an identifier appearing in XML Schema validator to use the NamedBitList, Enumerations or NamedNumberList (whichever is appropriate for the case).

   The identifier
      version.  This mechanism also accommodates an ASN.1 type that is
      renamed in a ValueMapping SHALL NOT be the same as later version of the
   identifier in any other ValueMapping ASN.1 specification.

   The notation for the same ValueMappingList.

   Definition: Each identifier in a BitStringType, EnumeratedType or
   IntegerType subject to a VALUES TYPE-AS-VERSION 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. defined as
   follows:

      TypeAsVersionInstruction ::= "TYPE-AS-VERSION"

   The replacement names for the identifiers Type in a BitStringType NamedType that is subject to a VALUES TYPE-AS-VERSION encoding
   instruction MUST be distinct. a Type that has a Qualified Reference Name
   [RXER].

   The replacement names for the identifiers in an EnumeratedType
   subject to addition of a VALUES TYPE-AS-VERSION encoding instruction MUST be distinct.

   The replacement names for does not
   affect the identifiers in backward compatibility of RXER encodings.

      Aside: In a translation of an IntegerType ASN.1 specification into XML Schema,
      any Type in a NamedType that is subject to a VALUES TYPE-AS-VERSION
      encoding instruction MUST is expected to be distinct.

   Example

      Traffic-Light ::= [VALUES ALL CAPITALIZED red AS "RED"]
          ENUMERATED {
              red,    -- effectively "RED"
              amber,  -- effectively "Amber"
              green   -- effectively "Green"
          }

21.  Insertion 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 Instructions

   Certain Instruction

   The TYPE-REF encoding instruction causes values of the RXER 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 instructions are categorized as
   insertion
      instruction does not have the effect of imposing a requirement to
      preserve the Infoset [ISET] representation of the RXER encoding instructions. of
      abstract values of the type.  It is still sufficient to preserve
      just the abstract values.

   The insertion notation for a TYPE-REF encoding instructions
   are instruction is defined as
   follows:

      TypeRefInstruction ::= "TYPE-REF" QNameValue RefParameters

   Taken together, the NO-INSERTIONS, HOLLOW-INSERTIONS, SINGULAR-INSERTIONS,
   UNIFORM-INSERTIONS QNameValue and MULTIFORM-INSERTIONS encoding instructions 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 19 23 April 2006 2007                [Page 25]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   (whose notations 23, 2006


      Aside: Entity declarations are described respectively not supported 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" CRXER.

   The insertion encoding instructions serve two purposes.  Firstly, QNameValue SHALL NOT be a direct reference 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 XML Schema
   NOTATION type [XSD2] (i.e., the ability for namespace name
   "http://www.w3.org/2001/XMLSchema" and local name "NOTATION"),
   however a decoder reference 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 XML Schema type derived from the most general case, an extension to a CHOICE, SET or SEQUENCE NOTATION
   type will generate zero or more attributes and zero or more elements
   due is permitted.

      Aside: This restriction is to ensure that the potential for use lexical space [XSD2]
      of the GROUP and ATTRIBUTE encoding
   instructions.

   The MULTIFORM-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward compatible extensions to a referenced type will
   always consist of one or more elements and zero or more attributes.
   No restriction is placed on 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 elements.

      ASIDE: Of necessity, the names ASN.X translation of this ASN.1 type definition
      provides a more natural way to reference the attributes will all be



Legg                      Expires 19 April 2006                [Page 26]

INTERNET-DRAFT 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 Instructions for RXER     October 19, 2005


      different in any given encoding. Instruction

   The UNIFORM-INSERTIONS UNION encoding instruction indicates that the causes an RXER
   encodings produced by forward compatible extensions encoder to encode the
   alternative of a CHOICE 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 without encapsulation in any
   given encoding a child
   element.  The chosen alternative is not required to be the same across all possible
   encodings of the extension. optionally indicated with a
   member attribute.  The SINGULAR-INSERTIONS encoding instruction indicates that optional PrecedenceList also allows a
   specification writer to alter the order in which an RXER
   encodings produced by forward compatible extensions to a type decoder will
   always consist of a single element and zero or more attributes.  The
   name
   consider the alternatives of the single element is not required to be CHOICE as it determines which
   alternative has been used (if the same across all
   possible encodings of actual alternative has not been
   specified through the extension. member attribute).

   The HOLLOW-INSERTIONS encoding instruction indicates that the RXER
   encodings produced by forward compatible extensions to notation for a type will
   always consist of zero elements and zero or more attributes.

   The NO-INSERTIONS UNION encoding instruction indicates that no forward
   compatible extensions can be made to a type.

   Examples of forward compatible extensions are provided in Appendix C. 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 Type in the EncodingPrefixedType for an insertion a UNION encoding instruction
   SHALL be:

   (a) a CHOICE type where the ChoiceType BuiltinType that is not subject to a UNION
       encoding instruction and is not from the
       AdditionalBasicDefinitions module [RXER], ChoiceType, or

   (b) a SET or SEQUENCE type that is not from the
       AdditionalBasicDefinitions module [RXER], or

   (c) ConstrainedType, other than a type notation that references a type that TypeWithConstraint, where the
       Type in the ConstrainedType is one of (a) to (g), (d), or

   (d)

   (c) a constrained type where the type BuiltinType that is constrained a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (a) to (g), (d), or

   (e)

   (d) a tagged type where the type BuiltinType that is tagged a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (a) to (g),
       or

   (f) an (d).

   The ChoiceType in case (a) is said to be "subject to" the UNION
   encoding prefixed instruction.

   The base type where of the type of each alternative of a ChoiceType that is
   subject to a UNION encoding reference (either
       explicitly instruction SHALL NOT be:

   (a) a CHOICE, SET or by default) is not RXER and SET OF type, or

   (b) a SEQUENCE type other than the one defining the QName type that from
       the AdditionalBasicDefinitions module [RXER] (i.e., QName is
       prefixed
       allowed), or

   (c) a SEQUENCE OF type where the SequenceOfType is one of (a) not subject to (g), a
       LIST encoding instruction, or

   (g)

   (d) an encoding prefixed type where 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 reference (either
   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 19 23 April 2006 2007                [Page 27]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


       explicitly or by default) is 23, 2006


      }

22.  The VALUES Encoding Instruction

   The VALUES encoding instruction causes an RXER and encoder to use
   nominated names instead of the type identifiers that is prefixed
       is one of (a) to (g).

   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, would otherwise
   appear in the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS
      and MULTIFORM-INSERTIONS encoding instructions offer no advantage
      over unrestricted extensions (for of a SET or SEQUENCE).  For
      example, an optional series value of singular insertions generates zero
      or more elements and zero a BIT STRING, ENUMERATED or more attributes, just like an
      unrestricted extension.
   INTEGER type.

   The first (i.e., outermost) Type that satisfies one of (a) to (f) is
   said to be "subject to" the insertion notation for a VALUES encoding instruction.

      ASIDE: Note that case (g) instruction is deliberately excluded. 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 Type in case (a) or case (b) MUST be extensible, either
   explicitly or by default.

   The insertion the EncodingPrefixedType for a VALUES encoding
   instruction and the type in case SHALL be:

   (a) a BuiltinType that is a BitStringType with a NamedBitList, or

   (b)
   are said to be "co-located" if case (c) has not been invoked.

   A type a BuiltinType that is said to be "affected by" an insertion encoding instruction
   (alternatively, the insertion encoding instruction "affects" the
   type) if the type is:

   (a) an encoding prefixed type where the encoding instruction EnumeratedType, or

   (c) a BuiltinType that is the
       insertion encoding instruction in question, an IntegerType with a NamedNumberList, or

   (b)

   (d) a prefixed type ConstrainedType, other than a TypeWithConstraint, where the type that is prefixed
       Type in the ConstrainedType is one of (a) to
       (d), (f), or

   (c)

   (e) a constrained type where the type BuiltinType that is constrained a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (a) to (d),

   (d) (f), or

   (f) a type notation BuiltinType that references is a type PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (a) to (d).

   If a type (f).

   The effect of this condition is affected by, or co-located with, multiple insertion
   encoding instructions then only to force the VALUES encoding
   instruction to be textually co-located with the highest
   precedence is considered.  The other instructions are ignored.  The
   precedence of the insertion encoding instructions is, from highest type definition to
   lowest: NO-INSERTIONS, HOLLOW-INSERTIONS, SINGULAR-INSERTIONS,
   UNIFORM-INSERTIONS, MULTIFORM-INSERTIONS.
   which it applies.

   The BitStringType, EnumeratedType or IntegerType in case (a), (b) or



Legg                      Expires 19 23 April 2006 2007                [Page 28]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   The insertion 23, 2006


   (c) (respectively) is said to be "subject to" the VALUES encoding instructions indicate what kinds of extensions
   can
   instruction.

   A BitStringType, EnumeratedType or IntegerType SHALL NOT be made subject
   to more than one VALUES encoding instruction.

   Each identifier in a type without breaking forward compatibility but they
   do not prohibit extensions that do break forward compatibility.  That
   is, it is not ValueMapping MUST be an error 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 type's base type BitStringType,
   EnumeratedType or IntegerType subject to contain extensions
   that do not satisfy an insertion a VALUES encoding
   instruction affecting has a replacement name.  If there is a ValueMapping for
   the
   type.  However, if any such extensions are made identifier, then a new value
   SHOULD be introduced into the extensible set of permitted values for
   a version indicator attribute (see Section 8), or attributes, whose
   scope encompasses the extensions.  An example replacement name is provided the character string
   specified by the NCNameValue in
   Appendix C.

22.  The GROUP Encoding Instruction

   The GROUP encoding instruction causes an RXER encoder to encode the
   component to which it ValueMapping, otherwise if
   AllCapitalized is applied without encapsulation as an element.
   It allows used, then the construction of non-trivial content models for element
   content.

   The notation for a GROUP encoding instruction replacement name is defined as follows:

      GroupInstruction ::= "GROUP" 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 base type of replacement names for the type of identifiers in a NamedType that is BitStringType subject
   to a GROUP VALUES encoding instruction SHALL be:

   (a) a SEQUENCE, SET or SET OF type, or

   (b) a CHOICE type where MUST be distinct.

   The replacement names for the ChoiceType is not identifiers in an EnumeratedType
   subject to a UNION VALUES encoding instruction, or

   (c) a SEQUENCE OF type where instruction MUST be distinct.

   The replacement names for the SequenceOfType is not identifiers in an IntegerType subject
   to a
       LIST VALUES encoding instruction, or

   The SEQUENCE type in case (a) SHALL NOT 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 associated type for a
   built-in type and SHALL NOT be from RXER encoding instructions are categorized as
   insertion encoding instructions.  The insertion encoding instructions
   are the AdditionalBasicDefinitions
   module [RXER].  Thus this condition excludes the CHARACTER STRING,
   EMBEDDED PDV, EXTERNAL, REAL NO-INSERTIONS, HOLLOW-INSERTIONS, SINGULAR-INSERTIONS,
   UNIFORM-INSERTIONS and QName types.

   The CHOICE type in case (b) SHALL NOT be from the
   AdditionalBasicDefinitions module.  Thus this condition excludes the
   AnyType type.

   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 GROUP MULTIFORM-INSERTIONS encoding
   instruction, the visible components for the type of the NamedType. instructions



Legg                      Expires 19 23 April 2006 2007                [Page 29]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   The visible components 23, 2006


   (whose notations are determined after the COMPONENTS OF
   transformation specified in X.680, Clause 24.4 [X.680].

      ASIDE: The set of visible attribute described respectively by
   NoInsertionsInstruction, HollowInsertionsInstruction,
   SingularInsertionsInstruction, UniformInsertionsInstruction and element components
   MultiformInsertionsInstruction).

   The notation for a
      type is the set of all the components of 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 type, and any nested
      types, ambiguity that describe attributes and child elements appearing in
      the RXER encodings of values can arise from use of the outer type.

   A GROUP encoding
   instruction MUST NOT be used where it would cause a
   NamedType over which extension insertion point to use for unknown
   extensions.  Secondly, to indicate what extensions can be a visible component of made to an
   ASN.1 specification without breaking forward compatibility for RXER
   encodings.

      Aside: Forward compatibility means the type of that same
   NamedType (which is only possible if the type is recursive).

      ASIDE: Components subject to ability for a GROUP decoder to
      successfully decode an encoding instruction are
      translated [CXSD] containing extensions introduced
      into XML Schema [XSD1] as group definitions.  A
      NamedType a version of the specification that is visible more recent than the
      one used by the decoder.

   In the most general case, an extension to its own a CHOICE, SET or SEQUENCE
   type is analogous will generate zero or more attributes and zero or more elements
   due to a
      circular group, which XML Schema disallows.

   Section 22.1 imposes additional conditions on the potential for use of the GROUP and ATTRIBUTE encoding instruction.

22.1.  Unambiguous Encodings

   Unregulated use of
   instructions by the GROUP extensions.

   The MULTIFORM-INSERTIONS encoding instruction can easily lead to
   specifications in which distinct abstract values have
   indistinguishable RXER encodings, i.e., ambiguous encodings.  If indicates that the
   original abstract value cannot be reliably decoded then RXER
   encodings produced by forward compatible extensions to a canonical
   encoding type will
   always consist of one or more elements and zero or more attributes.
   No restriction is placed on the original abstract value (using some other set names of
   encoding rules) cannot be reliably reproduced either.

   This section imposes restrictions on the use elements.

      Aside: Of necessity, the names of the GROUP 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 to ensure indicates that distinct abstract values have distinct the RXER encodings.  In addition, these restrictions ensure that an
   abstract value can be easily decoded in
   encodings produced by forward compatible extensions to 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 will
   always consist of element and attribute names,
   where one or more elements having the type definition describes same name, and zero
   or more attributes.  The name shared by the grammar for that language (in
   fact it element items in any
   given encoding 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 required to be described, however the
   procedure used MUST produce the same result.

   Section 22.1.1 describes the procedure for recasting a type
   definition containing components subject to across all possible
   encodings of the GROUP extension.

   The SINGULAR-INSERTIONS encoding instruction as a grammar.  Sections 22.1.2 and 22.1.3 specify



Legg                      Expires 19 April 2006                [Page 30]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   conditions indicates that the grammar must satisfy for the type definition RXER
   encodings produced by forward compatible extensions to
   be valid.  Appendices A and B have extensive examples.

22.1.1.  Grammar Construction

   A grammar consists of a collection type will
   always consist 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 element and terminal symbols. zero or more attributes.  The terminal symbols are the
   lexical items of the language that the grammar describes.  One
   name of the
   non-terminals single element is nominated not required to be the start symbol.  A valid sequence same across all
   possible encodings of terminals for the language can be generated from extension.

   The HOLLOW-INSERTIONS encoding instruction indicates that the grammar RXER
   encodings produced by
   beginning with the start symbol and repeatedly replacing any
   non-terminal with the right hand side forward compatible extensions to a type will
   always consist of one 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 productions where EncodingPrefixedType for an insertion encoding
   instruction SHALL be:

   (a) a BuiltinType that non-terminal is on a ChoiceType where the production's left hand side.  The final
   sequence of terminals ChoiceType is achieved when there are no remaining
   non-terminals not
       subject to replace.

      ASIDE: X.680 describes the ASN.1 basic notation using a
      context-free grammar.

   Each NamedType and each ExtensionAddition has an associated primary
   and secondary non-terminal.

      ASIDE: The secondary non-terminal for UNION encoding instruction, or

   (b) a NamedType BuiltinType that is used when the
      base type of a SequenceType or SetType, or

   (c) a ConstrainedType, other than a TypeWithConstraint, where the type
       Type in the NamedType ConstrainedType is a SEQUENCE OF type one of (a) to (e), or
      SET OF type.  The secondary non-terminal for an ExtensionAddition
      is used when

   (d) a type BuiltinType that is affected by an insertion encoding
      instruction.

   Each ExtensionAdditionAlternative has an associated primary
   non-terminal.  There a PrefixedType that is a non-terminal associated with TaggedType where
       the extension
   insertion point Type in the TaggedType is one of each extensible type.  There (a) to (e), or

   (e) a BuiltinType that is also a primary
   start non-terminal (this PrefixedType that is an
       EncodingPrefixedType where the start symbol) and a secondary start
   non-terminal.  The exact nature of Type in the non-terminals is not important
   however all the non-terminals MUST be mutually distinct.

   It EncodingPrefixedType
       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 primary non-terminals for the
   instances one of ExtensionAddition and ExtensionAdditionAlternative (a) to be
   E1, E2, E3 and so on, and for the primary non-terminals for (e).

   Case (b) is not permitted when the
   extension insertion points encoding instruction is
   the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS or MULTIFORM-INSERTIONS
   encoding instruction.

      Aside: Because extensions 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 SET or SEQUENCE type are S serial and S' respectively.
      effectively optional, the SINGULAR-INSERTIONS, UNIFORM-INSERTIONS



Legg                      Expires 19 23 April 2006 2007                [Page 31]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   Each NamedType 23, 2006


      and extension insertion point has an associated
   terminal.  There exists MULTIFORM-INSERTIONS encoding instructions offer no advantage
      over unrestricted extensions (for 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 unrecognized SET or SEQUENCE).  For
      example, an optional series of singular insertions generates zero
      or more elements in
   unknown extensions. and zero or more attributes, just like an
      unrestricted extension.

   The exact nature of the terminals Type in case (a) or case (b) is not
   important however said to be "subject to" the aforementioned terminals
   insertion encoding instruction.

   The Type in case (a) or case (b) MUST be mutually
   distinct.  The terminals are further categorized as extensible, either element
   terminals
   explicitly or attribute terminals. by default.

   A terminal for a NamedType is an
   attribute terminal if its associated NamedType is Type SHALL NOT be subject to an
   ATTRIBUTE or ATTRIBUTE-REF more than one insertion encoding instruction, otherwise
   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
   element terminal.  The general extension terminal and the terminals error for the extension a type's base type to contain extensions
   that do not satisfy an insertion points are categorized as element
   terminals.

   In the examples in this document encoding instruction affecting the terminal for
   type.  However, if any such extensions are made, then a component other
   than an attribute component will new value
   SHOULD be represented as introduced into the effective name extensible set of the component enclosed in quotes, and the terminal permitted values for an
   attribute component will be represented as the effective name of the
   component prefixed by
   a version indicator attribute, or attributes (see Section 24), whose
   scope encompasses the @ character and enclosed extensions.  An example is provided in quotes.
   Appendix C.

24.  The
   general extension terminal will be represented as "*" and the
   terminals VERSION-INDICATOR Encoding Instruction

   The VERSION-INDICATOR encoding instruction provides a mechanism for the extension insertion points will
   RXER decoders to be represented as
   "*1", "*2", "*3" and so on. alerted that an encoding contains extensions that
   break forward compatibility.

   The productions generated from notation for a VERSION-INDICATOR encoding instruction is defined
   as follows:

      VersionIndicatorInstruction ::= "VERSION-INDICATOR"

   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 that is subject to a
   type definition, which may be affected by insertion VERSION-INDICATOR encoding
   instructions.

   If the combining type definition being tested is not co-located with
   instruction MUST also be subject to an insertion ATTRIBUTE encoding instruction then the grammar is constructed
   beginning with the start non-terminals and the
   instruction.

   The type definition,
   otherwise of the grammar NamedType that is constructed beginning with the start
   non-terminals and the prefixed type containing subject to the co-located
   insertion VERSION-INDICATOR
   encoding instruction with the highest precedence.

   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 MUST be directly or indirectly a constrained
   type where the base type set of permitted values is defined to be extensible.

   If an RXER decoder encounters a
   SEQUENCE or SET type, a production value of the type that is added to not one of
   the grammar with N as root values or extension additions (but still allowed since the left hand side.  The right hand side
   set of permitted values is constructed from an
   initial empty state according to extensible), then this indicates that the following cases considered in
   order:



Legg                      Expires 19 23 April 2006 2007                [Page 32]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   (1) If the initial RootComponentTypeList 23, 2006


   decoder is present in the base type
       then the sequence using a version of primary non-terminals for the components in ASN.1 specification that RootComponentTypeList are appended is not
   compatible with the version used to produce the right hand side in encoding.  In such
   cases the order of their definition.

   (2) If decoder SHOULD treat the ExtensionAdditions is present in element containing the base type then if 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
       type decoder is affected by a NO-INSERTIONS or HOLLOW-INSERTIONS encoding
       instruction then using an incompatible older
      version if the secondary non-terminal for value of the first
       ExtensionAddition version attribute in a received RXER
      encoding is appended to the right hand side, otherwise
       the primary non-terminal for not 1, 2 or 3.

         SEQUENCE {
             version  [ATTRIBUTE] [VERSION-INDICATOR]
                          INTEGER (1, ..., 2..3),
             message  MessageType
         }

      In this second example, the first ExtensionAddition decoder is
       appended to using an incompatible older
      version if the right hand side.

   (3) If value of the ExtensionAdditions format attribute in a received RXER
      encoding is not present "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 the base type and the
       base type Appendix C.

   It is not necessary for every extensible (explicitly or by default) and the type
       is not affected by a NO-INSERTIONS or HOLLOW-INSERTIONS encoding
       instruction then to have its own version
   indicator attribute.  It would be typical for only the primary non-terminal corresponding types of
   top-level element components to include a version indicator
   attribute, which would serve as the
       extension insertion point version indicator for all of the type is appended
   nested components.

25.  The GROUP Encoding Instruction

   The GROUP encoding instruction causes an RXER encoder to encode the right
       hand side.

   (4) If the final RootComponentTypeList
   component to which it is present in applied without encapsulation as an element.
   It allows the base type
       then the primary non-terminals for the components in that
       RootComponentTypeList are appended to the right hand side in the
       order construction of their definition.

   If a component in a ComponentTypeList (in either non-trivial content models for element
   content.

   The notation for a
   RootComponentTypeList or an ExtensionAdditionGroup) GROUP encoding instruction is OPTIONAL or
   DEFAULT then a production with the primary non-terminal of the
   component defined as the left hand side and an empty right hand side is added
   to the grammar.

   If a component (regardless follows:




Legg                      Expires 23 April 2007                [Page 33]

INTERNET-DRAFT       Encoding Instructions for RXER     October 23, 2006


      GroupInstruction ::= "GROUP"

   The base type of the ASN.1 combining type containing it) of a NamedType that is subject to a GROUP
   encoding instruction then one SHALL be:

   (a) a SEQUENCE, SET 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 SET OF type, or

   (b) a component (regardless of the ASN.1 combining CHOICE type containing it) where the ChoiceType is not subject to a GROUP UNION
       encoding instruction then instruction, or

   (c) a production SEQUENCE OF type where the SequenceOfType is
   added not subject to a
       LIST encoding instruction.

   The SEQUENCE type in case (a) SHALL NOT be the grammar with the primary non-terminal of associated type for a
   built-in type, SHALL NOT be from the AdditionalBasicDefinitions
   module [RXER] and SHALL NOT contain a component
   as that is subject to a
   SIMPLE-CONTENT encoding instruction.  Thus this condition excludes
   the left hand side CHARACTER STRING, EMBEDDED PDV, EXTERNAL, REAL and QName types.

   The CHOICE type in case (b) SHALL NOT be from the terminal of the component as the right
   hand side.

   Example

      Consider
   AdditionalBasicDefinitions module.  Thus this condition excludes the following ASN.1
   Markup type.

   Definition (visible component): Ignoring all type definition:

         SEQUENCE {
             -- Start of initial RootComponentTypeList.



Legg                      Expires 19 April 2006                [Page 33]

INTERNET-DRAFT       Encoding Instructions constraints, the
   visible components for RXER     October 19, 2005


             one    [ATTRIBUTE] UTF8String,
             two    BOOLEAN OPTIONAL,
             three  INTEGER
             -- End of initial RootComponentTypeList.
         }

      Here a type that is the grammar derived from this type:

         S ::= one two three
         one ::= "@one"
         two ::= "two"
         two ::=
         three ::= "three"

   For each ExtensionAddition, directly or indirectly a production
   combining ASN.1 type (i.e., SEQUENCE, SET, CHOICE, SEQUENCE OF or
   SET OF) is added to the grammar
   where the left hand side is set of components of the primary non-terminal combining type definition
   plus, for each NamedType (of the
   ExtensionAddition and the right hand side is initially empty.  If the
   ExtensionAddition combining type definition) that is
   subject to a ComponentType then GROUP encoding instruction, the primary non-terminal visible components for
   the NamedType type of the ComponentType is appended to the right hand
   side, otherwise (an ExtensionAdditionGroup) NamedType.  The visible components are determined
   after the sequence COMPONENTS OF transformation specified in X.680, Clause
   24.4 [X.680].

      Aside: The set of primary
   non-terminals 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 ComponentTypeList RXER encodings of values of the
   ExtensionAdditionGroup are appended outer type.

   A GROUP encoding instruction MUST NOT be used where it would cause a
   NamedType to the right hand side in the
   order be a visible component of their definition.  If the ExtensionAddition type of that same
   NamedType (which is followed by
   another ExtensionAddition then the primary non-terminal for only possible if the next
   ExtensionAddition type definition is appended
   recursive).

      Aside: Components subject to the right hand side, otherwise the
   primary non-terminal for the extension insertion point a GROUP encoding instruction might be
      translated into a compatible XML Schema [XSD1] as group
      definitions.  A NamedType that is appended 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 right hand side.  If use of the empty sequence GROUP
   encoding instruction.

   In any use 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 GROUP encoding instruction there is added to the grammar where a type, the left hand side
   is
   including type, that contains the primary non-terminal for component subject to the ExtensionAddition GROUP
   encoding instruction, and a type, the right
   hand side included type, that is empty.

      ASIDE: An extension 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 always effectively optional since a sender
   extensible.

   The including and included types may be using an earlier version defined in different ASN.1
   modules, in which case the owner of the ASN.1 specification where
      none, including type, i.e., the
   person or only some, of organization having the authority to add extensions have been defined.

      ASIDE: The grammar generated for ExtensionAdditions is structured to take account of the condition that an extension can only
   including type's definition, may be
      used if all different from the earlier extensions are also used [X.680].

   For each ExtensionAddition, a production is added to the grammar
   where the left hand side is owner of the secondary non-terminal for
   included type.

   If the
   ExtensionAddition and owner of the right hand side including type is initial empty.  If not using the
   ExtensionAddition is a ComponentType then most recent
   version of the primary non-terminal
   for included type's definition, then the NamedType owner of the ComponentType is appended
   including type might add an extension to the right hand
   side, otherwise (an ExtensionAdditionGroup) including type which is
   valid with respect to the sequence older version of primary
   non-terminals for the components in included type but is
   later found to be invalid when the ComponentTypeList latest versions of the



Legg                      Expires 19 April 2006                [Page 34]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   ExtensionAdditionGroup including
   and included type definitions are appended to brought together (perhaps by a
   third party).  Although the right hand side in owner of the
   order including type must
   necessarily be aware of their definition.  If the ExtensionAddition is followed by
   another ExtensionAddition then existence of the secondary non-terminal for included type, the
   next ExtensionAddition
   reverse is appended to the right hand side.  If the
   empty sequence not necessarily true.  The owner of terminals cannot be generated from this production
   then another production is added the included type
   could add an extension to the grammar where 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 left hand
   side included type is defined in a different module from the secondary non-terminal for
       including type, and

   (2) the ExtensionAddition included type has an extensible content model, and

   (3) changes to the
   right hand side is empty.

      ASIDE: The productions for included type are not coordinated with the secondary non-terminal for an
      ExtensionAddition mirror owner
       of the productions for including type.

   Changes in the primary
      non-terminal except that included type are coordinated with the production for owner of the last
      ExtensionAddition does not have the non-terminal for the extension
      insertion point on its right hand side.  It may happen that either
      the primary non-terminal or the secondary non-terminal is not
      used, in which case the productions for that non-terminal can be
      disregarded.

   For each extension insertion point, a production is added to the
   grammar where the left hand side is the primary non-terminal for the
   extension insertion point and the right hand side is the general
   extension terminal followed by the the primary non-terminal for the
   extension insertion point.  Another production is added to
   including type if:

   (1) the
   grammar where owner of the left hand side included type is also the primary non-terminal for owner of the
   extension insertion point and including
       type, or

   (2) the right hand side is empty.

   Example

      Consider owner of the following annotated ASN.1 including 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 collaborating with the owner
       of final RootComponentTypeList.
             three  INTEGER the included type, or



Legg                      Expires 19 23 April 2006 2007                [Page 35]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


         }

      Here is 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 grammar derived from this type:

         S ::= one two E1 three

         E1 ::= four E2
         E1 ::=
         E2 ::= five E3
         E3 ::= six seven I1
         E3 ::=

         E1' ::= four E2'
         E1' ::=
         E2' ::= five E3'
         E3' ::= six seven
         E3' ::=

         I1 ::= "*" I1
         I1 ::=

         one ::= "one"
         two ::= "two"
         two ::=
         three ::= "three"
         four ::= "four"
         five ::= "five"
         five ::=
         six ::= "six"
         seven ::= "seven"
         seven ::= GROUP encoding instruction can easily lead to
   specifications in which distinct abstract values have
   indistinguishable RXER encodings, i.e., ambiguous encodings.  If the SEQUENCE type were co-located with
   original abstract value cannot be reliably decoded, then a NO-INSERTIONS or
      HOLLOW-INSERTIONS canonical
   encoding instruction then of the first production
      would become:

         S ::= one two E1' three

   Given a primary non-terminal, N, and 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 base type is a
   CHOICE type:

   (1) A production is added to definition describes the grammar for each NamedType in the
       RootAlternativeTypeList of the base type, where the left hand
       side that language (in
   fact it is N 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 right hand side is the primary non-terminal for
       the NamedType.

   (2) A production is added manner to be described, however the grammar for each
       ExtensionAdditionAlternative of the base type, where the left



Legg                      Expires 19 April 2006                [Page 36]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


       hand side is N and
   procedure used MUST produce the right hand side is same result.

   Section 25.1.1 describes the non-terminal procedure for
       the ExtensionAdditionAlternative.

   (3) If the base recasting a type is extensible (explicitly or by default) and
   definition containing components subject to the
       type is not affected by an insertion GROUP encoding
   instruction then as a
       production is added to grammar.  Sections 25.1.2 and 25.1.3 specify
   conditions that the grammar where 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 is N 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 the primary a sequence
   of non-terminal for and terminal symbols.  The terminal symbols are the
       extension insertion point
   lexical items of the base type.

   (4) If language that the type is affected by a HOLLOW-INSERTIONS encoding
       instruction then a production grammar describes.  One of the
   non-terminals is added nominated to be the start symbol.  A valid sequence
   of terminals for the language can be generated from the grammar where by
   beginning with the
       left hand side is N start symbol and repeatedly replacing any
   non-terminal with the right hand side is empty.

   (5) If the type is affected by a SINGULAR-INSERTIONS or
       UNIFORM-INSERTIONS encoding instruction then a production is
       added to of one of the grammar productions where
   that non-terminal is on the production's left hand side side.  The final
   sequence of terminals is N and the right
       hand side is the general extension terminal.

   (6) If the type is affected by a UNIFORM-INSERTIONS encoding
       instruction then a production is added 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 grammar where the
       left hand side is N ASN.1 basic notation using a
      context-free grammar.

   Each NamedType has an associated primary and the right hand side is the terminal secondary non-terminal.

      Aside: The secondary non-terminal for a NamedType is used when the extension insertion point
      base type of the base type followed by in the
       secondary NamedType is a SEQUENCE OF type or
      SET OF type.

   Each ExtensionAddition and ExtensionAdditionAlternative has an
   associated non-terminal.  There is a non-terminal for associated with the
   extension insertion point of the
       base each extensible type.

   (7) If the type  There is affected by a MULTIFORM-INSERTIONS encoding
       instruction then also a production
   primary start non-terminal (this is added to the grammar where the
       left hand side is N start symbol) and a secondary
   start non-terminal.  The exact nature of the right hand side non-terminals is not
   important however all the general
       extension terminal followed by the primary non-terminal non-terminals MUST be mutually distinct.

   It is adequate for the
       extension insertion point most of the base type.

   Note that examples in this document (though not
   in cases (4) to (7) only the insertion encoding instruction
   with most general case) for the highest precedence is considered.

   If an ExtensionAdditionAlternative is primary non-terminal for a
   NamedType then a production
   is added to be the grammar where identifier of the left hand side is 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 right hand side is 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 for
   label, e.g., the NamedType.

   If an ExtensionAdditionAlternative is primary and secondary start non-terminals are S and
   S' respectively.

   Each NamedType and extension insertion point has an
   ExtensionAdditionAlternativesGroup then associated
   terminal.  There exists a production is added to terminal called the
   grammar for each NamedType in general extension
   terminal that is not associated with any specific notation.  The
   general extension terminal and the AlternativeTypeList terminals for the
   ExtensionAdditionAlternativesGroup, where extension
   insertion points are used to represent elements in unknown
   extensions.  The exact nature of the left hand side terminals is not important
   however the
   non-terminal aforementioned terminals MUST be mutually distinct.  The
   terminals are further categorized as either element terminals or
   attribute terminals.  A terminal for the ExtensionAdditionAlternative and the right hand
   side 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 primary non-terminal terminals for the NamedType.

   For each extension insertion point, points are categorized
   as element terminals.

   In the examples in this document the terminal for a production is added to component other
   than an attribute component will be represented as the
   grammar where effective name
   of the left hand side is component enclosed in quotes, and the secondary non-terminal 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 19 23 April 2006 2007                [Page 37]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   the 23, 2006


   general extension insertion point terminal will be represented as "*" and the right hand side is the terminal
   terminals for the extension insertion point followed by 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 for (sometimes) and a type
   definition.

   The grammar is constructed beginning with the extension insertion point.  Another 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 where 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 secondary
   non-terminal base type,
       then the sequence of primary non-terminals for the extension insertion point and components in
       that RootComponentTypeList are appended to the right hand side is empty.

   Example

      Consider in
       the following annotated ASN.1 type definition:

         CHOICE {
             -- start of RootAlternativeTypeList
             one    BOOLEAN,
             two    INTEGER,
             -- end of RootAlternativeTypeList
             ...,
             -- start order of ExtensionAdditionAlternatives
             three  INTEGER,  -- their definition.

   (2) If the ExtensionAdditions is present in the base type, then the
       non-terminal for the first ExtensionAdditionAlternative (E1)
             [[ -- an ExtensionAdditionAlternativesGroup
                 four  UTF8String,
                 five  INTEGER
             ]] -- second ExtensionAdditionAlternative (E2)
             -- The extension insertion point ExtensionAddition is here (I1).
         }

      Here appended to the
       right hand side.

   (3) If the ExtensionAdditions is not present in the grammar derived from this type:

         S ::= one
         S ::= two
         S ::= E1
         S ::= E2
         S ::= I1

         E1 ::= three
         E2 ::= four
         E2 ::= five

         I1 ::= "*" I1
         I1 ::=

         I1' ::= "*1" I1'
         I1' ::=

         one ::= "one"
         two ::= "two"
         three ::= "three"
         four ::= "four" 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 19 23 April 2006 2007                [Page 38]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


         five ::= "five" 23, 2006


   is added to the grammar.

   If a component (regardless of the CHOICE ASN.1 combining type were co-located with containing it)
   is subject to a NO-INSERTIONS GROUP encoding
      instruction instruction, then one or more
   productions are added to the fifth production would be removed. 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 CHOICE ASN.1 combining type were co-located with containing it)
   is not subject to a HOLLOW-INSERTIONS GROUP encoding instruction instruction, then the fifth a production would be replaced
      by:

         S ::=

      If is
   added to the CHOICE type were co-located grammar with a SINGULAR-INSERTIONS
      encoding instruction then the fifth production would be replaced
      by:

         S ::= "*"

      If primary non-terminal of the CHOICE type were co-located with a UNIFORM-INSERTIONS
      encoding instruction then component
   as the fifth production would be replaced
      by:

         S ::= "*"
         S ::= "*1" I1'

      If left hand side and the CHOICE type were co-located with a MULTIFORM-INSERTIONS
      encoding instruction then terminal of the fifth production would be replaced
      by:

         S ::= "*" I1

   Constraints on a SEQUENCE, SET or CHOICE type are ignored.  They do
   not affect component as the grammar being generated.

      ASIDE: This avoids an awkward situation where values right
   hand side.

   Example

      Consider the following ASN.1 type definition:

         SEQUENCE {
             -- Start of a subtype
      have to be decoded differently from values initial RootComponentTypeList.
             one    [ATTRIBUTE] UTF8String,
             two    BOOLEAN OPTIONAL,
             three  INTEGER
             -- End of initial RootComponentTypeList.
         }

      Here is the parent type.  It
      also simplifies the verification procedure.

   Given a primary non-terminal, N, and a type that has grammar derived from this type:

         S ::= one two three
         one ::= "@one"
         two ::= "two"
         two ::=
         three ::= "three"

   For each ExtensionAddition (of a SEQUENCE OF or SET OF base type and that permits a value of size zero (an empty
   sequence or set):

   (1) type), a
   production is added to the grammar where the left hand side of
       the production is N 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 component of the
       SEQUENCE OF or SET OF base type, followed by N, and

   (2) a production ComponentType is added
   appended to the grammar where the left right hand side of
       the production is N and 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 empty.



Legg                      Expires 19 23 April 2006 2007                [Page 39]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   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 23, 2006


   appended to the right hand side.  If the empty sequence of size zero:

   (1) a 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 of
       the production is N 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 non-terminal
       for the NamedType ASN.1 specification where
      none, or only some, of the component 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 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' the
   non-terminal for the extension insertion point and the right hand
   side is the non-terminal
       for general extension terminal followed by the NamedType of the component of
   non-terminal for the SEQUENCE OF or SET OF
       base type, followed by N', and

   (3) a extension insertion point.  Another production
   is added to the grammar where the left hand side of
       the production is N' 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 SIZE(1..MAX) OF number {
             -- 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 ::= number S'
         S' one two E1 three

         E1 ::= number S'
         S' four E2
         E1 ::=

         number
         E2 ::= "number"

   Inner subtyping (InnerTypeContraints) is ignored for 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 purposes of
   deciding whether SEQUENCE type were subject to a value of size zero is permitted.

   This completes NO-INSERTIONS or
      HOLLOW-INSERTIONS encoding instruction, then the description of first production
      for E3 would be:

         E3 ::= six seven

   Given a primary non-terminal, N, and a type where the transformation of ASN.1
   combining base type definitions into is a grammar.

22.1.2.  Unique Component Attribution

   Definition:
   CHOICE type:

   (1) A non-terminal N production is used by added to the grammar if:

   (a) N is for each NamedType in the start symbol or

   (b) N appears on
       RootAlternativeTypeList of the base type, where the left hand
       side is N and the right hand side of a production where is the primary non-terminal on for
       the NamedType.

   (2) A production is added to the grammar for each
       ExtensionAdditionAlternative of the base type, where the left
       hand side is used by N and the right hand side is the grammar.

   Definition: A non-terminal N for
       the ExtensionAdditionAlternative.

   (3) If the base type is variously used 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 if: 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 19 23 April 2006 2007                [Page 40] 41]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   (a) 23, 2006


       instruction, then a production is added to the grammar where the
       left hand side is N appears on and the right hand side of is empty.

   (5) If the base type is subject to a SINGULAR-INSERTIONS encoding
       instruction, then a production where is added to the
       non-terminal on grammar where the
       left hand side is variously used by the
       grammar, or

   (b) N appears on and the right hand side of more than one is the general
       extension terminal.

   (6) If the base type is subject to a UNIFORM-INSERTIONS encoding
       instruction, then:

       (a) A production
       where is added to the non-terminal on grammar where 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 is the general extension
           terminal.

       (b) A production where is added to the non-terminal on grammar where the left hand side
           is used
       by N and the grammar.

   For every ASN.1 type with a base type containing components that are
   subject to a GROUP encoding instruction, right hand side is the grammar derived by terminal for the
   method described in this document MUST NOT have:

   (a) two or more primary non-terminals that are used
           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 are associated with element components having the same
       effective name, or

   (b) two or more primary non-terminals that are used 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 are associated with attribute components having the same
       effective name, or

   (c) a primary right hand side is the general
       extension terminal followed by the non-terminal that for the extension
       insertion point of the base type.

   (8) If the base type is variously used 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 associated with empty.

   If an attribute component.

      ASIDE: Case (a) ExtensionAdditionAlternative is in response to component referencing notations
      that are evaluated with respect a NamedType, then a production
   is added to the XML encoding of 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 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 ExtensionAdditionAlternative is an RXER encoding will be
      associated with equivalent type definitions.  Such equivalence
      allows a component referenced by element name to be re-encoded
      using
   ExtensionAdditionAlternativesGroup, then a different set of ASN.1 encoding rules without ambiguity as production is added to which type definition and encoding instructions apply.

      Cases (b) and (c) ensure that an attribute name the
   grammar for each NamedType in the AlternativeTypeList for the
   ExtensionAdditionAlternativesGroup, where the left hand side is always uniquely
      associated with one component that can occur at most once the
   non-terminal for the ExtensionAdditionAlternative and the right hand
   side is
      always nested in the same way.

   Example

      The following example types illustrate various uses and misuses of primary non-terminal for the GROUP encoding instruction with respect to unique component
      attribution: NamedType.



Legg                      Expires 19 23 April 2006 2007                [Page 41] 42]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


         TA ::= SEQUENCE {
             a  [GROUP] TB,
             b  [GROUP] 23, 2006


   Example

      Consider the following annotated ASN.1 type definition:

         CHOICE {
                 a  [GROUP] TB,
                 b  [NAME AS "c"] [ATTRIBUTE] INTEGER,
                 c
             -- start of RootAlternativeTypeList
             one    BOOLEAN,
             two    INTEGER,
                 d  TB,
                 e  [GROUP] TD,
                 f  [ATTRIBUTE] UTF8String
             },
             c  [ATTRIBUTE]
             -- end of RootAlternativeTypeList
             ...,
             -- start of ExtensionAdditionAlternatives
             three  INTEGER,
             d  [GROUP] SEQUENCE OF
                 a [GROUP] SEQUENCE {
                     a  [ATTRIBUTE] OBJECT IDENTIFIER,
                     b  -- first ExtensionAdditionAlternative (E1)
             [[ -- an ExtensionAdditionAlternativesGroup
                 four  UTF8String,
                 five  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
         }
             ]] -- second ExtensionAdditionAlternative (E2)
             -- The grammar for TA extension insertion point is constructed after performing the
      COMPONENTS OF transformation, the result of which here (I1).
         }

      Here is shown next.
      This example will depart from the usual convention of using just 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 identifier of a NamedType CHOICE type were subject to represent a NO-INSERTIONS encoding
      instruction, then the primary
      non-terminal for that NamedType.  A label relative to fifth production would be removed.

      If the
      outermost CHOICE type will be used instead were subject to better illustrate unique
      component attribution.  The labels used for the non-terminals are
      shown down a HOLLOW-INSERTIONS encoding
      instruction, then the right hand side.

         TA fifth production would be replaced by:

         S ::= SEQUENCE {
             a  [GROUP] TB,                             -- TA.a
             b  [GROUP] CHOICE {                        -- TA.b




Legg                      Expires 19 23 April 2006 2007                [Page 42] 43]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


                 a  [GROUP] TB,                         -- TA.b.a
                 b  [NAME AS "c"] [ATTRIBUTE] INTEGER,  -- TA.b.b
                 c  INTEGER,                            -- TA.b.c
                 d  TB,                                 -- TA.b.d
                 e  [GROUP] TD,                         -- TA.b.e
                 f  [ATTRIBUTE] UTF8String              -- TA.b.f
             },
             c  [ATTRIBUTE] INTEGER,                    -- TA.c
             d  [GROUP] SEQUENCE OF                     -- TA.d
                 a [GROUP] SEQUENCE {                   -- TA.d.a 23, 2006


      If the CHOICE type were subject to 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 SINGULAR-INSERTIONS encoding
      instruction, then the fifth production would be replaced by:

         S ::= SEQUENCE { "*"

      If the CHOICE type were subject to 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: UNIFORM-INSERTIONS encoding
      instruction, then the fifth and sixth productions would be
      replaced by:

         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"



Legg                      Expires 19 April 2006                [Page 43]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


         TA.b.c ::= "c"
         TA.b.d ::= "d"
         TA.b.e ::= TD.g
         TA.b.f ::= "@f"

         TD.g ::= "g"

         TA.c ::= "@c"

         TA.d ::= TA.d.a TA.d
         TA.d ::=

         TA.d.a ::= TA.d.a.a TA.d.a.b

         TA.d.a.a := "@a"
         TA.d.a.b ::= "b"

         TA.e ::= "c"

         TA.f ::= TA.f.h TA.f
         TA.f "*"
         S ::=

         TA.g "*1" I1

         I1 ::= "g"

      All "*1" I1

      If the non-terminals are used by CHOICE type were subject to a MULTIFORM-INSERTIONS encoding
      instruction, then the grammar.

      The fifth production would be replaced by:

         S ::= "*" I1

   Constraints on a SEQUENCE, SET or CHOICE type definition for TA is invalid because there are two
      instances where two or more primary non-terminals are associated
      with element components having ignored.  They do
   not affect the same effective name:

      (1) TA.b.c and TA.e (both generate grammar being generated.

      Aside: This avoids an awkward situation where values of a subtype
      have to be decoded differently from values of the terminal "c"), parent type.  It
      also simplifies the verification procedure.

   Given a primary non-terminal, N, and

      (2) TD.g a type that has a SEQUENCE OF or
   SET OF base type and TA.g (both generate that permits a value of size zero (an empty
   sequence or set):

   (1) a production is added to the terminal "g").

      In case (2), TD.g and TA.g are derived from grammar where the same instance left hand side of
       the production is N and the right hand side is the primary
       non-terminal for the NamedType notation but become distinct components following of the
      COMPONENTS component of the
       SEQUENCE OF transformation.

      AUTOMATIC tagging or SET OF base type, followed by N, and

   (2) a production is applied after added to the COMPONENTS OF
      transformation which means that grammar where the types left hand side of
       the components
      corresponding to TD.g and TA.g will end up with different tags production is N and
      therefore the types will not be equivalent.

      The type definition for TA is also invalid because there right hand side is one
      instance where two or more empty.

   Given a primary non-terminals are associated
      with attribute components having the same effective name: TA.b.b non-terminal, N, a secondary non-terminal, N', and TA.c (both generate the terminal "@c").




Legg                      Expires 19 April 2006                [Page 44]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      The non-terminals a
   type that are variously used 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 has a SEQUENCE OF or SET OF base 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.

22.1.3.  Deterministic Grammars

   Let the First Set does not
   permit a value of size zero:

   (1) a production P, denoted First(P), be is added to the set of
   all element terminals T for which a sequence grammar where the left hand side of terminals can be
   generated from
       the production is N and the right hand side of P where T is the first element
   terminal, i.e., there can be any number non-terminal
       for the NamedType of leading attribute
   terminals.

   Let the Follow Set component of the SEQUENCE OF or SET OF
       base type, followed by N', and

   (2) a non-terminal N, denoted Follow(N), be production is added to the set grammar where the left hand side of all element terminals T



Legg                      Expires 23 April 2007                [Page 44]

INTERNET-DRAFT       Encoding Instructions for which a sequence of non-terminals RXER     October 23, 2006


       the production is N' and
   terminals can be generated from the grammar where T right hand side is the first
   element terminal following N, i.e., there can be any number non-terminal
       for the NamedType of
   intervening attribute terminals.  If a sequence the component of non-terminals and
   terminals can be generated from the grammar where N is not SEQUENCE OF or SET OF
       base type, followed by any element terminals then Follow(N) also contains N', and

   (3) a special end
   terminal, denoted by "$".

      ASIDE: If N does not appear on production is added to the right grammar where the left hand side of any
       the production then Follow(N) will be is N' and the right hand side is empty.

   For a production P, let the predicate Empty(P) be true if and only if

   Example

      Consider the empty sequence of terminals can be generated from P.  Otherwise
   Empty(P) following ASN.1 type definition:

         SEQUENCE SIZE(1..MAX) OF number INTEGER

      Here is false.

   Definition: The base 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 rewriting 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 in which if:

   (a) N is the non-terminals for every ExtensionAddition and
   ExtensionAdditionAlternative are removed from start symbol or

   (b) N appears on the right hand side of
   all productions.

   For a production P, let where the predicate Preselected(P) be true if and
   only if every sequence of terminals that can be generated from
       non-terminal on the
   right left hand side of P using the base grammar contains at least one
   attribute terminal.  Otherwise Preselected(P) is false.

   The Select Set 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 P, denoted Select(P), is empty if
   Preselected(P) is true, otherwise it contains First(P).  Let N be where the
       non-terminal on the left hand side has multiple usage paths, or

   (b) N appears on the right hand side of P.  If Empty(P) is true then
   Select(P) also contains Follow(N).

      ASIDE: It may appear somewhat dubious to include more than one production
       where the attribute
      components in non-terminal on the grammar because in reality attributes appear
      unordered within left hand side is used by the start tag of an element,
       grammar, or

   (c) N is the start symbol and not interspersed it appears on the right hand side of a



Legg                      Expires 19 23 April 2006 2007                [Page 45]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      with 23, 2006


       production where the child elements as non-terminal on the grammar would suggest.  This left hand side is why
      attribute terminals used
       by the grammar.

   For every ASN.1 type with a base type containing components that are ignored
   subject to a GROUP encoding instruction, the grammar derived by the
   method described in composing this document MUST NOT have:

   (a) two or more primary non-terminals that are used by the First grammar
       and Follow
      Sets.  However are associated with element components having the attribute terminals same
       effective name, or

   (b) two or more primary non-terminals that are important in composing used by the Select Sets because they can preselect a production grammar
       and can
      block are associated with attribute components having the same
       effective name, or

   (c) a production from being able to generate primary non-terminal that has multiple usage paths and is
       associated with an empty sequence
      of terminals.  In real terms, this corresponds attribute component.

      Aside: Case (a) is in response to an RXER decoder
      using the attributes component referencing notations
      that are evaluated with respect to determine the presence or absence XML encoding of
      optional components and an abstract
      value.  Case (a) guarantees, without having to select between the alternatives do extensive
      testing (which would necessarily have to take account of a
      CHOICE even before considering the encoding
      instructions for all other encoding rules), that all child elements.

      An attribute appearing in an extension isn't used to preselect
      elements with a
      production since, particular name in general, a decoder using an earlier version
      of the specification would not RXER encoding will be able to associate the attribute
      associated with any particular extension insertion point.

   Let the Reach Set of equivalent type definitions.  Such equivalence
      allows a non-terminal N, denoted Reach(N), component referenced by element name to be the re-encoded
      using a different set of all element terminals T for ASN.1 encoding rules without ambiguity as
      to which a sequence of terminals
   including T can be generated from N.

      ASIDE: It can be readily shown type definition and encoding instructions apply.

      Cases (b) and (c) ensure that all the optional an attribute
      components and all but name is always uniquely
      associated with one of the mandatory attribute components
      of a SEQUENCE or SET type component that can be ignored in constructing the
      grammar because their omission does not alter the First, Follow,
      Select or Reach Sets, or the Preselected or 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 occur at most once and Q, with is
      always nested in the same
       non-terminal on the left hand side, where the intersection of
       Select(P) and Select(Q) is not empty, place.

   Example

      The following example types illustrate various uses and

   (b) there does not exist a primary or secondary non-terminal E for an
       ExtensionAddition or ExtensionAdditionAlternative where the
       intersection misuses 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 GROUP encoding instruction with respect 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 unique 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
      attribution:

         TA ::= SEQUENCE {
             a base type containing components that are  [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 19 23 April 2006 2007                [Page 46]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   subject to 23, 2006


             },
             c  [ATTRIBUTE] INTEGER,
             d  [GROUP] SEQUENCE OF
                 a GROUP encoding instruction, the [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 derived by the
   method described in this document MUST be deterministic.

22.1.4.  Attributes in Unknown Extensions

   An unrecognized attribute for TA is accepted by an RXER decoder if there constructed after performing the
      COMPONENTS OF transformation, the result of which is
   at least one available extension insertion point in shown next.
      This example will depart from the element
   content being decoded.

   In terms usual convention of using just
      the grammar, an extension insertion point is available
   for accepting unrecognized attributes if identifier of a NamedType to represent the primary or secondary
      non-terminal for that NamedType.  A label relative to the extension insertion point is
      outermost type will be used in recognizing
   the notional sequence of terminals corresponding instead to the element
   content.

   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. better illustrate unique
      component attribution.  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 labels used for the base
   type will sometimes permit unrecognized attributes, and sometimes
   not, depending on non-terminals are
      shown down the context in which it is used.

   Example

      Consider this type definition: right hand side.

         TA ::= SEQUENCE {
             a  [GROUP] TB,                             -- TA.a
             b  [GROUP] CHOICE {
             one  UTF8String,
             two                        -- 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 {
                  three                   -- 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
         }

      When decoding a value of this type, if the element content
      contains

         TB ::= SEQUENCE {
             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  INTEGER,                                -- TB.a
             b  [ATTRIBUTE] BOOLEAN,                    -- TB.b
             f  OBJECT IDENTIFIER                       -- TB.f
         }

         TD ::= SEQUENCE type were prefixed by a NO-INSERTIONS encoding
      instruction then any unrecognized attribute would be illegal for
      the "two" alternative also. {
             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 19 23 April 2006 2007                [Page 47] 48]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   If 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 available extension insertion points then a
   decoder is free to associate an unrecognized attribute primary non-terminals are associated
      with any one
   of those extension insertion points.  The justification for doing so
   comes from element components having the following two observations: same effective name:

      (1) If the encoding of an abstract value contains an extension where TA.b.c and TA.e (both generate the type of terminal "c"), and

      (2) TD.g and TA.g (both generate the extension is unknown to terminal "g").

      In case (2), TD.g and TA.g are derived from the receiver then it same instance of
      NamedType notation but become distinct components following the
      COMPONENTS OF transformation.

      AUTOMATIC tagging is
       generally impossible to re-encode applied after the value using a different set
       of encoding rules, including COMPONENTS OF
      transformation which means that the canonical variant types of the
       received encoding.  This is true no matter which encoding rules
       are being used.  It is desirable for a decoder to be able components
      corresponding to
       accept TD.g and store the raw encoding of an extension without raising
       an error, TA.g will end up with different tags and to re-insert the raw encoding of the extension when
       re-encoding the abstract value using
      therefore the same non-canonical
       encoding rules.  However, types will not be equivalent.

      The type definition for TA is also invalid because there is little one
      instance where two or more that an
       application can do primary non-terminals are associated
      with an unknown extension.

       An application using RXER can successfully accept, store attribute components having the same effective name: TA.b.b
      and
       re-encode 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 unrecognized attribute regardless
      component.

25.1.3.  Deterministic Grammars

   Let the First Set 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 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 value of any one sequence of an
       infinite number terminals can be
   generated from the right hand side of valid type definitions.  For example, an
       attribute or P where T is the first element component could
   terminal, i.e., there can be nested to any arbitrary
       depth within CHOICEs whose components are subject to GROUP
       encoding instructions.

          ASIDE: A similar series number of nested CHOICEs could describe an
          unknown extension in a BER encoding [X.690].

23.  Security Considerations

   ASN.1 compiler implementors should take special care to be thorough
   in checking that leading attribute
   terminals.

   Let the GROUP encoding instruction has been correctly
   used, otherwise ASN.1 specifications with ambiguous RXER encodings
   could Follow Set of a non-terminal N, denoted Follow(N), be deployed.

   Ambiguous encodings mean that the abstract value recovered by set
   of all element terminals T for which a
   decoder may differ sequence of non-terminals and
   terminals can be generated from the original abstract value that was encoded.
   If that grammar where T is the case then first
   element terminal following N, i.e., there can be any number of
   intervening attribute terminals.  If a digital signature sequence of non-terminals and
   terminals can be generated with respect
   to from the original abstract value (using a canonical encoding other than
   CRXER) will grammar where N is not be successfully verified followed
   by any element terminals, then Follow(N) also contains a receiver using special end
   terminal, denoted by "$".

      Aside: If N does not appear on 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 right hand side of any
      production, then Follow(N) will be empty.

   For a receiver using production P, let the decoded abstract value will predicate Empty(P) be applying different security policy to that embodied in true if and only if
   the



Legg                      Expires 19 April 2006                [Page 48]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   original abstract value.

24.  IANA Considerations

   This document has no actions for IANA.

Appendix A.  GROUP Encoding Instruction Examples

   This appendix is non-normative.

   This appendix contains examples empty sequence of both correct and incorrect use terminals can be generated from P.  Otherwise
   Empty(P) is false.

   Definition (base grammar): The base grammar is a rewriting of the GROUP encoding instruction, determined with respect to
   grammar in which the
   grammars derived non-terminals for every ExtensionAddition and
   ExtensionAdditionAlternative are removed from the example type definitions.  The productions right hand side of
   all productions.

   For a production P, let the grammars are labeled for convenience.  Sets predicate Preselected(P) be true if and predicates for
   non-terminals with
   only one production will if every sequence of terminals that can be omitted generated from the
   examples since they never indicate non-determinism.

   The requirements
   right hand side of Section 22.1.2 (unique component attribution) are
   satisfied by all the examples in this appendix and P using only 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 base grammar is:

      P1:  S ::= one three
      P2:  one ::= two
      P3: contains at least
   one ::=
      P4:  two ::= "two"
      P5:  two ::=
      P6:  three ::= "three" attribute terminal.  Otherwise Preselected(P) is false.

   The Select Sets have to Set of a production P, denoted Select(P), is empty if
   Preselected(P) is true, otherwise it contains First(P).  Let N be evaluated 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 test include the validity 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 type
   definition.  The grammar leads 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 following sets presence or absence of
      optional components and predicates:

      First(P2) = { "two" }
      First(P3) = { }
      Preselected(P2) = Preselected(P3) = false
      Empty(P2) = Empty(P3) = true to select between the alternatives of a
      CHOICE, even before considering the child elements.



Legg                      Expires 19 23 April 2006 2007                [Page 49] 50]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      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 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 Select(P2) and Select(P3) is not empty, hence the
   grammar is specification would not deterministic 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 definition is can be ignored in constructing the
      grammar because their omission does not valid.
   If alter the RXER encoding First, Follow,
      Select or Reach Sets, or the evaluation of a value 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 type 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 have exist a child
   element <two> then it non-terminal E for an ExtensionAddition or
       ExtensionAdditionAlternative where the intersection of Reach(E)
       and Follow(E) is not possible to determine whether empty.

      Aside: In case (a), if the "one"
   component intersection is present not empty, then a
      decoder would have two or absent in more possible ways to attempt to decode
      the input into an abstract value.

   Now consider this type definition with attributes in  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 "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: 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 ::=
      P4:  two ::= "two"
      P5:  two ::=
      P6:  four ::= "@four"
      P7:  five ::= "@five"
      P8:  five ::=
      P9:  three ::= "three"

   This grammar leads to available extension insertion point in the following sets and predicates:

      First(P2) = { "two" }
      First(P3) = { }
      Preselected(P3) = Empty(P2) = false
      Preselected(P2) = Empty(P3) = true element
   content being decoded.




Legg                      Expires 19 23 April 2006 2007                [Page 50] 51]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      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 23, 2006


   In terms of Select(P2) and Select(P3) is empty, as the grammar, an extension insertion point is available
   for accepting unrecognized attributes if the
   intersection of Select(P4) and Select(P5), and non-terminal for the intersection of
   Select(P7) and Select(P8), hence
   extension insertion point is used by the grammar is deterministic and the does not have
   multiple usage paths (see Section 25.1.2).

   In particular, if a type definition has an extensible base type but is valid.  In affected
   by a correct RXER NO-INSERTIONS encoding instruction, then the "one"
   component will 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 present if
   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 only if sometimes
   not, depending on the "four" attribute context in which it is
   present.

A.2. used.

   Example 2

      Consider this type definition:

         CHOICE {
             one  UTF8String,
             two  [GROUP] SEQUENCE {
              two    [ATTRIBUTE] BOOLEAN OPTIONAL
          },
                  three  INTEGER,
          four   [GROUP] SEQUENCE {
              five   BOOLEAN OPTIONAL
                  ...
             }
         }

   The associated grammar is:

      P1:  S ::= one
      P2:  S ::= three
      P3:  S ::= four
      P4:  one ::= two
      P5:  two ::= "@two"



Legg                      Expires 19 April 2006                [Page 51]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      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

      When decoding a value of Select(P1) and Select(P3) is not empty, hence this type, if the
   grammar is not deterministic and element content
      contains a <one> child element, then any unrecognized attribute
      would be illegal as the type definition is "one" alternative does not valid. admit an
      extension insertion point.  If the RXER encoding of element content contains a value of the type is empty
      <three> element, then it is not
   possible to determine whether an unrecognized attribute would be accepted
      because the "one" "two" alternative or that generates the "four"
   alternative <three> element
      has been chosen.

   Now consider this slightly different type definition:

      CHOICE {
          one    [GROUP] an extensible type.

      If the SEQUENCE {
              two    [ATTRIBUTE] BOOLEAN
          },
          three  INTEGER,



Legg                      Expires 19 April 2006                [Page 52]

INTERNET-DRAFT       Encoding Instructions type were prefixed by a NO-INSERTIONS encoding
      instruction, then any unrecognized attribute would be illegal for RXER     October 19, 2005


          four   [GROUP] SEQUENCE {
              five   BOOLEAN OPTIONAL
          }
      }

   The associated grammar is:

      P1:  S ::= one
      P2:  S ::= three
      P3:  S ::= four
      P4:  one ::= two
      P5:
      the "two" alternative also.

   If there are two ::= "@two"
      P6:  three ::= "three"
      P7:  four ::= Five
      P8:  five ::= "five"
      P9:  five ::=

   This grammar leads 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 sets and predicates:

      First(P1) = { }
      First(P2) = { "three" }
      First(P3) = { "five" }
      Preselected(P2) = Preselected(P3) = false
      Empty(P1) = Empty(P2) = false
      Preselected(P1) = Empty(P3) = true
      Follow(S) = { "$" }
      Select(P1) = { }
      Select(P2) = First(P2) = { "three" }
      Select(P3) = First(P3) + Follow(S) = { "five", "$" }

      First(P8) = { "five" }
      First(P9) = { }
      Preselected(P8) = Preselected(P9) = Empty(P8) = false
      Empty(P9) = true
      Follow(five) = { "$" }
      Select(P8) = First(P8) = { "five" }
      Select(P9) = First(P9) + Follow(five) = { "$" }

   The intersection of Select(P1) and Select(P2) is empty, two observations:

   (1) If the
   intersection encoding of Select(P1) and Select(P3) is empty, an abstract value contains an extension where
       the intersection type of Select(P2) and Select(P3) is empty, and the intersection of
   Select(P8) and Select(P9) extension is empty, hence unknown to the grammar receiver, then it is
   deterministic and
       generally impossible to re-encode the type definition is valid.  The "one" and "four"
   alternatives can be distinguished because the "one" alternative has value using a
   mandatory attribute.

A.3.  Example 3 different set
       of encoding rules, including the canonical variant of the



Legg                      Expires 19 23 April 2006 2007                [Page 53] 52]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   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" 23, 2006


       received encoding.  This grammar leads to the following sets and predicates:

      First(P2) = { }
      First(P3) = { "number" }
      First(P4) = { }
      Preselected(P3) = Preselected(P4) = Empty(P2) = false
      Preselected(P2) = Empty(P3) = Empty(P4) = true
      Follow(one) = { "$" }
      Select(P2) = { }
      Select(P3) = First(P3) + Follow(one) = { "number", "$" }
      Select(P4) = First(P4) + Follow(one) = { "$" }

      First(P6) = { "number" }
      First(P7) = { }
      Preselected(P6) = Preselected(P7) = Empty(P6) = false
      Empty(P7) = true
      Follow(three) = { "$" }
      Select(P6) = First(P6) = { "number" }
      Select(P7) = First(P7) + Follow(three) = { "$" }

   The intersection of Select(P3) and Select(P4) is not empty, hence the
   grammar true no matter which encoding rules
       are being used.  It is not deterministic desirable for a decoder to be able to
       accept and store the type definition is not valid.
   If the RXER raw encoding of a value an extension without raising
       an error, and to re-insert the raw encoding of the type is empty then it is not
   possible to determine whether extension when
       re-encoding the "one" component is absent or abstract value using the
   empty "three" alternative has been chosen.

A.4.  Example 4




Legg                      Expires 19 April 2006                [Page 54]

INTERNET-DRAFT       Encoding Instructions for same non-canonical
       encoding rules.  However, there is little more that an
       application can do with an unknown extension.

       An application using RXER     October 19, 2005


   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 can successfully accept, store 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
       re-encode an unrecognized attribute regardless of Select(P2) and Select(P3) which extension
       insertion point it might be ascribed to.

   (2) Even if there is empty, a single extension insertion point, an unknown
       extension could still be the
   intersection encoding of Select(P2) and Select(P4) is empty, and the
   intersection a value 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 { any one  [GROUP] SEQUENCE OF of an
       infinite number INTEGER OPTIONAL
      }

   The associated grammar is:

      P1:  S ::= one
      P2:  one ::= number one
      P3:  one ::=



Legg                      Expires 19 April 2006                [Page 55]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      P4:  one ::=
      P5:  number ::= "number"

   P3 is generated during the processing of the SEQUENCE OF type.  P4 is
   generated because the "one" valid type definitions.  For example, an
       attribute or element component is optional.

   This grammar leads could be nested 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 any arbitrary
       depth within CHOICEs whose components are subject to GROUP
       encoding instructions.

          Aside: A similar series of Select(P3) and Select(P4) is not empty, hence the
   grammar is not deterministic and the type definition is not valid.
   If 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 RXER GROUP encoding of 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 of that was encoded.
   If that is the type does not have any
   <number> child elements case, then it is not possible a digital signature generated with respect
   to determine whether the "one" component is present or absent in original abstract value (using a canonical encoding other than
   CRXER) will not be successfully verified by a receiver using the
   decoded abstract value.

   Consider this similar type definition with  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 SIZE constraint:

      SEQUENCE {
          one  [GROUP] SEQUENCE SIZE(1..MAX) OF number INTEGER OPTIONAL
      }

   The associated grammar is:

      P1:  S ::= one
      P2:  one ::= number one'
      P3:  one' ::= number one'
      P4:  one' ::=
      P5:  one ::=
      P6:  number ::= "number"

   This grammar leads receiver using the decoded abstract value will
   be applying different security policy to that embodied in 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" }
   original abstract value.

27.  IANA Considerations

   This document has no actions for IANA.

28.  References

28.1.  Normative References



Legg                      Expires 19 23 April 2006 2007                [Page 56] 53]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


      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) 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 Select(P5) is empty, as is the
   intersection of 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 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)



Legg                      Expires 19 April 2006                [Page 57]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
                 = { "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



Legg                      Expires 19 April 2006                [Page 58]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 = 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) = { }



Legg                      Expires 19 April 2006                [Page 59]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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) = { }



Legg                      Expires 19 April 2006                [Page 60]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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) = { }



Legg                      Expires 19 April 2006                [Page 61]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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) = { }



Legg                      Expires 19 April 2006                [Page 62]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

      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 ::=



Legg                      Expires 19 April 2006                [Page 63]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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).
          },



Legg                      Expires 19 April 2006                [Page 64]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
          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 element, then it will not know whether to associate it
   with extension insertion point I1 or I2.




Legg                      Expires 19 April 2006                [Page 65]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

   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 {



Legg                      Expires 19 April 2006                [Page 66]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
          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



Legg                      Expires 19 April 2006                [Page 67]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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.



Legg                      Expires 19 April 2006                [Page 68]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   If the <two> element is not present 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,



Legg                      Expires 19 April 2006                [Page 69]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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



Legg                      Expires 19 April 2006                [Page 70]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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 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 ::= "*"




Legg                      Expires 19 April 2006                [Page 71]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

      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 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,



Legg                      Expires 19 April 2006                [Page 72]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
              ... -- Extension insertion point (I2).
          }
      }

   The associated grammar is:

      P1:  S ::= one three
      P2:  one ::= two
      P3:  one ::= "*"
      P12: one ::= "*1" I1' I1
      P13: I1' I1 ::= "*1" I1' I1
      P14: I1' 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')
      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') 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 element, then a decoder will
   now assume that it and every subsequent unrecognized element with the



Legg                      Expires 19 April 2006                [Page 73]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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", "$" }



Legg                      Expires 19 April 2006                [Page 74]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

      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 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' I1
      P10: I1' I1 ::= "*1" I1' I1
      P11: I1' 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) = { "$" }



Legg                      Expires 19 April 2006                [Page 75]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

      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')
      Follow(I1) = { "two", "*", "*1", "$" }
      Select(P10) = First(P10) = { "*1" }
      Select(P11) = First(P11) + Follow(I1') 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", "*" }



Legg                      Expires 19 April 2006                [Page 76]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
      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"



Legg                      Expires 19 April 2006                [Page 77]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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,



Legg                      Expires 19 April 2006                [Page 78]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005 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]  [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]  [ATTRIBUTE] [VERSION-INDICATOR]
                      UTF8String ("1.0", ..., "1.1" ) "1.1") DEFAULT "1.0",
         one      [GROUP] [SINGULAR-INSERTIONS] CHOICE {
             two    BOOLEAN,
             ...,
             three  [ATTRIBUTE] INTEGER -- Added in Version 1.1
         },
         ...
      }

   If a version 1.1 conformant application hasn't used the version 1.1
   extension in a value of MyMessageType then it is allowed to set the
   value of the version attribute to "1.0".

   A pair of elements is added to the CHOICE for version 1.2.  Again the



Legg                      Expires 19 23 April 2006 2007                [Page 79] 85]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005


   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,
             ..., 23, 2006


             three  [ATTRIBUTE] INTEGER, INTEGER -- Added in Version 1.1
             four   [GROUP] SEQUENCE {
                 five  UTF8String,
                 six   GeneralizedTime
             } -- Added in version 1.2
         },
         ...
      }

   If a version 1.2 1.1 conformant application hasn't used the version 1.2 1.1
   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 MyMessageType, then it is allowed to set the
   value of the version attribute to "1.0".

Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [URI]      Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RXER]     Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER)
              for Abstract Syntax Notation One (ASN.1)",
              draft-legg-xed-rxer-xx.txt, a work in progress, October
              2005.

   [ASN.X]    Legg, S., "Abstract Syntax Notation X (ASN.X)",
              draft-legg-xed-asd-xx.txt, a work in progress, July 2005.

   [X.680]    ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
              Information technology - Abstract Syntax Notation One
              (ASN.1): Specification

   A pair of basic notation.

   [X.680-1]  Draft Amendment 1 (to ITU-T Rec. X.680 | ISO/IEC 8824-1)
              Support elements is added to the CHOICE for EXTENDED-XER.



Legg                      Expires 19 April 2006                [Page 80]

INTERNET-DRAFT       Encoding Instructions version 1.2.  Again the
   change does not satisfy the SINGULAR-INSERTIONS encoding instruction.
   The type definition for RXER     October 19, 2005


   [X.683]    ITU-T Recommendation X.683 (07/02) version 1.2 is:

      MyMessageType ::= SEQUENCE {
         version  [ATTRIBUTE] [VERSION-INDICATOR]
                      UTF8String ("1.0", ..., "1.1" | 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 (Third
              Edition)", W3C Recommendation,
              http://www.w3.org/TR/2004/REC-xml-20040204, February 2004.

   [XMLNS10]  Bray, T., Hollander, D. and A. Layman, "Namespaces "1.2")
                          DEFAULT "1.0",
         one      [GROUP] [SINGULAR-INSERTIONS] CHOICE {
             two    BOOLEAN,
             ...,
             three  [ATTRIBUTE] INTEGER, -- Added 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 (Second
              Edition)", W3C Recommendation,
              http://www.w3.org/TR/2004/REC-xml-infoset-20040204,
              February 2004.

   [CXSD]     Legg, S. and D. Prager, "Translation of ASN.1
              Specifications into XML Schema",
              draft-legg-xed-xsd-xx.txt, Version 1.1
             four   [GROUP] SEQUENCE {
                 five  UTF8String,
                 six   GeneralizedTime
             } -- Added in version 1.2
         },
         ...
      }

   If a work version 1.2 conformant application hasn't used the version 1.2
   extension in progress, a value of MyMessageType, then it is allowed to be
              published.

   [X.690]    ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
              Information technology - ASN.1 encoding rules:
              Specification 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 Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER). the version
   attribute to "1.0".

Author's Address




Legg                      Expires 19 April 2006                [Page 81]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

   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 Internet Society (2005). 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 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



Legg                      Expires 19 April 2006                [Page 82]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005
   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 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 AnyType 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.



Legg                      Expires 19 April 2006                [Page 83]

INTERNET-DRAFT       Encoding Instructions for RXER     October 19, 2005

   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 19 23 April 2006 2007                [Page 84] 89]

----