diff --git a/docs/odata-json-format/odata-json-format.html b/docs/odata-json-format/odata-json-format.html
index 39cd77bac..bc33d3f42 100644
--- a/docs/odata-json-format/odata-json-format.html
+++ b/docs/odata-json-format/odata-json-format.html
@@ -467,7 +467,7 @@ <h2 id="44-payload-ordering-constraints"><a name="PayloadOrderingConstraints" hr
 <pre><code>Content-Type: application/json;metadata=minimal</code></pre>
 <p>cannot be assumed to support streaming.</p>
 </div>
-<p>JSON producers are encouraged to follow the payload ordering constraints whenever possible (and include the <code>streaming=true</code> content-type parameter) to support the maximum set of client scenarios.</p>
+<p>JSON producers are encouraged to follow the payload ordering constraints whenever possible (and include the <code>streaming=true</code> media type parameter) to support the maximum set of client scenarios.</p>
 <p>To support streaming scenarios the following payload ordering constraints have to be met:</p>
 <ul>
 <li>If present, the <code>context</code> control information MUST be the first property in the JSON object.</li>
@@ -1062,7 +1062,7 @@ <h1 id="12-collection-of-operation-responses"><a name="CollectionofOperationResp
 <h1 id="13-collection-of-entities"><a name="CollectionofEntities" href="#CollectionofEntities">13 Collection of Entities</a></h1>
 <p>A collection of entities is represented as a JSON object containing a name/value pair named <code>value</code>. It MAY contain <a href="#ControlInformationcontextodatacontext"><code>context</code></a>, <a href="#ControlInformationtypeodatatype"><code>type</code></a>, <a href="#ControlInformationcountodatacount"><code>count</code></a>, <a href="#ControlInformationnextLinkodatanextLink"><code>nextLink</code></a>, or <a href="#ControlInformationdeltaLinkodatadeltaLink"><code>deltaLink</code></a> control information.</p>
 <p>If present, the <code>context</code> control information MUST be the first name/value pair in the response.</p>
-<p>The <code>count</code> name/value pair represents the number of entities in the collection. If present and the <a href="#PayloadOrderingConstraints"><code>streaming=true</code></a> content-type parameter is set, it MUST come before the <code>value</code> name/value pair. If the response represents a partial result, the <code>count</code> name/value pair MUST appear in the first partial response, and it MAY appear in subsequent partial responses (in which case it may vary from response to response).</p>
+<p>The <code>count</code> name/value pair represents the number of entities in the collection. If present and the <a href="#PayloadOrderingConstraints"><code>streaming=true</code></a> media type parameter is set, it MUST come before the <code>value</code> name/value pair. If the response represents a partial result, the <code>count</code> name/value pair MUST appear in the first partial response, and it MAY appear in subsequent partial responses (in which case it may vary from response to response).</p>
 <p>The value of the <code>value</code> name/value pair is a JSON array where each element is <a href="#Entity">representation of an entity</a> or a <a href="#EntityReference">representation of an entity reference</a>. An empty collection is represented as an empty JSON array.</p>
 <p>Functions or actions that are bound to this collection of entities are advertised in the “wrapper object” in the same way as <a href="#BoundFunction">functions</a> or <a href="#BoundAction">actions</a> are advertised in the object representing a single entity.</p>
 <p>The <a href="#ControlInformationnextLinkodatanextLink"><code>nextLink</code></a> control information MUST be included in a response that represents a partial result.</p>
diff --git a/docs/odata-json-format/odata-json-format.md b/docs/odata-json-format/odata-json-format.md
index 4a71f489f..d19c44307 100644
--- a/docs/odata-json-format/odata-json-format.md
+++ b/docs/odata-json-format/odata-json-format.md
@@ -688,7 +688,7 @@ cannot be assumed to support streaming.
 
 JSON producers are encouraged to follow the payload ordering constraints
 whenever possible (and include the `streaming=true`
-content-type parameter) to support the maximum set of client scenarios.
+media type parameter) to support the maximum set of client scenarios.
 
 To support streaming scenarios the following payload ordering
 constraints have to be met:
