Appendix B.  Insertion Encoding Instruction Examples

   This appendix is non-normative.

   This appendix contains examples showing the use of insertion encoding
   instructions to remove extension ambiguity arising from use of the
   GROUP encoding instruction.

B.1.  Example 1

   Consider the following type definition:

      SEQUENCE {
          one    [GROUP] SEQUENCE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  INTEGER OPTIONAL,
          ... -- Extension insertion point (I2).
      }

   The associated grammar is:

      P1:  S ::= one three I2
      P2:  one ::= two I1
      P3:  two ::= "two"
      P4:  I1 ::= "*" I1
      P5:  I1 ::=
      P6:  three ::= "three"
      P7:  three ::=
      P8:  I2 ::= "*" I2
      P9:  I2 ::=

   This grammar leads to the following sets and predicates:

      First(P4) = { "*" }
      First(P5) = { }
      Preselected(P4) = Preselected(P5) = Empty(P4) = false
      Empty(P5) = true
      Follow(I1) = { "three", "*", "$" }
      Select(P4) = First(P4) = { "*" }
      Select(P5) = First(P5) + Follow(I1) = { "three", "*", "$" }

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

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

   The intersection of Select(P4) and Select(P5) is not empty; hence,
   the grammar is not deterministic, and the type definition is not
   valid.  If an RXER decoder encounters an unrecognized element
   immediately after a <two> element, then it will not know whether to
   associate it with extension insertion point I1 or I2.

   The non-determinism can be resolved with either a NO-INSERTIONS or
   HOLLOW-INSERTIONS encoding instruction.  Consider this revised type
   definition:

      SEQUENCE {
          one    [GROUP] [HOLLOW-INSERTIONS] SEQUENCE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  INTEGER OPTIONAL,
          ... -- Extension insertion point (I2).
      }

   The associated grammar is:

      P1:  S ::= one three I2
      P10: one ::= two
      P3:  two ::= "two"
      P6:  three ::= "three"
      P7:  three ::=
      P8:  I2 ::= "*" I2
      P9:  I2 ::=

   With the addition of the HOLLOW-INSERTIONS encoding instruction, the
   P4 and P5 productions are no longer generated, and the conflict
   between Select(P4) and Select(P5) no longer exists.  The Select Sets

   for P6, P7, P8, and P9 are unchanged.  A decoder will now assume that
   an unrecognized element is to be associated with extension insertion
   point I2.  It is still free to associate an unrecognized attribute
   with either extension insertion point.  If a NO-INSERTIONS encoding
   instruction had been used, then an unrecognized attribute could only
   be associated with extension insertion point I2.

   The non-determinism could also be resolved by adding a NO-INSERTIONS
   or HOLLOW-INSERTIONS encoding instruction to the outer SEQUENCE:

      [HOLLOW-INSERTIONS] SEQUENCE {
          one    [GROUP] SEQUENCE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  INTEGER OPTIONAL,
          ... -- Extension insertion point (I2).
      }

   The associated grammar is:

      P11: S ::= one three
      P2:  one ::= two I1
      P3:  two ::= "two"
      P4:  I1 ::= "*" I1
      P5:  I1 ::=
      P6:  three ::= "three"
      P7:  three ::=

   This grammar leads to the following sets and predicates:

      First(P4) = { "*" }
      First(P5) = { }
      Preselected(P4) = Preselected(P5) = Empty(P4) = false
      Empty(P5) = true
      Follow(I1) = { "three", "$" }
      Select(P4) = First(P4) = { "*" }
      Select(P5) = First(P5) + Follow(I1) = { "three", "$" }

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

   The intersection of Select(P4) and Select(P5) is empty, as is the
   intersection of Select(P6) and Select(P7); hence, the grammar is
   deterministic, and the type definition is valid.  A decoder will now
   assume that an unrecognized element is to be associated with
   extension insertion point I1.  It is still free to associate an
   unrecognized attribute with either extension insertion point.  If a
   NO-INSERTIONS encoding instruction had been used, then an
   unrecognized attribute could only be associated with extension
   insertion point I1.

B.2.  Example 2

   Consider the following type definition:

      SEQUENCE {
          one  [GROUP] CHOICE {
              two  UTF8String,
              ... -- Extension insertion point (I1).
          } OPTIONAL
      }

   The associated grammar is:

      P1:  S ::= one
      P2:  one ::= two
      P3:  one ::= I1
      P4:  one ::=
      P5:  two ::= "two"
      P6:  I1 ::= "*" I1
      P7:  I1 ::=

   This grammar leads to the following sets and predicates:

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

      First(P6) = { "*" }
      First(P7) = { }
      Preselected(P6) = Preselected(P7) = Empty(P6) = false
      Empty(P7) = true

      Follow(I1) = { "$" }
      Select(P6) = First(P6) = { "*" }
      Select(P7) = First(P7) + Follow(I1) = { "$" }

   The intersection of Select(P3) and Select(P4) is not empty; hence,
   the grammar is not deterministic, and the type definition is not
   valid.  If the <two> element is not present, then a decoder cannot
   determine whether the "one" alternative is absent, or present with an
   unknown extension that generates no elements.

   The non-determinism can be resolved with either a
   SINGULAR-INSERTIONS, UNIFORM-INSERTIONS, or MULTIFORM-INSERTIONS
   encoding instruction.  The MULTIFORM-INSERTIONS encoding instruction
   is the least restrictive.  Consider this revised type definition:

      SEQUENCE {
          one  [GROUP] [MULTIFORM-INSERTIONS] CHOICE {
              two  UTF8String,
              ... -- Extension insertion point (I1).
          } OPTIONAL
      }

   The associated grammar is:

      P1:  S ::= one
      P2:  one ::= two
      P8:  one ::= "*" I1
      P4:  one ::=
      P5:  two ::= "two"
      P6:  I1 ::= "*" I1
      P7:  I1 ::=

   This grammar leads to the following sets and predicates:

      First(P2) = { "two" }
      First(P8) = { "*" }
      First(P4) = { }
      Preselected(P2) = Preselected(P8) = Preselected(P4) = false
      Empty(P2) = Empty(P8) = false
      Empty(P4) = true
      Follow(one) = { "$" }
      Select(P2) = First(P2) = { "two" }
      Select(P8) = First(P8) = { "*" }
      Select(P4) = First(P4) + Follow(one) = { "$" }

      First(P6) = { "*" }
      First(P7) = { }
      Preselected(P6) = Preselected(P7) = Empty(P6) = false

      Empty(P7) = true
      Follow(I1) = { "$" }
      Select(P6) = First(P6) = { "*" }
      Select(P7) = First(P7) + Follow(I1) = { "$" }

   The intersection of Select(P2) and Select(P8) is empty, as is the
   intersection of Select(P2) and Select(P4), the intersection of
   Select(P8) and Select(P4), and the intersection of Select(P6) and
   Select(P7); hence, the grammar is deterministic, and the type
   definition is valid.  A decoder will now assume the "one" alternative
   is present if it sees at least one unrecognized element, and absent
   otherwise.

