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

[Robert Wilton via Datatracker <[e-mail]>]

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