@@ -1995,7 +1995,7 @@ first name/value pair in the response.
 
 The `count` name/value pair represents the number of entities
 in the collection. If present and the [`streaming=true`](#PayloadOrderingConstraints)
-content-type parameter is set, it MUST come before the
+media type parameter is set, it MUST come before the
 `value` name/value pair. If the response represents a partial
 result, the `count` name/value pair MUST appear in the first
 partial response, and it MAY appear in subsequent partial responses (in
diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html
index 89e711567..6802647c6 100644
--- a/docs/odata-protocol/odata-protocol.html
+++ b/docs/odata-protocol/odata-protocol.html
@@ -660,7 +660,7 @@ <h3 id="811-header-content-type"><a name="HeaderContentType" href="#HeaderConten
 <p>The specified format MAY include format parameters. Clients MUST be prepared for the service to return custom format parameters not defined in OData and SHOULD NOT expect that such format parameters can be ignored. Custom format parameters MUST NOT start with <code>odata</code> and services MUST NOT require generic OData consumers to understand custom format parameters in order to correctly interpret the payload.</p>
 <p>See <a href="#ODataJSON">OData-JSON</a> for format-specific details about format parameters within the <code>Content-Type</code> header.</p>
 <h3 id="812-header-content-encoding"><a name="HeaderContentEncoding" href="#HeaderContentEncoding">8.1.2 Header <code>Content-Encoding</code></a></h3>
-<p>As defined in <a href="#rfc7231">RFC7231</a>, the <code>Content-Encoding</code> header field is used as a modifier to the media-type (as indicated in the <code>Content-Type</code>). When present, its value indicates what additional content codings have been applied to the entity-body. A service MAY specify a list of acceptable content codings using an annotation with term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#AcceptableEncodings"><code>Capabilities.AcceptableEncodings</code></a>, see <a href="#ODataVocCap">OData-VocCap</a>.</p>
+<p>As defined in <a href="#rfc7231">RFC7231</a>, the <code>Content-Encoding</code> header field is used as a modifier to the media-type (as indicated in the <code>Content-Type</code> header). When present, its value indicates what additional content codings have been applied to the entity-body. A service MAY specify a list of acceptable content codings using an annotation with term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#AcceptableEncodings"><code>Capabilities.AcceptableEncodings</code></a>, see <a href="#ODataVocCap">OData-VocCap</a>.</p>
 <p>If the <code>Content-Encoding</code> header is specified on an individual request or response within a batch, then it specifies the encoding for that individual request or response. Individual requests or responses that don’t include the <code>Content-Encoding</code> header inherit the encoding of the overall batch request or response.</p>
 <h3 id="813-header-content-language"><a name="HeaderContentLanguage" href="#HeaderContentLanguage">8.1.3 Header <code>Content-Language</code></a></h3>
 <p>As defined in <a href="#rfc7231">RFC7231</a>, a request or response can include a <code>Content-Language</code> header to indicate the natural language of the intended audience for the enclosed message body. OData does not add any additional requirements over HTTP for including <code>Content-Language</code>. OData services can annotate model elements whose content depends on the content language with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
@@ -682,7 +682,7 @@ <h3 id="821-header-accept"><a name="HeaderAccept" href="#HeaderAccept">8.2.1 Hea
 <p>Services MUST reject formats that specify unknown or unsupported format parameters.</p>
 <p>If a media type specified in the <code>Accept</code> header includes a <code>charset</code> format parameter and the request also contains an <a href="#HeaderAcceptCharset"><code>Accept-Charset</code></a> header, then the <code>Accept-Charset</code> header MUST be used.</p>
 <p>If the media type specified in the <code>Accept</code> header does not include a <code>charset</code> format parameter, then the <a href="#HeaderContentType"><code>Content-Type</code></a> header of the response MUST NOT contain a <code>charset</code> format parameter.</p>
-<p>The service SHOULD NOT add any format parameters to the <code>Content-Type</code> parameter not specified in the <code>Accept</code> header.</p>
+<p>The service SHOULD NOT add any format parameters to the <code>Content-Type</code> header not specified in the <code>Accept</code> header.</p>
 <p>If the <code>Accept</code> header is specified on an individual request within a batch, then it specifies the acceptable formats for that individual request. Requests within a batch that don’t include the <code>Accept</code> header inherit the acceptable formats of the overall batch request.</p>
 <h3 id="822-header-accept-charset"><a name="HeaderAcceptCharset" href="#HeaderAcceptCharset">8.2.2 Header <code>Accept-Charset</code></a></h3>
 <p>As defined in <a href="#rfc7231">RFC7231</a>, the client MAY specify the set of accepted character sets with the <code>Accept-Charset</code> header.</p>
@@ -693,7 +693,7 @@ <h3 id="823-header-accept-language"><a name="HeaderAcceptLanguage" href="#Header
 <h3 id="824-header-if-match"><a name="HeaderIfMatch" href="#HeaderIfMatch">8.2.4 Header <code>If-Match</code></a></h3>
 <p>As defined in <a href="#rfc7232">RFC7232</a>, a client MAY include an <code>If-Match</code> header in a request to <code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>PATCH</code> or <code>DELETE</code>. The value of the <code>If-Match</code> request header MUST be an ETag value previously retrieved for the resource, or <code>*</code> to match any value.</p>
 <p>If an operation on an existing resource requires an ETag, (see term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency"><code>Core.OptimisticConcurrency</code></a> in <a href="#ODataVocCore">OData-VocCore</a> and property <code>OptimisticConcurrencyControl</code> of type <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#NavigationPropertyRestriction"><code>Capabilities.NavigationPropertyRestriction</code></a> in <a href="#ODataVocCap">OData-VocCap</a>) and the client does not specify an <code>If-Match</code> request header in a <a href="#DataModification">Data Modification Request</a> or in an <a href="#Actions">Action Request</a> invoking an action bound to the resource, the service responds with a <code>428 Precondition Required</code> and MUST ensure that no observable change occurs as a result of the request.</p>
-<p>If present, the request MUST only be processed if the specified ETag value matches the current ETag value of the target resource. Services sending <a href="#HeaderETag"><code>ETag</code> headers</a> with weak ETags that only depend on the representation-independent entity state MUST use the weak comparison function because it is sufficient to prevent accidental overwrites. This is a deviation from <a href="#rfc7232">RFC7232</a>.</p>
+<p>If present, the request MUST only be processed if the specified ETag value matches the current ETag value of the target resource. Services sending <a href="#HeaderETag"><code>ETag</code></a> headers with weak ETags that only depend on the representation-independent entity state MUST use the weak comparison function because it is sufficient to prevent accidental overwrites. This is a deviation from <a href="#rfc7232">RFC7232</a>.</p>
 <p>If the value does not match the current ETag value of the resource for a <a href="#DataModification">Data Modification Request</a> or <a href="#Actions">Action Request</a>, the service MUST respond with <a href="#ResponseCode412PreconditionFailed"><code>412 Precondition Failed</code></a> and MUST ensure that no observable change occurs as a result of the request. In the case of an <a href="#UpsertanEntity">upsert</a>, if the addressed entity does not exist the provided ETag value is considered not to match.</p>
 <p>An <code>If-Match</code> header with a value of <code>*</code> in a <code>PUT</code> or <code>PATCH</code> request results in an <a href="#UpsertanEntity">upsert request</a> being processed as an update and not an insert.</p>
 <p>The <code>If-Match</code> header MUST NOT be specified on a batch request, but MAY be specified on individual requests within the batch.</p>
@@ -739,8 +739,8 @@ <h4 id="8282-preference-callback-odatacallback"><a name="Preferencecallbackodata
 <p>For HTTP based callbacks, the OData service executes an HTTP <code>GET</code> request against the specified URL.</p>
 <p>Services that support <code>callback</code> SHOULD support notifying the client through HTTP. Services can advertise callback support using the <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#CallbackSupported"><code>Capabilities.CallbackSupported</code></a> annotation term defined in <a href="#ODataVocCap">OData-VocCap</a>.</p>
 <p>If the service applies the <code>callback</code> preference it MUST include the <code>callback</code> preference in the <a href="#HeaderPreferenceApplied"><code>Preference-Applied</code></a> response header.</p>
-<p>When the <code>callback</code> preference is applied to asynchronous requests, the OData service invokes the callback endpoint once it has finished processing the request. The status monitor resource, returned in the <a href="#HeaderLocation"><code>Location</code> header</a> of the previously returned <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response, can then be used to retrieve the results of the asynchronously executed request.</p>
-<p>When the <code>callback</code> preference is specified on a <code>GET</code> request to a delta link and there are no changes available, the OData service returns a <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response with a <a href="#HeaderLocation"><code>Location</code> header</a> specifying the delta link to be used to check for future updates. The OData service then invokes the specified callback endpoint once new changes become available.</p>
+<p>When the <code>callback</code> preference is applied to asynchronous requests, the OData service invokes the callback endpoint once it has finished processing the request. The status monitor resource, returned in the <a href="#HeaderLocation"><code>Location</code></a> header of the previously returned <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response, can then be used to retrieve the results of the asynchronously executed request.</p>
+<p>When the <code>callback</code> preference is specified on a <code>GET</code> request to a delta link and there are no changes available, the OData service returns a <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response with a <a href="#HeaderLocation"><code>Location</code></a> header specifying the delta link to be used to check for future updates. The OData service then invokes the specified callback endpoint once new changes become available.</p>
 <p>Combining <a href="#Preferencerespondasync"><code>respond-async</code></a>, <code>callback</code> and <a href="#Preferencetrackchangesodatatrackchanges"><code>track-changes</code></a> preferences on a <code>GET</code> request to a delta-link might influence the response in a couple of ways.</p>
 <ul>
 <li>If the service processes the request synchronously, and no updates are available, then the response is the same as if the respond-async hadn’t been specified and results in a response as described above.</li>
@@ -867,7 +867,7 @@ <h3 id="836-header-preference-applied"><a name="HeaderPreferenceApplied" href="#
 <p>If the <code>Preference-Applied</code> header is specified on an individual response within a batch, then it specifies the preferences applied to that individual response. If the <code>Preference-Applied</code> header is specified on a batch response, then it specifies the preferences applied to the overall batch.</p>
 <h3 id="837-header-retry-after"><a name="HeaderRetryAfter" href="#HeaderRetryAfter">8.3.7 Header <code>Retry-After</code></a></h3>
 <p>A service MAY include a <code>Retry-After</code> header, as defined in <a href="#rfc7231">RFC7231</a>, in <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> and in <a href="#ResponseCode3xxRedirection"><code>3xx Redirect</code></a> responses</p>
-<p>The <code>Retry-After</code> header specifies the duration of time, in seconds, that the client is asked to wait before retrying the request or issuing a request to the resource returned as the value of the <a href="#HeaderLocation"><code>Location</code> header</a>.</p>
+<p>The <code>Retry-After</code> header specifies the duration of time, in seconds, that the client is asked to wait before retrying the request or issuing a request to the resource returned as the value of the <a href="#HeaderLocation"><code>Location</code></a> header.</p>
 <h3 id="838-header-vary"><a name="HeaderVary" href="#HeaderVary">8.3.8 Header <code>Vary</code></a></h3>
 <p>If a response varies depending on the <a href="#HeaderODataVersion"><code>OData-Version</code></a> of the response, the service MUST include a <code>Vary</code> header listing the <a href="#HeaderODataMaxVersion"><code>OData-MaxVersion</code></a> request header field to allow correct caching of the response.</p>
 <p>If a response varies depending on the applied preferences (<a href="#Preferenceallowentityreferencesodataallowentityreferences"><code>allow-entityreferences</code></a>, <a href="#Preferenceincludeannotationsodataincludeannotations"><code>include-annotations</code></a>, <a href="#Preferenceomitvalues"><code>omit-values</code></a><code>, </code><a href="#Preferencereturnrepresentationandreturnminimal"><code>return</code></a>), the service MUST include a <code>Vary</code> header listing the <a href="#HeaderPrefer"><code>Prefer</code></a> request header field to allow correct caching of the response.</p>
@@ -885,10 +885,10 @@ <h3 id="912-response-code-201-created"><a name="ResponseCode201Created" href="#R
 <h3 id="913-response-code-202-accepted"><a name="ResponseCode202Accepted" href="#ResponseCode202Accepted">9.1.3 Response Code <code>202 Accepted</code></a></h3>
 <p><code>202 Accepted</code> indicates that the <a href="#DataServiceRequests">Data Service Request</a> has been accepted and has not yet completed executing asynchronously. The asynchronous handling of requests is defined in the sections on <a href="#AsynchronousRequests">Asynchronous Requests</a> and <a href="#AsynchronousBatchRequests">Asynchronous Batch Requests</a>.</p>
 <h3 id="914-response-code-204-no-content"><a name="ResponseCode204NoContent" href="#ResponseCode204NoContent">9.1.4 Response Code <code>204 No Content</code></a></h3>
-<p>A request returns <code>204 No Content</code> if the requested resource has the <code>null</code> value, or if the service applies a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code> preference</a>. In this case, the response body MUST be empty.</p>
+<p>A request returns <code>204 No Content</code> if the requested resource has the <code>null</code> value, or if the service applies a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code></a> preference. In this case, the response body MUST be empty.</p>
 <p>As defined in <a href="#rfc7231">RFC7231</a>, a <a href="#DataModification">Data Modification Request</a> that responds with <code>204 No Content MAY </code>include an <code>ETag</code> header with a value reflecting the result of the data modification if and only if the client can reasonably “know” the new representation of the resource without actually receiving it. For a <code>PUT</code> request this means that the response body of a corresponding <code>200 OK</code> or <code>201 Created</code> response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no server-calculated values etc. For a <code>PATCH</code> request this means that the response body of a corresponding <code>200 OK</code> or <code>201 Created</code> response would have consisted of all values sent in the request body, plus (for values not sent in the request body) server-side values corresponding to the <code>ETag</code> value sent in the <code>If-Match</code> header of the <code>PATCH</code> request, i.e. the previous values “known” to the client.</p>
 <h3 id="915-response-code-3xx-redirection"><a name="ResponseCode3xxRedirection" href="#ResponseCode3xxRedirection">9.1.5 Response Code <code>3xx Redirection</code></a></h3>
-<p>As per <a href="#rfc7231">RFC7231</a>, a <code>3xx Redirection</code> indicates that further action needs to be taken by the client in order to fulfill the request. In this case, the response SHOULD include a <a href="#HeaderLocation"><code>Location</code> header</a>, as appropriate, with the URL from which the result can be obtained; it MAY include a <a href="#HeaderRetryAfter"><code>Retry-After</code> header</a>.</p>
+<p>As per <a href="#rfc7231">RFC7231</a>, a <code>3xx Redirection</code> indicates that further action needs to be taken by the client in order to fulfill the request. In this case, the response SHOULD include a <a href="#HeaderLocation"><code>Location</code></a> header, as appropriate, with the URL from which the result can be obtained; it MAY include a <a href="#HeaderRetryAfter"><code>Retry-After</code></a> header.</p>
 <h3 id="916-response-code-304-not-modified"><a name="ResponseCode304NotModified" href="#ResponseCode304NotModified">9.1.6 Response Code <code>304 Not Modified</code></a></h3>
 <p>As per <a href="#rfc7232">RFC7232</a>, a <code>304 Not Modified</code> is returned when the client performs a <code>GET</code> request containing an <a href="#HeaderIfNoneMatch"><code>If-None-Match</code></a> header and the content has not changed. In this case the response SHOULD NOT include other headers in order to prevent inconsistencies between cached entity-bodies and updated headers.</p>
 <p>The service MUST ensure that no observable change has occurred to the state of the service as a result of any request that returns a <code>304 Not Modified</code>.</p>
@@ -923,7 +923,7 @@ <h2 id="94-error-response-body"><a name="ErrorResponseBody" href="#ErrorResponse
 </ul>
 <p>Service implementations SHOULD carefully consider which information to include in production environments to guard against potential security concerns around information disclosure.</p>
 <h2 id="95-in-stream-errors"><a name="InStreamErrors" href="#InStreamErrors">9.5 In-Stream Errors</a></h2>
-<p>In the case that the service encounters an error after sending a success status to the client, the service MUST leave the response malformed according to its <a href="#HeaderContentType">content-type</a>. Clients MUST treat the entire response as being in error.</p>
+<p>In the case that the service encounters an error after sending a success status to the client, the service MUST leave the response malformed according to its <a href="#HeaderContentType"><code>Content-Type</code></a>. Clients MUST treat the entire response as being in error.</p>
 <p>Services MAY include the header <a href="#HeaderODataError"><code>OData-Error</code></a> as a trailing header if supported by the transport protocol (e.g. HTTP/1.1 with chunked transfer encoding, or HTTP/2).</p>
 <hr />
 <h1 id="10-context-url"><a name="ContextURL" href="#ContextURL">10 Context URL</a></h1>
@@ -1223,13 +1223,13 @@ <h3 id="1112-metadata-document-request"><a name="MetadataDocumentRequest" href="
 <p><a href="#ODataCSDL">OData-CSDLJSON</a> describes a JSON representation for OData metadata documents and provides a JSON schema to validate their contents. The media type of the JSON representation of an OData metadata document is <code>application/json</code>.</p>
 <p><a href="#ODataCSDL">OData-CSDLXML</a> describes an XML representation for OData metadata documents and provides an XML schema to validate their contents. The media type of the XML representation of an OData metadata document is <code>application/xml</code>.</p>
 <p>OData services can expose a metadata document that describes the data model exposed by the service. The <em>metadata document URL</em> MUST be the root URL of the service with <code>$metadata</code> appended. To retrieve this document the client issues a <code>GET</code> request to the metadata document URL.</p>
-<p>If a request for metadata does not specify a format preference (via <a href="#HeaderAccept"><code>Accept</code> header</a> or <a href="#SystemQueryOptionformat"><code>$format</code></a>) then the XML representation MUST be returned.</p>
+<p>If a request for metadata does not specify a format preference (via <a href="#HeaderAccept"><code>Accept</code></a> header or <a href="#SystemQueryOptionformat"><code>$format</code></a>) then the XML representation MUST be returned.</p>
 <h2 id="112-requesting-data"><a name="RequestingData" href="#RequestingData">11.2 Requesting Data</a></h2>
 <p>OData services support requests for data via HTTP <code>GET</code> requests.</p>
 <p>The path of the URL specifies the target of the request (for example; the collection of entities, entity, navigation property, structural property, or operation). Additional query operators, such as filter, sort, page, and projection operations are specified through query options.</p>
 <p>This section describes the types of data requests defined by OData. For complete details on the syntax for building requests, see <a href="#ODataURL">OData-URL</a>.</p>
 <p>OData services are hypermedia driven services that return URLs to the client. If a client subsequently requests the advertised resource and the URL has expired, then the service SHOULD respond with <a href="#ResponseCode410Gone"><code>410 Gone</code></a>. If this is not feasible, the service MUST respond with <a href="#ResponseCode404NotFound"><code>404 Not Found</code></a>.</p>
-<p>The format of the returned data is dependent upon the request and the format specified by the client, either in the <a href="#HeaderAccept"><code>Accept</code> header</a> or using the <a href="#SystemQueryOptionformat"><code>$format</code></a> query option. If the client specifies neither an <a href="#HeaderAccept"><code>Accept</code> header</a> nor the <a href="#SystemQueryOptionformat"><code>$format</code></a> query option, the service is allowed to return the response in any format.</p>
+<p>The format of the returned data is dependent upon the request and the format specified by the client, either in the <a href="#HeaderAccept"><code>Accept</code></a> header or using the <a href="#SystemQueryOptionformat"><code>$format</code></a> query option. If the client specifies neither an <a href="#HeaderAccept"><code>Accept</code></a> header nor the <a href="#SystemQueryOptionformat"><code>$format</code></a> query option, the service is allowed to return the response in any format.</p>
 <h3 id="1121-system-query-options"><a name="SystemQueryOptions" href="#SystemQueryOptions">11.2.1 System Query Options</a></h3>
 <p>OData defines a number of system query options that allow refining the request. System query options are prefixed with the dollar (<code>$</code>) character, which is optional in OData 4.01. 4.01 services MUST support case-insensitive system query option names specified with or without the <code>$</code> prefix. Clients that want to work with 4.0 services MUST use lower case names and specify the <code>$</code> prefix.</p>
 <p>The result of the request MUST be as if the system query options were evaluated in the following order.</p>
@@ -1501,7 +1501,7 @@ <h4 id="11262-system-query-option-orderby"><a name="SystemQueryOptionorderby" hr
 <p>Null values come before non-null values when sorting in ascending order and after non-null values when sorting in descending order.</p>
 <p>Items are sorted by the result values of the first expression, and then items with the same value for the first expression are sorted by the result value of the second expression, and so on.</p>
 <p>The Boolean value false comes before the value true in ascending order.</p>
-<p>Services SHOULD order language-dependent strings according to the <a href="#HeaderContentLanguage">content-language</a> of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
+<p>Services SHOULD order language-dependent strings according to the <a href="#HeaderContentLanguage"><code>Content-Language</code></a> of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
 <p>Values of type <code>Edm.Stream</code> or any of the <code>Geo</code> types cannot be sorted.</p>
 <div class="example">
 <p>Example 50: return all Products ordered by release date in ascending order, then by rating in descending order</p>
@@ -1609,8 +1609,8 @@ <h3 id="1127-requesting-related-entities"><a name="RequestingRelatedEntities" hr
 <h3 id="1128-requesting-entity-references"><a name="RequestingEntityReferences" href="#RequestingEntityReferences">11.2.8 Requesting Entity References</a></h3>
 <p>To request <a href="#EntityIdsandEntityReferences">entity references</a> in place of the actual entities, the client issues a <code>GET</code> request with <code>/$ref</code> appended to the resource path.</p>
 <p>If the resource path does not identify an entity or a collection of entities, the service returns <a href="#ResponseCode404NotFound"><code>404 Not Found</code></a>.</p>
-<p>If the resource path identifies a collection, the response MUST be the format-specific representation of a collection of entity references pointing to the related entities. If no entities are related, the response is the format-specific representation of an empty collection. The response MAY contain an <a href="#HeaderETag">ETag header</a> for the collection whose value changes if the collection of references changes, i.e. a reference is added or removed.</p>
-<p>If the resource path identifies a single existing entity, the response MUST be the format-specific representation of an entity reference. The response MAY contain an <a href="#HeaderETag">ETag header</a> which represents the identity of the referenced entity. If the resource path terminates in a single-valued navigation path, the ETag value changes if the relationship is changed and points to a different OData entity. If the resource path is the canonical path for a single entity, the returned ETag can never change.</p>
+<p>If the resource path identifies a collection, the response MUST be the format-specific representation of a collection of entity references pointing to the related entities. If no entities are related, the response is the format-specific representation of an empty collection. The response MAY contain an <a href="#HeaderETag"><code>ETag</code></a> header for the collection whose value changes if the collection of references changes, i.e. a reference is added or removed.</p>
+<p>If the resource path identifies a single existing entity, the response MUST be the format-specific representation of an entity reference. The response MAY contain an <a href="#HeaderETag"><code>ETag</code></a> header which represents the identity of the referenced entity. If the resource path terminates in a single-valued navigation path, the ETag value changes if the relationship is changed and points to a different OData entity. If the resource path is the canonical path for a single entity, the returned ETag can never change.</p>
 <p>If the resource path terminates on a single entity and no such entity exists, the service returns either <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> or <a href="#ResponseCode404NotFound"><code>404 Not Found</code></a>.</p>
 <div class="example">
 <p>Example 66: collection with an entity reference for each Order related to the Product with <code>ID=0</code></p>
@@ -1711,15 +1711,15 @@ <h3 id="1133-delta-payloads"><a name="DeltaPayloads" href="#DeltaPayloads">11.3.
 <h2 id="114-data-modification"><a name="DataModification" href="#DataModification">11.4 Data Modification</a></h2>
 <p>Updatable OData services support Create, Update, and Delete operations for some or all exposed entities. Additionally, <a href="#Actions">Actions</a> supported by a service can affect the state of the system.</p>
 <p>A successfully completed <a href="#DataModification">Data Modification Request</a> must not violate the integrity of the data.</p>
-<p>The client may request whether content be returned from a Create, Update, or Delete request, or the invocation of an Action, by specifying the <a href="#Preferencereturnrepresentationandreturnminimal"><code>return</code> Prefer header</a>.</p>
+<p>The client may request whether content be returned from a Create, Update, or Delete request, or the invocation of an Action, by specifying the <a href="#Preferencereturnrepresentationandreturnminimal"><code>return</code></a> preference.</p>
 <h3 id="1141-common-data-modification-semantics"><a name="CommonDataModificationSemantics" href="#CommonDataModificationSemantics">11.4.1 Common Data Modification Semantics</a></h3>
 <p><a href="#DataModification">Data Modification Requests</a> share the following semantics.</p>
 <h4 id="11411-use-of-etags-for-avoiding-update-conflicts"><a name="UseofETagsforAvoidingUpdateConflicts" href="#UseofETagsforAvoidingUpdateConflicts">11.4.1.1 Use of ETags for Avoiding Update Conflicts</a></h4>
 <p>Each entity has its own ETag value that MUST change when structural properties or links from that entity have changed. In addition, modifying, adding, or deleting a contained entity MAY change the ETag of the parent entity.</p>
 <p>Collections of entities (including collections of related entities) MAY have their own ETag value whose semantics is service-specific. It typically changes if entities are added to or removed from the collection, or if an entity in the collection is changed. The ETag of a collection of related entities reached via a navigation property MAY differ from the ETag of the entity containing the navigation property.</p>
 <p>A <a href="#DataModification">Data Modification Request</a> on an existing resource or an <a href="#Actions">Action Request</a> invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency"><code>Core.OptimisticConcurrency</code></a> in <a href="#ODataVocCore">OData-VocCore</a> and <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#NavigationRestrictions"><code>Capabilities.NavigationRestrictions</code></a> (nested property <code>OptimisticConcurrencyControl</code>) in <a href="#ODataVocCap">OData-VocCap</a>.</p>
-<p>If optimistic concurrency control is required for a resource, the service MUST include an <a href="#HeaderETag">ETag header</a> in a response to a <code>GET</code> request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource.</p>
-<p>The presence of an <a href="#HeaderETag">ETag header</a> in a response does not imply in itself that the resource requires optimistic concurrency control; the ETag may just be used for caching and/or conditional <code>GET</code> requests.</p>
+<p>If optimistic concurrency control is required for a resource, the service MUST include an <a href="#HeaderETag"><code>ETag</code></a> header in a response to a <code>GET</code> request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource.</p>
+<p>The presence of an <a href="#HeaderETag"><code>ETag</code></a> header in a response does not imply in itself that the resource requires optimistic concurrency control; the ETag may just be used for caching and/or conditional <code>GET</code> requests.</p>
 <p>If an ETag value is specified in an <a href="#HeaderIfMatch"><code>If-Match</code></a> or <a href="#HeaderIfNoneMatch"><code>If-None-Match</code></a> header of a <a href="#DataModification">Data Modification Request</a> or <a href="#Actions">Action Request</a>, the operation MUST only be invoked if the <code>If-Match</code> or <code>If-None-Match</code> condition is satisfied.</p>
 <p>If the client does not specify an <a href="#HeaderIfMatch"><code>If-Match</code></a> request header in a <a href="#DataModification">Data Modification Request</a> or <a href="#Actions">Action Request</a> on a resource that requires optimistic concurrency control, the service responds with a <code>428 Precondition Required</code> and MUST ensure that no observable change occurs as a result of the request. Clients can attempt to disable optimistic concurrency control by specifying <code>If-Match</code> with a value of <code>*</code>. Services MAY reject such requests.</p>
 <p>For requests including an <a href="#HeaderODataVersion"><code>OData-Version</code></a> header value of <code>4.01</code>, any ETag values specified in the request body of an <a href="#UpdateanEntity">update request</a> MUST be <code>*</code> or match the current value for the record being updated.</p>
@@ -1747,8 +1747,8 @@ <h3 id="1142-create-an-entity"><a name="CreateanEntity" href="#CreateanEntity">1
 <p>If the entity being created is not an open entity, additional property values beyond those specified in the metadata SHOULD NOT be sent in the request body. The service MUST fail if unable to persist all property values specified in the request.</p>
 <p>Properties computed by the service (annotated with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#Computed"><code>Core.Computed</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>) and properties that are tied to properties of the principal entity by a referential constraint, can be omitted and MUST be ignored if included in the request.</p>
 <p>Properties with a defined default value, nullable properties, and collection-valued properties omitted from the request are set to the default value, null, or an empty collection, respectively.</p>
-<p>Upon successful completion, the response MUST contain a <a href="#HeaderLocation"><code>Location</code> header</a> that contains the edit URL or read URL of the created entity.</p>
-<p>Upon successful completion the service MUST respond with either <a href="#ResponseCode201Created"><code>201 Created</code></a> and a representation of the created entity, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> if the request included a <a href="#Preferencereturnrepresentationandreturnminimal">Prefer header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code></a> and did not include the system query options <a href="#SystemQueryOptionselect"><code>$select</code></a> and <a href="#SystemQueryOptionexpand"><code>$expand</code></a>.</p>
+<p>Upon successful completion, the response MUST contain a <a href="#HeaderLocation"><code>Location</code></a> header that contains the edit URL or read URL of the created entity.</p>
+<p>Upon successful completion the service MUST respond with either <a href="#ResponseCode201Created"><code>201 Created</code></a> and a representation of the created entity, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> if the request included a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code></a> preference and did not include the system query options <a href="#SystemQueryOptionselect"><code>$select</code></a> and <a href="#SystemQueryOptionexpand"><code>$expand</code></a>.</p>
 <h4 id="11421-link-to-related-entities-when-creating-an-entity"><a name="LinktoRelatedEntitiesWhenCreatinganEntity" href="#LinktoRelatedEntitiesWhenCreatinganEntity">11.4.2.1 Link to Related Entities When Creating an Entity</a></h4>
 <p>To create a new entity with links to existing entities in a single request, the client includes references to the related entities in the request body.</p>
 <p>The representation for referencing related entities is format-specific.</p>
@@ -1805,7 +1805,7 @@ <h3 id="1143-update-an-entity"><a name="UpdateanEntity" href="#UpdateanEntity">1
 <p>If an update specifies both a binding to a single-valued navigation property and a dependent property that is tied to a key property of the principal entity according to the same navigation property, then the dependent property is ignored, and the relationship is updated according to the value specified in the binding.</p>
 <p>If the entity being updated is open, then additional values for properties beyond those specified in the metadata or returned in a previous request MAY be sent in the request body. The service MUST treat these as dynamic properties.</p>
 <p>If the entity being updated is not open, then additional values for properties beyond those specified in the metadata or returned in a previous request SHOULD NOT be sent in the request body. The service MUST fail if it is unable to persist all updatable property values specified in the request.</p>
-<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> and a representation of the updated entity, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal"><code>Prefer</code> header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a>, or by specifying the system query options <a href="#SystemQueryOptionselect"><code>$select</code></a> or <a href="#SystemQueryOptionexpand"><code>$expand</code></a>. If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags.</p>
+<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> and a representation of the updated entity, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a> preference, or by specifying the system query options <a href="#SystemQueryOptionselect"><code>$select</code></a> or <a href="#SystemQueryOptionexpand"><code>$expand</code></a>. If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags.</p>
 <h4 id="11431-update-related-entities-when-updating-an-entity"><a name="UpdateRelatedEntitiesWhenUpdatinganEntity" href="#UpdateRelatedEntitiesWhenUpdatinganEntity">11.4.3.1 Update Related Entities When Updating an Entity</a></h4>
 <p>Update requests with an OData-Version header with a value of <code>4.0</code> MUST NOT contain related entities as inline content. Such requests MAY contain binding information for navigation properties. For single-valued navigation properties this replaces the relationship. For collection-valued navigation properties this adds to the relationship.</p>
 <p>Payloads with an <code>OData-Version</code> header with a value of <code>4.01</code> or greater MAY include nested entities and entity references that specify the full set of to be related entities, or a nested <a href="#DeltaPayloads">delta payload</a> representing the related entities that have been added, removed, or changed. Such a request is referred to as a “deep update”. If the nested collection is represented identical to an expanded navigation property, then the set of nested entities and entity references specified in a successful update request represents the full set of entities to be related according to that relationship and MUST NOT include added links, deleted links, or deleted entities.</p>
@@ -1878,8 +1878,8 @@ <h3 id="1144-upsert-an-entity"><a name="UpsertanEntity" href="#UpsertanEntity">1
 <p>Upserts are not supported against <a href="#RequestingtheMediaStreamofaMediaEntityusingvalue">media entities</a>, single-valued non-containment navigation properties, or entities whose keys values are generated by the service. Services MUST fail an update request to a URL that would identify such an entity and the entity does not yet exist.</p>
 <p>Singleton entities can be upserted if they are nullable. Services supporting this SHOULD advertise it by annotating the singleton with the term <code>Capabilities.UpdateRestrictions</code> (nested property <code>Upsertable</code> with value <code>true</code>) defined in <a href="#ODataVocCap">OData-VocCap</a>.</p>
 <p>Key and other non-updatable properties, as well as dependent properties that are not tied to key properties of the principal entity, MUST be ignored by the service in processing the Upsert request.</p>
-<p>To ensure that an update request is not treated as an insert, the client MAY specify an <a href="#HeaderIfMatch"><code>If-Match</code> header</a> in the update request. The service MUST NOT treat an update request containing an <code>If-Match</code> header as an insert.</p>
-<p>A <code>PUT</code> or <code>PATCH</code> request MUST NOT be treated as an update if an <a href="#HeaderIfNoneMatch"><code>If-None-Match</code> header</a> is specified with a value of <code>*</code>.</p>
+<p>To ensure that an update request is not treated as an insert, the client MAY specify an <a href="#HeaderIfMatch"><code>If-Match</code></a> header in the update request. The service MUST NOT treat an update request containing an <code>If-Match</code> header as an insert.</p>
+<p>A <code>PUT</code> or <code>PATCH</code> request MUST NOT be treated as an update if an <a href="#HeaderIfNoneMatch"><code>If-None-Match</code></a> header is specified with a value of <code>*</code>.</p>
 <h3 id="1145-delete-an-entity"><a name="DeleteanEntity" href="#DeleteanEntity">11.4.5 Delete an Entity</a></h3>
 <p>To delete an individual entity, the client makes a <code>DELETE</code> request to a URL that identifies the entity. Services MAY restrict deletes only to requests addressing the <a href="#ReadURLsandEditURLs">edit URL</a> of the entity.</p>
 <p>The request body SHOULD be empty. Top-level singleton entities can be deleted if they are nullable. Services supporting this MAY advertise it by annotating the singleton with the term <code>Capabilities.DeleteRestrictions</code> (nested property <code>Deletable</code> with value <code>true</code>) defined in <a href="#ODataVocCap">OData-VocCap</a>.</p>
@@ -1912,8 +1912,8 @@ <h3 id="1147-managing-media-entities"><a name="ManagingMediaEntities" href="#Man
 <p>Because a media entity has both a media stream and standard entity properties special handling is required.</p>
 <h4 id="11471-create-a-media-entity"><a name="CreateaMediaEntity" href="#CreateaMediaEntity">11.4.7.1 Create a Media Entity</a></h4>
 <p>A <code>POST</code> request to a media entity’s entity set creates a new media entity. The request body MUST contain the media value (for example, the photograph) whose media type MUST be specified in a <a href="#HeaderContentType"><code>Content-Type</code></a> header. The request body is always interpreted as the media value, even if it has the media type of an OData format supported by the service. It is not possible to set the structural properties of the media entity when creating the media entity.</p>
-<p>Upon successful completion, the response MUST contain <a href="#HeaderLocation"><code>Location</code> header</a> that contains the edit URL of the created media entity.</p>
-<p>Upon successful completion the service responds with either <a href="#ResponseCode201Created"><code>201 Created</code></a>, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> if the request included a <a href="#Preferencereturnrepresentationandreturnminimal"><code>Prefer</code> header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code></a>.</p>
+<p>Upon successful completion, the response MUST contain <a href="#HeaderLocation"><code>Location</code></a> header that contains the edit URL of the created media entity.</p>
+<p>Upon successful completion the service responds with either <a href="#ResponseCode201Created"><code>201 Created</code></a>, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> if the request included a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=minimal</code></a> preference.</p>
 <h4 id="11472-update-a-media-entity-stream"><a name="UpdateaMediaEntityStream" href="#UpdateaMediaEntityStream">11.4.7.2 Update a Media Entity Stream</a></h4>
 <p>A successful <code>PUT</code> request to the media edit URL of a media entity changes the media stream of the entity.</p>
 <p>If the entity includes an ETag value for the media stream, the client MUST include an <a href="#HeaderIfMatch"><code>If-Match</code></a> header with the ETag value.</p>
@@ -1966,7 +1966,7 @@ <h4 id="11491-update-a-primitive-property"><a name="UpdateaPrimitiveProperty" hr
 <p>A successful <code>PUT</code> request to the edit URL for a primitive property updates the value of the property. The message body MUST contain the new value, formatted as a single property according to the specified format.</p>
 <p>A successful <code>PUT</code> request to the edit URL for the <a href="#RequestingaPropertysRawValueusingvalue">raw value</a> of a primitive property updates the property with the raw value specified in the payload. The payload MUST be formatted as an appropriate content type for the raw value of the property.</p>
 <p>The same rules apply whether this is a regular property or a dynamic property.</p>
-<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal">Prefer header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a>.</p>
+<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a> preference.</p>
 <p>Services MUST return an error if the property is not updatable.</p>
 <h4 id="11492-set-a-value-to-null"><a name="SetaValuetoNull" href="#SetaValuetoNull">11.4.9.2 Set a Value to Null</a></h4>
 <p>A successful <code>DELETE</code> request to the edit URL for a structural property, or to the edit URL of the <a href="#RequestingaPropertysRawValueusingvalue">raw value</a> of a primitive property, sets the property to null. The request body is ignored and should be empty.</p>
@@ -1980,7 +1980,7 @@ <h4 id="11493-update-a-complex-property"><a name="UpdateaComplexProperty" href="
 <p>The service MUST directly modify only those properties of the complex type specified in the payload of the <code>PATCH</code> request.</p>
 <p>If a complex-typed property is set to a different type in a <code>PATCH</code> request, properties shared through inheritance, as well as dynamic properties, are retained (unless overwritten by new values in the payload). Other properties of the original type are discarded.</p>
 <p>The service MAY additionally support clients sending a <code>PUT</code> request to a URL that specifies a complex type. In this case, the service MUST replace the entire complex property with the values specified in the request body and set all unspecified properties to their default value.</p>
-<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal">Prefer header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a>.</p>
+<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a> preference.</p>
 <p>Services MUST return an error if the property is not updatable.</p>
 <h4 id="11494-update-a-collection-property"><a name="UpdateaCollectionProperty" href="#UpdateaCollectionProperty">11.4.9.4 Update a Collection Property</a></h4>
 <p>A successful <code>PUT</code> request to the edit URL of a collection property updates that collection. The message body MUST contain the desired new value, formatted as a collection property according to the specified format.</p>
@@ -1988,7 +1988,7 @@ <h4 id="11494-update-a-collection-property"><a name="UpdateaCollectionProperty"
 <p>A successful <code>POST</code> request to the edit URL of a collection property adds an item to the collection. The body of the request MUST be a single item to be added to the collection. If the collection is ordered, the item is added to the end of the collection, and if the collection supports positional insert <a href="#RequestinganIndividualMemberofanOrderedCollection"><code>$index</code></a> MAY be used to specify the insert position.</p>
 <p>A successful <code>DELETE</code> request to the edit URL of a collection property deletes all items in that collection.</p>
 <p>Since collection members have no individual identity, <code>PATCH</code> is not supported for collection properties.</p>
-<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> and a representation of the updated collection, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal">Prefer header</a> with a value of <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a>.</p>
+<p>Upon successful completion the service responds with either <a href="#ResponseCode200OK"><code>200 OK</code></a> and a representation of the updated collection, or <a href="#ResponseCode204NoContent"><code>204 No Content</code></a>. The client may request that the response SHOULD include a body by specifying a <a href="#Preferencereturnrepresentationandreturnminimal"><code>return=representation</code></a> preference.</p>
 <p>Services MUST return an error if the property is not updatable.</p>
 <h3 id="11410-managing-members-of-an-ordered-collection"><a name="ManagingMembersofanOrderedCollection" href="#ManagingMembersofanOrderedCollection">11.4.10 Managing Members of an Ordered Collection</a></h3>
 <p>Collections annotated with the <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#Ordered"><code>Core.Ordered</code></a> term (see <a href="#ODataVocCore">OData-VocCore</a>) have a stable order. Members of an ordered collection of primitive and complex types can be individually updated or deleted by invoking an update operation against the URL of the collection appended by a segment containing the zero-based ordinal of the item within the collection. A negative ordinal number indexes from the end of the collection, with -1 representing the last item in the collection.</p>
@@ -2179,11 +2179,11 @@ <h4 id="11551-invoking-an-action"><a name="InvokinganAction" href="#InvokinganAc
 <p>Non-binding parameters that are nullable or annotated with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter"><code>Core.OptionalParameter</code></a> defined in <a href="#ODataVocCore">OData-VocCore</a> MAY be omitted from the request body. If an omitted parameter is not annotated (and thus nullable), it MUST be interpreted as having the <code>null</code> value. If it is annotated and the annotation specifies a <code>DefaultValue</code>, the omitted parameter is interpreted as having that default value. If omitted and the annotation does not specify a default value, the service is free on how to interpret the omitted parameter. Note: a nullable non-binding parameter is equivalent to being annotated as optional with a default value of <code>null</code>.</p>
 <p>4.01 services MUST support invoking actions with no non-binding parameters and parameterless action imports both without a request body and with a request body representing no parameters, according to the particular format. Interoperable clients SHOULD always include a request body, even when invoking actions with no non-binding parameters and parameterless action imports.</p>
 <p>If the action returns results, the client SHOULD use content type negotiation to request the results in the desired format, otherwise the default content type will be used.</p>
-<p>The client can request whether any results from the action be returned using the <a href="#Preferencereturnrepresentationandreturnminimal"><code>return Prefer</code> header</a>.</p>
-<p>Actions that create and return a single entity follow the rules for <a href="#CreateanEntity">entity creation</a> and return a <a href="#HeaderLocation"><code>Location</code> header</a> that contains the edit URL or read URL of the created entity.</p>
+<p>The client can request whether any results from the action be returned using the <a href="#Preferencereturnrepresentationandreturnminimal"><code>return</code></a> preference.</p>
+<p>Actions that create and return a single entity follow the rules for <a href="#CreateanEntity">entity creation</a> and return a <a href="#HeaderLocation"><code>Location</code></a> header that contains the edit URL or read URL of the created entity.</p>
 <p>If the action returns a value of type <code>Edm.Stream</code>, the response to the <code>POST</code> request follows the rules for <a href="#RequestingStreamProperties">requesting stream properties</a>.</p>
 <p>Actions without a return type respond with <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> on success.</p>
-<p>To request processing of the action only if the binding parameter value, an entity or collection of entities, is unmodified, the client includes the <a href="#HeaderIfMatch"><code>If-Match</code></a> header with the latest known ETag value for the entity or collection of entities. The ETag value for a collection as a whole is transported in the <code>ETag</code> header of a collection response.</p>
+<p>To request processing of the action only if the binding parameter value, an entity or collection of entities, is unmodified, the client includes the <a href="#HeaderIfMatch"><code>If-Match</code></a> header with the latest known ETag value for the entity or collection of entities. The ETag value for a collection as a whole is transported in the <a href="#HeaderETag"><code>ETag</code></a> header of a collection response.</p>
 <div class="example">
 <p>Example 98: invoke the <code>SampleEntities.CreateOrder</code> action using <code>Customers('ALFKI')</code> as the customer (or binding parameter). The values <code>2</code> for the <code>quantity</code> parameter and <code>BLACKFRIDAY</code> for the <code>discountCode</code> parameter are passed in the body of the request. Invoke the action only if the customer’s ETag still matches.</p>
 <div class="sourceCode" id="cb120"><pre class="sourceCode json"><code class="sourceCode json"><span id="cb120-1"><a href="#cb120-1" aria-hidden="true" tabindex="-1"></a><span class="er">POST</span> <span class="er">http://host/service/Customers(&#39;ALFKI&#39;)/SampleEntities.CreateOrder</span></span>
@@ -2202,12 +2202,12 @@ <h4 id="11552-action-overload-resolution"><a name="ActionOverloadResolution" hre
 <p>The same action name may be used multiple times within a schema provided there is at most one unbound overload, and each bound overload specifies a different binding parameter type.</p>
 <p>If the action is bound and the binding parameter type is part of an inheritance hierarchy, the action overload is selected based on the type of the URL segment preceding the action name. A type-cast segment can be used to select an action defined on a particular type in the hierarchy, see <a href="#ODataURL">OData-URL</a>.</p>
 <h2 id="116-asynchronous-requests"><a name="AsynchronousRequests" href="#AsynchronousRequests">11.6 Asynchronous Requests</a></h2>
-<p>A <a href="#HeaderPrefer">Prefer</a> header with a <a href="#Preferencerespondasync"><code>respond-async</code></a> preference allows clients to request that the service process a <a href="#DataServiceRequests">Data Service Request</a> asynchronously.</p>
+<p>A <a href="#HeaderPrefer"><code>Prefer</code></a> header with a <a href="#Preferencerespondasync"><code>respond-async</code></a> preference allows clients to request that the service process a <a href="#DataServiceRequests">Data Service Request</a> asynchronously.</p>
 <p>If the client has specified<code> respond-async</code> in the request, the service MAY process the request asynchronously and return a <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response. A service MUST NOT reply to a <a href="#DataServiceRequests">Data Service Request</a> with <code>202 Accepted</code> if the request has not included the <code>respond-async</code> preference.</p>
-<p>Responses that return <code>202 Accepted</code> MUST include a <a href="#HeaderLocation"><code>Location</code> header</a> pointing to a <em>status monitor resource</em> that represents the current state of the asynchronous processing in addition to an optional <a href="#HeaderRetryAfter"><code>Retry-After</code> header</a> indicating the time, in seconds, the client should wait before querying the service for status. Services MAY include a response body, for example, to provide additional status information.</p>
-<p>A <code>GET</code> request to the status monitor resource again returns <code>202 Accepted</code> response if the asynchronous processing has not finished. This response MUST again include a <a href="#HeaderLocation"><code>Location</code> header</a> and MAY include a <a href="#HeaderRetryAfter"><code>Retry-After</code> header</a> to be used for a subsequent request. The <code>Location</code> header and optional <code>Retry-After</code> header may or may not contain the same values as returned by the previous request.</p>
+<p>Responses that return <code>202 Accepted</code> MUST include a <a href="#HeaderLocation"><code>Location</code></a> header pointing to a <em>status monitor resource</em> that represents the current state of the asynchronous processing in addition to an optional <a href="#HeaderRetryAfter"><code>Retry-After</code></a> header indicating the time, in seconds, the client should wait before querying the service for status. Services MAY include a response body, for example, to provide additional status information.</p>
+<p>A <code>GET</code> request to the status monitor resource again returns <code>202 Accepted</code> response if the asynchronous processing has not finished. This response MUST again include a <a href="#HeaderLocation"><code>Location</code></a> header and MAY include a <a href="#HeaderRetryAfter"><code>Retry-After</code></a> header to be used for a subsequent request. The <code>Location</code> header and optional <code>Retry-After</code> header may or may not contain the same values as returned by the previous request.</p>
 <p>A <code>GET</code> request to the status monitor resource returns <a href="#ResponseCode200OK"><code>200 OK</code></a> once the asynchronous processing has completed. For OData 4.01 and greater responses, or OData 4.0 requests that include an <code>Accept</code> header that does not specify <code>application/http</code>, the response MUST include the <a href="#HeaderAsyncResult"><code>AsyncResult</code></a> response header. Any other headers, along with the response body, represent the result of the completed asynchronous operation. If the <code>GET</code> request to the status monitor includes an <code>OData-MaxVersion</code> header with a value of <code>4.0</code> and no <code>Accept</code> header, or an <code>Accept</code> header that includes <code>application/http</code>, then the body of the final <code>200 OK</code> response MUST be represented as an HTTP message, as described in <a href="#rfc7230">RFC7230</a>, which is the full HTTP response to the completed asynchronous operation.</p>
-<p>A <code>DELETE</code> request sent to the status monitor resource requests that the asynchronous processing be canceled. A <code>200 OK</code> or a <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> response indicates that the asynchronous processing has been successfully canceled. A client can request that the <code>DELETE</code> should be executed asynchronously. A <code>202 Accepted</code> response indicates that the cancellation is being processed asynchronously; the client can use the returned <a href="#HeaderLocation"><code>Location</code> header</a> (which MUST be different from the status monitor resource of the initial request) to query for the status of the cancellation. If a delete request is not supported by the service, the service returns <a href="#ResponseCode405MethodNotAllowed"><code>405 Method Not Allowed</code></a>.</p>
+<p>A <code>DELETE</code> request sent to the status monitor resource requests that the asynchronous processing be canceled. A <code>200 OK</code> or a <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> response indicates that the asynchronous processing has been successfully canceled. A client can request that the <code>DELETE</code> should be executed asynchronously. A <code>202 Accepted</code> response indicates that the cancellation is being processed asynchronously; the client can use the returned <a href="#HeaderLocation"><code>Location</code></a> header (which MUST be different from the status monitor resource of the initial request) to query for the status of the cancellation. If a delete request is not supported by the service, the service returns <a href="#ResponseCode405MethodNotAllowed"><code>405 Method Not Allowed</code></a>.</p>
 <p>After a successful <code>DELETE</code> request against the status monitor resource, any subsequent <code>GET</code> requests for the same status monitor resource returns <a href="#ResponseCode404NotFound"><code>404 Not Found</code></a>.</p>
 <p>If an asynchronous request is cancelled for reasons other than the consumers issuing a <code>DELETE</code> request against the status monitor resource, a <code>GET</code> request to the status monitor resource returns <code>200 OK</code> with a response body containing a single HTTP response with a status code in the <a href="#ServerErrorResponses"><code>5xx Server Error</code></a> range indicating that the operation was cancelled.</p>
 <p>The service MUST ensure that no observable change has occurred as a result of a canceled request.</p>
diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md
index 2525bba86..8e43e236c 100644
--- a/docs/odata-protocol/odata-protocol.md
+++ b/docs/odata-protocol/odata-protocol.md
@@ -912,7 +912,7 @@ parameters within the `Content-Type` header.
 
 As defined in [RFC7231](#rfc7231), the `Content-Encoding` header
 field is used as a modifier to the media-type (as indicated in the
-`Content-Type`). When present, its value indicates what additional
+`Content-Type` header). When present, its value indicates what additional
 content codings have been applied to the entity-body.
 A service MAY specify a list of acceptable content codings using an
 annotation with term
@@ -1008,7 +1008,7 @@ If the media type specified in the `Accept` header does not include a
 contain a `charset` format parameter.
 
 The service SHOULD NOT add any format parameters to the `Content-Type`
-parameter not specified in the `Accept` header.
+header not specified in the `Accept` header.
 
 If the `Accept` header is specified on an individual request within a
 batch, then it specifies the acceptable formats for that individual
@@ -1058,7 +1058,7 @@ occurs as a result of the request.
 
 If present, the request MUST only be processed if the specified ETag
 value matches the current ETag value of the target resource. Services
-sending [`ETag` headers](#HeaderETag) with weak ETags that only depend
+sending [`ETag`](#HeaderETag) headers with weak ETags that only depend
 on the representation-independent entity state MUST use the weak
 comparison function because it is sufficient to prevent accidental
 overwrites. This is a deviation from [RFC7232](#rfc7232).
@@ -1255,14 +1255,14 @@ If the service applies the `callback` preference it MUST include the
 When the `callback` preference is applied to asynchronous requests, the
 OData service invokes the callback endpoint once it has finished
 processing the request. The status monitor resource, returned in the
-[`Location` header](#HeaderLocation) of the previously returned
+[`Location`](#HeaderLocation) header of the previously returned
 [`202 Accepted`](#ResponseCode202Accepted) response, can then be used to
 retrieve the results of the asynchronously executed request.
 
 When the `callback` preference is specified on a `GET` request to a
 delta link and there are no changes available, the OData service returns
-a [`202 Accepted`](#ResponseCode202Accepted) response with a [`Location`
-header](#HeaderLocation) specifying the delta link to be used to check
+a [`202 Accepted`](#ResponseCode202Accepted) response with a
+[`Location`](#HeaderLocation) header specifying the delta link to be used to check
 for future updates. The OData service then invokes the specified
 callback endpoint once new changes become available.
 
@@ -1736,8 +1736,8 @@ and in [`3xx Redirect`](#ResponseCode3xxRedirection) responses
 
 The `Retry-After` header specifies the duration of time, in seconds,
 that the client is asked to wait before retrying the request or issuing
-a request to the resource returned as the value of the [`Location`
-header](#HeaderLocation).
+a request to the resource returned as the value of the
+[`Location`](#HeaderLocation) header.
 
 ### <a name="HeaderVary" href="#HeaderVary">8.3.8 Header `Vary`</a>
 
@@ -1801,8 +1801,9 @@ Requests](#AsynchronousBatchRequests).
 ### <a name="ResponseCode204NoContent" href="#ResponseCode204NoContent">9.1.4 Response Code `204 No Content`</a>
 
 A request returns `204 No Content` if the requested resource has the
-`null` value, or if the service applies a [`return=minimal`
-preference](#Preferencereturnrepresentationandreturnminimal). In this case, the response body MUST be empty.
+`null` value, or if the service applies a
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference.
+In this case, the response body MUST be empty.
 
 As defined in [RFC7231](#rfc7231), a [Data Modification
 Request](#DataModification) that responds with
@@ -1824,10 +1825,10 @@ server-side values corresponding to the `ETag` value sent in the
 
 As per [RFC7231](#rfc7231), a `3xx Redirection` indicates that
 further action needs to be taken by the client in order to fulfill the
-request. In this case, the response SHOULD include a [`Location`
-header](#HeaderLocation), as appropriate, with the URL from which the
-result can be obtained; it MAY include a [`Retry-After`
-header](#HeaderRetryAfter).
+request. In this case, the response SHOULD include a
+[`Location`](#HeaderLocation) header, as appropriate, with the URL from which the
+result can be obtained; it MAY include a
+[`Retry-After`](#HeaderRetryAfter) header.
 
 ### <a name="ResponseCode304NotModified" href="#ResponseCode304NotModified">9.1.6 Response Code `304 Not Modified`</a>
 
@@ -1941,7 +1942,7 @@ concerns around information disclosure.
 
 In the case that the service encounters an error after sending a success
 status to the client, the service MUST leave the response malformed
-according to its [content-type](#HeaderContentType). Clients MUST treat
+according to its [`Content-Type`](#HeaderContentType). Clients MUST treat
 the entire response as being in error.
 
 Services MAY include the header [`OData-Error`](#HeaderODataError) as a
@@ -2607,7 +2608,7 @@ root URL of the service with `$metadata` appended. To retrieve this
 document the client issues a `GET` request to the metadata document URL.
 
 If a request for metadata does not specify a format preference (via
-[`Accept` header](#HeaderAccept) or
+[`Accept`](#HeaderAccept) header or
 [`$format`](#SystemQueryOptionformat)) then the XML representation MUST
 be returned.
 
@@ -2632,10 +2633,10 @@ the URL has expired, then the service SHOULD respond with
 MUST respond with [`404 Not Found`](#ResponseCode404NotFound).
 
 The format of the returned data is dependent upon the request and the
-format specified by the client, either in the [`Accept`
-header](#HeaderAccept) or using the
+format specified by the client, either in the
+[`Accept`](#HeaderAccept) header or using the
 [`$format`](#SystemQueryOptionformat) query option. If
-the client specifies neither an [`Accept` header](#HeaderAccept) nor the
+the client specifies neither an [`Accept`](#HeaderAccept) header nor the
 [`$format`](#SystemQueryOptionformat) query option, the
 service is allowed to return the response in any format.
 
@@ -3291,7 +3292,7 @@ result value of the second expression, and so on.
 The Boolean value false comes before the value true in ascending order.
 
 Services SHOULD order language-dependent strings according to the
-[content-language](#HeaderContentLanguage) of the response, and SHOULD
+[`Content-Language`](#HeaderContentLanguage) of the response, and SHOULD
 annotate string properties with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).
@@ -3583,13 +3584,13 @@ If the resource path identifies a collection, the response MUST be the
 format-specific representation of a collection of entity references
 pointing to the related entities. If no entities are related, the
 response is the format-specific representation of an empty collection.
-The response MAY contain an [ETag header](#HeaderETag) for the
+The response MAY contain an [`ETag`](#HeaderETag) header for the
 collection whose value changes if the collection of references changes,
 i.e. a reference is added or removed.
 
 If the resource path identifies a single existing entity, the response
 MUST be the format-specific representation of an entity reference. The
-response MAY contain an [ETag header](#HeaderETag) which represents the
+response MAY contain an [`ETag`](#HeaderETag) header which represents the
 identity of the referenced entity. If the resource path terminates in a
 single-valued navigation path, the ETag value changes if the
 relationship is changed and points to a different OData entity. If the
@@ -3958,7 +3959,7 @@ must not violate the integrity of the data.
 
 The client may request whether content be returned from a Create,
 Update, or Delete request, or the invocation of an Action, by specifying
-the [`return` Prefer header](#Preferencereturnrepresentationandreturnminimal).
+the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 ### <a name="CommonDataModificationSemantics" href="#CommonDataModificationSemantics">11.4.1 Common Data Modification Semantics</a>
 
@@ -3990,11 +3991,11 @@ announce this via annotations with the terms
 [OData-VocCap](#ODataVocCap).
 
 If optimistic concurrency control is required for a resource, the
-service MUST include an [ETag header](#HeaderETag) in a response to a
+service MUST include an [`ETag`](#HeaderETag) header in a response to a
 `GET` request to the resource, and MAY include the ETag in a
 format-specific manner in responses containing that resource.
 
-The presence of an [ETag header](#HeaderETag) in a response does not
+The presence of an [`ETag`](#HeaderETag) header in a response does not
 imply in itself that the resource requires optimistic concurrency
 control; the ETag may just be used for caching and/or conditional `GET`
 requests.
@@ -4134,16 +4135,15 @@ Properties with a defined default value, nullable properties, and
 collection-valued properties omitted from the request are set to the
 default value, null, or an empty collection, respectively.
 
-Upon successful completion, the response MUST contain a [`Location`
-header](#HeaderLocation) that contains the edit URL or read URL of the
+Upon successful completion, the response MUST contain a
+[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
 created entity.
 
 Upon successful completion the service MUST respond with either
 [`201 Created`](#ResponseCode201Created) and a representation of the
 created entity, or [`204 No Content`](#ResponseCode204NoContent) if the
-request included a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) and did not
+request included a
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference and did not
 include the system query options [`$select`](#SystemQueryOptionselect)
 and [`$expand`](#SystemQueryOptionexpand).
 
@@ -4343,8 +4343,7 @@ Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) and a representation of the updated
 entity, or [`204 No Content`](#ResponseCode204NoContent). The client may
 request that the response SHOULD include a body by specifying a
-[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal), or by
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference, or by
 specifying the system query options
 [`$select`](#SystemQueryOptionselect) or
 [`$expand`](#SystemQueryOptionexpand). If the service uses ETags for
@@ -4508,12 +4507,12 @@ that are not tied to key properties of the principal entity, MUST be
 ignored by the service in processing the Upsert request.
 
 To ensure that an update request is not treated as an insert, the client
-MAY specify an [`If-Match` header](#HeaderIfMatch) in the update
+MAY specify an [`If-Match`](#HeaderIfMatch) header in the update
 request. The service MUST NOT treat an update request containing an
 `If-Match` header as an insert.
 
 A `PUT` or `PATCH` request MUST NOT be treated as an update if an
-[`If-None-Match` header](#HeaderIfNoneMatch) is specified with a value
+[`If-None-Match`](#HeaderIfNoneMatch) header is specified with a value
 of `*`.
 
 ### <a name="DeleteanEntity" href="#DeleteanEntity">11.4.5 Delete an Entity</a>
@@ -4638,15 +4637,14 @@ OData format supported by the service. It is not possible to set the
 structural properties of the media entity when creating the media
 entity.
 
-Upon successful completion, the response MUST contain [`Location`
-header](#HeaderLocation) that contains the edit URL of the created media
+Upon successful completion, the response MUST contain
+[`Location`](#HeaderLocation) header that contains the edit URL of the created media
 entity.
 
 Upon successful completion the service responds with either
 [`201 Created`](#ResponseCode201Created), or
 [`204 No Content`](#ResponseCode204NoContent) if the request included a
-[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=minimal`](#Preferencereturnrepresentationandreturnminimal).
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 #### <a name="UpdateaMediaEntityStream" href="#UpdateaMediaEntityStream">11.4.7.2 Update a Media Entity Stream</a>
 
@@ -4793,9 +4791,8 @@ property.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
@@ -4845,9 +4842,8 @@ request body and set all unspecified properties to their default value.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
@@ -4877,9 +4873,8 @@ supported for collection properties.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) and a representation of the updated collection, or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
@@ -5511,11 +5506,11 @@ negotiation to request the results in the desired format, otherwise the
 default content type will be used.
 
 The client can request whether any results from the action be returned
-using the [`return Prefer` header](#Preferencereturnrepresentationandreturnminimal).
+using the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Actions that create and return a single entity follow the rules for
-[entity creation](#CreateanEntity) and return a [`Location`
-header](#HeaderLocation) that contains the edit URL or read URL of the
+[entity creation](#CreateanEntity) and return a
+[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
 created entity.
 
 If the action returns a value of type `Edm.Stream`, the response to the `POST` request
@@ -5528,7 +5523,7 @@ To request processing of the action only if the binding parameter value,
 an entity or collection of entities, is unmodified, the client includes
 the [`If-Match`](#HeaderIfMatch) header with the latest known ETag value
 for the entity or collection of entities. The ETag value for a
-collection as a whole is transported in the `ETag` header of a
+collection as a whole is transported in the [`ETag`](#HeaderETag) header of a
 collection response.
 
 ::: example
@@ -5566,7 +5561,7 @@ see [OData-URL](#ODataURL).
 
 ## <a name="AsynchronousRequests" href="#AsynchronousRequests">11.6 Asynchronous Requests</a>
 
-A [Prefer](#HeaderPrefer) header with a
+A [`Prefer`](#HeaderPrefer) header with a
 [`respond-async`](#Preferencerespondasync) preference allows clients
 to request that the service process a [Data Service
 Request](#DataServiceRequests) asynchronously.
@@ -5578,18 +5573,18 @@ NOT reply to a [Data Service Request](#DataServiceRequests) with
 `202 Accepted` if the request has not included the `respond-async`
 preference.
 
-Responses that return `202 Accepted` MUST include a [`Location`
-header](#HeaderLocation) pointing to a *status monitor resource* that
+Responses that return `202 Accepted` MUST include a
+[`Location`](#HeaderLocation) header pointing to a *status monitor resource* that
 represents the current state of the asynchronous processing in addition
-to an optional [`Retry-After` header](#HeaderRetryAfter) indicating the
+to an optional [`Retry-After`](#HeaderRetryAfter) header indicating the
 time, in seconds, the client should wait before querying the service for
 status. Services MAY include a response body, for example, to provide
 additional status information.
 
 A `GET` request to the status monitor resource again returns
 `202 Accepted` response if the asynchronous processing has not finished.
-This response MUST again include a [`Location` header](#HeaderLocation)
-and MAY include a [`Retry-After` header](#HeaderRetryAfter) to be used for a subsequent request. The
+This response MUST again include a [`Location`](#HeaderLocation) header
+and MAY include a [`Retry-After`](#HeaderRetryAfter) header to be used for a subsequent request. The
 `Location` header and optional `Retry-After` header may or may not
 contain the same values as returned by the previous request.
 
@@ -5612,7 +5607,7 @@ asynchronous processing be canceled. A `200 OK` or a
 been successfully canceled. A client can request that the `DELETE`
 should be executed asynchronously. A `202 Accepted` response indicates
 that the cancellation is being processed asynchronously; the client can
-use the returned [`Location` header](#HeaderLocation) (which MUST be
+use the returned [`Location`](#HeaderLocation) header (which MUST be
 different from the status monitor resource of the initial request) to
 query for the status of the cancellation. If a delete request is not
 supported by the service, the service returns
diff --git a/docs/odata-url-conventions/odata-url-conventions.html b/docs/odata-url-conventions/odata-url-conventions.html
index a939a6207..1e6b5a6fc 100644
--- a/docs/odata-url-conventions/odata-url-conventions.html
+++ b/docs/odata-url-conventions/odata-url-conventions.html
@@ -840,7 +840,7 @@ <h2 id="417-passing-query-options-in-the-request-body"><a name="PassingQueryOpti
 <p>The query options part of an OData URL can be quite long, potentially exceeding the maximum length of URLs supported by components involved in transmitting or processing the request. One way to avoid this is wrapping the request in a batch request, which has the penalty of needing to construct a well-formed batch request body.</p>
 <p>An easier alternative for <code>GET</code> requests is to append <code>/$query</code> to the resource path of the URL, use the <code>POST</code> verb instead of <code>GET</code>, and pass the query options part of the URL in the request body.</p>
 <p>Requests to paths ending in <code>/$query</code> MUST use the <code>POST</code> verb. Query options specified in the request body and query options specified in the request URL are processed together.</p>
-<p>The request body MUST use the content-type <code>text/plain</code>. It contains the query portion of the URL and MUST use the same percent-encoding as in URLs (especially: no spaces, tabs, or line breaks allowed) and MUST follow the syntax rules described in chapter Query Options.</p>
+<p>The request body MUST use <code>Content-Type: text/plain</code>. It contains the query portion of the URL and MUST use the same percent-encoding as in URLs (especially: no spaces, tabs, or line breaks allowed) and MUST follow the syntax rules described in chapter Query Options.</p>
 <div class="example">
 <p>Example 49: passing a filter condition in the request body</p>
 <pre><code>POST http://host/service/People/$query
@@ -898,7 +898,7 @@ <h5 id="51113-greater-than"><a name="GreaterThan" href="#GreaterThan">5.1.1.1.3
 <p>The <code>gt</code> operator returns true if the left operand is greater than the right operand, otherwise it returns false.</p>
 <p>The special value <code>INF</code> is greater than any number, and any number is greater than <code>-INF</code>.</p>
 <p>The Boolean value <code>true</code> is greater than <code>false</code>.</p>
-<p>Services SHOULD order language-dependent strings according to the content-language of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
+<p>Services SHOULD order language-dependent strings according to the <code>Content-Language</code> of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
 <p>If any operand is <code>null</code>, the operator returns false.</p>
 <h5 id="51114-greater-than-or-equal"><a name="GreaterThanorEqual" href="#GreaterThanorEqual">5.1.1.1.4 Greater Than or Equal</a></h5>
 <p>The <code>ge</code> operator returns true if the left operand is greater than or equal to the right operand, otherwise it returns false.</p>
@@ -907,7 +907,7 @@ <h5 id="51115-less-than"><a name="LessThan" href="#LessThan">5.1.1.1.5 Less Than
 <p>The <code>lt</code> operator returns true if the left operand is less than the right operand, otherwise it returns false.</p>
 <p>The special value <code>-INF</code> is less than any number, and any number is less than <code>INF</code>.</p>
 <p>The Boolean value <code>false</code> is less than <code>true</code>.</p>
-<p>Services SHOULD order language-dependent strings according to the content-language of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
+<p>Services SHOULD order language-dependent strings according to the <code>Content-Language</code> of the response, and SHOULD annotate string properties with language-dependent order with the term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent"><code>Core.IsLanguageDependent</code></a>, see <a href="#ODataVocCore">OData-VocCore</a>.</p>
 <p>If any operand is <code>null</code>, the operator returns false.</p>
 <h5 id="51116-less-than-or-equal"><a name="LessThanorEqual" href="#LessThanorEqual">5.1.1.1.6 Less Than or Equal</a></h5>
 <p>The <code>le</code> operator returns true if the left operand is less than or equal to the right operand, otherwise it returns false.</p>
diff --git a/docs/odata-url-conventions/odata-url-conventions.md b/docs/odata-url-conventions/odata-url-conventions.md
index bc585dfda..ff5a8cb5f 100644
--- a/docs/odata-url-conventions/odata-url-conventions.md
+++ b/docs/odata-url-conventions/odata-url-conventions.md
@@ -1380,7 +1380,7 @@ Requests to paths ending in `/$query` MUST use the `POST` verb. Query
 options specified in the request body and query options specified in the
 request URL are processed together.
 
-The request body MUST use the content-type `text/plain`. It contains the
+The request body MUST use `Content-Type: text/plain`. It contains the
 query portion of the URL and MUST use the same percent-encoding as in
 URLs (especially: no spaces, tabs, or line breaks allowed) and MUST
 follow the syntax rules described in chapter Query Options.
@@ -1559,7 +1559,7 @@ greater than `-INF`.
 The Boolean value `true` is greater than `false`.
 
 Services SHOULD order language-dependent strings according to the
-content-language of the response, and SHOULD annotate string properties
+`Content-Language` of the response, and SHOULD annotate string properties
 with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).
@@ -1584,7 +1584,7 @@ than `INF`.
 The Boolean value `false` is less than `true`.
 
 Services SHOULD order language-dependent strings according to the
-content-language of the response, and SHOULD annotate string properties
+`Content-Language` of the response, and SHOULD annotate string properties
 with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).
diff --git a/odata-json-format/10 Media Entity.md b/odata-json-format/10 Media Entity.md
index 1b8322cc3..ac05f3e0e 100644
--- a/odata-json-format/10 Media Entity.md	
+++ b/odata-json-format/10 Media Entity.md	
@@ -153,7 +153,7 @@ first name/value pair in the response.
 
 The `count` name/value pair represents the number of entities
 in the collection. If present and the [`streaming=true`](#PayloadOrderingConstraints)
-content-type parameter is set, it MUST come before the
+media type parameter is set, it MUST come before the
 `value` name/value pair. If the response represents a partial
 result, the `count` name/value pair MUST appear in the first
 partial response, and it MAY appear in subsequent partial responses (in
diff --git a/odata-json-format/4 Common Characteristics.md b/odata-json-format/4 Common Characteristics.md
index 22f0494ff..03e2e2c22 100644
--- a/odata-json-format/4 Common Characteristics.md	
+++ b/odata-json-format/4 Common Characteristics.md	
@@ -153,7 +153,7 @@ cannot be assumed to support streaming.
 
 JSON producers are encouraged to follow the payload ordering constraints
 whenever possible (and include the `streaming=true`
-content-type parameter) to support the maximum set of client scenarios.
+media type parameter) to support the maximum set of client scenarios.
 
 To support streaming scenarios the following payload ordering
 constraints have to be met:
diff --git a/odata-protocol/11 Data Service Requests.md b/odata-protocol/11 Data Service Requests.md
index 933597829..956e733d9 100644
--- a/odata-protocol/11 Data Service Requests.md	
+++ b/odata-protocol/11 Data Service Requests.md	
@@ -78,7 +78,7 @@ root URL of the service with `$metadata` appended. To retrieve this
 document the client issues a `GET` request to the metadata document URL.
 
 If a request for metadata does not specify a format preference (via
-[`Accept` header](#HeaderAccept) or
+[`Accept`](#HeaderAccept) header or
 [`$format`](#SystemQueryOptionformat)) then the XML representation MUST
 be returned.
 
@@ -103,10 +103,10 @@ the URL has expired, then the service SHOULD respond with
 MUST respond with [`404 Not Found`](#ResponseCode404NotFound).
 
 The format of the returned data is dependent upon the request and the
-format specified by the client, either in the [`Accept`
-header](#HeaderAccept) or using the
+format specified by the client, either in the
+[`Accept`](#HeaderAccept) header or using the
 [`$format`](#SystemQueryOptionformat) query option. If
-the client specifies neither an [`Accept` header](#HeaderAccept) nor the
+the client specifies neither an [`Accept`](#HeaderAccept) header nor the
 [`$format`](#SystemQueryOptionformat) query option, the
 service is allowed to return the response in any format.
 
@@ -763,7 +763,7 @@ result value of the second expression, and so on.
 The Boolean value false comes before the value true in ascending order.
 
 Services SHOULD order language-dependent strings according to the
-[content-language](#HeaderContentLanguage) of the response, and SHOULD
+[`Content-Language`](#HeaderContentLanguage) of the response, and SHOULD
 annotate string properties with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).
@@ -1055,13 +1055,13 @@ If the resource path identifies a collection, the response MUST be the
 format-specific representation of a collection of entity references
 pointing to the related entities. If no entities are related, the
 response is the format-specific representation of an empty collection.
-The response MAY contain an [ETag header](#HeaderETag) for the
+The response MAY contain an [`ETag`](#HeaderETag) header for the
 collection whose value changes if the collection of references changes,
 i.e. a reference is added or removed.
 
 If the resource path identifies a single existing entity, the response
 MUST be the format-specific representation of an entity reference. The
-response MAY contain an [ETag header](#HeaderETag) which represents the
+response MAY contain an [`ETag`](#HeaderETag) header which represents the
 identity of the referenced entity. If the resource path terminates in a
 single-valued navigation path, the ETag value changes if the
 relationship is changed and points to a different OData entity. If the
diff --git a/odata-protocol/11.4 Data Modification.md b/odata-protocol/11.4 Data Modification.md
index c5908be0a..4e55d3564 100644
--- a/odata-protocol/11.4 Data Modification.md	
+++ b/odata-protocol/11.4 Data Modification.md	
@@ -9,7 +9,7 @@ must not violate the integrity of the data.
 
 The client may request whether content be returned from a Create,
 Update, or Delete request, or the invocation of an Action, by specifying
-the [`return` Prefer header](#Preferencereturnrepresentationandreturnminimal).
+the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 ### ##subsubsec Common Data Modification Semantics
 
@@ -41,11 +41,11 @@ announce this via annotations with the terms
 [OData-VocCap](#ODataVocCap).
 
 If optimistic concurrency control is required for a resource, the
-service MUST include an [ETag header](#HeaderETag) in a response to a
+service MUST include an [`ETag`](#HeaderETag) header in a response to a
 `GET` request to the resource, and MAY include the ETag in a
 format-specific manner in responses containing that resource.
 
-The presence of an [ETag header](#HeaderETag) in a response does not
+The presence of an [`ETag`](#HeaderETag) header in a response does not
 imply in itself that the resource requires optimistic concurrency
 control; the ETag may just be used for caching and/or conditional `GET`
 requests.
@@ -185,16 +185,15 @@ Properties with a defined default value, nullable properties, and
 collection-valued properties omitted from the request are set to the
 default value, null, or an empty collection, respectively.
 
-Upon successful completion, the response MUST contain a [`Location`
-header](#HeaderLocation) that contains the edit URL or read URL of the
+Upon successful completion, the response MUST contain a
+[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
 created entity.
 
 Upon successful completion the service MUST respond with either
 [`201 Created`](#ResponseCode201Created) and a representation of the
 created entity, or [`204 No Content`](#ResponseCode204NoContent) if the
-request included a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) and did not
+request included a
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference and did not
 include the system query options [`$select`](#SystemQueryOptionselect)
 and [`$expand`](#SystemQueryOptionexpand).
 
@@ -394,8 +393,7 @@ Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) and a representation of the updated
 entity, or [`204 No Content`](#ResponseCode204NoContent). The client may
 request that the response SHOULD include a body by specifying a
-[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal), or by
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference, or by
 specifying the system query options
 [`$select`](#SystemQueryOptionselect) or
 [`$expand`](#SystemQueryOptionexpand). If the service uses ETags for
@@ -559,12 +557,12 @@ that are not tied to key properties of the principal entity, MUST be
 ignored by the service in processing the Upsert request.
 
 To ensure that an update request is not treated as an insert, the client
-MAY specify an [`If-Match` header](#HeaderIfMatch) in the update
+MAY specify an [`If-Match`](#HeaderIfMatch) header in the update
 request. The service MUST NOT treat an update request containing an
 `If-Match` header as an insert.
 
 A `PUT` or `PATCH` request MUST NOT be treated as an update if an
-[`If-None-Match` header](#HeaderIfNoneMatch) is specified with a value
+[`If-None-Match`](#HeaderIfNoneMatch) header is specified with a value
 of `*`.
 
 ### ##subsubsec Delete an Entity
@@ -689,15 +687,14 @@ OData format supported by the service. It is not possible to set the
 structural properties of the media entity when creating the media
 entity.
 
-Upon successful completion, the response MUST contain [`Location`
-header](#HeaderLocation) that contains the edit URL of the created media
+Upon successful completion, the response MUST contain
+[`Location`](#HeaderLocation) header that contains the edit URL of the created media
 entity.
 
 Upon successful completion the service responds with either
 [`201 Created`](#ResponseCode201Created), or
 [`204 No Content`](#ResponseCode204NoContent) if the request included a
-[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=minimal`](#Preferencereturnrepresentationandreturnminimal).
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 #### ##subsubsubsec Update a Media Entity Stream
 
@@ -844,9 +841,8 @@ property.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
@@ -897,9 +893,8 @@ request body and set all unspecified properties to their default value.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
@@ -929,9 +924,8 @@ supported for collection properties.
 Upon successful completion the service responds with either
 [`200 OK`](#ResponseCode200OK) and a representation of the updated collection, or
 [`204 No Content`](#ResponseCode204NoContent). The client may request
-that the response SHOULD include a body by specifying a [Prefer
-header](#Preferencereturnrepresentationandreturnminimal) with a value of
-[`return=representation`](#Preferencereturnrepresentationandreturnminimal).
+that the response SHOULD include a body by specifying a
+[`return=representation`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Services MUST return an error if the property is not updatable.
 
diff --git a/odata-protocol/11.5 Operations.md b/odata-protocol/11.5 Operations.md
index 9be53635c..37e7c2e4a 100644
--- a/odata-protocol/11.5 Operations.md	
+++ b/odata-protocol/11.5 Operations.md	
@@ -402,11 +402,11 @@ negotiation to request the results in the desired format, otherwise the
 default content type will be used.
 
 The client can request whether any results from the action be returned
-using the [`return Prefer` header](#Preferencereturnrepresentationandreturnminimal).
+using the [`return`](#Preferencereturnrepresentationandreturnminimal) preference.
 
 Actions that create and return a single entity follow the rules for
-[entity creation](#CreateanEntity) and return a [`Location`
-header](#HeaderLocation) that contains the edit URL or read URL of the
+[entity creation](#CreateanEntity) and return a
+[`Location`](#HeaderLocation) header that contains the edit URL or read URL of the
 created entity.
 
 If the action returns a value of type `Edm.Stream`, the response to the `POST` request
@@ -419,7 +419,7 @@ To request processing of the action only if the binding parameter value,
 an entity or collection of entities, is unmodified, the client includes
 the [`If-Match`](#HeaderIfMatch) header with the latest known ETag value
 for the entity or collection of entities. The ETag value for a
-collection as a whole is transported in the `ETag` header of a
+collection as a whole is transported in the [`ETag`](#HeaderETag) header of a
 collection response.
 
 ::: example
@@ -457,7 +457,7 @@ see [OData-URL](#ODataURL).
 
 ## ##subsec Asynchronous Requests
 
-A [Prefer](#HeaderPrefer) header with a
+A [`Prefer`](#HeaderPrefer) header with a
 [`respond-async`](#Preferencerespondasync) preference allows clients
 to request that the service process a [Data Service
 Request](#DataServiceRequests) asynchronously.
@@ -469,18 +469,18 @@ NOT reply to a [Data Service Request](#DataServiceRequests) with
 `202 Accepted` if the request has not included the `respond-async`
 preference.
 
-Responses that return `202 Accepted` MUST include a [`Location`
-header](#HeaderLocation) pointing to a *status monitor resource* that
+Responses that return `202 Accepted` MUST include a
+[`Location`](#HeaderLocation) header pointing to a *status monitor resource* that
 represents the current state of the asynchronous processing in addition
-to an optional [`Retry-After` header](#HeaderRetryAfter) indicating the
+to an optional [`Retry-After`](#HeaderRetryAfter) header indicating the
 time, in seconds, the client should wait before querying the service for
 status. Services MAY include a response body, for example, to provide
 additional status information.
 
 A `GET` request to the status monitor resource again returns
 `202 Accepted` response if the asynchronous processing has not finished.
-This response MUST again include a [`Location` header](#HeaderLocation)
-and MAY include a [`Retry-After` header](#HeaderRetryAfter) to be used for a subsequent request. The
+This response MUST again include a [`Location`](#HeaderLocation) header
+and MAY include a [`Retry-After`](#HeaderRetryAfter) header to be used for a subsequent request. The
 `Location` header and optional `Retry-After` header may or may not
 contain the same values as returned by the previous request.
 
@@ -503,7 +503,7 @@ asynchronous processing be canceled. A `200 OK` or a
 been successfully canceled. A client can request that the `DELETE`
 should be executed asynchronously. A `202 Accepted` response indicates
 that the cancellation is being processed asynchronously; the client can
-use the returned [`Location` header](#HeaderLocation) (which MUST be
+use the returned [`Location`](#HeaderLocation) header (which MUST be
 different from the status monitor resource of the initial request) to
 query for the status of the cancellation. If a delete request is not
 supported by the service, the service returns
diff --git a/odata-protocol/8 Header Fields.md b/odata-protocol/8 Header Fields.md
index 58d4a050f..c7c174615 100644
--- a/odata-protocol/8 Header Fields.md	
+++ b/odata-protocol/8 Header Fields.md	
@@ -34,7 +34,7 @@ parameters within the `Content-Type` header.
 
 As defined in [RFC7231](#rfc7231), the `Content-Encoding` header
 field is used as a modifier to the media-type (as indicated in the
-`Content-Type`). When present, its value indicates what additional
+`Content-Type` header). When present, its value indicates what additional
 content codings have been applied to the entity-body.
 A service MAY specify a list of acceptable content codings using an
 annotation with term
@@ -130,7 +130,7 @@ If the media type specified in the `Accept` header does not include a
 contain a `charset` format parameter.
 
 The service SHOULD NOT add any format parameters to the `Content-Type`
-parameter not specified in the `Accept` header.
+header not specified in the `Accept` header.
 
 If the `Accept` header is specified on an individual request within a
 batch, then it specifies the acceptable formats for that individual
@@ -180,7 +180,7 @@ occurs as a result of the request.
 
 If present, the request MUST only be processed if the specified ETag
 value matches the current ETag value of the target resource. Services
-sending [`ETag` headers](#HeaderETag) with weak ETags that only depend
+sending [`ETag`](#HeaderETag) headers with weak ETags that only depend
 on the representation-independent entity state MUST use the weak
 comparison function because it is sufficient to prevent accidental
 overwrites. This is a deviation from [RFC7232](#rfc7232).
@@ -377,14 +377,14 @@ If the service applies the `callback` preference it MUST include the
 When the `callback` preference is applied to asynchronous requests, the
 OData service invokes the callback endpoint once it has finished
 processing the request. The status monitor resource, returned in the
-[`Location` header](#HeaderLocation) of the previously returned
+[`Location`](#HeaderLocation) header of the previously returned
 [`202 Accepted`](#ResponseCode202Accepted) response, can then be used to
 retrieve the results of the asynchronously executed request.
 
 When the `callback` preference is specified on a `GET` request to a
 delta link and there are no changes available, the OData service returns
-a [`202 Accepted`](#ResponseCode202Accepted) response with a [`Location`
-header](#HeaderLocation) specifying the delta link to be used to check
+a [`202 Accepted`](#ResponseCode202Accepted) response with a
+[`Location`](#HeaderLocation) header specifying the delta link to be used to check
 for future updates. The OData service then invokes the specified
 callback endpoint once new changes become available.
 
@@ -861,8 +861,8 @@ and in [`3xx Redirect`](#ResponseCode3xxRedirection) responses
 
 The `Retry-After` header specifies the duration of time, in seconds,
 that the client is asked to wait before retrying the request or issuing
-a request to the resource returned as the value of the [`Location`
-header](#HeaderLocation).
+a request to the resource returned as the value of the
+[`Location`](#HeaderLocation) header.
 
 ### ##subsubsec Header `Vary`
 
@@ -926,8 +926,8 @@ Requests](#AsynchronousBatchRequests).
 ### ##subsubsec Response Code `204 No Content`
 
 A request returns `204 No Content` if the requested resource has the
-`null` value, or if the service applies a [`return=minimal`
-preference](#Preferencereturnrepresentationandreturnminimal). 
+`null` value, or if the service applies a
+[`return=minimal`](#Preferencereturnrepresentationandreturnminimal) preference.
 In this case, the response body MUST be empty.
 
 As defined in [RFC7231](#rfc7231), a [Data Modification
@@ -950,10 +950,10 @@ server-side values corresponding to the `ETag` value sent in the
 
 As per [RFC7231](#rfc7231), a `3xx Redirection` indicates that
 further action needs to be taken by the client in order to fulfill the
-request. In this case, the response SHOULD include a [`Location`
-header](#HeaderLocation), as appropriate, with the URL from which the
-result can be obtained; it MAY include a [`Retry-After`
-header](#HeaderRetryAfter).
+request. In this case, the response SHOULD include a
+[`Location`](#HeaderLocation) header, as appropriate, with the URL from which the
+result can be obtained; it MAY include a
+[`Retry-After`](#HeaderRetryAfter) header.
 
 ### ##subsubsec Response Code `304 Not Modified`
 
@@ -1067,7 +1067,7 @@ concerns around information disclosure.
 
 In the case that the service encounters an error after sending a success
 status to the client, the service MUST leave the response malformed
-according to its [content-type](#HeaderContentType). Clients MUST treat
+according to its [`Content-Type`](#HeaderContentType). Clients MUST treat
 the entire response as being in error.
 
 Services MAY include the header [`OData-Error`](#HeaderODataError) as a
diff --git a/odata-url-conventions/4 Resource Path.md b/odata-url-conventions/4 Resource Path.md
index 5138d0866..977ff2f3f 100644
--- a/odata-url-conventions/4 Resource Path.md	
+++ b/odata-url-conventions/4 Resource Path.md	
@@ -946,7 +946,7 @@ Requests to paths ending in `/$query` MUST use the `POST` verb. Query
 options specified in the request body and query options specified in the
 request URL are processed together.
 
-The request body MUST use the content-type `text/plain`. It contains the
+The request body MUST use `Content-Type: text/plain`. It contains the
 query portion of the URL and MUST use the same percent-encoding as in
 URLs (especially: no spaces, tabs, or line breaks allowed) and MUST
 follow the syntax rules described in chapter Query Options.
diff --git a/odata-url-conventions/5 Query Options.md b/odata-url-conventions/5 Query Options.md
index a71a06031..4420143ae 100644
--- a/odata-url-conventions/5 Query Options.md	
+++ b/odata-url-conventions/5 Query Options.md	
@@ -162,7 +162,7 @@ greater than `-INF`.
 The Boolean value `true` is greater than `false`.
 
 Services SHOULD order language-dependent strings according to the
-content-language of the response, and SHOULD annotate string properties
+`Content-Language` of the response, and SHOULD annotate string properties
 with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).
@@ -187,7 +187,7 @@ than `INF`.
 The Boolean value `false` is less than `true`.
 
 Services SHOULD order language-dependent strings according to the
-content-language of the response, and SHOULD annotate string properties
+`Content-Language` of the response, and SHOULD annotate string properties
 with language-dependent order with the term
 [`Core.IsLanguageDependent`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#IsLanguageDependent),
 see [OData-VocCore](#ODataVocCore).