B.3.  Example 3

   Consider the following type definition:

      SEQUENCE {
          one    [GROUP] CHOICE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  [GROUP] CHOICE {
              four   UTF8String,
              ... -- Extension insertion point (I2).
          }
      }

   The associated grammar is:

      P1:  S ::= one three
      P2:  one ::= two
      P3:  one ::= I1
      P4:  two ::= "two"
      P5:  I1 ::= "*" I1
      P6:  I1 ::=
      P7:  three ::= four
      P8:  three ::= I2
      P9:  four ::= "four"
      P10: I2 ::= "*" I2
      P11: I2 ::=

   This grammar leads to the following sets and predicates:

      First(P2) = { "two" }
      First(P3) = { "*" }
      Preselected(P2) = Preselected(P3) = Empty(P2) = false
      Empty(P3) = true

      Follow(one) = { "four", "*", "$" }
      Select(P2) = First(P2) = { "two" }
      Select(P3) = First(P3) + Follow(one) = { "*", "four", "$" }

      First(P5) = { "*" }
      First(P6) = { }
      Preselected(P5) = Preselected(P6) = Empty(P5) = false
      Empty(P6) = true
      Follow(I1) = { "four", "*", "$" }
      Select(P5) = First(P5) = { "*" }
      Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }

      First(P7) = { "four" }
      First(P8) = { "*" }
      Preselected(P7) = Preselected(P8) = Empty(P7) = false
      Empty(P8) = true
      Follow(three) = { "$" }
      Select(P7) = First(P7) = { "four" }
      Select(P8) = First(P8) + Follow(three) = { "*", "$" }

      First(P10) = { "*" }
      First(P11) = { }
      Preselected(P10) = Preselected(P11) = Empty(P10) = false
      Empty(P11) = true
      Follow(I2) = { "$" }
      Select(P10) = First(P10) = { "*" }
      Select(P11) = First(P11) + Follow(I2) = { "$" }

   The intersection of Select(P5) and Select(P6) is not empty; hence,
   the grammar is not deterministic, and the type definition is not
   valid.  If the first child element is an unrecognized element, then a
   decoder cannot determine whether to associate it with extension
   insertion point I1, or to associate it with extension insertion point
   I2 by assuming that the "one" component has an unknown extension that
   generates no elements.

   The non-determinism can be resolved with either a SINGULAR-INSERTIONS
   or UNIFORM-INSERTIONS encoding instruction.  Consider this revised
   type definition using the SINGULAR-INSERTIONS encoding instruction:

      SEQUENCE {
          one    [GROUP] [SINGULAR-INSERTIONS] CHOICE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  [GROUP] CHOICE {
              four   UTF8String,
              ... -- Extension insertion point (I2).
          }
      }

   The associated grammar is:

      P1:  S ::= one three
      P2:  one ::= two
      P12: one ::= "*"
      P4:  two ::= "two"
      P7:  three ::= four
      P8:  three ::= I2
      P9:  four ::= "four"
      P10: I2 ::= "*" I2
      P11: I2 ::=

   With the addition of the SINGULAR-INSERTIONS encoding instruction,
   the P5 and P6 productions are no longer generated.  The grammar leads
   to the following sets and predicates for the P2 and P12 productions:

      First(P2) = { "two" }
      First(P12) = { "*" }
      Preselected(P2) = Preselected(P12) = false
      Empty(P2) = Empty(P12) = false
      Follow(one) = { "four", "*", "$" }
      Select(P2) = First(P2) = { "two" }
      Select(P12) = First(P12) = { "*" }

   The sets for P5 and P6 are no longer generated, and the remaining
   sets are unchanged.

   The intersection of Select(P2) and Select(P12) is empty, as is the
   intersection of Select(P7) and Select(P8) and the intersection of
   Select(P10) and Select(P11); hence, the grammar is deterministic, and
   the type definition is valid.  If the first child element is an
   unrecognized element, then a decoder will now assume that it is
   associated with extension insertion point I1.  Whatever follows,
   possibly including another unrecognized element, will belong to the
   "three" component.

   Now consider the type definition using the UNIFORM-INSERTIONS
   encoding instruction instead:

      SEQUENCE {
          one    [GROUP] [UNIFORM-INSERTIONS] CHOICE {
              two    UTF8String,
              ... -- Extension insertion point (I1).
          },
          three  [GROUP] CHOICE {
              four   UTF8String,
              ... -- Extension insertion point (I2).
          }
      }

   The associated grammar is:

      P1:  S ::= one three
      P2:  one ::= two
      P13: one ::= "*"
      P14: one ::= "*1" I1
      P4:  two ::= "two"
      P15: I1 ::= "*1" I1
      P6:  I1 ::=
      P7:  three ::= four
      P8:  three ::= I2
      P9:  four ::= "four"
      P10: I2 ::= "*" I2
      P11: I2 ::=

   This grammar leads to the following sets and predicates for the P2,
   P13, P14, P15, and P6 productions:

      First(P2) = { "two" }
      First(P13) = { "*" }
      First(P14) = { "*1" }
      Preselected(P2) = Preselected(P13) = Preselected(P14) = false
      Empty(P2) = Empty(P13) = Empty(P14) = false
      Follow(one) = { "four", "*", "$" }
      Select(P2) = First(P2) = { "two" }
      Select(P13) = First(P13) = { "*" }
      Select(P14) = First(P14) = { "*1" }

      First(P15) = { "*1" }
      First(P6) = { }
      Preselected(P15) = Preselected(P6) = Empty(P15) = false
      Empty(P6) = true
      Follow(I1) = { "four", "*", "$" }
      Select(P15) = First(P15) = { "*1" }
      Select(P6) = First(P6) + Follow(I1) = { "four", "*", "$" }

   The remaining sets are unchanged.

   The intersection of Select(P2) and Select(P13) is empty, as is the
   intersection of Select(P2) and Select(P14), the intersection of
   Select(P13) and Select(P14) and the intersection of Select(P15) and
   Select(P6); hence, the grammar is deterministic, and the type
   definition is valid.  If the first child element is an unrecognized
   element, then a decoder will now assume that it and every subsequent
   unrecognized element with the same name are associated with I1.
   Whatever follows, possibly including another unrecognized element
   with a different name, will belong to the "three" component.

   A consequence of using the UNIFORM-INSERTIONS encoding instruction is
   that any future extension to the "three" component will be required
   to generate elements with names that are different from the names of
   the elements generated by the "one" component.  With the
   SINGULAR-INSERTIONS encoding instruction, extensions to the "three"
   component are permitted to generate elements with names that are the
   same as the names of the elements generated by the "one" component.

B.4.  Example 4

   Consider the following type definition:

      SEQUENCE OF one [GROUP] CHOICE {
          two    UTF8String,
          ... -- Extension insertion point (I1).
      }

   The associated grammar is:

      P1:  S ::= one S
      P2:  S ::=
      P3:  one ::= two
      P4:  one ::= I1
      P5:  two ::= "two"
      P6:  I1 ::= "*" I1
      P7:  I1 ::=

   This grammar leads to the following sets and predicates:

      First(P1) = { "two", "*" }
      First(P2) = { }
      Preselected(P1) = Preselected(P2) = false
      Empty(P1) = Empty(P2) = true
      Follow(S) = { "$" }
      Select(P1) = First(P1) + Follow(S) = { "two", "*", "$" }
      Select(P2) = First(P2) + Follow(S) = { "$" }

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

      First(P6) = { "*" }
      First(P7) = { }
      Preselected(P6) = Preselected(P7) = Empty(P6) = false
      Empty(P7) = true
      Follow(I1) = { "two", "*", "$" }
      Select(P6) = First(P6) = { "*" }
      Select(P7) = First(P7) + Follow(I1) = { "two", "*", "$" }

   The intersection of Select(P1) and Select(P2) is not empty, as is the
   intersection of Select(P3) and Select(P4) and the intersection of
   Select(P6) and Select(P7); hence, the grammar is not deterministic,
   and the type definition is not valid.  If a decoder encounters two or
   more unrecognized elements in a row, then it cannot determine whether
   this represents one instance or more than one instance of the "one"
   component.  Even without unrecognized elements, there is still a
   problem that an encoding could contain an indeterminate number of
   "one" components using an extension that generates no elements.

   The non-determinism cannot be resolved with a UNIFORM-INSERTIONS
   encoding instruction.  Consider this revised type definition using
   the UNIFORM-INSERTIONS encoding instruction:

      SEQUENCE OF one [GROUP] [UNIFORM-INSERTIONS] CHOICE {
          two    UTF8String,
          ... -- Extension insertion point (I1).
      }

   The associated grammar is:

      P1:  S ::= one S
      P2:  S ::=
      P3:  one ::= two
      P8:  one ::= "*"
      P9:  one ::= "*1" I1
      P5:  two ::= "two"
      P10: I1 ::= "*1" I1
      P7:  I1 ::=

   This grammar leads to the following sets and predicates:

      First(P1) = { "two", "*", "*1" }
      First(P2) = { }
      Preselected(P1) = Preselected(P2) = Empty(P1) = false
      Empty(P2) = true
      Follow(S) = { "$" }
      Select(P1) = First(P1) = { "two", "*", "*1" }
      Select(P2) = First(P2) + Follow(S) = { "$" }

      First(P3) = { "two" }
      First(P8) = { "*" }
      First(P9) = { "*1" }
      Preselected(P3) = Preselected(P8) = Preselected(P9) = false
      Empty(P3) = Empty(P8) = Empty(P9) = false
      Follow(one) = { "two", "*", "*1", "$" }
      Select(P3) = First(P3) = { "two" }
      Select(P8) = First(P8) = { "*" }
      Select(P9) = First(P9) = { "*1" }

      First(P10) = { "*1" }
      First(P7) = { }
      Preselected(P10) = Preselected(P7) = Empty(P10) = false
      Empty(P7) = true
      Follow(I1) = { "two", "*", "*1", "$" }
      Select(P10) = First(P10) = { "*1" }
      Select(P7) = First(P7) + Follow(I1) = { "two", "*", "*1", "$" }

   The intersection of Select(P1) and Select(P2) is now empty, but the
   intersection of Select(P10) and Select(P7) is not; hence, the grammar
   is not deterministic, and the type definition is not valid.  The
   problem of an indeterminate number of "one" components from an
   extension that generates no elements has been solved.  However, if a
   decoder encounters a series of elements with the same name, it cannot
   determine whether this represents one instance or more than one
   instance of the "one" component.

   The non-determinism can be fully resolved with a SINGULAR-INSERTIONS
   encoding instruction.  Consider this revised type definition:

      SEQUENCE OF one [GROUP] [SINGULAR-INSERTIONS] CHOICE {
          two    UTF8String,
          ... -- Extension insertion point (I1).
      }

   The associated grammar is:

      P1:  S ::= one S
      P2:  S ::=
      P3:  one ::= two
      P8:  one ::= "*"
      P5:  two ::= "two"

   This grammar leads to the following sets and predicates:

      First(P1) = { "two", "*" }
      First(P2) = { }
      Preselected(P1) = Preselected(P2) = Empty(P1) = false
      Empty(P2) = true
      Follow(S) = { "$" }
      Select(P1) = First(P1) = { "two", "*" }
      Select(P2) = First(P2) + Follow(S) = { "$" }

      First(P3) = { "two" }
      First(P8) = { "*" }
      Preselected(P3) = Preselected(P8) = false
      Empty(P3) = Empty(P8) = false
      Follow(one) = { "two", "*", "$" }
      Select(P3) = First(P3) = { "two" }
      Select(P8) = First(P8) = { "*" }

   The intersection of Select(P1) and Select(P2) is empty, as is the
   intersection of Select(P3) and Select(P8); hence, the grammar is
   deterministic, and the type definition is valid.  A decoder now knows
   that every extension to the "one" component will generate a single
   element, so the correct number of "one" components will be decoded.

