IETF 80 - HTTPbis -13 Changes Overview

Julian Reschke, greenbytes

History

• -09: published March 2010 (before IETF 77)
• -10: published July 2010 (before IETF 78)
• -11: published August 2010 (after IETF 78)
• -12: published October 2010 (before IETF 79, WG did not meet)
• -13: published March 2011 (before IETF 80)

Changes: relations to other specifications (1/2)

RFC 2145 (Use and Interpretation of HTTP Version Numbers)

• RFC2145 Normative (Ticket 75)

-> Part 1 now obsoletes RFC 2145

RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication)

• should we have an auth scheme registry (Ticket 141)
• absorbing the auth framework from 2617 (Ticket 237)

-> Part 7 now updates RFC 2617 with respect to the authentication framework, and introduces an authentication scheme registry

Changes: relations to other specifications (2/2)

RFC 2817 (Upgrading to TLS Within HTTP/1.1)

• Migrate Upgrade details from RFC2817 (Ticket 240)
• Migrate CONNECT from RFC2817 to p2 (Ticket 239)

-> Part 1 and 2 now update RFC 2817 (defining CONNECT, and updating the Upgrade header field)

Changes: terminology and ABNF

• Clarify "Requested Variant" (Ticket 69)
• Clarify entity / representation / variant terminology (Ticket 109)
• duplicate ABNF for Reason-Phrase (Ticket 137) (editorial)
• define "transparent" proxy (Ticket 210) (editorial)
• duplicate ABNF for "Method" (Ticket 275) (editorial)
• untangle ABNFs for header fields (Ticket 276) (editorial)

-> We now create an aggregated ABNF from the source code of the specs

Changes: extension points

• Custom Ranges (Ticket 85)
• Max-Forwards vs extension methods (Ticket 203)
• Allowing heuristic caching for new status codes (Ticket 223)
• proxies not supporting certain methods (Ticket 226) (editorial)
• Considerations for new status codes (Ticket 229)
• Considerations for new methods (Ticket 230)
• Is * usable as a request-uri for new methods? (Ticket 233)

Other Changes (1/5)

non-specific

• 205 Bodies (Ticket 88)
• HTTP(s) URI scheme definitions (Ticket 159)
• Note special status of Content-* prefix in header registration procedures (Ticket 180) (editorial)
• Status codes and caching (Ticket 199)
• Header Classification (Ticket 224)

Other Changes (2/5)

Part 1 (Messaging)

• Delimiting messages with multipart/byteranges (Ticket 90)
• Trailer requirements (Ticket 193)
• What is the value space of HTTP status codes? (Ticket 213)
• confusing Date requirements for clients (Ticket 248)

Other Changes (3/5)

Part 2 (Semantics)

• Connection closing (Ticket 28) (editorial)
• Fragment combination / precedence during redirects (Ticket 43)
• Content-* vs. PUT (Ticket 79)
• Understanding Content-* on non-PUT requests (Ticket 102)
• Monitoring connections (Ticket 108) (editorial)
• Methods and Caching (Ticket 139)
• Are OPTIONS and TRACE safe? (Ticket 171)
• User-Agent guidelines (Ticket 232)
• clarify PUT semantics (Ticket 267)

Other Changes (4/5)

Part 3 (Payload)

• confusing req. language for Content-Location (Ticket 136) (editorial)
• "requested resource" in content-encoding definition (Ticket 183)

Part 5 (Range)

• Caches can't be required to serve ranges (Ticket 217)

Other Changes (5/5)

Part 6 (Cache)

• No-cache definition (Ticket 216)
• Does no-store in request imply no-cache? (Ticket 249)
• Clarify "public" (Ticket 268)

Part 7 (Auth)

• auth-param syntax (Ticket 195)

Changes: housekeeping

• MIME-Version not listed in P1, general header fields (Ticket 122) (editorial)
• Factor out Content-Disposition (Ticket 123)
• introduction to part 7 is work-in-progress (Ticket 130) (editorial)
• consider removing the "changes from 2068" sections (Ticket 220) (editorial)
• update RFC 2109 reference (Ticket 279) (editorial)