can we pass user defined content type/format using flag COAP_OPTION_CONTENT_FORMAT

[safwansada]

Hello Team,

We are currently using libcoap in our project and have encountered a scenario where we would like to utilize the PUT method from the client-side while specifying a custom content format in the CoAP headers using the COAP_OPTION_CONTENT_FORMAT option.

It would be beneficial if libcoap allowed for user-defined content formats, such as application/x.myapp.api.Add.v0.1.0+json, in addition to the standard IANA registered media types.

Enhancement Request:
Feature: Allow the use of user-defined content formats in the COAP_OPTION_CONTENT_FORMAT option.
Use Case: We aim to define and use content formats specific to our application’s API, like application/x.myapp.api.Add.v0.1.0+json, for structured data exchange in CoAP messages.

Impact: This feature would provide greater flexibility for developers to specify and use custom content types based on the version and type, enhancing the ability to support application-specific APIs within CoAP communication.

Thank you for considering this request. We believe this feature would significantly improve the adaptability of libcoap for custom application protocols.

[mrdeep1]

Content-Format is an integer value when held in a CoAP Message in the Content-Format CoAP Option. It is up to the transmitter of the request response message generator as to what integer value is used, and up to the message receiver to get the integer option and use it for the appropriate purpose.

The currently defined set of known (IANA registered) content-formats can be found at CoAP Content Type.

While the whole set of integer values (as defined by IANA) can be used by libcoap for message transmission / receipt, only a subset of the names are printed out by the libcoap debug in print_content_format() logic - else the integer value gets printed out.

libcoap does not care if you use an un-assigned integer value. So, you can locally define things like application/x.myapp.api.Add.v0.1.0+json with an associated integer value and pass the integer value back and forth. The applications running at both ends of the session just need to know what action they should be taking.

There is nothing to stop you to use a locally defined COAP_MEDIA_TYPE_* (that does not clash with any of the IANA definition integer values) for your particular application requirements.

coap_add_data_large_response() already gives you the ability to define media_type, which is the Content-Format type (as an integer).

coap_add_data_large_request() does not have this ability, but as you need to define the PDU to send (with any options), there is no reason as to why you cannot add a Content-Format CoAP Option (using something like coap_insert_optlist()) to the PDU before it gets sent. See coap_pdu_setup(3), in particular the first Example where COAP_OPTON_OBSERVE is added in (you would be using COAP_OPTION_CONTENT_FORMAT).