I haven’t seen feedback on the below. I now merged PR #50, as this is a detail technical change with a good rationale. It is less clear to me that we should merge #43 or #53 without additional support. Both are editorial changes that we don’t have to make. If nobody cares for them, the document is as useful as a Standards-Track specification without them as with them. I plan to submit a new revision of the spec during the weekend, so feedback during this work week (AoE) would be appreciated. Grüße, Carsten > On 22. Jun 2023, at 17:22, Carsten Bormann <cabo@xxxxxxx> wrote: > > Sedate WG, > > 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: > > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-sedate-datetime-extended&url_2=https://ietf-wg-sedate.github.io/draft-ietf-sedate-datetime-extended/draft-ietf-sedate-datetime-extended.txt > > (Use https://is.gd/mvFIPV if your mail client chokes on this URI.) > > > There are three PRs still open [1]: > > > PR #53: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/53/files > This picks up John Klensin’s 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. > > We’d like to hear some feedback whether we should do that and whether we have hit the right words before we merge this. > > > 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). From a “design for decades” point of view, it seems obvious that we don’t 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’t 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. > > This is a technical change (even if a very compatible one), so we didn’t want to merge this without mentioning it here even if we think it is a no-brainer. > > > 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’t managed to merge now; none of this is strictly needed but we shouldn’t really pass on making such improvements. > > We would like to hear some comments after Justin Grant has updated the PR based on the current review. > > > Of course, we are asking all the last-call commenters to look at the outcome as well and indicate where we dropped the ball. > > In summary, a little more feedback from the WG would be good, and then we’ll generate an update for further consumption by the AD and then the IESG. > > Grüße, Carsten > > > [1]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pulls > [2]: https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/46 > > > >> On 2023-06-01, at 19:10, The IESG <iesg-secretary@xxxxxxxx> wrote: >> >> >> 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' >> <draft-ietf-sedate-datetime-extended-08.txt> as Proposed Standard >> >> 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@xxxxxxxx mailing lists by 2023-06-15. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
