Hi Juergen, Coming back to this thread. I was hoping for more folks to comment on this thread. But with the opinions we have, it seems the consensus is around ...
> On Apr 18, 2024, at 6:05 AM, Jürgen Schönwälder > <jschoenwaelder@constructor.university> wrote: > > 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. … deprecate the use of -00:00, and add a note that its use is being discouraged. > > * 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. Agree. For now, how about going with a signed integer types using 64-bit? > > 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). Again agree. But I am not hearing a strong desire for the new work. In either case, there is nothing stopping that work from starting when it does, including moving some of these types to the new document. As a forcing function, how about making the changes we agree, and calling the work done? Thanks. > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
