On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh Jethanandani wrote: > Hi Jürgen, > > It appears that Brian and you had made progress on the other thread related > to IPv6 zone definition. Are there any outstanding issues that need to be > resolved? > > What is the plan to submit an updated version of the document? >
I had to take a fresh look at things and I think the discussion around zones of IP addresses is moving to a conclusion. That said, I believe we are not done with the work related to dates, times, and durations. What we have is not really good and also in conflict with newer work that came out of the sedate WG and has passed IESG approval (I think). Here is a not so short summary (I have even more details since I did take a look into what standard libraries of various system programming languages offer). * date-and-time, date, time For time zones, we used to have the canonical format +00:00 for systems in UTC located and a known timezone offset of 00:00. For systems in UTC with an unknown timezone offset, the canonical format has been -00:00. This was based on RFC 3339 which introduced the -00:00 which is not strictly allowed by the ISO 8601 format. The sedate work is updating RFC 3339 recommending against the use of the -00:00 notation (since it is not conforming to ISO 8601) and instead suggests that Z is used for systems in UTC with an unknown timezone offset. The question is now how we deal with this non-backwards compatible change of RFC 3339 that apparently got approved by the IESG and hence there is believe that the Internet won't break based on the argument that using Z instead of -00:00 is already common practice. If so, do we simply align our definition with the updated version of RFC 3339? Or do we go an deprecate date-and-time and create a new definition (and then we deal with the updates of all affected modules over time)? Note that this also affects the newly defined zoned types date and time. Looking forward, we may even want to consider supporting formats that allow for timezone names instead of only static numeric offsets. So another option might be to leave date-and-time as is (potentially deprecating it once there is a better replacement) and to start a new module, say ietf-chrono, that defines new date and time related types that are aligned with the updated RFC 3339 and the work done by the sedate working group to enable the use of time zone names. * nanoseconds, microseconds, milliseconds, seconds, minutes, hours There was some discussion around the choice of signed vs unsigned base types and the choice between 32 and 64 bits. I have investigated a bit what standard libraries of system programming languages do and I concluded that using signed integer types dominates and that we should use 64-bit types for everything up to and including seconds (and not offer 32-bit alternatives). It is easy to range restrict to just positive numbers and it is also easy to range restrict to use less than 64 bits. If we would start a new module for date and time types, then these definitions should likely be moved there as well. I believe to have proper types for data and time and durations, it is best to factor this work out into a separate effort. This gives us more freedom to do things right without any harm on backwards compatibility (we would not change date-and-time, except perhaps adding a warning note that use of -00:00 is getting discouraged). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
