From cabo@tzi.org Tue Oct 17 12:49:53 2023 Return-Path: X-Original-To: sedate@ietfa.amsl.com Delivered-To: sedate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2DDC170607; Tue, 17 Oct 2023 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 LF8nc2liVWO3; Tue, 17 Oct 2023 12:49:48 -0700 (PDT) Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (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 D6BBEC15107C; Tue, 17 Oct 2023 12:49:44 -0700 (PDT) Received: from [192.168.217.124] (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (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 4S94Ls48J9zDCd0; Tue, 17 Oct 2023 21:49:41 +0200 (CEST) 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: <169754492241.50922.4898950343637250435@ietfa.amsl.com> Date: Tue, 17 Oct 2023 21:49:41 +0200 Cc: The IESG , draft-ietf-sedate-datetime-extended@ietf.org, sedate-chairs@ietf.org, sedate@ietf.org, Mark McFadden X-Mao-Original-Outgoing-Id: 719264981.080792-2bd75ace69add40a47d8cf6218186ae7 Content-Transfer-Encoding: quoted-printable Message-Id: <0BBAD1C9-AE32-4EAA-83E6-2A984B9DDBEA@tzi.org> References: <169754492241.50922.4898950343637250435@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Sedate] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-sedate-datetime-extended-10=3A_=28with_COMMENT=29?= X-BeenThere: sedate@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Serialising Extended Data About Times and Events List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2023 19:49:53 -0000 Hi =C3=89ric, thank you for this review. The changes mentioned below are in = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull= /59 Gr=C3=BC=C3=9Fe, Carsten > On 2023-10-17, at 14:15, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-sedate-datetime-extended-10: No Objection > [=E2=80=A6] >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > # COMMENTS >=20 > ## Section 1.2 (mostly nits) >=20 > The example of New York time would benefit of adding "in the USA" and = "in 2023" > (the latter would allow a better aging -- who knows ?). Added. > Should ICAO be expanded ? This is a quotation from RFC 3339. I added a reference after it, which carries the expansion. (The referenced document is unfortunately behind an ICAO paywall =E2=80=94= trying to avoid the obvious NATO reference [1] here.) [1]: = https://www.nato.int/nato_static_fl2014/assets/pdf/pdf_2018_01/20180111_na= to-alphabet-sign-signal.pdf > Should "San Francisco" be qualified as in "San Francisco, California" = ? The sentence would actually be true for San Francisco, Antioquia, which = has not observed DST since 1993 (or any other San Francisco), because = the politicians can still change the time zone, but I added this. > ## Backward compatibility >=20 > As I am not familiar with RFC 3339, I wonder whether the new syntax = could break > some legacy RFC 3339 implementations (including parsing libraries). Any use of the new features in IXDTF *must* cause RFC 3339 = implementations worth their salt to reject the string. IXDTF is not in general forward compatible(*) with respect to RFC 3339 = implementations (RFC 3339, as updated, is a proper subset of IXDTF). * Backward compatibility =3D old data, new system. * Forward compatibility =3D new data, old system. > Were there > some tests ? There is an implementer community that is watching, but I can=E2=80=99t = point to any specific tests. Do you think we need any? Gr=C3=BC=C3=9Fe, Carsten