ASN.1 extensibility

[ErfanBabakhani]

Hello I have a question about the extensibility as I know extension mark is forbidden in your compiler however using extension mark consume too much bits

Command DEFINITIONS AUTOMATIC TAGS ::= BEGIN


FreqVal ::= INTEGER (0..31)

-- Define the structure for freqVal
FreqArgs ::= SEQUENCE {
    freqVal        INTEGER (0..127),
    channel        INTEGER (0..3)
}

-- Define the structure for powerStatus
PowerStatus ::= BOOLEAN

Start ::= SEQUENCE {
    freqVal        FreqArgs,
    power          BOOLEAN
}

-- Define the main Command structure
CommandV2 ::= SEQUENCE {
 --we may change it in new version
}

CommandV1 ::= SEQUENCE {
    arg CHOICE {
        setFrequency   FreqVal,
        setPower       PowerStatus
    }
}

Command ::= SEQUENCE {
    version        CHOICE {
        cm1            CommandV1,
        cm2            CommandV2
    }
}

END

I have a problem to sending some commands like above code and I think if I use some spare bits I can choice between the different version of Commands so future version can communicate with older versions

I want you to help me make it better and say your opinion about it
Thank a lot

[maxime-esa]

Could you be more specific when you say you have problems sending some commands like this?

Otherwise I suggest you check this answer where I propose an alternative way to support extensibility : #267

[ErfanBabakhani]

sorry I didn't mean I can't send Command SEQUENCE I just wanted to know what is your opinion about this approach for providing extensibility I am not English, so I think I have made a mistake in my sentence Regards and thanks for responding

…

On Mon, Sep 2, 2024, 15:26 Maxime Perrotin ***@***.***> wrote: Could you be more specific when you say you have problems sending some commands like this? Otherwise I suggest you check this answer where I propose an alternative way to support extensibility : #267 <#267> — Reply to this email directly, view it on GitHub <#313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4OGA5BUIKBYYBDOPVZPDP3ZURG57AVCNFSM6AAAAABMWJABVSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJSGAYTENQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[maxime-esa]

This could actually work, but I am not sure until it is tested with an actual example

If v1 gets a message with v2 content, the size of the packet will be larger than what v1 expects and there may be buffer/size issue in the v1 application. Perhaps it would work with the decoder in streaming mode. If the packet choice is v2, then the remaining bytes should be ignored.