--On Wednesday, October 19, 2022 21:44 +0200 Carsten Bormann <[email protected]> wrote:
> Hi John, > > thank you for weighing in. > >> (1) The language in RFC 5322 that describes the interpretation >> of -00:00 (actually "-0000" in those specs -- while 8601 makes >> the colon optional, 3339 requires it) and rules about it are >> under review in EMAILCORE. > > Thank you for that pointer! > My summary of the 51(!) messages that mention -0000 (the email > date version of -00:00) is that implementors don't really > seem to pick up those fine points, so it is hard to rely on > the information that supposedly is being conveyed. Right. And, thanks to the recent SEDATE discussion, I suddenly had an insight into why. I'll copy you on a message that will go to EMAILCORE as soon as I finish it. Feel free to forward it, or excerpts of it, to the SEDATE (and other list here) if you think it would be useful. > Given that the people who do ISO 8601 and RFC 3339 > implementations might be more focussed on time, we might be a > bit more optimistic for SEDATE. Indeed. >> If people have opinions about that, >> please review those discussions and please, please, do not do >> anything in SEDATE that would produce the possibility of a >> conflicting definition between the two IETF specs. > > I'm not sure what a conflict would be: > — ISO 8601 definitely does not have -00:00 so there will be > a difference. > — There is no point in trying to change ISO > 8601. I have not been nearly close enough to ISO/TC 154 to express an opinion on the point/no point spectrum, but some "what does this time zone statement mean" convention would seem to be within the scope of ISO 8601-2:2019 as I understand it. > — Some change to RFC 3339 will be needed if there is > interest in being able to express no information about time > zone offsets. Except that it already contains what appears to me to be "no information" language in Section 4.3. Whether is it clear enough to be understandable to everyone in the same way is a separate question (see that forthcoming note and its three separate categories). > — Email headers are not going to change, so > they have -0000 but not Z (so that's a perfect match to what > SEDATE proposes). > So there always will be a need to translate the time zone > offset information at the same time while translating all the > other differences between RFC 3339 and RFC 2822/5322. No > conflict/incompatibility in sight. I was merely suggesting the possibility of a statement in the SEDATE spec that makes it clear that the conventions in it (and 3339) and the email specs (not just 2822/5322 but 2821/5321 and their successors) are different. >> (2) The discussion of the bad effects of standards that can >> legally be obtained only at high prices is old news. > > (And off-topic for this thread. Sorry for leading in that way. > I agree with the rest of what you said.) >> (3) We are, however, supposed to be about interoperability and >> reality. ISO 8601 is very widely used in many contexts that >> interact with the Internet. I hope we all agree that >> pretending it could be safely ignored would be a terrible >> idea. > > Well… ISO 8601:1988 should not be ignored. > And we have made our profile in RFC 3339. > The more recent changes to ISO 8601? > They lead into a direction we probably aren't that > interested in. (A.k.a. "Look, ma, how much weird and rarely > needed semantics I can encode into an incomprehensible > string.") At least on some days, I might agree with that. Arguably the ideal solution would be an update/replacement for 3339 that would be based on ISO 8601-1:2019, and 8601-2:2019 if needed that would act as a real "use this, ignore that" profile and a supplemental document (like the SEDATE work) that would cover everything else, particularly conflicting extensions. I am not volunteering to do the work. >> Arguably, >> we have RFC 3339 just because of the tradeoffs between >> developing an IETF-exclusive spec, technical and financial >> issues with ISO 8601, and places where 8601 allowed too much >> flexibility for good interoperation (in ISO-speak, that is >> what "profiles" are about). > > Yep. And, as you point out above, as 8601 has evolved, that need has just gotten more pronounced. >> (4) I don't remember the full history of RFC 3339, but assume >> that the -00:00 convention was introduced for easy and >> accurate transcoding from email date-times, notably that >> specified in RFC 2822. > > One of my hopes of bringing this up in a wider context was to > uncover some of this history. Graham is still very much around and active and Chris is easy to reach. You, or someone more closely involved with SEDATE than I am, might try asking :-) >> Unless someone actually has memories or documentation to >> the contrary, it is not reasonable to assume that the >> incompatibility with ISO 8601 was a mistake or due to "not >> having a copy of" that spec. It is at least as likely that, >> had everyone involved in 3339's development had ISO 8601 in >> front of them, that provision for "-00:00" would have been >> put in anyway. > RFC 3339 touts itself as "an Internet profile of the ISO > 8601 [ISO8601]", so unless the meaning of the word > "profile of" wasn't widely known in 2002, that doesn't > sound too likely to me. But weirder mistakes have been made. The ISO, and ISO/IEC, definition of "profile" goes back at least to the 1970s, in is, curiously, one of the things that got ISO (and, later, CCITT/ITU-T) data communications protocols into interoperability trouble (and data traffic from Bonn to Paris via New York). But that definition is about picking among options listed in a standard and strict subsets; it does not allow adding anything not in the base spec. So 3339 plays a little loose with that definition of "profile" no matter how -00:00 got in there. >> (4) I believe that there are at least two important lessons >> for SEDATE in the above. First, extending ISO 8601:2019 > > 1988, please, not 2019. See above. If nothing else, whatever unkind things several of us might say about the price of ISO documents, the 1988 versions are as unavailable as ISO can make them. You could negotiate with my bookshelf, but I could not make copies then and can't make them now. So, yes, I understand what you are saying and why, but there is a bit of a trap there. >> and its >> various parts where we can demonstrate and explain clear needs >> is reasonable, especially when those extensions can be as >> compatible as possible _and_ we document where we are >> extending things (in retrospect, I believe 3339 failed in the >> latter regard even though there is a good deal of information >> in the opening paragraphs of Appendix A). Second, at an >> appropriate time but certainly no later than when SEDATE's >> work is approved for publication, we carefully and >> respectfully explain to ISO/TC 154/WG 5 (not just to some >> member of, or liaison to, them) what extended functionality >> we concluded was needed, why, and the extensions we specified >> as a result. Assuming they behave reasonably, they might >> consider adding our extensions to a future version of 8601-2 > (I'm afraid this would lead to another instance of the > restatement antipattern.) On the other hand, 3339 contains references to ISO 8601:1988 and, for that matter, ISO 8601:2000 and at least the former is rather close to normative. So, give the availability (or last thereof) of those two specs at any price, a reference to either 3339 is essentially a belief that you can trust Graham and Chris and their reading of that spec in 2002 and/or the reading of people like me who have copies of the 1988 document around and who might be persuaded to open them. Thin ice either way. >> or at least avoid future extensions >> with the same syntax but different definitions. > > Much better. best, john _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
