Specifications can change over time. It sounds to me as though the developer who made the change to the system that invalidated the invariant of the original specification wasn't aware of the spec in the first place. Maybe they should have worked on the specification first before proceeding.
I haven't taken a look at the spec, but assuming what's noted in that issue comment is indeed the case, then I find it surprising that something as obvious as this would not be fixed/raised during the RFC and review of the spec itself.
I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities.
I think less than a week ago (weakdh) tptacek was mentioning on twitter that security schemes should be versioned but not extensible exactly due to these kind of errors.
In this case, the something wrong is that the specification didn't have the foresight to create a syntax robust enough to support actually upgrading the spec for real users. Discarding unrecognized syntax is a nice, robust behavior, but it doesn't cut it.
"If it isn't in the specification, it isn't legitimate, period."
You have some goal you're trying to achieve, or why was a specification written at all? If you find that the existing specification is not the optimal path to that goal, you may very well want to change the specification. In which case, it's entirely legitimate.
Interesting - I didn't knew that one. It seems very security related - I'm not sure if issues for not supporting a specific part in a spec or for improving documentation for a feature will fit in.
Those are intentional deviations from the standard, and I think there's a reasonable assumption that those stay the same/compatible from version to version. I think the other kind are a bit more problematic, and without a standard it can be difficult to tell whether your assumptions are reasonable.
Ah, good to know. I'm tempted to respond that this means the spec has failed to address an important use case. But I'm certainly not going to learn enough of the spec to back up that claim.
Yes, I'd add to that by pointing out that the "spec" is a de facto spec subject to Hyrum's Law, that is, people have built their apps against other implementations of the platform and inevitably don't handle any behavior not seen on those other implementations.
The new spec (2.0, not implemented by any client) is made by a committee that is also building a standard DRM implementation to go alongside it. (Search for Readium).
That was when I lost all interest in the new spec.
>> but that they should be protected from instability.
Appropriate protection is a warning in the docs "this code might change when the spec is finalised".
Inappropriate protection is hiding those features away behind difficult-to-configure barriers making it only possible for experts to configure their systems to run it.
Sounds like a communication issue to me.
reply