From nobody Wed Jan 18 15:18:36 2023 Return-Path: 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 D8ED6C1522CC for ; Wed, 18 Jan 2023 15:18:34 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 aZR05DoYSPy3 for ; Wed, 18 Jan 2023 15:18:29 -0800 (PST) Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 39C69C1522CB for ; Wed, 18 Jan 2023 15:18:28 -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 4Ny1sG1Z6rzDCbn; Thu, 19 Jan 2023 00:18:26 +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 In-Reply-To: Date: Thu, 19 Jan 2023 00:18:25 +0100 Cc: Vadim Goncharov , cbor@ietf.org X-Mao-Original-Outgoing-Id: 695776705.7716-db28b7c3a905851e0eb59cfc9e778599 Content-Transfer-Encoding: quoted-printable Message-Id: References: <167345627851.15097.9738487459393843034@ietfa.amsl.com> <0B9B7A5E-D61E-4B97-9CE5-9A8AE7055F50@tzi.org> <20230117004326.5642c6ab@nuclight> <20230117204606.2b742f14@nuclight> <20230117220443.6c5054e7@nuclight> <5EFA83F3-7FD3-4B11-A23A-8D98E59542AB@tzi.org> To: Emile Cormier X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2023 23:18:34 -0000 > My only remaining concern at this point is whether there should be a = clause that says decoders may discard nested clock quality attributes = within the Uncertainty and Guarantee attributes. My decoder will discard = them regardless of what the RFC says, but I guess that doesn't matter to = anyone much while it remains closed-source. You can always pretend to not understand them =E2=80=94 they are = elective... (But we could make this more explicit.) > 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). Gr=C3=BC=C3=9Fe, Carsten