BACnet encoding

[bachp]

BACnet uses ASN.1 to encode it's datastructures. It also defines an encoding that is similar but not the same as the standard BER encoding.

The following are the main difference I identified between the BACnet Encoding and BER:

• While BACnet also uses a TLV encoding simular to BER, it uses a different header:

|------|------|------|--------|------|------|------|------|
|   0  |   1  |  2   |   3    |   4  |  5   |  6   |    7 |
|------|------|------|--------|------|------|------|------|
|  Tag Number                 |Class |Length/Value/Type   |
|------|------|------|--------|------|------|------|------|

• Because of the above header, the class attribute can is only one bit. This means the standard only supports context and application tagging.
• A list off application specific datatypes is defined in the standard:

0 = Null
1 = Boolean
2 = Unsigned Integer
3 = Signed Integer (2's complement notation)
4 = Real (ANSI/IEEE-754 floating point)
5 = Double (ANSI/IEEE-754 double precision floating point)
6 = Octet String
7 = Character String
8 = Bit String
9 = Enumerated
10 = Date
11 = Time
12 = BACnetObjectIdentifier

These are used instead of the universal ones.

I see the following possible ways of implemementing this:

1. Add the encoding as an option to the current BER encoding, similart to CER and DER.
2. Add it as a completely new encoding alongside the current BER encoding.
3. Implement it in a spearate crate.

Currently I'm playing around with the code to see if option 1 or 2 is a better fit.

@XAMPPRocky I would like to get your opinion which option you think is preferable? Specifically I would like to know if you see the BACnet encoding as part of this repo, or if I should go with a separate one.

[XAMPPRocky]

Thank you for your issue! I am aware of BACnet through reading about ASN.1, though I never really looked much into it. I would be open to including BACnet as an encoding in the rasn crate, provided that the standard for the format is openly available for me to read and verify. It certainly seems to be used widely enough to merit being included.

On whether 1 or 2 would be preferable, I think as long 1 doesn't require unreasonable amount of changes, having it as an option might work, though it might be easier to define it as its own type, and just use the free functions in src/de/parser.rs for parsing.

[bachp]

I did some first trials and option 1, to add it to the existing BER encoder turned out the be not a good idea. So I went with option 2 and created a separate encoder.

I already managed to sucessfully encode Null and Bool. But now I'm not sure how to best move forward with signed and unsigned integers an real/float values

For the two integer types I decided to encode them both via encode_integer. This is fine as I can use the tag number to distingush them.

However I'm not sure what to do with the real. There is no encode_real yet. Should I add an encode_real to the encoder trait, or is there an other way how application tagged types should be encoded that don't correspond to any existing universal type?

[XAMPPRocky]

Well Real types should have {encode, decode}_real methods on Encoder and Decoder. I just haven't added it yet, because real types are the most difficult to understand and implement IMO. Another unresolved question is what would be the appropriate type to use in Rust for Real types, as I'm pretty sure (though could be wrong, see X.680) real types can be wider than f64. Help figuring out a good enough solution would be appreciated.