Reconsider extensibility / size constraints for encoding purposes

[xssfox]

Project Horus / Horus Binary is starting to utilize ASN.1 for our high altitude balloons, and we've recently adopted using ASN1SCC for generating the embedded C components.

While a lot of high altitude ballooning is similar spacecraft there are some subtle differences, the most relevant to this discussion is - often our payloads are TX only - no RX, and that there is disconnect between receivers and balloon operators. We chose to build an ASN.1 definition that balloon operators can use to ensure compatibility with a wide range of receivers.

Like many others using ASN.1 we have adopted using extension markers to provide future functionality. Given ASN1SCC was built with space craft constraints in mind it provides a snarky/annoying little error message.

Think about it: what would you do when the embedded platform in your satellite runs out of memory? Blue screen? :-)

While there's hacks to provide similar functionality without extension markers, I don't feel like the work arounds suggested are all that nice.

For our use I think the error message is somewhat irrelevant as the payload is only ever transmitting. It doesn't need to worry itself about receiving a packet that is too large to process. For transmitting purposes it would be safe to process the extension marker as if it were fixed/complete. The receiving side can use more flexible decoders where memory is inexpensive.

I believe this is also the case for unconstrained strings. While receiving this could be a problem, for transmitting the payload itself has a pretty good idea of the max size the string could be.

I wouldn't be surprised if these same "TX only" constraints would also be useful for spacecraft protocol standardisation efforts as well.

In the meantime a workaround others might want to use

For the moment we are still using ASN1SCC for transmission with extension markers in our definitions, but as we haven't needed to yet extend the specification we have implemented a work around. When generating the C we "burn a bit" by placing an optional field at the start of the SEQUENCE.

Before:

Telemetry ::= SEQUENCE {
  payloadCallsign     IA5String (FROM("-/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789")^SIZE (1..15)),
  sequenceNumber      INTEGER (0..65535),
  ...
}

After:

Telemetry ::= SEQUENCE {
  extensionMarkerForASN1CC BOOLEAN OPTIONAL,  -- this is an extension marker - it lets us add fields

  payloadCallsign     IA5String (FROM("-/abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789")^SIZE (1..15)),
  sequenceNumber      INTEGER (0..65535)
}