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. 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. > 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. — Some change to RFC 3339 will be needed if there is interest in being able to express no information about time zone offsets. — 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. > (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.") > 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. > (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. > 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. > (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. > 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.) > or at least avoid future extensions > with the same syntax but different definitions. Much better. Grüße, Carsten _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
