Substitute references to obsolete RFC2616

Delete reference to RFC2616 and include the appropriate up-to-date specification(s): We have 16 references to RFC2616. From the six new specifications only rfc7230, rfc7231, and rfc 7232 are required. List of proposed changes (section, current reference and new reference): 1.2 Normative References Current: [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616.txt . New: [RFC7230] Fielding, R., and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014. http://www.ietf.org/rfc/rfc7230.txt [RFC7231] Fielding, R., and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014. http://www.ietf.org/rfc/rfc7231.txt [RFC7232] Fielding, R., and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, June 2014. http://www.ietf.org/rfc/rfc7232.txt 7. Formats Current: The client MAY request a particular response format through the Accept header, as specified in [RFC2616] , or through... New: The client MAY request a particular response format through the Accept header, as specified in [RFC7231] , or through... 8.1.1 Header Content-Type Current: As specified in [RFC2616] , the format of an individual request or response body MUST be specified in the Content-Type header of the request or response. New: As specified in [RFC7231] , the format of an individual request or response body MUST be specified in the Content-Type header of the request or response. 8.1.2 Header Content-Encoding Current: As specified in [RFC2616] , the Content-Encoding header field is used as a modifier to the media-type (as indicated in the Content-Type). New: As specified in [RFC7231] , the Content-Encoding header field is used as a modifier to the media-type (as indicated in the Content-Type). 8.1.3 Header Content-Language Current: As specified in [RFC2616] , a request or response can include a Content-Language header to indicate the natural language of the intended audience for the enclosed message body New: As specified in [RFC7231] , a request or response can include a Content-Language header to indicate the natural language of the intended audience for the enclosed message body 8.1.4 Header Content-Length Current: As specified in [RFC2616] , a request or response SHOULD include a Content-Length header when the message's length can be determined prior to being transferred. New: As specified in [RFC7230] , a request or response SHOULD include a Content-Length header when the message's length can be determined prior to being transferred. 8.2.1 Header Accept Current: As specified in [RFC2616] , the client MAY specify the set of accepted formats with the Accept Header. New: As specified in [RFC7231] , the client MAY specify the set of accepted formats with the Accept Header. 8.2.2 Header Accept-Charset Current: As specified in [RFC2616] , the client MAY specify the set of accepted character sets with the Accept-Charset header. New: As specified in [RFC7231] , the client MAY specify the set of accepted character sets with the Accept-Charset header. 8.2.3 Header Accept-Language Current: As specified in [RFC2616] , the client MAY specify the set of accepted natural languages with the Accept-Language header. New: As specified in [RFC7231] , the client MAY specify the set of accepted natural languages with the Accept-Language header. 8.2.4 Header If-Match Current: As specified in [RFC2616] , a client MAY include an If-Match header in a request to GET, PUT, PATCH or DELETE. New: As specified in [RFC7232] , a client MAY include an If-Match header in a request to GET, PUT, PATCH or DELETE. 8.2.5 Header If-None-Match Current: As specified in [RFC2616] , a client MAY include an If-None-Match header in a request to GET, PUT, PATCH or DELETE. New: As specified in [RFC7232] , a client MAY include an If-Match header in a request to GET, PUT, PATCH or DELETE. 9.1.5 Response Code 3xx Redirection Current: As per [RFC2616] , a 3xx Redirection indicates that further action needs to be taken by the client in order to fulfill the request. New: As per [RFC7231] , a 3xx Redirection indicates that further action needs to be taken by the client in order to fulfill the request. 9.1.6 Response Code 304 Not Modified Current: As per [RFC2616] , a 304 Not Modified is returned when the client performs a GET request containing an If-Match or If-None-Match header and the content has not changed. New: As per [RFC7231] , a 304 Not Modified is returned when the client performs a GET request containing an If-Match or If-None-Match header and the content has not changed. 9.2.2 Response Code 405 Method Not Allowed 405 Method Not Allowed indicates that the resource specified by the request URL does not support the request method. Current: In this case the response MUST include an Allow header containing a list of valid request methods for the requested resource as specified in [RFC2616] . New: In this case the response MUST include an Allow header containing a list of valid request methods for the requested resource as specified in [RFC7231] . 9.3 Server Error Responses Current: As specified in [RFC2616] , error codes in the 5xx range indicate service errors. New: As specified in [RFC7231] , error codes in the 5xx range indicate service errors. 12 Security Considerations Current: For HTTP relevant security implications please cf. the relevant sections of [RFC2616] (15 Security Considerations) and for the HTTP PATCH method [RFC5789] (5. Security Considerations) as starting points. New: For HTTP relevant security implications please cf. the relevant sections of [RFC7231] (9 Security Considerations) and for the HTTP PATCH method [RFC5789] (5. Security Considerations) as starting points.