RFC7159 -> RFC8259

This commit is contained in:
Tony Garnock-Jones 2018-09-24 19:12:43 +01:00
parent 35726436c9
commit 3c7215397d
1 changed files with 4 additions and 4 deletions

View File

@ -939,14 +939,14 @@ Specifically, JSON does not:
In short, JSON syntax doesn't *denote* anything.[^xml-infoset] [^other-formats]
[^meaning-ieee-double]:
[Section 6 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-6)
[Section 6 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-6)
does go so far as to indicate “good interoperability can be
achieved” by imagining that parsers are able reliably to
understand the syntax of numbers as denoting an IEEE 754
double-precision floating-point value.
[^string-key-comparison]:
[Section 8.3 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-8.3)
[Section 8.3 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-8.3)
suggests that *if* an implementation compares strings used as
object keys “code unit by code unit”, then it will interoperate
with *other such implementations*, but neither requires this
@ -954,12 +954,12 @@ In short, JSON syntax doesn't *denote* anything.[^xml-infoset] [^other-formats]
contexts.
[^json-member-ordering]:
[Section 4 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-4)
[Section 4 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-4)
remarks that “[implementations] differ as to whether or not they
make the ordering of object members visible to calling software.”
[^json-key-uniqueness]:
[Section 4 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-4)
[Section 4 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-4)
is the only place in the specification that mentions the issue. It
explicitly sanctions implementations supporting duplicate keys,
noting only that “when the names within an object are not unique,