Hi Joe,
thank you for this review.
> On 2023-06-12, at 17:16, Joe Clarke via Datatracker <noreply@xxxxxxxx> wrote:
>
> Reviewer: Joe Clarke
> Review result: Has Issues
>
> I have been tasked to review this document on behalf of the OPS DIR. Overall,
> I struggled with this, and I don't know that "Has Issues" is the right result.
> The document is well-written and clear (and let's face it, time is hard). But
> as an operator, the backwards compatibility didn't resonate with me.
Before I continue responding, I’ll explain the terminology that I am used to:
* Backward compatibility = old data, new system.
* Forward compatibility = new data, old system.
Clearly, IXDTF is backward compatible with RFC 3339 (as adjusted by accepting the now common semantic interpretation of Z).
I think you are interested in what I’d call forward compatibility.
But there is generally (*) no way to add a receptacle for information to an existing format that did not have an extension point for that, so we didn’t try.
> I realize
> there is a bit of chicken vs. egg here in terms of standardizing the new format
> before tooling will use it, but I think this could cause some incompatibility
> issues when you consider something like this:
>
> ```python
> from datetime import datetime
> datetime.fromisoformat("2022-07-08T00:14:07Z[!Europe/London]")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: Invalid isoformat string: '2022-07-08T00:14:07Z[!Europe/London]'
> ```
>
> Until language libraries are updated for this, generators and consumers will be
> out of sync. And let's face it: people don't always move to the latest version
> of their favorite language or libraries.
I’m sensing an underlying assumption that IXDTF will replace plain RFC 3339 format for all applications. That was not the intention. (But of course we’d like RFC 3339 implementors to provide a mode where they are at least robust to additional information in IXDTF format.)
> So unless I'm missing something (and I might very well be), I think this
> document would benefit from a section on migration guidance.
This, again, assumes there will be a massive, uncontrolled migration.
Instead, it seems the specifications that use RFC 3339 now should make deliberate decisions whether and how to deal with IXDTF additional information.
Many won’t need them (e.g., a future RFC 6991 ter would not migrate, but simply define new types so module authors could easily use IXDTF where that actually makes sense).
In others, they would drop right in, but still probably need some text how to make use of the additional information in the context of the specific specification.
> Moreover, what
> about some thought for some strptime/strftime format symbols for this to aim
> for language consistency? I know this might not be the canonical place, but
> given the Java references it seems like a recommendation might be acceptable.
That looks harder to me than it might seem on first look — IXDTF is a vessel that can carry very different types of information, which would in turn need different kinds of representation in strp/ftime.
If we had strong structure on the strp/ftime curation side with whom we could develop a common proposal, maybe. But if we had that, we could rely on that specification to pick up some IXDTF functionality.
So I don’t think we want to load down the IXDTF format spec itself with API considerations for various platforms.
(But I wouldn’t mind setting up a Wiki pointing to existing and emerging implementations and their APIs!)
And thank you for this editorial comment:
> On the smaller side, I think Section 5 should be baked into Section 3 to
> introduce the u-ca notation before you use it in examples.
To maintain the structure, I must admit I’d rather live with a forward reference here.
Grüße, Carsten
(*) Yes, you can encode information into the number of trailing zeroes on the fractional part of the seconds… Obviously, we didn’t try that.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
