Re: [core-parameters] Content-Format for application/sdf+json

[Esko Dijk <[e-mail]>]

> Another application that is becoming more common is to use a content-format number in places like COSE’s “content type” (3) header parameter (RFC 9052) or in formats such as RFC 8710 or RFC 9193, or via Section 4.3 of RFC 9277.

That's good to know! Agreed.

> Right — it wouldn’t hurt to earmark a number,
Earmarking 434 - right next to the competing "Thing" formats from W3C!

Thought: should the SDF draft also have a reference to the W3C thing variant (https://www.w3.org/TR/wot-thing-description11/) and point out the differences?

Esko

-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: Monday, March 11, 2024 13:35
To: Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: Re: [core-parameters] Content-Format for application/sdf+json

Hi Esko,


On 2024-03-11, at 12:00, Esko Dijk <[e-mail]> wrote:
> Maybe the draft could hint how this format is going to be used over CoAP? E.g. a future IoT device can host its own sdfThing description; or an action resource could have an associated sdfAction description hosted.

That is certainly possible, but SDF wasn’t really designed to be particularly good for this application.  Another application that is becoming more common is to use a content-format number in places like COSE’s “content type” (3) header parameter (RFC 9052) or in formats such as RFC 8710 or RFC 9193, or via Section 4.3 of RFC 9277.

More generally speaking, the availability of a content-format number for an IoT-related format is increasingly taken for granted — they also don’t cost much (at least the 2-byte variant), so we are registering these now as a matter of course.

> The registration looks good - allocation should be handled in the upcoming IANA review of the draft I think.

Right — it wouldn’t hurt to earmark a number, but it isn’t particularly needed at this point.

Grüße, Carsten