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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Carsten,

Thanks for the explanation.  I think that explanation is sufficient for me to clear my discuss, but I'm still not entirely convinced how the use of these new types is going to pan out.  There seem to be a lot of different ways of doing the encoding (both choice of tags, and encodings within a particular tag), and I would guess that that may mean that cbor libraries for different languages will choose different encodings, at least by default, and perhaps that is the right choice because then the sender doesn't lose any precision, but will potentially put the burden on receivers to understand and convert more time encodings (or for the application to select a subset of the extended time type that they support).

I think that this may allow more proliferation of different variants of the time encoding, but at least a generic decoder will be possible.

You also suggest that some applications may drop the tag because the type is already known.  But then I wonder whether a Java application wouldn't go further and just use an int64 to represent the time in msecs, i.e., to achieve a more compact representation.

So overall, I have some nagging concerns here, but I'm not an expert in how CBOR is being used/deployed and will defer to the authors/WG for their design choices.

Regards,
Rob


> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Thursday, October 26, 2023 9:22 AM
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; cbor-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-cbor-time-tag-11: (with
> DISCUSS and COMMENT)
> 
> 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