[2422] | 1 | 1. Summary |
---|
| 2 | |
---|
| 3 | Document: draft-ietf-httpbis-p2-semantics-24 |
---|
| 4 | Document Shepherd: Mark Nottingham |
---|
[2423] | 5 | Responsible Area Director: Barry Leiba |
---|
[2422] | 6 | Publication Type: Proposed Standard |
---|
| 7 | |
---|
| 8 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for |
---|
| 9 | distributed, collaborative, hypertext information systems. This document |
---|
| 10 | defines the semantics of HTTP/1.1 messages, as expressed by request methods, |
---|
| 11 | request header fields, response status codes, and response header fields, along |
---|
| 12 | with the payload of messages (metadata and body content) and mechanisms for |
---|
| 13 | content negotiation. |
---|
| 14 | |
---|
| 15 | Note that this document is part of a set, which should be reviewed together: |
---|
| 16 | |
---|
| 17 | * draft-ietf-httpbis-p1-messaging |
---|
| 18 | * draft-ietf-httpbis-p2-semantics |
---|
| 19 | * draft-ietf-httpbis-p4-conditional |
---|
| 20 | * draft-ietf-httpbis-p5-range |
---|
| 21 | * draft-ietf-httpbis-p6-cache |
---|
| 22 | * draft-ietf-httpbis-p7-auth |
---|
| 23 | * draft-ietf-httpbis-method-registrations |
---|
| 24 | * draft-ietf-httpbis-authscheme-registrations |
---|
| 25 | |
---|
| 26 | |
---|
| 27 | 2. Review and Consensus |
---|
| 28 | |
---|
| 29 | As chartered, this work was very constrained; the WG sought only to clarify |
---|
| 30 | RFC2616, making significant technical changes only where there were |
---|
| 31 | considerably interoperability or security issues. |
---|
| 32 | |
---|
| 33 | While the bulk of the work was done by a core team of editors, it has been |
---|
| 34 | reviewed by a substantial number of implementers, and design issues enjoyed |
---|
| 35 | input from many of them. |
---|
| 36 | |
---|
| 37 | It has been through two Working Group Last Calls, with multiple reviewers each |
---|
| 38 | time. We have also discussed this work with external groups (e.g., the W3C TAG). |
---|
| 39 | |
---|
| 40 | 3. Intellectual Property |
---|
| 41 | |
---|
| 42 | There are no IPR disclosures against this document. The authors have confirmed |
---|
| 43 | that they have no direct, personal knowledge of IPR related to this document |
---|
| 44 | that has not been disclosed. |
---|
| 45 | |
---|
| 46 | 4. Other Points |
---|
| 47 | |
---|
| 48 | Downward references: |
---|
| 49 | * RFC1950 |
---|
| 50 | * RFC1951 (already in downref registry) |
---|
| 51 | * RFC1952 |
---|
| 52 | * "Welch" |
---|
| 53 | |
---|
| 54 | New registries created: |
---|
| 55 | |
---|
| 56 | * HTTP Method registry. IETF Review is required to assure that registrations |
---|
| 57 | are appropriate, as HTTP methods are purposefully constrained. |
---|
| 58 | |
---|
| 59 | Updated registries: |
---|
| 60 | |
---|
| 61 | * HTTP Status Code registry policy remains at IETF Review, and the registration |
---|
| 62 | procedures are now defined by this document. |
---|
| 63 | |
---|
| 64 | * The Content Coding Registry policy is changed from First Come First Served to |
---|
| 65 | IETF Review, and registration procedures are now defined by this document. |
---|
| 66 | the policy was changed to assure adequate review. |
---|
| 67 | |
---|
| 68 | There is also an informational reference to RFC1305, which has been obsoleted |
---|
| 69 | by RFC5905. This will be addressed in an update. |
---|