CODEWITHSUNDEEP
asn.1der
Dmytro Starosud
Dmytro Starosud

Reputation: 396

ASN.1 schema compatibility

Does ASN.1 schema support some form of well-defined set of backward/forward-compatible changes?

I worked with protobuf and it allows changing schema in a way that clients using old schema would continue to work normally. Is there the same for ASN.1, I mean some set of rules which one has to follow to be sure he won't break clients using old schema?

In particular is that possible to add new (probably optional) field to SEQUENCE or add/remove CHOICE? Tried googling that, but didn't find appropriate article regarding this.

Upvotes: 0

Views: 480

Answers (2)

bazza
bazza

Reputation: 8444

To add to treuss's answer, the way ellipsis tend to get handled in generated code is as follows.

In code generated from the original version of a schema, it will make allowances for future extensions by carrying anything it doesn't understand still encoded in a byte array as part of the language object (struct in C, class in C++, etc) that represents the decoded message. This allows the object to be modified (in the fields that are understood) and re-serialised, without ever having to understand the new fields.

The consequence is that an old subsystem can receive a message created against a newer version of the schema, do its thing, and pass it on. It does not have to be recompiled to keep doing its job.

Things that will ruin this is if automatic tagging is assumed, and a wireformat with tags is used (e.g. BER), and the schema gets a message / PDU inserted part way through the schema file. The inserted message bumps the tag values up by 1 for all the messages that follow it, which can cause mighty confusion to old subsystems that aren't getting recompiled.

CHOICEs can also be extensible.

Constraints

Constraints can also be extensible: for example,

ConstrainedInt ::= INTEGER (0..10, ...)

This allows ConstrainedInt's to be limited in value from 0 to 10. Generated code for the first version will not allow encoding of values outside of 0..10, and will decode values outside of 0..10 but probably return an error. A future version of the schema can add to this:

ConstrainedInt ::= INTEGER (0..10, 20..30, ...)

The same with sizes:

ConstrainedList ::= SEQUENCE (SIZE(1..10, ...)) OF INTEGER

Upvotes: 1

treuss
treuss

Reputation: 2388

Yes, ASN.1 supports forward/backward capability. However, it starts with the original definition. E.g. for a sequence, if a client is built based on the following definition

NetworkLocation ::= [APPLICATION 156] SEQUENCE
{
   recEntityCode RecEntityCode OPTIONAL,
   callReference CallReference OPTIONAL,
   locationArea LocationArea OPTIONAL,
   cellId CellId OPTIONAL,
   ...                            -- future versions may add fields here
}

it should be built in a was, that it accepts further fields as part of this type where the ellipsis is. Naturally, in any future version of the specification, additional fields should be OPTIONAL. The same is true for the definition of CHOICEs and ENUMERATED types.

Upvotes: 1

Related Questions