8. IANA Considerations

This specification updates the registries established by [RFC2817], [RFC2818], and [RFC4229], in addition to defining new registries for method names, status codes, and associated semantics.

8.1. Method Registration

The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the namespace for the request method token (Section 4). The method registry has been created and is now maintained at <http://www.iana.org/assignments/http-methods>.

8.1.1. Procedure

Registrations MUST include the following fields:

• Method Name
• Safe (yes/no)
• Idempotent (yes/no)
• Pointer to specification text

Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]).

8.1.2. Considerations for New Methods

Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.

Since message parsing (Section 3 of [RFC7230]) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a value of "0".

A new method definition needs to indicate whether it is safe (Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.3), what semantics are to be associated with the request message body (if any), and what semantics are to be associated with the response message body (if any). Note that a request method's idempotence is a property of the implementation on the origin server. Since implementations may depart from the intended behavior, the client cannot rely upon a method being idempotent or safe.

If a new method is cacheable, its definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy a subsequent request. A new method ought to describe whether it can be made conditional (Section 5 of [RFC7232]) and, if so, how a server responds when the condition is false. Likewise, if a new method might have some use for partial response semantics ([RFC7233]), it ought to document this, too.

Note: Avoid defining a method name that starts with "M-", since that prefix might be misinterpreted as having the semantics assigned to it by [RFC2774].

8.1.3. Registrations

The method registration procedure for HTTP has been updated per this specification. The HTTP Method Registry has been updated with the registrations below:

Method Name	Safe	Idempotent	Reference
GET	yes	yes	Section 4.3.1
HEAD	yes	yes	Section 4.3.2
POST	no	no	Section 4.3.3
PUT	no	yes	Section 4.3.4
DELETE	no	yes	Section 4.3.5
CONNECT	no	no	Section 4.3.6
OPTIONS	yes	yes	Section 4.3.7
TRACE	yes	yes	Section 4.3.8

8.2. Status Code Registration

The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines the namespace for the response status-code token (Section 6). The status code registry has been created and is now maintained at http://www.iana.org/assignments/http-status-codes.

8.2.1. Procedure

Registrations MUST include the following fields:

• Status Code (3 digits)
• Short Description
• Pointer to specification text

Values to be added to the HTTP status code namespace require IETF Review (see Section 4.1 of [RFC5226]).

8.2.2. Considerations for New Status Codes

When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application.

New status codes are required to fall under one of the categories defined in Section 6. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can mandate a zero-length payload body.

Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN" or "3N0" to indicate the class of the proposed status code(s) without consuming a number prematurely.

The definition of a new status code ought to explain the semantics of responses with that status code, including any required preconditions, the request characteristics that triggered the status, and the expected client behavior for processing such responses.

8.2.3. Registrations

The status code registry has been updated with the registrations below:

Value	Description	Reference
100	Continue	Section 6.2.1
101	Switching Protocols	Section 6.2.2
200	OK	Section 6.3.1
201	Created	Section 6.3.2
202	Accepted	Section 6.3.3
203	Non-Authoritative Information	Section 6.3.4
204	No Content	Section 6.3.5
205	Reset Content	Section 6.3.6
206	Partial Content	[RFC7233], Section 4.1
300	Multiple Choices	Section 6.4.1
301	Moved Permanently	Section 6.4.2
302	Found	Section 6.4.3
303	See Other	Section 6.4.4
304	Not Modified	[RFC7232], Section 4.1
305	Use Proxy	Section 6.4.5
306	(Unused)	Section 6.4.6
307	Temporary Redirect	Section 6.4.7
400	Bad Request	Section 6.5.1
401	Unauthorized	[RFC7235], Section 3.1
402	Payment Required	Section 6.5.2
403	Forbidden	Section 6.5.3
404	Not Found	Section 6.5.4
405	Method Not Allowed	Section 6.5.5
406	Not Acceptable	Section 6.5.6
407	Proxy Authentication Required	[RFC7235], Section 3.2
408	Request Timeout	Section 6.5.7
409	Conflict	Section 6.5.8
410	Gone	Section 6.5.9
411	Length Required	Section 6.5.10
412	Precondition Failed	[RFC7232], Section 4.2
413	Payload Too Large	Section 6.5.11
414	URI Too Long	Section 6.5.12
415	Unsupported Media Type	Section 6.5.13
416	Range Not Satisfiable	[RFC7233], Section 4.4
417	Expectation Failed	Section 6.5.14
426	Upgrade Required	Section 6.5.15
500	Internal Server Error	Section 6.6.1
501	Not Implemented	Section 6.6.2
502	Bad Gateway	Section 6.6.3
503	Service Unavailable	Section 6.6.4
504	Gateway Timeout	Section 6.6.5
505	HTTP Version Not Supported	Section 6.6.6

