CODEWITHSUNDEEP
asn.1
Farsee
Farsee

Reputation: 477

ASN.1 Expressing SEQUENCE size constraint

I want to describe an existing data structure in ASN.1 so I can use a suitable library to decode/encode/validate the transactions without having to write everything from scratch.

Also:

Consider the following simplified example:

World-Schema DEFINITIONS AUTOMATIC TAGS ::= 
BEGIN
  Test ::= SEQUENCE {
     id IA5String (SIZE(5)),
     nbData IA5String (SIZE(2)),
     dataList ListOfData
  }
  ListOfData ::= SEQUENCE(SIZE(0..99)) OF DataPoint
  DataPoint ::= SEQUENCE {
     x IA5String (SIZE(2)),
     y IA5String (SIZE(2))
  }
END

The field nbData dictates the number of dataPoint elements that are present in the stream of transmitted data.

Beside the fact that nbData is actually an Integer coded as a String, this must be a very common way of compacting transmitted data. Still, I'm stuck trying to find a way to define this structure.

How can I express this constraint in ASN.1 ?

Upvotes: 0

Views: 1886

Answers (3)

Dave
Dave

Reputation: 3956

You are confusing the ASN.1 schema, which defines the structure and allowed values of a message, with the content of a specific message that conforms to that schema. You define the allowed number of DataPoints for all messages (0..99) when you write the schema.

You define the number of DataPoints in a specific message at runtime, when you send the message. Encoding rules such as BER or XER specify how a message is transmitted - you give the encoder a ListOfData message with 17 DataPoints and it will:

1) check that the number of points is within the range allowed by the schema (0..99), and
2) send that list of 17 DataPoints as specified by the encoding rules.

When you receive the message, ListOfData will have a size (17) that is known from the encoding rules, and that size will again be validated against the schema (0..99).

If you want to create a separate nbData variable in your program, you can copy the the length of ListOfData into it after you decode the message. But nbData is not a variable that is specified inside the schema and transmitted redundantly within the message.

If you can't change things like the Test data structure to get rid of nbData entirely, just populate it with the right value at the sender. At the receiver either ignore it or compare it to the right value after the message is decoded. Don't bother messing with the ASN.1 to add constraints; the right way to mess with it is to delete the cruft.

The thing with ASN.1 is that it is an abstract data description language, independent of programming languages and serialization formats. If you are programming in a low-level language like C, you'd use a memory structure that has an integer number of data points (nbData) and a pointer to struct DataPoint. But if you are using a high-level language like Java, JS, Python, etc, ListOfData would be an array or list and it would have a length.

So if you are programming in C, your ASN.1 serialization library may give you a ListOfData struct that has something like nbData built into it. But if you are programming in Python, the library will give you a list, and if you want something like nbData you'd get it using len(ListOfData).

ASN.1 abstracts away that difference in implementation, which is why nbData isn't a separate ASN.1 variable, it is built into ListOfData.

Upvotes: 0

Paul Thorpe
Paul Thorpe

Reputation: 2070

This kind of constraint is not one "native" to ASN.1, especially since the field containing the integer is being represented as a string. While it is possible for ECN (Encoding Control Notation) to handle this, it may be better to use what ASN.1 calls a "user defined constraint" such as:

Test ::= SEQUENCE {
     id IA5String (SIZE(5)),
     nbData IA5String (SIZE(2)),
     dataList ListOfData
} (CONSTRAINED BY {-- English text describing your constraint --})

Some commercial ASN.1 compilers are able use this constraint notation to generate function stubs in the generated encoder/decoder to allow you to enforce constraints that exceed the built-in capabilities of ASN.1 constraint notation.

There is a much more complicated way you could enforce the constraint using the "WITH COMPONENTS" constraint on the SEQUENCE, but the amount of text required write the complete constraint to do this is not likely worthwhile.

Upvotes: 1

Kevin
Kevin

Reputation: 1978

How do you express that constraint in ASN.1? You can't.

You can look into ECN, which is a (rather complicated) syntax that is part of the ASN.1 family and which is meant to be used together with ASN.1 to specify non-standard (ie. other than BER, PER, etc.) encodings.

I don't know whether ECN will be expressive enough to specify the encoding you want, but I think it is likely. But, you will have to figure ECN out, and then you'll have to find a tool that supports ECN. Good luck!

Upvotes: 0

Related Questions