-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Hannah Stern
<[email protected]> writes
>What I _am_ convinced of is my suggestion for the spec to forbid additional
>elements in the JSON in _all_ places (including top-level).
We could do this, by adding additionalProperties and additionalItems
lines to schema ... (and drawing attention to it in the text)
Is this a good idea ? We explicitly allow extra tags and tell people
that they MUST ignore them because are something really useful from the
future. Why would we not wish to do that in the JSON schema ??
>What I'd also be more than ok with would be adding prose to Security
>Considerations that if one uses a generic JSON parser, that needs to fulfill
>the
>security requirements like in other settings where JSON is used in contact to
>potentially hostile adversaries. Parsing depth (CPU/memory) limiting, for
>example.
We could certainly write a "motherhood and apple pie" statement that
said that if your code has bugs or is not written defensively to
consider the possibility of incoming messages that are or not conformant
with the spec, or that have indefinite numbers of items, that there is a
risk of incorrect validation or worse.
If that is considered useful then I think it should be a separate
document and should be tagged as amending the security section of
several thousand other RFCs
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBarZ/8GHfC/FfW545EQL83wCghr2G7FiEN6hfup1FdpnNitqf9pkAoMxp
X/xuSuknFaYT9KCKJHEmZt5j
=CtOc
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
