Does OSS ASN.1 Tools implement OER fully?

OSS ASN.1 Tools for C, C++ and Java implement the NTCIP 1102:2004 standard fully. Below you can find details on how the OSS ASN.1 Tools deal with ASN.1 types that are either not defined or ambiguously defined by the NTCIP standard.

• Encoding/Decoding of ASN.1 types that are not defined in the NTCIP 1102:2004 standard:
  • The EXTERNAL type is encoded as a SEQUENCE specified in the ITU-T Recommendation X.690 (11/2008) clause 8.18. It includes fields carrying semantics of the embedded data. NOTE: new specifications should use "EMBEDDED PDV" instead of EXTERNAL.
  • Open Type and ANY are encoded as OCTET STRING.
  • GeneralizedTime, UTCTime, ObjectDescriptor are encoded as the corresponding ASN.1 string types specified in the ITU-T Recommendation X.680 (11/2008), clauses 46-48.
  • TIME, DATE, TIME-OF-DAY, DATE-TIME, DURATION (ISO 8601 time types) are encoded as restricted character string (UTF8String) containing the corresponding value notation, e.g. "P29M0DT0.00M".
  • RELATIVE-OID is encoded similarly to OBJECT IDENTIFIER, but the content octets are constructed according to the ITU-T Recommendation X.690 (11/2008) clause 8.20.
  • OID-IRI and RELATIVE-OID-IRI are encoded as character strings (UTF8String) restricted by the ITU-T Recommendation X.690 (11/2008) clauses 8.21 and 8.22.
• For ASN.1 types that the NTCIP 1102:2004 specifies the encoding procedure ambiguously, the following implementation decisions have been made:
  • For a nested untagged CHOICE encoding, the definition "IDENTIFIER OCTETS of the selected type" in the clause 2.3.12.2 of NTCIP 1102:2004 is interpreted as "the outermost identifier octets" of the selected type rather than "textually present identifier (tag) of the selected alternative". Hence, if the currently selected alternative is an untagged CHOICE, the first field of the CONTENT OCTETS of the CHOICE is the identifier of the selected type of that nested untagged CHOICE;
  • For extensible CHOICEs where the extension alternative is selected, the second field of the CONTENT OCTETS is the OER encoding of the selected type, prefixed by the length of this encoding (which is similar to the encoding procedure of an extension field in a SEQUENCE);
  • When the SET type is extensible, the encoding procedure specified by the NTCIP 1102:2004 leads to ambiguous result. For this reason the implementation has replaced this procedure and codes the SET types as if it would be a SEQUENCE where the components of the SET are sorted in the canonical order of their tags, as specified by the ITU-T Recommendation X.691 (11/2008), clause 21.
  • For BIT STRING with named bits, whose size is constrained to the fixed value, the encoder may pad or truncate non-significant trailing zero bits to satisfy this size constraint.
  • IA5String, VisibleString, ISO646String, PrintableString, NumericString, BMPString, and UniversalString character strings which are constrained to a fixed size are encoded without the length octets (similar to BIT STRINGs and OCTET STRINGs).
  • Encoding of special REAL values (PLUS-INFINITY, MINUS-INFINITY, NOT-A-NUMBER) and minus zero is not specified by NTCIP 1102:2004. These values are encoded as ASCII strings "PLUS-INFINITY", "MINUS-INFINITY", "NOT-A-NUMBER", and "-0" respectively.

---

The samples included with some of the Knowledge Center answers are meant for your general understanding of the OSS products. Different versions of the products might produce slightly different outputs. Consult the products documentation and samples for the most up-to-date products information and code examples.