Re: [Cbor] I-D Action: draft-ietf-cbor-time-tag-04.txt

Carsten Bormann <cabo@tzi.org> Thu, 19 January 2023 21:12 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 64FF6C15154F for <cbor@ietfa.amsl.com>; Thu, 19 Jan 2023 13:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqmUpfDyFByQ for <cbor@ietfa.amsl.com>; Thu, 19 Jan 2023 13:12:43 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4C0C14F74A for <cbor@ietf.org>; Thu, 19 Jan 2023 13:12:43 -0800 (PST)
Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Nyb1k0KvHzDCcC; Thu, 19 Jan 2023 22:12:42 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20230119222753.7c3744b7@nuclight>
Date: Thu, 19 Jan 2023 22:12:41 +0100
Cc: Emile Cormier <emile.cormier.jr@gmail.com>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 695855561.503953-7888dee09495c3d110d3e6f268275804
Content-Transfer-Encoding: quoted-printable
Message-Id: <527266CA-AD27-4ACA-B8E7-8E3BCC1DD89F@tzi.org>
References: <167345627851.15097.9738487459393843034@ietfa.amsl.com> <CAM70yxD2Z52JsJ=XHFFrJWFuAEG5oHv-B8gf6zRYVK4fhpDpeQ@mail.gmail.com> <0B9B7A5E-D61E-4B97-9CE5-9A8AE7055F50@tzi.org> <20230117004326.5642c6ab@nuclight> <CAM70yxAs=9S-H6ve2HfDf5W=f4cKGZ3B=AXJV==vm26ERs9-mg@mail.gmail.com> <20230117204606.2b742f14@nuclight> <CAM70yxAeLGmiPyidn1zc64rjRcKNHp7hSUt+d6veH-AqguObkw@mail.gmail.com> <20230117220443.6c5054e7@nuclight> <CAM70yxBbNtn0D91tZ1mSY3Cg-MMVnpaCodius5MWH-wEjQHu-g@mail.gmail.com> <5EFA83F3-7FD3-4B11-A23A-8D98E59542AB@tzi.org> <CAM70yxCm7PV9bD5Wf=rJpVHKrTpZ+kRyHWW+_E5vQF9s6BYusg@mail.gmail.com> <C10ACFB0-9C44-4B17-A18E-BAE367984065@tzi.org> <20230119222753.7c3744b7@nuclight>
To: Vadim Goncharov <vadimnuclight@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/k6GTrTcW7lCO6o1EK9EyzmSmQR0>
Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-time-tag-04.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 19 Jan 2023 21:12:47 -0000

On 2023-01-19, at 20:27, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
> 
> On Thu, 19 Jan 2023 00:18:25 +0100
> Carsten Bormann <cabo@tzi.org> wrote:
> 
>>> What about the ability to encode a local time having an unspecified
>>> time zone? The C++ std::chrono::local_time duration is computed
>>> from the date time of day the same way as std::chrono::sys_time
>>> (POSIX), except that the time zone is unspecified instead of UTC.
>>> All that would be needed is a "Local" time scale to be added to the
>>> time scale registry. I already understand that you want to launch
>>> the time tag RFC with only the UTC and TAI time scales for now.  
>> 
>> As was discussed over in SEDATE as well, there even are some noises
>> that NTPv5 might adopt such a locally defined time scale (naysayers
>> notwithstanding that argue that NTP can only be used internet-wide
>> where such a locally defined time scale would not apply).
> 
> Sounds like not a very good idea…

That opinion depends a lot on perspectives.
If your job is to make NTP appliances that are used in intranets your perspective will be different from someone who tries to maintain pool.ntp.org.

> BTW, do they have changes in format
> to suport e.g. decimal?

they = NTP?
That certainly will stay binary.

> And what/where is SEDATE ?

WG charter:
https://datatracker.ietf.org/wg/sedate/about/

This is about adding extensibility to RFC 3339 date/time timestamps (the Internet profile of ISO 8601).

Let me cite:
>> Particularly when using times for interval, recurrence, or offset calculations,
>> it is necessary to know the context in which the timepoint exists. It would be
>> valuable to have a standard text serialisation format for this contextual data.
>> This working group will develop and publish a format meeting that requirement,
>> subject to the additional constraints described below.

Current draft:
https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html
Just finished WGLC.

Example of another SDO we are cooperating with on this:
https://tc39.es/proposal-temporal/
https://tc39.es/proposal-temporal/docs/

Grüße, Carsten