Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-26
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-27
|
26 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-05-05
|
26 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-16
|
26 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-03-25
|
26 | (System) | RFC Editor state changed to REF from EDIT |
2014-02-18
|
26 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-02-17
|
26 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-02-17
|
26 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-02-13
|
26 | (System) | IANA Action state changed to In Progress |
2014-02-12
|
26 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-02-12
|
26 | (System) | RFC Editor state changed to EDIT |
2014-02-12
|
26 | (System) | Announcement was received by RFC Editor |
2014-02-12
|
26 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-02-12
|
26 | Amy Vezza | IESG has approved the document |
2014-02-12
|
26 | Amy Vezza | Closed "Approve" ballot |
2014-02-12
|
26 | Amy Vezza | Ballot approval text was generated |
2014-02-12
|
26 | Barry Leiba | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2014-02-06
|
26 | Julian Reschke | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-02-06
|
26 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-26.txt |
2014-01-23
|
25 | Barry Leiba | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2014-01-23
|
25 | Sean Turner | [Ballot comment] 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) s4.1: Same comment as on p1 about 'ought to' … [Ballot comment] 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) s4.1: Same comment as on p1 about 'ought to' register methods with IANA. 2) s4.3.3/4/5: What Stephen said about authorization. I'm surprised that there's nothing about just accepting things without knowing whence they came. 3) s4.3.7/8: Is it allowed for an HTTP server to just not respond to a OPTIONS/TRACE method? I.e., I'd rather not tell you what I support - kind of like not replying to ping messages? Or is a 501 response always returned. 4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF 5) s5.5.3: So what happens if this isn't followed: a sender MUST NOT generate advertising or other non-essential information within the product identifier. 6) s6.1: Is it worth mentioning that the reason-phrase can also be not sent? I think that's elsewhere but it might be worth mentioning again. 7) s6.4.6: What does a client do if it gets one of these in an HTTP 1.1 response? 8) s4.2.1/s8: "safe" was probably not the greatest of choices - readonly would have been better. But, I guess this is water under the bridge at this point. |
2014-01-23
|
25 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2014-01-02
|
25 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-12-30
|
25 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2013-12-19
|
25 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-12-19
|
25 | Jari Arkko | [Ballot comment] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call … [Ballot comment] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call about the topic of mentioning injection attacks (in general) in the security considerations section, maybe Section 9.3. |
2013-12-19
|
25 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2013-12-19
|
25 | Jari Arkko | [Ballot discuss] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call … [Ballot discuss] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call about the topic of mentioning injection attacks (in general) in the security considerations section, maybe Section 9.3. |
2013-12-19
|
25 | Jari Arkko | Ballot discuss text updated for Jari Arkko |
2013-12-19
|
25 | Ted Lemon | [Ballot comment] The paragraph crossing the page break at the bottom of page 16: For example, if a client makes a PUT request on … [Ballot comment] The paragraph crossing the page break at the bottom of page 16: For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI. It's good that there's an example here, but this creates more questions than it answers: if I do a PUT to a particular URI, for which there are currently multiple representations of the document in different languages, based on a GET that had a specific language representation, is the semantics being specified here that the other language representations go away? That's kind of what it sounds like. This text makes sense for different content encodings like JSON and XML, where the server might be able to generate one from the other, but it's giving me a headache thinking about it in terms of natural language. Am I missing the point here? If so, could this be clarified, or did I just not drink enough coffee this morning? I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1. Am I missing something? |
2013-12-19
|
25 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-12-19
|
25 | Jari Arkko | [Ballot discuss] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call … [Ballot discuss] Thank you for doing this important work. Before recommending approval, I would like to briefly discuss with the other ADs on the call about the topic of mentioning injunction attacks (in general) in the security considerations section, maybe Section 9.3. |
2013-12-19
|
25 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2013-12-19
|
25 | Sean Turner | [Ballot discuss] Okay you're on a role wrt well written. Kudos again! 0) s8.3.1: Should a consideration be whether the new header discloses privacy related-data? |
2013-12-19
|
25 | Sean Turner | [Ballot comment] *) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If … [Ballot comment] *) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) s4.1: Same comment as on p1 about 'ought to' register methods with IANA. 2) s4.3.3/4/5: What Stephen said about authorization. I'm surprised that there's nothing about just accepting things without knowing whence they came. 3) s4.3.7/8: Is it allowed for an HTTP server to just not respond to a OPTIONS/TRACE method? I.e., I'd rather not tell you what I support - kind of like not replying to ping messages? Or is a 501 response always returned. 4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF 5) s5.5.3: So what happens if this isn't followed: a sender MUST NOT generate advertising or other non-essential information within the product identifier. 6) s6.1: Is it worth mentioning that the reason-phrase can also be not sent? I think that's elsewhere but it might be worth mentioning again. 7) s6.4.6: What does a client do if it gets one of these in an HTTP 1.1 response? 8) s4.2.1/s8: "safe" was probably not the greatest of choices - readonly would have been better. But, I guess this is water under the bridge at this point. |
2013-12-19
|
25 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-12-19
|
25 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-12-18
|
25 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-12-18
|
25 | Pete Resnick | [Ballot comment] 2: Even after reading sections 4 & 5, I find the last paragraph of this section almost incomprehensible. Especially given that it's got … [Ballot comment] 2: Even after reading sections 4 & 5, I find the last paragraph of this section almost incomprehensible. Especially given that it's got a normative protocol instruction in it (SHOULD NOT), I think it could use a rewrite. 3.3 a representation in the payload of a POST request (Section 4.3.3) represents an anonymous resource for providing data to be processed, such as the information that a user entered within an HTML form. "anonymous resource"? I don't know what that means. 5: Why are you listing (and not providing semantics) for things that are not in this document? Cache-Control Host Pragma Range TE Age Expires Warning All Conditionals All Authentication 5.3.1: Do you really want to allow a weight of "0." or "1." with no trailing digits? Instead maybe: qvalue = ( "0" [ "." 1*3DIGIT ] ) / ( "1" [ "." 1*3("0") ] ) 5.3.2: Completely bored ABNF dorking: media-range = ( "*/*" / ( type "/" ( subtype / "*") ) ) *( OWS ";" OWS parameter ) 7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that. |
2013-12-18
|
25 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-12-18
|
25 | Richard Barnes | [Ballot comment] In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements … [Ballot comment] In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements is useful and the specification is ultimately there, so OK. I agree with Stephen's comment that it would be useful to include Origin here in the list of "request context" headers. COMMENT 1: Section 5.1.1 defines an entirely new, secondary handshake using a header field. I realize this might be necessary for backward compatibility, but it seems so wrong. COMMENT 2: In Section 5.3.5, "A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field." This seems unnecessary, and unrealistic. For example, on my Mac, Safari sends "Accept-Language: en-us", but as far as I can tell, there is no way to change the value. |
2013-12-18
|
25 | Richard Barnes | Ballot comment text updated for Richard Barnes |
2013-12-18
|
25 | Richard Barnes | [Ballot comment] In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements … [Ballot comment] In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements is useful and the specification is ultimately there. I agree with Stephen's comment that it would be useful to include Origin here in the list of "request context" headers. COMMENT 1: Section 5.1.1 defines an entirely new, secondary handshake using a header field. I realize this might be necessary for backward compatibility, but it seems so wrong. COMMENT 2: In Section 5.3.5, "A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field." This seems unnecessary, and unrealistic. For example, on my Mac, Safari sends "Accept-Language: en-us", but as far as I can tell, there is no way to change the value. |
2013-12-18
|
25 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-12-18
|
25 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-12-18
|
25 | Stephen Farrell | [Ballot comment] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are … [Ballot comment] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are a number of ways in which that could have been done (e.g. just a ref, or changing the IANA registry to point to here and update 6454) but making no mention of it at all seems wrong. Please consider whether it'd be worth including that header field here in some form or other. - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when DELETE is allowed. - 4.3.6 makes no mention of TLS - is CONNECT really used without TLS? Seems odd to not mention (what I think) is the main use-case for this method at all. - 5.5.2: CSRF attack could do with a reference and expansion of the acronym |
2013-12-18
|
25 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-12-18
|
25 | Stephen Farrell | [Ballot discuss] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are … [Ballot discuss] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are a number of ways in which that could have been done (e.g. just a ref, or changing the IANA registry to point to here and update 6454) but making no mention of it at all seems wrong. Perhaps this was discussed though, was it? (I didn't see the mail for this, maybe I hit the wrong button, so sorry if you get a dup.) |
2013-12-18
|
25 | Stephen Farrell | [Ballot comment] - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when … [Ballot comment] - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when DELETE is allowed. - 4.3.6 makes no mention of TLS - is CONNECT really used without TLS? Seems odd to not mention (what I think) is the main use-case for this method at all. - 5.5.2: CSRF attack could do with a reference and expansion of the acronym |
2013-12-18
|
25 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-12-18
|
25 | Stephen Farrell | [Ballot discuss] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are … [Ballot discuss] Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are a number of ways in which that could have been done (e.g. just a ref, or changing the IANA registry to point to here and update 6454) but making no mention of it at all seems wrong. Perhaps this was discussed though, was it? |
2013-12-18
|
25 | Stephen Farrell | [Ballot comment] - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when … [Ballot comment] - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when DELETE is allowed. - 4.3.6 makes no mention of TLS - is CONNECT really used without TLS? Seems odd to not mention (what I think) is the main use-case for this method at all. - 5.5.2: CSRF attack could do with a reference and expansion of the acronym |
2013-12-18
|
25 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-12-17
|
25 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-12-17
|
25 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-12-16
|
25 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-12-16
|
25 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-12-13
|
25 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-12-12
|
25 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2013-12-12
|
25 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2013-11-17
|
25 | Julian Reschke | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-11-17
|
25 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-25.txt |
2013-11-15
|
24 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Sarah Banks |
2013-11-15
|
24 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Sarah Banks |
2013-11-11
|
24 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2013-11-05
|
24 | Barry Leiba | Ballot has been issued |
2013-11-05
|
24 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2013-11-05
|
24 | Barry Leiba | Created "Approve" ballot |
2013-11-05
|
24 | Barry Leiba | Placed on agenda for telechat - 2013-12-19 |
2013-11-05
|
24 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-11-05
|
24 | Barry Leiba | Changed consensus to Yes from Unknown |
2013-11-04
|
24 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-11-04) |
2013-10-31
|
24 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-10-31
|
24 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-httpbis-p2-semantics-24. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-httpbis-p2-semantics-24. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: NOTE: several entries that are part of the fourth action (Content-Coding registrations) have draft-ietf-httpbis-p1-messaging as their reference. If we're to update those entries with an RFC number once draft-ietf-httpbis-p1-messaging has been assigned one, these entries need to be requested in the IANA Considerations section for draft-ietf-httpbis-p1-messaging, rather than this document. We have no other mechanism to ensure that reference updates aren't overlooked. IANA understands that, upon approval of this document, there are four actions which IANA must complete. The third action must be approved by the designated expert for Permanent Message Header Field Names. First, a new registry called the HTTP Method Registry will be created at http://www.iana.org/assignments/http-methods The registration rule for this name space is IETF Review as defined in RFC 5226. The column names are "Method," "Safe" (a Y/N column), "Idempotent" (a Y/N column), and "Reference." The initial registrations are +---------+------+------------+---------------+ | Method | Safe | Idempotent | Reference | +---------+------+------------+---------------+ | CONNECT | no | no | [ RFC-to-be ] | | DELETE | no | yes | [ RFC-to-be ] | | GET | yes | yes | [ RFC-to-be ] | | HEAD | yes | yes | [ RFC-to-be ] | | OPTIONS | yes | yes | [ RFC-to-be ] | | POST | no | no | [ RFC-to-be ] | | PUT | no | yes | [ RFC-to-be ] | | TRACE | yes | yes | [ RFC-to-be ] | +---------+------+------------+---------------+ Second, the HTTP Status Code Registry, located at http://www.iana.org/assignments/http-status-codes/ is revised as follows: The registration procedure is changed to IETF Review as defined in RFC 5226. The following values in the existing registry are updated as follows: +-------+-------------------------------+----------------+ | Value | Description | Reference | +-------+-------------------------------+----------------+ | 100 | Continue | [ RFC-to-be ] | | 101 | Switching Protocols | [ RFC-to-be ] | | 200 | OK | [ RFC-to-be ] | | 201 | Created | [ RFC-to-be ] | | 202 | Accepted | [ RFC-to-be ] | | 203 | Non-Authoritative Information | [ RFC-to-be ] | | 204 | No Content | [ RFC-to-be ] | | 205 | Reset Content | [ RFC-to-be ] | | 300 | Multiple Choices | [ RFC-to-be ] | | 301 | Moved Permanently | [ RFC-to-be ] | | 302 | Found | [ RFC-to-be ] | | 303 | See Other | [ RFC-to-be ] | | 305 | Use Proxy | [ RFC-to-be ] | | 306 | (Unused) | [ RFC-to-be ] | | 307 | Temporary Redirect | [ RFC-to-be ] | | 400 | Bad Request | [ RFC-to-be ] | | 402 | Payment Required | [ RFC-to-be ] | | 403 | Forbidden | [ RFC-to-be ] | | 404 | Not Found | [ RFC-to-be ] | | 405 | Method Not Allowed | [ RFC-to-be ] | | 406 | Not Acceptable | [ RFC-to-be ] | | 408 | Request Timeout | [ RFC-to-be ] | | 409 | Conflict | [ RFC-to-be ] | | 410 | Gone | [ RFC-to-be ] | | 411 | Length Required | [ RFC-to-be ] | | 413 | Payload Too Large | [ RFC-to-be ] | | 414 | URI Too Long | [ RFC-to-be ] | | 415 | Unsupported Media Type | [ RFC-to-be ] | | 417 | Expectation Failed | [ RFC-to-be ] | | 426 | Upgrade Required | [ RFC-to-be ] | | 500 | Internal Server Error | [ RFC-to-be ] | | 501 | Not Implemented | [ RFC-to-be ] | | 502 | Bad Gateway | [ RFC-to-be ] | | 503 | Service Unavailable | [ RFC-to-be ] | | 504 | Gateway Timeout | [ RFC-to-be ] | | 505 | HTTP Version Not Supported | [ RFC-to-be ] | +-------+-------------------------------+----------------+ Third, in the Permanent Message Header Field Names registry at http://www.iana.org/assignments/message-headers the entries below will be updated as follows: +-------------------+----------+----------+-----------------+ | 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 | | MIME-Version | http | standard | Appendix A.1 | | Max-Forwards | http | standard | Section 5.1.2 | | 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 | +-------------------+----------+----------+-----------------+ Fourth, HTTP Content-Coding registry (for which an author and the shepherd are designated experts) of the Hypertext Transfer Protocol (HTTP) Parameters registry located at: http://www.iana.org/assignments/http-parameters/ is modified as follows: The registration rules for the registry are changed to IETF Review as defined in RFC 5226. These values in the existing registry are updated as follows: +------------+--------------------------------------+---------------------------------+ | Name | Description | Reference | +------------+--------------------------------------+---------------------------------+ | compress | UNIX "compress" data format [Welch] | draft-ietf-httpbis-p1-messaging | | | | | | deflate | "deflate" compressed data | draft-ietf-httpbis-p1-messaging | | | ([RFC1951]) inside the "zlib" data | | | | format ([RFC1950]) | | | gzip | GZIP file format [RFC1952] | draft-ietf-httpbis-p1-messaging | | | | | | identity | Reserved (synonym for "no encoding" | [ RFC-to-be ] | | | in Accept-Encoding) | | | x-compress | Deprecated (alias for compress) | draft-ietf-httpbis-p1-messaging | | | | | | x-gzip | Deprecated (alias for gzip) | draft-ietf-httpbis-p1-messaging | | | | | +------------+--------------------------------------+---------------------------------+ IANA understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-10-24
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2013-10-24
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2013-10-24
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2013-10-24
|
24 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2013-10-21
|
24 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-10-21
|
24 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Hypertext Transfer Protocol (HTTP/1.1): Semantics … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) to Proposed Standard The IESG has received a request from the Hypertext Transfer Protocol Bis WG (httpbis) to consider the following document: - 'Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. Note that this document is part of a set, which should be reviewed together: * draft-ietf-httpbis-p1-messaging * draft-ietf-httpbis-p2-semantics * draft-ietf-httpbis-p4-conditional * draft-ietf-httpbis-p5-range * draft-ietf-httpbis-p6-cache * draft-ietf-httpbis-p7-auth * draft-ietf-httpbis-method-registrations * draft-ietf-httpbis-authscheme-registrations The following normative references should be noted as "downward references": RFC 1950, "ZLIB Compressed Data Format Specification version 3.3" RFC 1951, "DEFLATE Compressed Data Format Specification version 1.3" RFC 1952, "GZIP file format specification version 4.3" Welch, T., "A Technique for High Performance Data Compression" In addition, the obsolete reference to RFC 1305 will be updated to point to RFC 5905. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/ Once IESG evaluation begins, IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-10-21
|
24 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-10-21
|
24 | Barry Leiba | Last call announcement was changed |
2013-10-21
|
24 | Barry Leiba | Last call was requested |
2013-10-21
|
24 | Barry Leiba | Ballot approval text was generated |
2013-10-21
|
24 | Barry Leiba | State changed to Last Call Requested from AD Evaluation |
2013-10-21
|
24 | Barry Leiba | Last call announcement was changed |
2013-10-21
|
24 | Barry Leiba | Last call announcement was generated |
2013-10-18
|
24 | Barry Leiba | Ballot writeup was changed |
2013-10-18
|
24 | Barry Leiba | Ballot writeup was generated |
2013-10-18
|
24 | Barry Leiba | State changed to AD Evaluation from Publication Requested |
2013-10-07
|
24 | Cindy Morgan | 1. Summary Document: draft-ietf-httpbis-p2-semantics-24 Document Shepherd: Mark Nottingham Responsible Area Director: Barry Leiba Publication Type: Proposed Standard The Hypertext Transfer Protocol (HTTP) is an application-level … 1. Summary Document: draft-ietf-httpbis-p2-semantics-24 Document Shepherd: Mark Nottingham Responsible Area Director: Barry Leiba Publication Type: Proposed Standard The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. Note that this document is part of a set, which should be reviewed together: * draft-ietf-httpbis-p1-messaging * draft-ietf-httpbis-p2-semantics * draft-ietf-httpbis-p4-conditional * draft-ietf-httpbis-p5-range * draft-ietf-httpbis-p6-cache * draft-ietf-httpbis-p7-auth * draft-ietf-httpbis-method-registrations * draft-ietf-httpbis-authscheme-registrations 2. Review and Consensus As chartered, this work was very constrained; the WG sought only to clarify RFC2616, making significant technical changes only where there were considerably interoperability or security issues. While the bulk of the work was done by a core team of editors, it has been reviewed by a substantial number of implementers, and design issues enjoyed input from many of them. It has been through two Working Group Last Calls, with multiple reviewers each time. We have also discussed this work with external groups (e.g., the W3C TAG). 3. Intellectual Property There are no IPR disclosures against this document. The authors have confirmed that they have no direct, personal knowledge of IPR related to this document that has not been disclosed. 4. Other Points Downward references: * RFC1950 * RFC1951 (already in downref registry) * RFC1952 * "Welch" New registries created: * HTTP Method registry. IETF Review is required to assure that registrations are appropriate, as HTTP methods are purposefully constrained. Updated registries: * HTTP Status Code registry policy remains at IETF Review, and the registration procedures are now defined by this document. * The Content Coding Registry policy is changed from First Come First Served to IETF Review, and registration procedures are now defined by this document. the policy was changed to assure adequate review. There is also an informational reference to RFC1305, which has been obsoleted by RFC5905. This will be addressed in an update. |
2013-10-07
|
24 | Mark Nottingham | Working group state set to Submitted to IESG for Publication |
2013-10-07
|
24 | Mark Nottingham | IETF WG state changed to Submitted to IESG for Publication |
2013-10-07
|
24 | Mark Nottingham | IESG state changed to Publication Requested |
2013-10-07
|
24 | Mark Nottingham | IESG state set to Publication Requested |
2013-10-07
|
24 | Mark Nottingham | Changed document writeup |
2013-10-07
|
24 | Mark Nottingham | Document shepherd changed to Mark Nottingham |
2013-09-25
|
24 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-24.txt |
2013-07-15
|
23 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-23.txt |
2013-02-23
|
22 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-22.txt |
2012-10-04
|
21 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-21.txt |
2012-07-16
|
20 | Julian Reschke | New version available: draft-ietf-httpbis-p2-semantics-20.txt |
2012-07-05
|
19 | Barry Leiba | Responsible AD changed to Barry Leiba from Peter Saint-Andre |
2012-03-12
|
19 | Roy Fielding | New version available: draft-ietf-httpbis-p2-semantics-19.txt |
2012-01-03
|
18 | (System) | New version available: draft-ietf-httpbis-p2-semantics-18.txt |
2011-11-14
|
18 | Peter Saint-Andre | Intended Status has been changed to Proposed Standard from Standard |
2011-10-31
|
17 | (System) | New version available: draft-ietf-httpbis-p2-semantics-17.txt |
2011-10-17
|
18 | Peter Saint-Andre | Draft added in state AD is watching |
2011-08-24
|
16 | (System) | New version available: draft-ietf-httpbis-p2-semantics-16.txt |
2011-07-11
|
15 | (System) | New version available: draft-ietf-httpbis-p2-semantics-15.txt |
2011-04-18
|
14 | (System) | New version available: draft-ietf-httpbis-p2-semantics-14.txt |
2011-03-14
|
13 | (System) | New version available: draft-ietf-httpbis-p2-semantics-13.txt |
2010-10-25
|
12 | (System) | New version available: draft-ietf-httpbis-p2-semantics-12.txt |
2010-08-04
|
11 | (System) | New version available: draft-ietf-httpbis-p2-semantics-11.txt |
2010-07-12
|
10 | (System) | New version available: draft-ietf-httpbis-p2-semantics-10.txt |
2010-03-08
|
09 | (System) | New version available: draft-ietf-httpbis-p2-semantics-09.txt |
2009-10-26
|
08 | (System) | New version available: draft-ietf-httpbis-p2-semantics-08.txt |
2009-07-13
|
07 | (System) | New version available: draft-ietf-httpbis-p2-semantics-07.txt |
2009-03-09
|
06 | (System) | New version available: draft-ietf-httpbis-p2-semantics-06.txt |
2008-11-17
|
05 | (System) | New version available: draft-ietf-httpbis-p2-semantics-05.txt |
2008-08-29
|
04 | (System) | New version available: draft-ietf-httpbis-p2-semantics-04.txt |
2008-06-17
|
03 | (System) | New version available: draft-ietf-httpbis-p2-semantics-03.txt |
2008-02-25
|
02 | (System) | New version available: draft-ietf-httpbis-p2-semantics-02.txt |
2008-01-13
|
01 | (System) | New version available: draft-ietf-httpbis-p2-semantics-01.txt |
2007-12-21
|
00 | (System) | New version available: draft-ietf-httpbis-p2-semantics-00.txt |