From 6ae2170113935dd670928d51d58fed176bd3d24b Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 4 Aug 2021 18:26:51 -0700 Subject: [PATCH] Clarify the origin of contentEncoding It is related to MIME's Content-Transfer-Encoding, and not HTTP's Content-Encoding. --- jsonschema-validation.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index e12c6cd2..fb244a0a 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -964,7 +964,7 @@ 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. @@ -972,7 +972,13 @@ Possible values indicating base 16, 32, and 64 encodings with several variations are listed in RFC 4648. Additionally, sections 6.7 and 6.8 of RFC 2045 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. + + + 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