Re: [Cbor] [EXTERNAL] CBOR tag for RFC 3339 full-date values

[Carsten Bormann <[e-mail]>]

Hi Mike,

I don’t mind if the outcome of the discussion is as you propose, but I’d like to point out why I think the outcome I proposed is also valid.

> On 2020-03-11, at 23:10, Mike Jones <[e-mail]> wrote:
> 
> The point of having the tag is that the code knows what follows.  

Not quite: The code already knows "what follows” (what is the tag content) — it is *right there!*.
The tag allows the code to know that what follows is meant as a date.

In either outcome, the code will have to check that the tag content actually is the string that it expected.

So I don’t think there is much of an advantage to having different tags.
(There is a slight POLS violation that tag 0 and tag 1 are separate but there is only one tag for dates, in my preferred outcome, I have to concede.)

> If a polymorphic tag were used, in which two unrelated representations of dates are legal, then the code doesn't know what follows.  

(It still has to check the tag content.)

> And it also opens up questions that it would be cleaner to never have to consider - questions such as "If the polymorphic tag is adopted, must Mobile Driver's Licenses accept both representations?"  

The draft could be quite explicit that the answer is no (i.e., that it is the job of the application protocol to say which of the forms can be used).

> And "Will interoperability be harmed if some Mobile Driver's Licenses use one representation and some use the other?"  (The answer to that one is probably "Yes, interoperability will be harmed".)

That would indeed be a bad outcome, so I’d day don’t do that.

> Carsten, I take your point about both integers and floats being acceptable for tag 1.  But those are closely related (numeric) representations of the same thing.  Whereas a date string versus number of days relative to the Epoch are nearly unrelated representations, with fairly complicated conversion rules between them (involving leap years, leap centuries, leap 400th years, etc.).

(Which is maybe a reason to use the numeric form in the driver’s license, but I think that ship has sailed.  And you only need the 4-year component until 2100 :-))

> Given that Jörg stated below that he's OK with using different tags, I propose that we move forward with using tag 1004 (requested) for RFC 3339 full-date values and tag char('d') (requested) for integer number of days relative to the Epoch.  If I don't hear objections soon, I'll publish that draft.

In that case, we have two separate registrations and don’t have to merge the documents!
(It would still be nice if they referred to each other as complementary at some point.)
If we have tag 1004, we also can simplify 100 to be numeric only (and probably should do the same split for time-of-day later).

Grüße, Carsten


> 
> Jörg - I'll also add you as a co-author.  What affiliation and e-mail address for you should I use?  And is there a URL for a blog or Webpage you'd also like me to include for you?
> 
> 				Cheers,
> 				-- Mike
> 
> -----Original Message-----
> From: CBOR <[e-mail]> On Behalf Of Carsten Bormann
> Sent: Wednesday, March 11, 2020 2:09 PM
> To: "Richter, Jörg" <[e-mail]>
> Cc: [e-mail]; Mike Jones <Michael.Jones=[e-mail]>; Anthony Nadalin <[e-mail]>
> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values
> 
> On 2020-03-11, at 21:31, Richter, Jörg <[e-mail]> wrote:
>> 
>> (Replying to more than one message here)
>> 
>> Carsten Bormann: 
>>> Is that a good way forward?
>> 
>> I am fine with the suggested procedure. 
> 
> Great!
> 
>> 
>>> What I like about Mike’s draft is that he references RFC 3339, which 
>>> already is an established specification for how to write dates 
>>> textually
>> 
>> ISO 8601 also defines this format for dates. It is mentioned in the "Detailed Semantics" 
>> section of my proposal.
> 
> ISO 8601 is very “flexible”.  RFC 3339 uses ISO 8601, but helps by restricting this to commonly used cases.
> So I think referencing RFC 3339 is strictly better than just naked ISO 8601.
> 
>> Mike Jones:
>>> I'm fine merging Jörg's numeric date tag into my draft, provided that 
>>> the result is not a polymorphic tag, in which the value could be either a number or a string.
>>> We should allocate separate tags for string date and numeric date, 
>>> just as tags
>>> 0 and 1 are different, and not polymorphic.
>> 
>> I've got the impression that using a polymorphic tag would be no major problem.
>> We can even specify that decoders might only support one representation of the tag.
>> I think it would have the same effect if a decoder supports only one of the two tags.
>> But either way I would have no objections to using two tags.
> 
> I’m not sure I like the term “polymorphic” here too much — in any case, the “value” would be a date.  The content could be both text and number.  Tag 1 already does this (integer vs. floating-point), so we already have to deal with these (i.e., allow applications to not just say “Tag 1”, but “Tag 1 with integer content”).  But we did separate Tag 0 and Tag 1, mostly because the semantics of the value are subtly different.  Are they here?
> 
>> Laurence Lundblade:
>>> I’d suggest the numeric date be restricted to integers. No floats, 
>>> bignums, decimal fractions…
>> 
>> Yes, that was the plan. Only major types 0 and 1. 
> 
> Finer granularity between dates would be times, which we already have, so this naturally should be integers.
> 
>>> Fractions of days can be represented by tag 0 or tag 1 using hours, 
>>> minutes, seconds. 64-bit integer counts of days are large enough.
>> 
>> This I don't understand. The proposal only handles whole days as one number.
> 
> Right.  Only full days.  (The related observation is that these are always in the local time of some context that is not expressed, which is rather different from our time tags.)
> 
>> Another thing to consider:
>> We should mention that this tag(s) use the proleptic Gregorian 
>> calendar. So that dates before the Gregorian calendar have a unique semantics.
> 
> Good point.  In 7049bis, we just say:
> 
> Negative values (major type 1 and negative floating-point numbers) are interpreted as determined by the application requirements as there is no universal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this is particularly true for points in time that precede discontinuities in national calendars).  […]
> 
> That is less of a problem on the date-only side (as long as dates change on local midnight… and not noon), so we may be able to be more specific.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor