Original text:
A non-normative example of a grant request is below: <del> The request MUST be sent as a JSON object in the body of the HTTP POST request with Content-Type "application/json", unless otherwise specified by the signature mechanism. </del>  2.1.

Reviewer comments:
The specification doesn't mention the Cache-Control header, as well as the Content-Type header for the responses. This is the 1st step to add this information. All examples of responses may also include this header. Right now, it's true for a few examples. I am unsure if it's necessary to include a bit obsolete header Pragma. URL
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 8a756ce36a5af1b0f97c6abc17ab1d772adfde10 https://deploy-preview-199--gnap-core-protocol-editors-URL
This seems like it's still in progress, so I've marked it as a draft for now. Would like to see more input on the right behavior around cache control headers here.
There is no place for the Pragma header. This header is actually for a request, not a response, and it’s for backward compatibility for ancient HTTP 1.0. explains what this header does. There was even about the improper use of this header. The draft for OAuth 2.1 (which is currently under development) still suggests using it. Although, I don’t really think it does it for some particular purpose other than historical reasons. I believe "Cache-Control: no-store” will be sufficient.
NAME do you still want me to provide more inputs on this one?
Roles: Editor's note: The names for the roles are an area of ongoing discussion within the working group, as is the appropriate precision of what activities and expectations a particular role covers. In particular, the AS might be formally decomposed into delegation components, that the client talks to, and interaction components, that the user talks to. Several alternative names have been proposed for different roles and components, including: Grant Server (for Authorization Server) Grant Client (for Resource Client) Operator (for Requesting Party) See also
Part of the terminology
Process comment: I suggest to move the top note over to and close this one as Duplicate.
Closing as duplicate Examples in RFC 6750 and RFC 6749 as well as some normative text in section of RFC 6749 use a "Pragma: no-cache" HTTP response header. However, both RFC 2616 and the shiny new RFC 7234 make special note along the lines of the following to say that it doesn't work as response header: 'Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.' The header doesn't hurt anything, I don't think, so having it in these documents isn't really a problem. But it seems like it'd be better to not further perpetuate the "Pragma: no-cache" response header myth in actual published RFCs. So with that said, two questions: 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response header inappropriately? 2) If so, does this qualify as errata?

Revised text:
A non-normative example of a grant request is below:  <ins> The request and response MUST be sent as a JSON object in the body of the HTTP POST request with Content-Type "application/json", unless otherwise specified by the signature mechanism. The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value set to "no-store". </ins> 2.1.