Appendix C.  Extension and Versioning Examples

   This appendix is non-normative.

C.1.  Valid Extensions for Insertion Encoding Instructions

   The first example shows extensions that satisfy the HOLLOW-INSERTIONS
   encoding instruction.

      [HOLLOW-INSERTIONS] CHOICE {
          one    BOOLEAN,
          ...,
          two    [ATTRIBUTE] INTEGER,
          three  [GROUP] SEQUENCE {
              four  [ATTRIBUTE] UTF8String,
              five  [ATTRIBUTE] INTEGER OPTIONAL,
              ...
          },
          six    [GROUP] CHOICE {
              seven  [ATTRIBUTE] BOOLEAN,
              eight  [ATTRIBUTE] INTEGER
          }
      }

   The "two" and "six" components generate only attributes.

   The "three" component in its current form does not generate elements.
   Any extension to the "three" component will need to do likewise to
   avoid breaking forward compatibility.

   The second example shows extensions that satisfy the
   SINGULAR-INSERTIONS encoding instruction.

      [SINGULAR-INSERTIONS] CHOICE {
          one    BOOLEAN,
          ...,
          two    INTEGER,
          three  [GROUP] SEQUENCE {
              four   [ATTRIBUTE] UTF8String,
              five   INTEGER
          },
          six    [GROUP] CHOICE {
              seven  BOOLEAN,
              eight  INTEGER
          }
      }

   The "two" component will always generate a single <two> element.

   The "three" component will always generate a single <five> element.
   It will also generate a "four" attribute, but any number of
   attributes is allowed by the SINGULAR-INSERTIONS encoding
   instruction.

   The "six" component will either generate a single <seven> element or
   a single <eight> element.  Either case will satisfy the requirement
   that there will be a single element in any given encoding of the
   extension.

   The third example shows extensions that satisfy the
   UNIFORM-INSERTIONS encoding instruction.

      [UNIFORM-INSERTIONS] CHOICE {
          one    BOOLEAN,
          ...,
          two    INTEGER,
          three  [GROUP] SEQUENCE SIZE(1..MAX) OF four INTEGER,
          five   [GROUP] SEQUENCE {
              six    [ATTRIBUTE] UTF8String OPTIONAL,
              seven  INTEGER
          },
          eight  [GROUP] CHOICE {
              nine   BOOLEAN,
              ten    [GROUP] SEQUENCE SIZE(1..MAX) OF eleven INTEGER
          }
      }

   The "two" component will always generate a single <two> element.

   The "three" component will always generate one or more <four>
   elements.

   The "five" component will always generate a single <seven> element.
   It may also generate a "six" attribute, but any number of attributes
   is allowed by the UNIFORM-INSERTIONS encoding instruction.

   The "eight" component will either generate a single <nine> element or
   one or more <eleven> elements.  Either case will satisfy the
   requirement that there must be one or more elements with the same
   name in any given encoding of the extension.

