How is ellpisis (...) usually handled in Sequences/Choices?

[Nicceboy]

Hey,

I am just wondering how the extension mark (...) is handled when the ASN.1 definition uses it.

For example

HashedData::= CHOICE { 
  sha256HashedData HashedId32,
  ...,
  sha384HashedData HashedId48,
  sm3HashedData    HashedId32
}

The first case is always supported, but on newer versions the latter as well.
Is this something which is handled automatically by encoder/decoder or how I can mark that after specific point there might be extensions? Or should I add it manually for encoder/decoder.

[XAMPPRocky]

Thank you for your question! There's two parts to this question, but they have similar answers.

• For sequences/sets, both the encoder and decoder accept a C: Constructed argument, which has an associated constant called EXTENDED_FIELDS which is Option<Fields> and fields is a slice (which can be empty). You can use this associated constant to determine if a type is extensible, and what extended fields it has.
• For choices it's a similar setup where the encoder and decoder accept a C: Choice argument, which has an associated constant called EXTENDED_VARIANTS which is similarly Option<TagTree>, and you can use this constant to determine if a choice is extensible and what extended variants it has.

[Nicceboy]

Thanks!

[Nicceboy]

I am writing this here, since I might be doing something wrong, but it could be also an issue.

There might be a little design error for handling default values for discriminant values and how they are handled in enumerated types.
If I understood correctly, the default behavior for extended variants is, that their default values are set based on the variants in root list.

It is defined in the section 20.6 in ITU-T Rec. X.680 (02/2021), for example

A ::= ENUMERATED {a, b, ..., c}		-- c = 2
B ::= ENUMERATED {a, b, c(0), ..., d}	-- d = 3
C ::= ENUMERATED {a, b, ..., c(3), d}	-- d = 4
D ::= ENUMERATED {a, z(25), ..., d}	-- d = 1

Let's say we have a following rasn example:

#[derive(AsnType, Clone, Copy, Debug, Decode, Encode, PartialEq)]
#[rasn(enumerated, crate_root = "crate")]
enum Enum {
    Red, // Should be 0
    Blue, // Should be 1
    Green, // Should be 2
    #[rasn(extension_addition)]
    Yellow, // Should be 3, but currently is 0 (living alone in EXTENDED_DISCRIMINANTS list)
    Purple, // Should be 4, but currently is 3 (I assume this is also extension variant, but it is still in root (DISCRIMINANTS) list)
}

I would assume that discriminant values should be incremented correctly.

Also, shouldn't Purple also be on the EXTENDED_DISCRIMINANTS list?
In documentation it says about DISCRIMINANTS; "Variants contained in the "root component list". Purple is not part of the root component list.
Or maybe I am trying to use the types differently than intended...

If I am supposed supposed to mark every extension variant with #[rasn(extension_addition)]

#[derive(AsnType, Clone, Copy, Debug, Decode, Encode, PartialEq)]
#[rasn(enumerated, crate_root = "crate")]
enum Enum {
    Red, // Should be 0
    Blue, // Should be 1
    Green, // Should be 2
    #[rasn(extension_addition)]
    Yellow, // Should be 3, but currently is 0 (living in EXTENDED_DISCRIMINANTS list)
    #[rasn(extension_addition)]
    Purple, // Should be 4, but currently is 1 (living also in EXTENDED_DISCRIMINANTS list)
}

This does not feel intuitive, since I was expecting #[rasn(extension_addition)] to mark ... ellipsis.

On the other hand, if I use #[rasn(extension_addition_group)] on the first example instead of #[rasn(extension_addition)], all the variants are in DISCRIMINANTS, and Purple or Yellow are not in EXTENDED_DISCRIMINANTS list.

In this case, the values are correct as none are in separate list, but is this intended?

If the extended variants are supposed to be on separate list, temporal easy fix for values might be on adding DISCRIMINANTS length as base for default i in https://github.com/XAMPPRocky/rasn/blob/e64391c49c34efdd3a342df81976a56cdfb487d2/macros/src/enum.rs#L100

But this not might cover all the cases.