From nobody Wed Jul 12 06:17:10 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 E490FC151097; Wed, 12 Jul 2023 06:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.887 X-Spam-Level: X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=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 EuXk83Qr0rO1; Wed, 12 Jul 2023 06:17:04 -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 ECD9FC151087; Wed, 12 Jul 2023 06:17:01 -0700 (PDT) Received: from client-0227.vpn.uni-bremen.de (client-0227.vpn.uni-bremen.de [134.102.107.227]) (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 4R1JDT6K8tzDCg0; Wed, 12 Jul 2023 15:16:57 +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: <4E2FFF1C-C865-4D0B-AB0D-38A1C1E7C60E@tzi.org> Date: Wed, 12 Jul 2023 15:16:57 +0200 Cc: draft-ietf-sedate-datetime-extended@ietf.org, sedate-chairs@ietf.org, "Murray S. Kucherawy" , last-call@ietf.org X-Mao-Original-Outgoing-Id: 710860617.8523051-08fda8a2fd58cadebb8100a4be9d34ea Content-Transfer-Encoding: quoted-printable Message-Id: References: <168563945262.9013.365267588795978250@ietfa.amsl.com> <4E2FFF1C-C865-4D0B-AB0D-38A1C1E7C60E@tzi.org> To: sedate@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Sedate] [Last-Call] Wrapping up: Last Call: (Date and Time on the Internet: Timestamps with additional information) to Proposed Standard 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: Wed, 12 Jul 2023 13:17:09 -0000 I merged both PRs mentioned below, as there was no pushback and the = editors believe the changes proposed provide improvements. Thanks to all the commenters in the IETF last call and on the github = repository [0]. Obviously, I=E2=80=99m a bit late for the I-D deadline now, so we = can=E2=80=99t submit a -09 right away (unless we get special AD = approval). So, if you had comments or want to see where we are, please have a look = at the editor=E2=80=99s copy [1] and/or at the diff with revision -08 = [2] [3]. The authors believe this (once submitted) is now ready for continued = IESG processing. I=E2=80=99m looking forward to a report from ECMA TC39 which is meeting = this week. Gr=C3=BC=C3=9Fe, Carsten [0]: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended [1]: = https://ietf-wg-sedate.github.io/draft-ietf-sedate-datetime-extended/draft= -ietf-sedate-datetime-extended.html [2] = https://author-tools.ietf.org/api/iddiff?doc_1=3Ddraft-ietf-sedate-datetim= e-extended&url_2=3Dhttps://ietf-wg-sedate.github.io/draft-ietf-sedate-date= time-extended/draft-ietf-sedate-datetime-extended.txt [3] https://is.gd/mvFIPV (Shortened URL in case [2] is too much for your mail reader.) > On 2023-07-06, at 06:04, Carsten Bormann wrote: >=20 > I haven=E2=80=99t seen feedback on the below. >=20 > I now merged PR #50, as this is a detail technical change with a good = rationale. >=20 > It is less clear to me that we should merge #43 or #53 without = additional support. > Both are editorial changes that we don=E2=80=99t have to make. > If nobody cares for them, the document is as useful as a = Standards-Track specification without them as with them. >=20 > I plan to submit a new revision of the spec during the weekend, so = feedback during this work week (AoE) would be appreciated. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >> On 22. Jun 2023, at 17:22, Carsten Bormann wrote: >>=20 >> Sedate WG, >>=20 >> The editors have made a first round at processing the comments from = IETF last call. Most comments were editorial, so we tried to integrate = editorial changes to address them. The delta can be seen at: >>=20 >> = https://author-tools.ietf.org/api/iddiff?doc_1=3Ddraft-ietf-sedate-datetim= e-extended&url_2=3Dhttps://ietf-wg-sedate.github.io/draft-ietf-sedate-date= time-extended/draft-ietf-sedate-datetime-extended.txt >>=20 >> (Use https://is.gd/mvFIPV if your mail client chokes on this URI.) >>=20 >>=20 >> There are three PRs still open [1]: >>=20 >>=20 >> PR #53: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull= /53/files >> This picks up John Klensin=E2=80=99s idea to use Section 2 to provide = actual replacement text for Section 4.3 of RFC 3339, in addition to = describing in prose the what and why of the change. >>=20 >> We=E2=80=99d like to hear some feedback whether we should do that and = whether we have hit the right words before we merge this. >>=20 >>=20 >> PR #50: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull= /50/files >> This updates the ABNF to be more permissive about the length of = time-zone-parts. See discussion at [2] (and the mailing list discussion = referenced from there). =46rom a =E2=80=9Cdesign for decades=E2=80=9D = point of view, it seems obvious that we don=E2=80=99t want to enforce = the 14-character limit right from the ABNF grammar, in particular if we = know that this limit is based on a limitation of the UNIX V7 (!) file = system that hasn=E2=80=99t been technically relevant for at least a = couple of decades, and that there is at least one widely deployed = platform timezone database that has a longer time-zone-part. >>=20 >> This is a technical change (even if a very compatible one), so we = didn=E2=80=99t want to merge this without mentioning it here even if we = think it is a no-brainer. >>=20 >>=20 >> PR #43: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull= /43 >> This has a few older editorial improvements that we haven=E2=80=99t = managed to merge now; none of this is strictly needed but we shouldn=E2=80= =99t really pass on making such improvements. >>=20 >> We would like to hear some comments after Justin Grant has updated = the PR based on the current review. >>=20 >>=20 >> Of course, we are asking all the last-call commenters to look at the = outcome as well and indicate where we dropped the ball. >>=20 >> In summary, a little more feedback from the WG would be good, and = then we=E2=80=99ll generate an update for further consumption by the AD = and then the IESG. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> [1]: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull= s >> [2]: = https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issu= es/46 >>=20 >>=20 >>=20 >>> On 2023-06-01, at 19:10, The IESG wrote: >>>=20 >>>=20 >>> The IESG has received a request from the Serialising Extended Data = About >>> Times and Events WG (sedate) to consider the following document: - = 'Date and >>> Time on the Internet: Timestamps with additional information' >>> as Proposed Standard >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits final >>> comments on this action. Please send substantive comments to the >>> last-call@ietf.org mailing lists by 2023-06-15.=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call