Codec specs should clarify that decoders shouldn't require strictness #196
Assignees
Comments
rvagg
added a commit
that referenced
this issue
May 10, 2022
Fixes: #196 Current text reflects an idealistic perspective, not a pragmatic one that accounts for historical data and handling data from encoders that don't quite follow the rules. Nor do the current statements requiring strictness reflect the reality of our current decoders, which are lose and don't even yet have full opt-in strictness modes; even though we note the lack of strictness in the implementation notes.
rvagg
added a commit
that referenced
this issue
May 13, 2022
Fixes: #196 Current text reflects an idealistic perspective, not a pragmatic one that accounts for historical data and handling data from encoders that don't quite follow the rules. Nor do the current statements requiring strictness reflect the reality of our current decoders, which are lose and don't even yet have full opt-in strictness modes; even though we note the lack of strictness in the implementation notes.
rvagg
added a commit
that referenced
this issue
May 13, 2022
* dag-cbor,dag-json: relax strictness rules for decoders Fixes: #196 Current text reflects an idealistic perspective, not a pragmatic one that accounts for historical data and handling data from encoders that don't quite follow the rules. Nor do the current statements requiring strictness reflect the reality of our current decoders, which are lose and don't even yet have full opt-in strictness modes; even though we note the lack of strictness in the implementation notes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See ipld/go-ipld-prime#390 (comment) and the comments below.
In short, specs like dag-cbor currently require decoders to strictly enforce determinism, but our main implementations (Go, JS) do not, and will never be able to due to backwards compatibility concerns. We should update the spec to say that the codec decoders should not have this strictness requirement by default, but that it should be implemented as an opt-in instead.
The text was updated successfully, but these errors were encountered: