Thanks for your review, Bron. See my response inline... On Sun, Sep 29, 2024 at 09:27:56AM -0700, Bron Gondwana via Datatracker wrote: > Reviewer: Bron Gondwana > Review result: Not Ready > > I'm the designated ARTART reviewer for this document. It's generally well > written and clear; I didn't see any issues with the document itself, however > there are some obsolete references and changes to align with work done > elsewhere in the IETF which I believe would improve the overall > cross-compatibility of IETF specifications significantly, hence my marking it > as "NOT READY". > > *Date-Time:* > > While the date-time format duplicates the description found in RFC 6021 and > later RFC 6991, the construct -00:00 has been identified as being incompatible > with the latest ISO8601 by the work in the SEDATE working group. I would refer > you to section 2 of RFC 9557 for the full description and update of RFC 3339 > which was done there. I suggest that this document should be updated to align > with (and reference) RFC 9557 and deprecate the usage of -00:00; instead using > "Z" to mean "local time reference point is unknown" as is common practice. > This will improve future interoperability with ISO8601. > > Likewise the same issue occurs with the new "date" format and "time" format. This has been discussed in the WG and the conclusion was to not change the 'date-and-time' format as it is widely implemented. Note that RFC 6020 picked -00:00 as the canonical representation for values in UTC with an unknown local time-offset. RFC 9557 now suggests to use Z instead. If we change date-and-time to use Z instead of -00:00, then existing implementations of 'date-and-time' become non-compliant. Hence, we prefer to stick to what we have. For the new 'date' and 'time' definitions we can adopt RFC 9557 and use Z instead of -00:00. This of course means that UTC values with an unknown local time-offset will be reported differently in 'date-and time' values and 'date' or 'time' values. Yes, all this is somewhat unfortunate. I will update the definitions of 'date' and 'time' to follow RFC 9557 but I will not touch 'date-and-time' for now unless lets say the IESG decides that alignment with RFC 9557 is more important than our concerns about compliance of existing implementations generating canonical representations. > *Email Address:* > > The email-address construct in this document is limited to 7-bit. > RFC 6531 and RFC 6532 have extended Email Address to allow UTF-8 > characters. There's a good analysis of the changes at: [...] > Since this is a new datatype being added, it should support all legal email > addresses as defined in current IETF RFCs; so be extended for 8 bit > local-parts. Similarly, the domain part of the address should explicitly > mention A-labels for Internationalized domain names, as the "domain-name" > construct does. I agree that we should support internationalized email addresses. Given the complexity of defining a tight regular expression, this seems to be the wrong path to go. (You pointed to a regular expression that is already close to 1k long and according to its author still has limitations.) Instead, we should leave it to implementations to do validation using regular code. My take is that standardizing a regex to validate email addresses is not something this WG should do. Instead, we should leave it to implementations to do validation in regular code. I will replace the current regular expression with a rather generic expression that accepts international characters, I will add a reference to RFC 6531, and I will add text spelling out that this email type supports u-labels and a-labels in DNS names. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
