Updated proposal from 2019-3-7: We need to specify the format-independent minimal content of an error response body in Protocol code: non-empty string, not null -  code: not language-dependent -  message: language-dependent, non-empty, not null, human-readable -  target: string, can be null, can be omitted, can be empty details: collection of structured instances with code, message, target, same rules as above innererror: optional, structured instance, anything goes Make comment about security concerns "global" to error response, not only specific to innererror   Change paragraphs 3 to 5 in chapter 21 Error Response: The value for the code name/value pair is a language-independent string. Its value is a service-defined error code. This code serves as a sub-status for the HTTP error code specified in the response. The value for the message name/value pair MUST be is a string containing a human-readable, language-dependent representation of the error. The Content-Language header MUST contain the language code from [RFC5646] corresponding to the language in which the value for message is written. The value for the target name/value pair is a string containing  the target of the particular error (for example, the name of the property in error). Neither code nor message can have the value null .