Skip to content

Clarify the origin of contentEncoding #1117

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.

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 1 commit into from
Nov 9, 2021
Merged
Changes from all commits
Commits
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
10 changes: 8 additions & 2 deletions jsonschema-validation.xml
Original file line number Diff line number Diff line change
Expand Up @@ -964,15 +964,21 @@

<t>
If the instance value is a string, this property defines that the string
SHOULD be interpreted as binary data and decoded using the encoding
SHOULD be interpreted as encoded binary data and decoded using the encoding
named by this property.
</t>

<t>
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
encodings used in MIME. This keyword is derived from MIME's
Content-Transfer-Encoding header, which was designed to map binary data
into ASCII characters. It is not related to HTTP's Content-Encoding header,
which is used for compressing HTTP request and response payloads.
</t>
<t>
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
Expand Down