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

+1

Tag number 1 seems useful for just much human activity to me. For example time stamps files, messages, documents, log entries and such. I think it would be useful to say this and to say that this time format is for special use cases like scientific measurements. It can be stated tersely in the abstract and with a little more detail in the intro.

I’m kind of a fan of the most direct statements in the abstract. Something like:

This defines an alternate CBOR time tag that provides higher resolution and range that CBOR time tag number 1 for special use cases (CBOR tag number 1 remains useful and recommended for most time use cases).

(Anyone reading this will know what CBOR and its design goals are so they don’t need to be restated in the abstract)

Also, here’s a time tag implementation FAQ I wrote some time ago: https://github.com/laurencelundblade/QCBOR/blob/master/doc/TimeTag1FAQ.md
Maybe this level of detail is not necessary in standards docs, but I think it is helpful for the average IT person that just squeaked through their college degree to figure out what to do.

LL

On Oct 25, 2023, at 3:31 AM, Robert Wilton via Datatracker <noreply@ietf.org> wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-cbor-time-tag-11: Discuss

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/about/groups/iesg/statements/handling-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-cbor-time-tag/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document, I have a few "discuss" level comments:

Moderate level comments:

(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.

(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?

(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,
and if so should they be listed and what should a receiver do if they receive
them?  Or is the only rational choice here that is has to be down to the
application to decide how to handle this case?  Either way, is any additional
text needed here?

----------------------------------------------------------------------
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.

Regards,
Rob

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor