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

Carsten Bormann <cabo@tzi.org> Tue, 03 March 2020 22:59 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2D3A07B0 for <cbor@ietfa.amsl.com>; Tue, 3 Mar 2020 14:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IJbwlfvfxKa for <cbor@ietfa.amsl.com>; Tue, 3 Mar 2020 14:59:41 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF1D3A07D5 for <cbor@ietf.org>; Tue, 3 Mar 2020 14:59:41 -0800 (PST)
Received: from [172.16.42.113] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48XCBg2x6lz10sS; Tue, 3 Mar 2020 23:59:39 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CH2PR00MB0679818FABC93C37FF88A404F5E40@CH2PR00MB0679.namprd00.prod.outlook.com>
Date: Tue, 03 Mar 2020 23:59:38 +0100
Cc: "cbor@ietf.org" <cbor@ietf.org>, Anthony Nadalin <tonynad@microsoft.com>
X-Mao-Original-Outgoing-Id: 604969178.884051-1173c66b9890ad962f9de0b3ce62a587
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB18584F-BA25-464E-8DEC-217067D7643E@tzi.org>
References: <CH2PR00MB0679818FABC93C37FF88A404F5E40@CH2PR00MB0679.namprd00.prod.outlook.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/jSgUVkym81F3Tx0SXVVhWJ3bvV4>
Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2020 22:59:51 -0000

Hi Mike,

> On 2020-03-03, at 23:41, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> 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:
>                 Dates in this document use either date-time or full-date from RFC3339, unless otherwise indicated.

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

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