OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (ODATA-706) Substitue references to obselete RFC2616


     [ https://issues.oasis-open.org/browse/ODATA-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Zurmuehl updated ODATA-706:
----------------------------------

    Proposal: 
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.


  was:Delete reference to RFC2616 and include the appropriate up-to-date specification(s).


> Substitue references to  obselete RFC2616
> -----------------------------------------
>
>                 Key: ODATA-706
>                 URL: https://issues.oasis-open.org/browse/ODATA-706
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_OS
>            Reporter: Martin Zurmuehl
>             Fix For: V4.0_ERRATA01
>
>
> RFC2616 is obsolete since  6.6.2014 and was substitute by six specifications (see https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]