BACnet media type #357
Comments
|
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. |
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. |
|
Ok, so can we define it like this? "contentType": "application/X-bacnet" |
|
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
|
|
If a media type is strictly needed, registering one with IANA would be the right way to go. No "x-" prefix or similar should be used (see RFC 6648). The requirements and registration process for a media type are described in RFC 6838. So we would need to have at least a fully completed registration template. Ideally, there should also be a detailed specification of the media type itself. Overall, however, I'm not sure how much sense it makes to register the payload formats of all sorts of non-Internet protocols as Internet Media Types. When a TD consumer invokes an action using HTTP, it needs to know how to serialize the action parameters in the HTTP message body. To do this, the TD needs to specify a media type to use. In the case of CoAP, the TD consumer needs to serialize the data in a CoAP content format, which is more than just a media type. In the case of BACnet, the TD consumer always serializes the data according to the BACnet specification. This means that even though protocols and serialization formats can be considered orthogonal, I'd say the vocabulary to specify the serialization format to use is protocol specific. And for BACnet, no vocabulary is needed because it is always unambiguously clear. |
|
In other words, instead of this:
... I think we should be doing this:
Unlike a "HTTP driver", a "BACnet driver" already knows how to convert data to and from the BACnet payload format and does not need to reach out to an orthogonal data serializer. |
|
I agree that it is redundant information in the case of BACnet but not indicating a contentType can confuse some parsers which should assume JSON as the default for all protocols. This is an annoying limitation of the TD which we can get rid of but we would still need a value for the Regarding the images:
|
|
I understand And I think @ektrah @egekorkan and I agree that we don't need such an indication in BACnet-context. So the problem is reduced into: when the In practice this is not an issue, because no BACnet driver would try to send JSON over the wire. But we should be careful about the concept. Question: Where is the defaulting to JSON specified? I couldn't find it in the section on contentType. Solution ideas:
|
|
The default value for My preference for TD 2.0 would be for For TD 1.1, |
|
Agree on most points so far. BACnet can use octet-stream like Modbus for now and we can make this optional in the next version. There should be a note that explains that we are doing nothing new for BACnet drivers and they should do what they always did in terms of serialisation. Regarding making the term protocol specific: While I see the reasoning, I think if the concept is the same, we should have a single word across protocols. |
✨= new |
|
Thank you @ektrah for the detailed table 👍 I think I understand why one might want to have (need?) protocol-specific terms. However, this means that you can no longer make any statements about the data without knowing the protocol. I am myself not sure whether I want that to happen. |
|
As it is the case with node-wot, dart_wot implements the relevant parts of the Scripting API here, where the Therefore, the schema information is unfortunately not that universally usable, which made me think whether payload bindings should rather each define their own schemas for validation (so the current DataSchemas in the core TD specification would only apply to JSON). As a consequence, the |
Without specification it falls back to application/json, which is wrong Now it will default to application/octet-stream, which means arbitrary binary data BACnet media type #357
We had this problem also in BACnet. Simple example: JSON has only one integer type, and BACnet differentiates between signed and unsigned. Solution was to allow BACnet define its own data model under the protocol binding, see The |
|
I created now #390 to address this issue. |
|
fixed by #390 |
In the BACnet binding, there is no usage of
contentTypein 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 ?The text was updated successfully, but these errors were encountered: