ASN.1 Dynamic Profile

OVERVIEW

GOALS

PROFILE

Modules

Types

Defaults and Optionality

Extensibility and Versioning

Constraints and Validation

Tags

Advanced ASN.1 features

Encoding Rules

Codec Library APIs

PUBLIC REFERENCES

ASN.1 REFERENCES

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:

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

Recommended

Prohibited

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

REAL

UTF8String

SEQUENCE

SEQUENCE OF

Is an array.

CHOICE

Recommended

      Age ::= INTEGER (0..127) (see Constraints and Validation)

Limit ::=SEQUENCE {

   version  Version OPTIONAL,

   v1       INTEGER (0..1000) OPTIONAL,

   ..., 

   [[2: v2  INTEGER (0..2000) OPTIONAL]],

   [[3: v3  INTEGER (0..3000) OPTIONAL]]

}

Prohibited

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 character sets. 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

SET OF        

SEQUENCE

SEQUENCE OF

Recommended 

It is recommended to use

Prohibited

It is prohibited to use

Example of a prohibited definition:
    Driver ::= SEQUENCE {
       
age  INTEGER, -- recommended to use a DEFAULT here
       addr SEQUENCE {
              street UTF8String,
              country UTF8String
       }
DEFAULT {   -- prohibited for a SEQUENCE type
              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

Prohibited

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, …).

SingleValue

 

Error ::= UTF8String ("Err")

CitySpeedLimit ::= INTEGER(40)

Applicable to scalar types.

ContentsConstraint,

CONTAINING,
ENCODED BY

Envelope ::= SEQUENCE {

  version INTEGER(0..255),

  msg OCTET STRING

     (CONTAINING MsgBody)

}

Applicable to OCTET STRING.

 

Can be used for enveloping a message (embedding, versioning).

InnerType

 

 

WITH COMPONENTS

WITH COMPONENT

PRESENT/ABSENT

Offers a number of alternatives to serialize REAL types using JSON.

Recommended

Prohibited

Prohibited constraint

Example

Notes

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)

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

Prohibited

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

Encoding Rules

Required

One or more of the followings encoding rules are required:

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