ASN.1 Dynamic Profile
OVERVIEW
Connected world reached unprecedented diversity. We see continuously evolving and converging devices, apps and protocols[1]. A standalone application or an unconnected device becomes a rarity. Most apps span across multiple platforms, backends and services. This leads to the need for a fast integration, which can be achieved with ”elastic” schemas, dynamic types, simple protocols. Yet, interoperability remains a major challenge [4].
On the other end of the dynamic spectrum are small resource-oriented systems, intended to run on low power and are constrained by size. A simplified set of ASN.1 features may be an attractive alternative to technologies competing in this sector.
GOALS
ASN.1 standard provides a rich and powerful set of features which are suitable for its traditional uses and the needs of the IoT market (dynamic, small, simple implementations). The ASN.1 Dynamic Profile selects a subset of ASN.1 to address the following goals:
- Smaller footprint – The variety and complexity of the type system is reduced by focusing on native types of programming languages.
- Dynamic environments – The ASN.1 Dynamic Profile will be an attractive choice for environments characterized by “elastic” schemas (schemas that employ optional or expandable data) and “self-describing” encoding formats (encoding formats that rely on the use of tags or keys). The number of encoding formats will be limited to one for each kind: TLV-based, human-readable text, and fast or compact binary format.
A potential additional benefits may include a shorter learning curve, ease of conversion between programming languages, use of dynamic schema bindings (dynamic types, which take place at runtime).
PROFILE
This profile focuses on a subset of ASN.1 features that should or should not be used when implementing the ASN.1 Dynamic Profile. The following terms are used throughout the profile:
Term | Meaning |
Required | Must be implemented. If a required feature is not implemented, the compiler, encoder, or decoder issues an error. For example, support for INTEGER types is required. |
Prohibited | Must not be implemented or must be disabled. If a prohibited feature is used, the compiler, encoder, or decoder issues an error. For example, support for BIT STRING types is prohibited. |
Recommended | Must be implemented, but its use is optional. If the compiler, encoder, or decoder cannot find a recommended feature that it needs, it will issue a warning. For example, use of DEFAULTs or value range constraints is recommended instead of INTEGER types. |
Proportional font is used for ASN.1 terms | See the ASN.1 specifications section. For example: NamedNumber |
Important Note
Any ASN.1 features that are not addressed in this profile should be considered as not recommended and should not be expected to be either present or absent in any implementation of the ASN.1 Dynamic Profile.
The ASN.1 Dynamic Profile does not deviate from the ASN.1 standard. The implementations that conform to this profile will create schemas and encodings that are compatible with all ASN.1 products.
Required
- Use of either EXPLICIT TAGS or AUTOMATIC TAGS mode. For related information, see Tags.
Recommended
- Use of EXPLICIT TAGS mode.
Prohibited
- IMPLICIT TAGS
- OID or IRI as part of the module names (i.e., the DefinitiveIdentification)
- EXTENSIBILITY IMPLIED
- EXPORT
- IMPORT
Required
Support for the following types:
Required type | Notes |
BOOLEAN | |
ENUMERATED | |
INTEGER | |
NULL | NULL has a single value. It is useful for indicating the absence or presence of something, for example: Location ::= CHOICE { coordinates GPS, address Address, unknown NULL } |
OCTET STRING | Useful for byte arrays |
REAL | Useful for floating point numbers (decimal, double) |
UTF8String | |
SEQUENCE | An ordered collection of items |
SEQUENCE OF | An ordered array |
CHOICE | A collection that defines mutually exclusive items where only one at a time can be “selected” in its value. |
[JER:OBJECT] |
This specific form of SET OF (with the [OBJECT] encoding instruction applied) defines a schema type for maps and dictionaries, which are popular in JSON. Other forms of SET/SET OF are prohibited. |
Recommended
- ValueRange constraints for more compact encodings, for example:
Age ::= INTEGER (0..127) (see Constraints and Validation)
- OPTIONAL for components of SEQUENCE types
- Extensions for SEQUENCE and CHOICE types
- Version brackets (see Extensibility and Versioning), for example:
Limit ::=SEQUENCE {
version Version OPTIONAL,
v1 INTEGER (0..1000) OPTIONAL,
...,
[[2: v2 INTEGER (0..2000) OPTIONAL]],
[[3: v3 INTEGER (0..3000) OPTIONAL]]
}
Prohibited
- Named numbers (NamedNumberList and NamedNumber)
- Use of sequence-like syntax to define a REAL number (NumericRealValue defined via SequenceValue). E.g. notations like {mantissa X, base Y, exponent Z} are prohibited, while a regular decimal number can be used instead
- The following ASN.1 types are prohibited (a replacement for each is proposed):
Prohibited type | Replacement | Notes |
IA5String | UTF8String | |
NumericString GeneralString UniversalString TeletexString T61String VideotexString VisibleString ISO646String PrintableString BMPString GraphicString CHARACTER STRING ObjectDescriptor | UTF8String | UTF8String has no constraints on the character set. Applications or add-ons can further validate characters or other string semantics. |
BIT STRING | OCTET STRING ENUMERATED SEQUENCE OF BOOLEANS | A SEQUENCE containing OPTIONAL NULLs can be an alternative for a more compact encoding. |
OBJECT IDENTIFIER RELATIVE-OID RELATIVE-OID-IRI | UTF8String | A string in dotted format, for example: “1.3.6.1.4.1.5518”. |
DATE DATE-TIME TIME TIME-OF-DAY DURATION GeneralizedTime UTCTime | UTF8String | A string in ISO 8601 format, for example: “2016-03-11T03:45:40Z”. |
Open Type EXTERNAL EMBEDDED PDV | OCTET STRING | Application logic and a separate identifier field must be used to specify the type. |
SET | SEQUENCE | |
SET OF except [JER:OBJECT] SET OF |
SEQUENCE OF
|
See [JER:OBJECT] SET OF SEQUENCE {key UTF8String, value <T>} in the required types.
|
Recommended
It is recommended to use
- DEFAULT values defined for components of primitive types (i.e., all types except for SEQUENCE, SEQUENCE OF, and CHOICE).
- Components defined as OPTIONAL when their default values are unknown.
Prohibited
It is prohibited to use
- DEFAULT values for “constructed” components, i.e., components whose types are themselves SEQUENCE, SEQUENCE OF, or CHOICE types.
Example of a prohibited definition:
Driver ::= SEQUENCE {
age INTEGER, -- recommended to use a DEFAULT here
addr SEQUENCE {
street UTF8String,
country UTF8String
} DEFAULT { -- prohibited for structured types
street "unknown",
country "US"}
}
Example of a recommended definition:
Driver2 ::= SEQUENCE {
age INTEGER DEFAULT 18,
addr SEQUENCE {
street UTF8String DEFAULT "unknown",
country UTF8String DEFAULT "US"
}
}
Extensibility and versioning are used to support forward and backward compatibility.
Recommended
- Define schemas with extensible SEQUENCE, CHOICE, and ENUMERATED types (i.e., use the extension marker “...”).
- Define SEQUENCE type components as OPTIONAL or DEFAULT (see Optionality). This allows you to skip or deprecate fields when a schema evolves. It also helps with forward compatibility, when an older application has no knowledge about newer fields and cannot set any meaningful values for them.
- Use the extension grouping with a version number for subsequent versions of a schema (e.g., [[2: new BOOLEAN, group INTEGER]]).
Prohibited
- Any type extensions, except for SEQUENCE, CHOICE, and ENUMERATED types (including Subtype extensions, see Constraints and Validation).
- Use of a second root in a SEQUENCE.
Required
Required constraint | Example | Notes |
SizeConstraint
| Data ::= OCTET STRING (SIZE (4..8)) | Applicable to strings and arrays (SEQUENCE OF).
Memory utilization. |
ValueRange, MIN, MAX | CarSpeed ::= INTEGER (0 .. 200) | Applicable to scalar types. By constraining INTEGERs, the encoding size becomes smaller (it is compatible with other protocols types, e.g., uint8, int8, sint16, int32, …). |
ContentsConstraint, CONTAINING, | Envelope ::= SEQUENCE { version INTEGER(0..255), msg OCTET STRING (CONTAINING MsgBody) } | Applicable to OCTET STRING.
Can be used for enveloping a message (embedding, versioning). |
Recommended
- SizeConstraint and ValueRange constraints
Prohibited
- Constraints with element sets (defined in ASN.1 as Unions or Exclusions; the syntax includes UNION, INTERSECTION, EXCEPT, ALL, “^”, “|”)
- Range and size constraints with ‘<’ literal; for example, use INTEGER (1..MAX) instead of INTEGER (0<..<MAX)
- Constraint extensions (the syntax includes ellipsis (“...”))
- The constraints in the following table:
Prohibited constraint | Example | Notes |
SingleValue
| Error ::= UTF8String ("Err") CitySpeedLimit ::= INTEGER(40) | Use range or size constraints instead. Define schema values to be used by the application validation logic. |
Extended constraints | INTEGER (1..8, ...) | Use a type extension with optional fields to replace a previous field with a new (extended) one. |
Constraint with sets (ElementSetSpec) | INTEGER ((1..20) | (100..200)) HighwaySpeedLimit ::= INTEGER (40 | 50 | 70) | Use (1..200) to indicate a complete range. This is useful for encoders or decoders, while the application handles the gap between 20 and 100. Use ENUMERATED. |
PermittedAlphabet, PatternConstraint | HardToRead ::= IA5String (FROM("8BI10OD5S")) USPhoneNumber ::= IA5String (PATTERN "\(\d#3\) \d#3-\d#4") -- (NNN) NNN-NNNN | Applicable only to strings. Slows down encoding and decoding. Use application logic or regular expressions (RegEx) to validate it. |
ContainedSubtype | SignColors ::= UTF8String (InfoColors UNION WarningColors) | |
InnerType
| Includes WITH COMPONENT, WITH COMPONENTS, PRESENT/ABSENT | |
TypeConstraint | Applicable only to open types. Use application logic to encode/decode values of such types. | |
Table Constraint, Component Relation Constraint | Applicable only to Information Objects, Sets, Classes. | |
PropertySettings, DurationRange, TimePointRange, RecurrenceRange | Applicable to time types. | |
UserDefinedConstraint | Encrypted ::= OCTET STRING (CONSTRAINED BY {...}) |
Required
- A context-specific tag is required for every component of a SEQUENCE or CHOICE. The context-specific tag must be unique across all components on the same level. It can be assigned either automatically (AUTOMATIC TAGS) or manually (EXPLICIT TAGS or AUTOMATIC TAGS).
Prohibited
- PRIVATE and APPLICATION tag classes
Example:
MTags DEFINITIONS EXPLICIT TAGS ::= BEGIN
Struct ::= SEQUENCE {
i [0] INTEGER,
s [1] UTF8String,
c [2] CHOICE {
b0 [0] BOOLEAN,
b1 [1] BOOLEAN
}
}
END
Advanced ASN.1 features
Prohibited
- Classes
- Objects
- Object sets
- Value sets
Hint: use A ::= INTEGER (0..200) instead of A INTEGER ::= {0..200} - Exception identifiers
- Encoding control sections
- Parameterisation
Encoding Rules
Required
One or more of the followings encoding rules are required:
- Distinguished Encoding Rules (DER)
- Octet Encoding Rules (OER)
- JSON Encoding Rules (JER)
For details about the encoding rules, see ASN.1 References.
Codec Library APIs
The ASN.1 Dynamic Profile considers two types of codec APIs: static and dynamic. With a static API, you compile a schema into data structures (also known as bindings). Once compiled, the schema and the data are statically linked, that is, they cannot be changed unless they are recompiled again. With a dynamic API, you can change a schema at runtime after compiling the application. The data structure becomes available when enumerating or identifying nodes and fields via tags or keys.
PUBLIC REFERENCES
[1] IP on Wi-Fi, ZigBee, and Bluetooth: opportunity and risk http://www.electronicproducts.com/Digital_ICs/Communications_Interface/IP_on_Wi_Fi_ZigBee_and_Bluetooth_opportunity_and_risk.aspx
[2] 5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/
[3] 11 Internet of Things (IoT) Protocols You Need to Know About http://www.rs-online.com/designspark/electronics/knowledge-item/eleven-internet-of-things-iot-protocols-you-need-to-know-about
[4] The Internet of Things: Five critical questions http://www.mckinsey.com/industries/high-tech/our-insights/the-internet-of-things-five-critical-questions
[5] Feature comparison for Protobuf, Cap'n Proto, SBE, FlatBuffers https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html
[6] Schema evolution in Avro, Protocol Buffers and Thrift https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
[7] “ASN.1 Complete” by professor John Larmouth
http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.html#larmouth
[8] ECMA-404 The JSON Data Interchange Standard http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
ASN.1 REFERENCES
- Recommendation ITU-T X.680. International Standard 8824-1. Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation
- Recommendation ITU-T X.682. International Standard 8824-3. Information technology – Abstract Syntax Notation One (ASN.1): Constraint specification
- Recommendation ITU-T X.690. International Standard 8825-1. Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
- Recommendation ITU-T X.696. Information technology – ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)
- JSON Encoding Rules (JER). https://www.oss.com/asn1/resources/asn1-papers/Overview of JER.pdf