Hi. I do not have nearly the level of misgivings about this document that I did about the versions of many months ago. In particular, explicit removal of attempts to cover future dates and times as well as non-UTC timekeeping systems, IMO, strengthen the document even if it implies that more work will be needed for other applications. However, I do not believe it is ready for publication as a standards track spec. I'm going to try to avoid writing one of my long and detailed notes that many people will not read but, instead, will try to concentrate on a few key points (but with the understanding that they are closer to examples than a comprehensive list of problems). (1) ISO 8601 is a very widely adopted and used International Standard. In addition to the sorts of uses that can reasonably be expected to show up in contexts related to Internet protocols (and the Java time format work), it is heavily used in the notations of a number of scientific fields and incorporated into regulations in some countries. While I have no problem at all with the IETF extending 8601 in a way that is compatible with that standard and how it might evolve, there is little or no evidence in the document that serious consideration was given to that issue. In particular, the document's references to ISO 8601 are to the long-obsolete and withdrawn 1988 version of that document and not to the current one(s) (the URL given in the reference for [ISO8601:1988] leads to a page that says " Status: Withdrawn" and does not even point to a current document). For reasons that closely parallel some of the recent RSWG discussions about obsolete references and links, this document should either reference the current version of ISO 8601 and explain why the extension syntax chosen is unlikely to cause conflicts in the future or should carefully and respectfully explain why not. If necessary, consider how the IETF would react if some other SDO (possibly even an ISO subgroup) referenced RFC 1163 and suggested it represented the IETF's latest thinking on BGP and its use. (2) Parts of the document are very confusing, to the point that it is not clear what is being specified. Take Section 2 as an example. The second paragraph includes "The latter convention is in actual use, while the former always was handicapped...". But the previous sentence points to RFC 5322 first and then to RFC 2822. Is it the later spec (5322) that is "in actual use" or is the earlier spec, listed second? And what does "in actual use" mean? There has been enough diversity in email systems, especially various flavors of MUAs, that it is reasonable to assume that someone, somewhere, implemented whatever 2822 or 5322 specified. Then, in the next paragraph, the text goes on to describe how, in the opinion of the authors (and, I presume, the WG) "Z" has been used and then, in the one after says that "Z" should now be interpreted differently. But then the last two paragraphs of the section say that the old use is not deprecated and then says "For the intents and purposes of the present specification," (rather awkward English) "the local offset Z can be used in its place". That would seem to imply that we are back to treating Z as a synonym for "-00:00" while the prior paragraph starting "This specification updates..." seems to imply that "Z" implies +00:00, which is consistent with most international usage that allows single-letter time zone indications. It must be possible to write that section in a way that is clear, that specifies how "Z" is to be interpreted, and that identifies exactly what is being changed in 3339. If the rest of the section is intended to provide historical context, then separate that out and identify it as such. (3) Robert Sparks's Genart review [1] identifies several other places where the specification is ambiguous as to what is actually allowed. I disagree with him only in that I do not believe that list adds up to "Ready with Issues" but, instead, that his list identifies things that the community (and the IESG on its behalf) should insist on being clarified before the I-D is approved. For most or all of them, I believe that making decisions and getting them clearly expressed is more important than what the decisions actually are. However, others may not agree with that and "clearly" may be in the mind of the beholder, so we should see a new version of the document and a (brief, I hope) period for community review, not some quiet revision negotiated with the IESG. thanks, john p.s. as a strictly editorial matter that would not be worth mentioning except insofar as it is a symptom that the authors and WG were not quite finished with this document before asking that an IETF Last Call be initiated, there are five BCP documents (six entries) listed as Normative References. Two of them are listed by BCP numbers, the others, including two that make up one BCP, are listed by RFC numbers. Is there any reason for that distinction other than to confuse the reader? [1] https://mailarchive.ietf.org/arch/msg/last-call/WOmMJWxsMFjz12nZM3nz7o3aGG0 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
