UPER representation of extensible CHOICE

[jbeyerstedt]

While updating the V2X/ ETSI ITS-G5 IVIM message definition to the latest version, our unit tests failed because the parser can't decode an old IVIM UPER buffer with the new definition. The root cause seems to be the IviContainer from https://standards.iso.org/iso/ts/19321/ed-3/en/ISO19321IVIv3.1.asn:

IviContainer::= CHOICE {
   glc	    GeographicLocationContainer,
   giv	    GeneralIviContainer,
   rcc	    RoadConfigurationContainer,
   tc	    TextContainer,
   lac	    LayoutContainer,
   ...,	-- original extension indicator of V1
[[ 
   avc	    AutomatedVehicleContainer,	
   mlc	    MapLocationContainer, 
   rsc	    RoadSurfaceContainer ]], -- Extension in V2
   isc      InfrastructureSupportContainer  -- Extension in V3.1
}

The issue seems to be that the parser uses more bits for the choice ID than it was encoded with and is therefore offset by a few bits in the message and fails at some point in the remaining IVIM message.

This was validated given the following minimal example:

ChoiceBase ::= CHOICE {
  opt1              INTEGER (0..255),
  opt2              INTEGER (0..255),
  opt3              INTEGER (0..255),
  opt4              INTEGER (0..255),
  ...,	-- original extension indicator of V1
}

ChoiceExt ::= CHOICE {
  opt1              INTEGER {} (0..255),
  opt2              INTEGER {} (0..255),
  opt3              INTEGER {} (0..255),
  opt4              INTEGER {} (0..255),
  ...,	-- original extension indicator of V1
  opt5              INTEGER {} (0..255),  -- Extension in V2
}

Encoding an opt2(0x0b) will yield 0x21.60 when using the ChoiceBase definition, but it will output 0x10.b0 when using the ChoiceExt definition. Just adding an extension to the definition shouldn't change the UPER output.

From my understanding of X.691 clause, the choice index shall only count choices that aren't in any extension. Even though clause 23.7 is not 100% precise how the choice index shall be constrained, it's fair to assume that the same rules of 23.6 apply. And in that case, the index shall be constrained to n with the definition: "let 'n' be the value of the largest index in the root".

I will try to dig into the library tomorrow to find a solution, but will appreciate hints where to look.