Skip to content

Improve contentEncoding RFC references #862

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 23, 2020
Merged

Improve contentEncoding RFC references #862

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
05fe4a3
Improve contentEncoding RFC references
handrews Feb 21, 2020
6fa4289
Review feedback on contentEncoding, add change log
handrews Mar 19, 2020
3948c47
Change log entry for email format fix
handrews Mar 19, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 17 additions & 9 deletions jsonschema-validation.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -979,19 +979,21 @@
</t>

<t>
Possible values for this property are listed in
<xref target="RFC2045">RFC 2045, Sec 6.1</xref> and
<xref target="RFC4648">RFC 4648</xref>. For "base64", which is defined
in both RFCs, the definition in RFC 4648, which removes line length
limitations, SHOULD be used, as various other specifications have
mandated different lengths. Note that line lengths within a string
can be constrained using the <xref target="pattern">"pattern"</xref> keyword.
Possible values indicating base 16, 32, and 64 encodings with several
variations are listed in <xref target="RFC4648">RFC 4648</xref>. Additionally,
sections 6.7 and 6.8 of <xref target="RFC2045">RFC 2045</xref> provide
encodings used in MIME. As "base64" is defined in both RFCs, the definition
from RFC 4648 SHOULD be assumed unless the string is specifically intended
for use in a MIME context. Note that all of these encodings result in
strings consisting only of 7-bit ASCII characters. Therefore, this keyword
has no meaning for strings containing characters outside of that range.
</t>

<t>
If this keyword is absent, but "contentMediaType" is present, this
indicates that the media type could be encoded into UTF-8 like any
other JSON string value, and does not require additional decoding.
indicates that the encoding is the identity encoding, meaning that
no transformation was needed in order to represent the content in
a UTF-8 string.
</t>

<t>
Expand Down Expand Up @@ -1426,6 +1428,12 @@
</t>
<t>
<list style="hanging">
<t hangText="draft-handrews-json-schema-validation-03">
<list style="symbols">
<t>Correct email format RFC reference to 5321 instead of 5322</t>
<t>Clarified the set and meaning of "contentEncoding" values</t>
</list>
</t>
<t hangText="draft-handrews-json-schema-validation-02">
<list style="symbols">
<t>Grouped keywords into formal vocabuarlies</t>
Expand Down