Support for ANY in XER, [U]PER and JER

[djelenc]

Are you planning to add codec support for type ANY for codecs besides BER?

[eerimoq]

No immediate plans, but I can have a look at it tonight. Hopefully it's easy to implement and, if so, I can have an implementation completed fairly soon.

[djelenc]

Thank you for your quick response. I'm looking at the sources myself, and I also initially thought so too, but now I have doubts.

However, it is not the code-base of asn1tools that I have doubts about, it is the functioning of ANY that raises questions.

For instance, in other ASN.1 libraries that I’ve been using, namely asn1c and jASN1, the data that goes into the field of type ANY, gets first DER encoded and then the field contains the bytes that represent the DER encoding of that data. This happens regardless of the final encoding of the parent PDU.

My schema is the following. (The actual type definition of the value field is given in the parent PDU that holds a SEQUENCE OF Rating. So the receiver knows how to parse the values.)

Rating ::= SEQUENCE {
  source  Entity,
  target  Entity,
  service Service,
  date    BinaryTime,
  value   ANY
}

In those libraries, the value field is first DER encoded and then filled with the bytes obtained from the encoding. This happens regardless of what the Rating will eventually be encoded. So you can get unusual combinations. DER with PER, DER with XER, etc.

While I’m not sure what the standard says, I find it unusual, particularly in cases when the encoding is textual, for instance XER or JER. In those cases one may get a XML or a JSON that contains non-printable characters.

Intuitively, I’d say that the encoding of the type ANY has to match the encoding of its parent.

[eerimoq]

ANY was removed from the standard 1994 according to http://erlang.org/documentation/doc-5.2/lib/asn1-1.4/doc/html/asn1_ug.html#ANY. It's recommended to use an information object class instead. Information object classes are not yet part of asn1tools, and it's quite a lot of work to implement support for them.

I recommend using an OCTET STRING instead of ANY, and decode the OCTET STRING after decoding the outer structure (the inverse for encoding). An OCTET STRING is a sequence of bytes. OCTET STRING is supported by all codecs I believe.

[eerimoq]

I added ANY and ANY DEFINED BY to the list of known limitations. They will likely not be implemented as they were removed from the standard 1994.

[djelenc]

Thank you for your comments. I think the best approach for my case is to simply use the OCTET STRING as you suggest.