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

From: Mike Jones <[email-masked]>
Date: Tue, 3 Mar 2020 22:41:52 +0000

The working group ISO/IEC JTC 001/SC 17 "Cards and security devices for personal identification" would like to have a CBOR tag allocated to identify RFC 3339 full-date values (which are defined at https://tools.ietf.org/html/rfc3339#section-5.6).  This is needed for use by the ISO Mobile Driver's License specification, which contains this normative text:
                Dates in this document use either date-time or full-date from RFC3339, unless otherwise indicated.

While there's already tag 0 for date-time (which is defined at https://tools.ietf.org/html/rfc7049#section-2.4.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7049%23section-2.4.1&data=04%7C01%7Ctonynad%40microsoft.com%7C079c082880ba4b18361408d7bfc0dbdb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637188707355658777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=5A5ATBiPNrfCd23LfGImn00GlAAaWiA89eu6MOWiYMg%3D&reserved=0>), there's currently no tag allocated for full-date.

Is the best way to allocate this tag to create an Internet Draft and submit it to the CBOR working group or would you suggest another course to accomplish this?

                                                                Thanks,
                                                                -- Mike

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Mar 2020 23:59:38 +0100

Hi Mike,

> On 2020-03-03, at 23:41, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> The working group ISO/IEC JTC 001/SC 17 "Cards and security devices for personal identification" would like to have a CBOR tag allocated to identify RFC 3339 full-date values (which are defined athttps://tools.ietf.org/html/rfc3339#section-5.6).  

I presume you are thinking about the full-date production there?
(Note that this cannot store time zone information, which may be of interest even for dates in certain cases.)

> This is needed for use by the ISO Mobile Driver’s License specification, which contains this normative text:

Right.
 
> While there’s already tag 0 for date-time (which is defined at https://tools.ietf.org/html/rfc7049#section-2.4.1), there’s currently no tag allocated for full-date.
>  

Creating an I-D is definitely a good idea.  We don’t necessarily need to wait for that to be published before registering the tag: the registry has various levels, from standards action via specification required up to FCFS.  One question that may need to be answered is how constrained the space is for these data; if there is no particularly pressing situation, we would go for the 1+2 space (where also the extended time tag described in draft-bormann-cbor-time-tag was allocated).
[This is also registered, but not published — at some point we probably want to roll up a number of these and publish an RFC for them.]

The need for a date (not time) tag has come up before; I just can’t remember where.

Grüße, Carsten

---

From: Richter, Jörg <[email-masked]>
Date: Wed, 4 Mar 2020 07:42:56 +0000

Hi,

> The need for a date (not time) tag has come up before; I just can’t remember where.

One year ago I sent a proposal für a date tag [1].
So far it has not made it into the overview of the assigned CBOR-tags [2].

I would very much appreciate if the suggested tag number is used for the date-tag, since we already use it internally.

What is missing for the suggested tag numbers to be assigned? Btw. I have another proposal for currencies and money amounts at [3] whose tags were not assigned either.

- Jörg

[1] https://j-richter.github.io/CBOR/date.html
[2] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
[3] https://j-richter.github.io/CBOR/currency.html

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Mar 2020 16:25:11 +0100

Hi Joerg,

I’m sorry we didn’t handle your requests properly.
Let’s try to fix this now.

> On 2020-03-04, at 08:42, Richter, Jörg <[email-masked]> wrote:
> 
> Hi,
> 

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.  For that half of the proposal, I don’t think there is a technical difference with your proposal (except that Mike suggested a different tag number).  Beyond Mike’s draft, we would need to decide that we like to use the same tag with an epoch-based numeric date.  I think this is OK; it just requires users of the tag to specify which of the internal structures (or both) they would accept.  Note that we are running into the same issue with tag 1 (as used in EAT in the RATS WG), so that may help accepting that this is a normal thing to so.

> What is missing for the suggested tag numbers to be assigned?

I think we just have to make the decision to spend the 1+1 (short) tag.
That becomes somewhat easier with including the numeric date, because that is indeed quite compact and merits a short tag.

> Btw. I have another proposal for currencies and money amounts at [3] whose tags were not assigned either.

Let’s get to that, too, right after we are done with the date tag.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Mar 2020 17:50:38 +0100

Hi Joerg, Mike,

we discussed the date tag proposals at the CBOR interim today.
The meeting consensus was that we should merge the date tag part of Joerg’s specification (i.e., both textual and numeric date references) with Mike’s draft, and spend a 1+1 tag (which would indeed conveniently be tag 100 = ‘d’).

I would like to work with the two of you to generate a -01 of Mike’s draft with text from Joerg, for discussion on May 25th (or whatever replacement we find for the physical IETF107 meeting.)

(We would look at time-of-day and timezone right after registering the date tag from -01; maybe in a -02.  My personal view would be that the time-of-day tag from Joerg would go right in, but we might want to go for a 1+2 tag for timezone [29818 for ’tz’ maybe?].  But let’s discuss this when we are there.)

Is that a good way forward?

Grüße, Carsten

> On 2020-03-11, at 16:25, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Joerg,
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Mar 2020 16:57:06 +0000

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.

If this works for everyone, I'll add the numeric date tag with proposed value 'd' into my draft.

				-- Mike

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
Sent: Wednesday, March 11, 2020 9:51 AM
To: "Richter, Jörg" <[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>
Cc: [email-masked]; Anthony Nadalin <[email-masked]>
Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values

Hi Joerg, Mike,

Grüße, Carsten

>> [3] https://j-richter.github.io/CBOR/currency.html

_______________________________________________
CBOR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cbor

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 11 Mar 2020 11:56:51 -0700

I’d suggest the numeric date be restricted to integers. No floats, bignums, decimal fractions… 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.

LL

> On Mar 11, 2020, at 9:57 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
>

---

From: Richter, Jörg <[email-masked]>
Date: Wed, 11 Mar 2020 20:31:46 +0000

(Replying to more than one message here)

> Is that a good way forward?

I am fine with the suggested procedure. 

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

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.

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. 

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

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.

- Jörg

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Mar 2020 22:09:17 +0100

> I am fine with the suggested procedure. 

Great!

> ISO 8601 also defines this format for dates. It is mentioned in the "Detailed Semantics" 

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.

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

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

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

> 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

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Mar 2020 22:10:58 +0000

The point of having the tag is that the code knows what follows.  If a polymorphic tag were used, in which two unrelated representations of dates are legal, then the code doesn't know what follows.  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?"  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".)

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

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.

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 <[email-masked]> On Behalf Of Carsten Bormann
Sent: Wednesday, March 11, 2020 2:09 PM
To: "Richter, Jörg" <[email-masked]>
Cc: [email-masked]; Mike Jones <Michael.Jones=[email-masked]>; Anthony Nadalin <[email-masked]>
Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values

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
> 

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

> Laurence Lundblade:
>> I’d suggest the numeric date be restricted to integers. No floats, 
>> bignums, decimal fractions…
> 

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

> We should mention that this tag(s) use the proleptic Gregorian 
> calendar. So that dates before the Gregorian calendar have a unique semantics.

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).  […]

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Mar 2020 00:44:40 +0100

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 <[email-masked]> 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 numbe…

(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 i…

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

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 11 Mar 2020 19:03:28 -0700

> On Mar 11, 2020, at 2:09 PM, Carsten Bormann <[email-masked]> wrote:
> 

Right. If you wish to represent a fraction of a day (which is a time), don’t use this tag. Use tag 0 or tag 1 that already exists to represent a time. This tag doesn’t need to handle it. Same with distant future or past.

LL