2025-10-02 RFC9110, Section 16.6.1 IETF Review aes128gcm AES-GCM encryption with a 128-bit content encryption key br Brotli Compressed Data Format compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] Section 8.4.1.1 dcb "Dictionary-Compressed Brotli" data format. Section 4 dcz "Dictionary-Compressed Zstandard" data format. Section 5 deflate "deflate" compressed data () inside the "zlib" data format () Section 8.4.1.2 exi W3C Efficient XML Interchange W3C Recommendation: Efficient XML Interchange (EXI) Format gzip GZIP file format Section 8.4.1.3 identity Reserved Section 12.5.3 pack200-gzip Network Transfer Format for Java Archives JSR 200: Network Transfer Format for Java x-compress Deprecated (alias for compress) Section 8.4.1.1 x-gzip Deprecated (alias for gzip) Section 8.4.1.3 zstd A stream of bytes compressed using the Zstandard protocol with a Window_Size of not more than 8 MB. RFC9112, Section 7.3 IETF Review chunked Transfer in a series of chunks Section 7.1 compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] Section 7.2 deflate "deflate" compressed data () inside the "zlib" data format () Section 7.2 gzip GZIP file format Section 7.2 identity (withdrawn in errata to ) Section 3.6 trailers (reserved) Section 12.3 x-compress Deprecated (alias for compress) Section 7.2 x-gzip Deprecated (alias for gzip) Section 7.2 IETF Review by IP-address of incoming interface of a proxy Section 5.1 for IP-address of client making a request through a proxy Section 5.2 host Host header field of the incoming request Section 5.3 proto Application protocol used for incoming request Section 5.4 Specification Required Julian Reschke Registration requests should be sent to the mailing list described in . If approved, designated experts should notify IANA within two weeks. For assistance, please contact iana@iana.org. respond-async Indicates that the client prefers that the server respond asynchronously to a request. , Section 4.1 return One of either "minimal" or "representation" When the value is "minimal", it indicates that the client prefers that the server return a minimal response to a request. When the value is "representation", it indicates that the client prefers that the server include a representation of the current state of the resource in response to a request. , Section 4.2 wait Indicates an upper bound to the length of time the client expects it will take the server to process the request once it has been received. , Section 4.3 handling One of either "strict" or "lenient" When value is "strict", it indicates that the client wishes the server to apply strict validation and error handling to the processing of a request. When the value is "lenient", it indicates that the client wishes the server to apply lenient validation and error handling to the processing of the request. , Section 4.4 depth-noroot The "depth-noroot" preference indicates that the client wishes for the server to exclude the target (root) resource from processing by the HTTP method and only apply the HTTP method to the target resource's subordinate resources. This preference is only intended to be used with HTTP methods whose definitions explicitly provide support for the Depth header field. Furthermore, this preference only applies when the Depth header field has a value of "1" or "infinity" (either implicitly or explicitly). , Section 4 safe Indicates that safe (i.e., unobjectionable) content is preferred. odata.allow-entityreferences Indicates that the service is allowed to return references in place of resources that have previously been returned, with at least the properties requested, in the same response. OData Version 4.01 Part 1: Protocol odata.callback Requests that the service invoke the specified URL to signal some service state, such as the completion of an asynchronous result or availability of new or modified information. The service state that triggers the change is dependent upon the request. OData Version 4.01 Part 1: Protocol odata.continue-on-error Requests that the service attempt to continue processing a request that encounters non-fatal errors, for example in a multi-part request. The response SHOULD indicate what portions of the request were and were not able to be successfully handled. OData Version 4.01 Part 1: Protocol odata.include-annotations Comma-separated list of terms to include or, when prefixed with a minus sign (-), exclude from the response. Terms MUST be namespace-qualified and MAY specify just a namespace to include or exclude all terms within that namespace. The special value "*" matches all annotations. Specifies the set of annotations the client requests to be included, where applicable, or excluded in the response. OData Version 4.01 Part 1: Protocol odata.maxpagesize A positive integer that represents the maximum number of items each collection in a response SHOULD contain. Requests that each collection within the response contain no more than the number of items specified as the positive integer value of this preference. OData Version 4.01 Part 1: Protocol omit-values One of nulls - properties containing null values may be omitted from the response defaults - properties containing the property default value may be omitted from the response. Specifies whether a server can omit properties with a null value or properties set to their default value from a response. OData Version 4.01 Part 1: Protocol odata.track-changes Requests that the service initiate change tracking on the result of this request, according to the underlying protocol. OData Version 4.01 Part 1: Protocol RFC9110, Section 16.5.1 IETF Review bytes a range of octets Section 14.1.2 none reserved as keyword to indicate range requests are not supported Section 14.3 Kumar Srinivasan mailto:Kumar.Srinivasan&Sun.COM 2006-10-27 John Rose mailto:John.Rose&Sun.COM 2006-10-27