ITU-T standardized the JSON encoding of ASN.1 data in X.697 (JER), but we believe customers want to support use cases the standard doesn't address. This post briefly describes two extensions to JER that we're planning to implement in our ASN.1 compiler, ASN1C. We plan to implement the first extension (for contents constraints) as an undocumented feature in a 7.3.x patch release in the September-October time frame.
Extension for Contents Constraints
The first extension relates to encoding of BIT STRING or OCTET STRING with a contents constraint. For example:
OCTET STRING (CONTAINING SomeType)
In short, the purpose of this first extension is to allow the contained type to be encoded in JSON just as it would be encoded if it weren't a contained type, instead of encoding it as a string of hexadecimal characters. This extension is all about making the JSON more human-readable. Here's an example:
Say your ASN.1 has something like this:
my-bit-string BIT STRING ( CONTAINING TwoStrings )
TwoStrings ::= SEQUENCE {
one UTF8String,
two UTF8String
}
The standard JER encoding would look something like:
"my-bit-string" : { "value" : "7B20226F6E6522203A20226D6F6E6579222C202274776F22203A202273686F7722207D", "length" : 280 }
Our extension would instead produce something like:
"my-bit-string" : { "value+" : { "one" : "money", "two" : "show" } }
Extension for Values of Unknown Types
The second extension relates to encoding values of unknown types, which may appear as SEQUENCE/SET/CHOICE extension elements or in open types. It isn't possible to convert values of unknown types from BER or PER to standard JER. Since its type isn't known, the value is stuck in BER or PER, so to speak. So, in short, the purpose of our second extension is to enable converting the rest of your data to JSON while preserving what can't be properly converted (in case you need it) and making a round trip back to the original encoding possible. This is done by embedding the original encoding in the JSON in hexadecimal form, along with some supplemental information where necessary.
Below are some examples of the JSON that would be produced using our extension.
Handling an unknown open type value:
"some-open-type-element" : {
"encoding-rules+" : "BER",
"encoded-data+" : "03020101"
}
Handling unknown SEQUENCE or SET extension elements:
"extensions+" : {
"encoding-rules+" : "BER",
"encoded-data+": [ "hex for extension X", "hex for extension Y" ]
}
Handling an unknown CHOICE extension element:
some-choice-field : {
"extension+" : {
"encoding-rules+" : "PER",
"encoded-data+" : "04020301",
"encoded-per-index+" : 5
}
}