Subject: [core] Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 21 Sep 2021 01:38:47 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-core-senml-data-ct-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.

I have to confess that I am less convinced of the need to have two ways to
represent this information, i.e., to also support Content-Format-Strings as
opposed to always requiring a entry in the CoAP Content-Formats registry.  The
CoAP Content-Formats registry seems to be of reasonable size and have a lot of
space available for FCFS allocations which would mean that it should be quite
easy to extend if required.  However, I'm willing to defer to the authors &
CORE WG expertise here supporting both ways are needed/useful.

Regards,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Sep 2021 08:53:46 +0200

Hi Rob,

thank you for pointing out this concern.

Indeed, we actually have an outstanding project to automatically register a Content-Format number for every one of the couple-thousand media-type registration out there (this is mostly stalled on practical issues around how to ensure this is then done for new registrations as well).

However, a Content-Type is not just a media-type name, but also potentially parameters, and content-codings.
Some media-types have a few parameters that can only take a few values, so it would be possible to register content-format numbers for each combination.

text/plain; charset=utf-8 (Content-Format number 0) is the first example where this is breaking down a bit:
We clearly do not want to register the cross-product of media-type names that happen to have charset parameters with the registered charset names, in particular as UTF-8 is the only reasonable value for an interchange format like SenML that targets long-lived applications.

It then gets ugly quickly with actually variable parameters such as sampling rate, source coding parameters etc.

The cross-product consideration also applies to content-coding — more so as new content-codings (beyond the widely used, but ageing, deflate) are becoming more widely used.
It is also quite likely that a SenML processor wants to add a content-coding that has not been on the original sensor data.

So we think there is no way to ensure that content-format numbers are available for all records in a SenML pack, and we need the flexibility to fall back to a content-format-spec.

Grüße, Carsten

---

From: Michelle Cotton <[email-masked]>
Date: Wed, 29 Sep 2021 17:49:14 +0000

Hello Carsten,

Just double checking regarding this comment below:

    Indeed, we actually have an outstanding project to automatically register a Content-Format number for every one of the couple-thousand media-type 
    registration out there (this   is mostly stalled on practical issues around how to ensure this is then done for new registrations as well).

Does this mean IANA "automatically" registering something?  Can you please clarify about this project?

Thank you,

Michelle

************
Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

On 9/28/21, 11:54 PM, "iesg on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Rob,

    Grüße, Carsten