Draft: draft-ietf-httpapi-rfc7807bis

Commentary: From IETF last - call review 
 Thanks !
To address that shortcoming, this specification defines simple JSON
JSON and XML XML document formats and a HTTP field to describe the
specifics of problem(s) encountered - "problem details".
For example, consider a response indicating that the client's account
doesn't have enough credit.  The API's designer might decide to use
the 403 Forbidden status code to inform HTTP-generic software (such
as client libraries, caches, and proxies) of the response's general
semantics.  API-specific problem details (such as the why the server
refused the request and the applicable account balance) can be
carried in the response content, so that the client can act upon them
appropriately (for example, triggering a transfer of more credit into
the account).
To address that shortcoming, this specification defines simple JSON
JSON and XML XML document formats and an HTTP field to describe the
specifics of problem(s) encountered - "problem details".
For example, consider a response indicating that the client's account
doesn't have enough credit.  The API's designer might decide to use
the 403 Forbidden status code to inform HTTP-generic software (such
as client libraries, caches, and proxies) of the response's general
semantics.  API-specific problem details (such as why the server
refused the request and the applicable account balance) can be
carried in the response content, so that the client can act upon them
appropriately (for example, triggering a transfer of more credit into
the account).
If the type URI is a locator (e.g., those with a "http" or "https"
scheme), dereferencing it SHOULD provide human-readable documentation
for the problem type (e.g., using HTML HTML5).  However, consumers
SHOULD NOT automatically dereference the type URI, unless they do so
when providing information to developers (e.g., when a debugging tool
is in use).
If the type URI is a locator (e.g., those with an "http" or "https"
scheme), dereferencing it SHOULD provide human-readable documentation
for the problem type (e.g., using HTML HTML5).  However, consumers
SHOULD NOT automatically dereference the type URI, unless they do so
when providing information to developers (e.g., when a debugging tool
is in use).
Similarly, the "validation error" example defines a "errors"
extension that contains a list of individual error occurrences found,
with details and a pointer to the location of each.
Similarly, the "validation error" example defines an "errors"
extension that contains a list of individual error occurrences found,
with details and a pointer to the location of each.
Some problems might best be conveyed in a HTTP header or trailer
field, rather than in the message content.  For example, when a
problem does not prevent a successful response from being generated,
or when the problem's details are useful to software that does not
inspect the response content.
Some problems might best be conveyed in an HTTP header or trailer
field, rather than in the message content.  For example, when a
problem does not prevent a successful response from being generated,
or when the problem's details are useful to software that does not
inspect the response content.