Should POUF-1 allow whitespace for prettified output? #161
Comments
|
My vote is yes: POUF-1 should allow whitespace |
|
As long as the implementations are compatible, they should be able to share a POUF number. We should update POUF-1 accordingly. |
erickt
added a commit
to erickt/rust-tuf
that referenced
this issue
Sep 28, 2022
After a discussion with the TUF community, we decided it made more sense to name our implementation of [POUF-1] as `Pouf1`, not `Json`, because it has additional restrictions on top of JSON. Furthermore, it doesn't make sense to call this [CJSON] since TUF doesn't allow for raw bytes in strings. This also moves `JsonPretty` into the interop-tests, since this is only used to make the interop tests easier to review. I've filed [161] with the TUF spec to consider allowing whitespace in POUF-1. If this is accepted we can move this back into the tuf::pouf submodule. [POUF-1]: https://github.com/theupdateframework/taps/blob/master/POUFs/reference-POUF/pouf1.md [161]: theupdateframework/taps#161 [CJSON]: https://wiki.laptop.org/go/Canonical_JSON
erickt
added a commit
to erickt/rust-tuf
that referenced
this issue
Sep 28, 2022
After a discussion with the TUF community, we decided it made more sense to name our implementation of [POUF-1] as `Pouf1`, not `Json`, because it has additional restrictions on top of JSON. Furthermore, it doesn't make sense to call this [CJSON] since TUF doesn't allow for raw bytes in strings. This also moves `JsonPretty` into the interop-tests, since this is only used to make the interop tests easier to review. I've filed [161] with the TUF spec to consider allowing whitespace in POUF-1. If this is accepted we can move this back into the tuf::pouf submodule. [POUF-1]: https://github.com/theupdateframework/taps/blob/master/POUFs/reference-POUF/pouf1.md [161]: theupdateframework/taps#161 [CJSON]: https://wiki.laptop.org/go/Canonical_JSON
erickt
added a commit
to theupdateframework/rust-tuf
that referenced
this issue
Sep 28, 2022
After a discussion with the TUF community, we decided it made more sense to name our implementation of [POUF-1] as `Pouf1`, not `Json`, because it has additional restrictions on top of JSON. Furthermore, it doesn't make sense to call this [CJSON] since TUF doesn't allow for raw bytes in strings. This also moves `JsonPretty` into the interop-tests, since this is only used to make the interop tests easier to review. I've filed [161] with the TUF spec to consider allowing whitespace in POUF-1. If this is accepted we can move this back into the tuf::pouf submodule. [POUF-1]: https://github.com/theupdateframework/taps/blob/master/POUFs/reference-POUF/pouf1.md [161]: theupdateframework/taps#161 [CJSON]: https://wiki.laptop.org/go/Canonical_JSON
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In this conversation on #tuf, I'm in the process of renaming rust-tuf's interchange types to
pouf, since that's more aligned with the tuf project. One complication though is that rust-tuf supports a prettified version ofpouf-1with JsonPretty. We use this to generate golden files to make sure code changes don't unintentionally change pregenerated metadata. It's much easier to read pretty json than minified json. However, according to pouf-1, this format uses OLPC's canonical json format, which disallows whitespace.rust-tuf, and I'm guessing all the other implementations of POUF-1, can work with prettified metadata without issue. Should this be something that's formally supported? Or should implementations like this be treated as a non-standard POUF? If the latter, how should we refer to things like this? Should we avoid using the term
POUFwith things like this?The text was updated successfully, but these errors were encountered: