1 | 1. Summary |
---|
2 | |
---|
3 | Document: draft-ietf-httpbis-p2-semantics-24 |
---|
4 | Document Shepherd: Mark Nottingham |
---|
5 | Responsible Area Director: Barry Lieba |
---|
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. |
---|