C.2.  Versioning Example

   Making extensions that are not forward compatible is permitted
   provided that the incompatibility is signalled with a version
   indicator attribute.

   Suppose that version 1.0 of a specification contains the following
   type definition:

      MyMessageType ::= SEQUENCE {
         version  [ATTRIBUTE] [VERSION-INDICATOR]
                      UTF8String ("1.0", ...) DEFAULT "1.0",
         one      [GROUP] [SINGULAR-INSERTIONS] CHOICE {
             two  BOOLEAN,
             ...
         },
         ...
      }

   An attribute is to be added to the CHOICE for version 1.1.  This
   change is not forward compatible since it does not satisfy the
   SINGULAR-INSERTIONS encoding instruction.  Therefore, the version
   indicator attribute must be updated at the same time (or added if it
   wasn't already present).  This results in the following new type
   definition for version 1.1:

      MyMessageType ::= SEQUENCE {
         version  [ATTRIBUTE] [VERSION-INDICATOR]
                      UTF8String ("1.0", ..., "1.1") DEFAULT "1.0",
         one      [GROUP] [SINGULAR-INSERTIONS] CHOICE {
             two    BOOLEAN,
             ...,
             three  [ATTRIBUTE] INTEGER -- Added in Version 1.1
         },
         ...
      }

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

   A pair of elements is added to the CHOICE for version 1.2.  Again the
   change does not satisfy the SINGULAR-INSERTIONS encoding instruction.
   The type definition for version 1.2 is:

      MyMessageType ::= SEQUENCE {
         version  [ATTRIBUTE] [VERSION-INDICATOR]
                      UTF8String ("1.0", ..., "1.1" | "1.2")
                          DEFAULT "1.0",
         one      [GROUP] [SINGULAR-INSERTIONS] CHOICE {
             two    BOOLEAN,
             ...,
             three  [ATTRIBUTE] INTEGER, -- Added in Version 1.1
             four   [GROUP] SEQUENCE {
                 five  UTF8String,
                 six   GeneralizedTime
             } -- Added in version 1.2
         },
         ...
      }

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

Author's Address

   Dr. Steven Legg
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre
   935 Station Street
   Box Hill North, Victoria 3129
   AUSTRALIA

   Phone: +61 3 9896 7830
   Fax:   +61 3 9896 7801
   EMail: steven.legg@eb2bcom.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.