BACnet media type

[egekorkan]

In the BACnet binding, there is no usage of contentType in the examples so the default mechanism would apply and we would get JSON payloads. However, BACnet is not using JSON afaik. How should we handle this @fennibay ?

[fennibay]

I understand that the logical payload is always JSON-based. contentType defines the physical payload on the wire.

BACnet always uses the same ASN.1-based encoding on the wire. It is implemented in the available BACnet stacks.

So from BACnet POV there is not really a need for a contentType field.

But for the sake of completeness we could define one as a default in schema. I checked the media types on IANA, and I don't see anything for BACnet or ASN.1. So we would have to register one on IANA first.

There is application/bacnet-xdd+zip, but that one is not for BACnet data, but a special BACnet file format, used for exchanging device descriptions.

[egekorkan]

So from BACnet POV there is not really a need for a contentType field.

The issue is that if we don't define one, a TD process MUST automatically insert application/json (see here).

The contentType in a TD form doesn't have to be registered in IANA first (at least for now) so it should be fine to define one in the binding spec for now.

[fennibay]

Ok, so can we define it like this?

"contentType": "application/X-bacnet"

[danielpeintner]

Minor: I usually see lower-case content-types only...

Even though looking into https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1 states some vague statements like

The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on
the semantics of the parameter name.

[egekorkan]

I propose to use "application/bacnet-x" to be aligned with lowercase throughout and starting with bacnet since the other bacnet media type starts like that too. Ideally, something should be registered to IANA. Any thoughts @ektrah and @mjkoster ?