Re: [Cbor] Robert Wilton's Discuss on draft-ietf-cbor-time-tag-11: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Rob,

thank you for this feedback!

> On 2023-10-25, at 12:31, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-cbor-time-tag-11: Discuss
> […]
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Thanks for this document, I have a few "discuss" level comments:
> 
> Moderate level comments:

I think that this discussion could lead to quite different conclusions based on different perspectives on how tags like these will be used.
I think that most people in the CBOR WG see these new tags as building blocks that do not constitute a complete application protocol by themselves (e.g., we are not defining a media type here), but that are used as components of actual application protocols.
This means that much of the onus of discussing the below questions rests with those application protocols.

> (1) p 0, sec
> 
>   The Concise Binary Object Representation (CBOR, RFC 8949) is a data
>   format whose design goals include the possibility of extremely small
>   code size, fairly small message size, and extensibility without the
>   need for version negotiation.
> 
> My main concern here is the risk that introducing these new time encodings
> could end reducing interoperability.  My initial reading is that these new
> types are more flexible, contain more information, and hence require more code
> to parse and understand than say the tag 1 type, and hence may not be so widely
> understood and used by implementations.  Hence, please can the authors consider
> whether there should be a recommendation to use time type 1 in preference, and
> only use the extended time types where required?  Or conversely, encourage
> everyone to move to a particular variant of the new extended time type.

Tag 1 is fine for its intended purpose, and we are not changing anything about this (except maybe relieving the pressure that Tag 1 should have been defined to accept Tag 4 or Tag 5 numbers, which 1001 now does).

We could define a 1001 with just map key 1 as equivalent in general to Tag 1 and declare this as the preferred representation.

But it really should be the application protocol that decides this.
Many application protocols will uses an “unwrapped” form of this (without a tag, because that would be redundant with context information already available), and then possibly also integrate the unwrapped form of tag 1:

unwrapped-time = ~Etime / ~time
my-application-struct = {
  4711: unwrapped-time
  …: …
}

> (2)
> Related to my previous comment, I have a question about normalization or
> canonicalization.  The new extended time type allows the same time to be
> represented in multiple different ways (e.g., int, binary float, decimal float,
> split secs + fraction).  Does any guidance need to be given if canonicalization
> is required?

Again, this really should be defined in the application protocol; preferred/deterministic representation requirements can be very application specific.
E.g., a protocol that essentially represents UNIX (Posix) timestamps might prescribe that keys 1 (seconds, with an integer value) and -9 (nanoseconds) are always used, but no other keys.  These data items can then be processed by any generic extended time implementation, but also by one very specifically targeted for this application protocol.

> (3) p 12, sec 4.  Duration Format
> 
>   Semantically, they do not measure the time elapsed from a given
>   epoch, but from the start to the end of (an otherwise unspecified)
>   interval of time.
> 
> Are any of the fields defined in etime-detailed not appropriate for a duration,

In my response to Erik Kline’s COMMENT in
<https://mailarchive.ietf.org/arch/msg/cbor/RrZOgsy1iapx6W-H1uaw5zR-U1U>, I wrote about Duration:

>> Indeed, not all combinations of (possibly even nested) keys make a lot of sense (e.g., an uncertainty for an uncertainty, see the note in Section 3.5.4).  I wouldn’t know what to do with a critical Time Zone Hint, unless there is context that supplies an epoch.
>> 
>> I don’t think we could provide exhaustive rules that would define which combinations make sense, in particular with new map keys being assigned in an open registry.

> and if so should they be listed

(I don’t think we can say that in general)

> and what should a receiver do if they receive
> them?

(The example of a critical Time Zone Hint on a Duration would make me reject the Duration, unless there is context that is intended to supply an epoch, which would again something that an application protocol would define.)

I don’t think we could provide exhaustive rules that would define which combinations make sense, in particular with new map keys being assigned in an open registry.

> Or is the only rational choice here that is has to be down to the
> application to decide how to handle this case?  

I think this is indeed the case.

> Either way, is any additional
> text needed here?

A need for this probably didn’t occur to us as we see tags like 1001 to 1003 as building blocks that are used by applications, not applications by themselves.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Minor level comments:
> 
> (4) p 13, sec 5.  Period Format
> 
>   Period = #6.1003([
>     start: ~Etime / null
>     end: ~Etime / null
>     ? duration: ~Duration / null
>   ])
>   If the third array element is not given, the duration element is
>   null.  Exactly two out of the three elements must be non-null, this
>   can be somewhat verbosely expressed in CDDL as:
> 
> I found it harder (but not impossible) to understanding the intended encoding
> here.  Also, rather than allowing duration to be null, or missing (i.e., len 2
> array), would it better to choose just one of these encodings, or otherwise do
> you need to consider canonicalization of start/end periods?
> 
> Perhaps splitting this into two paragraphs would be easier to read/explain. 
> E.g.,
> 
>  A period can be represented by a start and end time, in which case it is
>  represented as an array of two elements.
> 
>  Alternatively, a period can be represented as a start time with duration or
>  an end time with duration.  This is represented as an array of 3 elements
>  where either the start or end time MUST be set to null.

That is a slight simplification that I personally like.

I edited this a bit further; it is now:
https://github.com/cbor-wg/time-tag/pull/25

This is a slight technical change as the third element no longer can be null, but I count that as an improvement (one less variant to interop-test).

Grüße, Carsten