Should the spec have recommendations on how encoders/decoders handle draft features?

[leo-barnes]

This was discussed in the last meeting. In order to make sure that draft-features work in practice, you want to implement them before the draft is published. But this can cause issues since the draft may change before it is published. The consensus was that the following is a good approach:

• Encoders should only create files that contain published features, unless clients ask for experimental features explicitly. Spec drafts may change and we want to minimize the risk of creating files that end up non-compliant.
• Decoders (especially ones that can easily be updated) can add support for experimental features early. This helps make sure that the feature is tested and will actually work in practice. If the spec changes you end up with what is essentially a bug in the decoder, but the bug only applies to a feature that is bleeding edge and probably not very common yet.

Do we want to add a short recommendation in the spec so that we document that this is how we think it should work?

[baumanj]

Do we want to add a short recommendation in the spec so that we document that this is how we think it should work?

Yeah, I think that sounds great. While it sounds very simple/obvious in theory, I think in the real world it can be kind of subtle because it's easy to forget about the complex N:M interactions of many different writers (and versions thereof) interacting with many different readers.

One thing it brings up for me is whether we should restrict the language to features or write more broadly about specification changes. Or perhaps the two cases should be handled differently, which means we'll need to define what the distinction is relatively precisely. Two real world examples I think will help test whether the language we want to write is achieving the goal:

1. The interpretation of imir changed in ISO/IEC 23008-12:2017/DAmd 2, reversing what the spec says to align it with the overwhelming (but technically backward) implementations in the wild. This is a good change, but tricky because it puts implementations trying to follow the spec in direct conflict with what the majority of users will expect.
2. The quantity requirement of "at most one" colr box was relaxed in DIS 23008-12, but because of the inherent ambiguity prior to that codification, a conformant reader would appropriately reject inputs with multiple colr boxes. That seems to operate more like a feature where it seems safe for readers to implement the change before it's published as long as writers require an explicit override to use multiple colr boxes.