Re: [core] Roman Danyliw's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Roman,

Francesca reminded me never replied to your comments.
Sorry about that.

> On 2021-09-18, at 21:15, Roman Danyliw via Datatracker <[e-mail]> wrote:
[…]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Is there any generic guidance to provide on expected error handling behavior if:
> 
> -- ct (or bct) contains a number outside of the 0-65535 range, or an
> unregistered value per the CoAP Content-Formats?
> 
> -- ct (or bct) contains a text value that is not a registered
> Content-Format-String?
> 
> -- ct (or bct) contains a valid Content-Format-String, but an unregistered 
> Content-Format?
> 
> Or is this application specific?

Based on the discussion at the CoRE Virtual interim - 2021-10-13 [1], in -06 we actually decided to answer the question you didn’t ask, and added a subsection [2]:
 
+## Evolution
+
+As with SenML in general, there is no expectation that the creator of
+a SenML pack knows (or has negotiated with) the consumer of that pack,
+which may be very remote in space and particularly in time.
+This means that the SenML creator has no way to know whether the
+consumer knows:
+
+- each specific media-type name used
+- each parameter and each parameter value used
+- each content-coding in use
+- each content-format number in use for a combination of these
+
+What SenML, as well as the new fields defined here, guarantees is that
+a recipient implementation *knows* when it needs to be updated to
+understand these field values and the values controlled by them;
+registries are used to evolve these name spaces in a controlled way.
+SenML packs can be processed by a consumer while not understanding all
+the information in them, and information can generally be preserved in
+this processing such that it is useful for further consumers.

I hope this, indirectly, does answer your question, as evolution can make it look like a creator used unregistered values (that the consumer just hasn’t heard about yet), and that needs to be handled exactly the same way.

(The content-format being out of range is the only error that can be reliably detected by a consumer the writer of which didn’t have a crystal ball.
I think at some point we’ll write an informative document about SenML best practices, and that will also contain some hints about error handling.
But putting this here would be going outside the scope of the specification of this single pair of fields.)

Grüße, Carsten

[1]: https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-202110131600/
[2]: https://github.com/core-wg/senml-data-ct/commit/0a57952 and
https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-06.html#name-evolution