8.3. Header Field Registration

This specification updates the HTTP-header field registry defined in [RFC4229] with the registration procedure of [RFC3864].

8.3.1. Considerations for New Header Fields

Header fields are key components of the HTTP extensibility framework. They define additional data associated with either a message or a resource. There are many considerations that need to be made when defining a new header field.

New header fields need to at least define:

1. The field name (Section 3.2 of [RFC7230])
2. The expected grammar of the field value
3. The semantics of the field
4. For request header fields, how they can override or augment the message semantics
5. For response header fields, how they modify the interpretation of the response
6. Whether the field should be stored by a cache and whether it can be returned in responses to subsequent requests
7. Whether the field should be forwarded by proxies

It is also useful to document:

• Whether the header field is intended for use by intermediaries or only end-to-end
• Security and privacy considerations (see Section 9)
• Interaction with other header fields

Detailed advice for defining new header fields is available in "Guidelines for HTTP Header Field Specifications" [RFC6648bis].

8.3.2. Registrations

The "Hypertext Transfer Protocol (HTTP) Header Field Registry" located at http://www.iana.org/assignments/message-headers/ should be updated with the permanent registrations below (see [RFC3864]):

Header Field Name	Protocol	Status	Reference
Accept	http	standard	Section 5.3.2
Accept-Charset	http	standard	Section 5.3.3
Accept-Encoding	http	standard	Section 5.3.4
Accept-Language	http	standard	Section 5.3.5
Allow	http	standard	Section 7.4.1
Content-Encoding	http	standard	Section 3.1.2.2
Content-Language	http	standard	Section 3.1.3.2
Content-Location	http	standard	Section 3.1.4.2
Content-Type	http	standard	Section 3.1.1.5
Date	http	standard	Section 7.1.1.2
Expect	http	standard	Section 5.1.1
From	http	standard	Section 5.5.1
Location	http	standard	Section 7.1.2
Max-Forwards	http	standard	Section 5.1.2
MIME-Version	http	standard	Appendix A.1
Referer	http	standard	Section 5.5.2
Retry-After	http	standard	Section 7.1.3
Server	http	standard	Section 7.4.2
User-Agent	http	standard	Section 5.5.3
Vary	http	standard	Section 7.1.4

The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".

8.4. Content Coding Registration

The "HTTP Content Coding Registry" defines the namespace for content coding names (Section 3.1.2.1). The content coding registry has been created and is now maintained at http://www.iana.org/assignments/http-parameters.

8.4.1. Procedure

Registrations MUST include the following fields:

• Name
• Description
• Pointer to specification text

Names that start with "x-" are reserved for Private Use (as defined by [RFC5226]) and thus cannot be registered.

Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]).

8.4.2. Registrations

The content coding registry has been updated with the registrations below:

Name	Description	Reference
compress	UNIX "compress" data format	Section 3.1.2.1
deflate	"deflate" compressed data	Section 3.1.2.1
gzip	GZIP file format	Section 3.1.2.1
identity	Reserved (synonym for no encoding)	Section 3.1.2.1

---