Re: [Last-Call] Wrapping up: Last Call: <draft-ietf-sedate-datetime-extended-08.txt> (Date and Time on the Internet: Timestamps with additional information) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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’m a bit late for the I-D deadline now, so we can’t 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’s 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’m looking forward to a report from ECMA TC39 which is meeting this week.

Grüße, 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=draft-ietf-sedate-datetime-extended&url_2=https://ietf-wg-sedate.github.io/draft-ietf-sedate-datetime-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 <cabo@xxxxxxx> wrote:
> 
> 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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux