HTTP Working Group (original) (raw)

HTTP Working GroupIssue list

For HTTP-WG use only

Please note: this list is an internal working document of the IETF HTTP-WG. Please do not distribute, publish, or quote.

Last update Id:http−wg.html,v1.121996/03/2620:56:17jgExpjgId: http-wg.html,v 1.12 1996/03/26 20:56:17 jg Exp jg Id:http−wg.html,v1.121996/03/2620:56:17jgExpjg Updated to reorganize list.

Issue Status

This is a list of issues. If you think the summary is wrong in any of these instances, please send mail to Jim Gettys, or, if you really think you have a new issue, please send mail to the http working group.

If there's an open issue or something is wrong, please speak up. Note that we declared that Any proposed HTTP/1.1 features not in HTTP/1.0 for which there is no consensus will revert to HTTP/1.0 status in 1.1 and be considered for inclusion in HTTP/1.2.

The comments are based on the HTTP/1.1 Version 01 specificationand the reports of various subgroups. Security issues to be coordinated with the members of the Web Transaction Security working group.

Process to close out issues

Process to close out the issues.

Internet Draft 05

Internet Draft 05 is out. We believe it will be forwarded to the IESG for action as a proposed standard. I (jg) have completed all edits I know of as of 9PM EDT Friday June 7, 1996.

See the W3C protocols pagefor pointers to the draft.

We believe all significant issues have been resolved, with the exception of any raised after Friday, June 9.

Document Structure

The document structure has been frozen; examine the draft…

Key to Issue Owner

• JG: Jim Gettys
• LM: Larry Masinter
• PL: Paul Leach
• JM: Jeff Mogul
• RF: Roy Fielding
• HF: Henrik Frystyk
• JF: John Franks
• KH: Koen Holtman
• AH: Alex Hoppman
• BB: Brian Behlendorf
• DC: Dan Connolly
• TBL: Tim Berners-Lee
• SHH: It's a secret
• NO: Not in 1.1 or in spec

Editorial teleconference agenda for 6/6/96.
Editorial teleconference agenda for 5/30/96.
Editorial teleconference agenda for 5/02/96.
Editorial teleconference agenda for 4/25/96.
Editorial teleconference agenda for 4/18/96.
Editorial teleconference agenda for 4/11/96.
Editorial teleconference agenda for 4/4/96.

Issues for HTTP/1.1

Roughly organized by topic, and therefore people.

• New issues:
  • unassigned MULTIENC Unassigned
    Issue: Apparently, the spec language left some people thinking that order didn't matter. See mail on the topic.
    Status: unassigned.
  • unassigned IANAREG Unassigned Closed
    Issue: need new rules for IANA to register things, including HTTP charset name.
    Status: unassigned.
  • Proxy-Authorization [clarification from Ari Luotonen] Closed
    Proxy authentication follows the exact same format as normal authentication; the status code and header names are just different:
    407 <-> 401
    Proxy-authenticate <-> WWW-Authenticate
    Proxy-authorization <-> Authorization
    If the proxy doesn't consume the authorization info, and it is configured to use another proxy, it will forward any Proxy-authorization to the next proxy. If it consumes the proxy auth info itself, or even if it doesn't, but the next connection is directly to the server, the Proxy-authorization header is not forwarded.
    Status: The last paragraph above needs to be added to the description of Proxy-Authorization in 1.1.
• Mostly Editorial
  • JG MUST/SHOULD Closed
• Issue: review use of must/should across the spec
• Status: solicit proposals for review of entire document.
  • JG CONTENT Closed
    Section 3.5: Content codings: There are other new codings supplied, e.g., CONDENSE. IANA registers these? If not, who?
    e.g. URL:ftp://prep.ai.mit.edu/pub/gnu not adequate for reference.
    Status: call for IANA to register. Maybe add CONDENSE.
  • JG MEDIATYPES Closed
    Issue: Fix language to be consistent with 1.0 language.
    Status: diffs sent to W.G. for final approval.
  • JG UNUSED Closed
• Issue: remove unused methods from this and 5.1.1, 6.1.1, 7.1
• Status: Closed by moving PATCH, COPY, MOVE, LINK, UNLINK, Content-version, Link, Derived-From to appendix. Put, delete remain in normative section.
  • JG TBS Duplicate
    Section 10.13 TBS need filling
    Status: Same as INTEGOK.
  • JG TBSDuplicate
    Section 10.14 TBS need filling
    Status: Same as RANGE
  • JG WTSLINK Closed
• Issue: Should HTTP/1.1 draft point to WTS work?
• Response: no, it should not.
  • JG ENTITY
    Issue: General 'entity' vs. 'request response' model as a way of explaining caching? (mail on http-caching)
    Status: need editor
  • JG BYPASS Closed
    Issue: Cache hierarchies and bypassing
    Status: Will review document for any issues that would make bypassing impossible, but belief of the editorial group is that protocol allows for bypassing.
  • JG EXTENSIBILITY (Not in 1.1),
    Issue: Extensibility
    Status:other than what Jeff has in caching specand review as sections come in, 1.1 will not have explicit statements around extensibility.
  • JG HEADERSIZE Closed
    Issue: Header's too big? How to make accept headers smaller.
    Status: JG to review as other issues get drafted and closed.
  • JG NEWMETHODS (Not in 1.1).
    Issue: Are new methods allowed? How are the defined? Registered?
  • JG Registration (Not in 1.1)
    Issue: what things does HTTP ask IANA to register? Should HTTP ask IANA media type registration to change?
  • JG: FULLURL Closed by HOST
    Issue: Full URL must be accepted by server, may be sent by client.
    Status: folded into the resolution of Host.
  • JG: HOST Closed
    Issue: Host header as drafted in the 1.1 spec is not a reliable way to ensure multiple servers at a single host will actually become possible.
    Status: J.G. review of options sent to W.G.John Klensin's opinion of preferable solution.
    Extensive comments on the W.G. list. Will adopt host header, roughly JG's option 4. Drafting underway, based on Roy's suggested wording. Note that we must make sure persistent connections do not close connections unnecessarily to truly close this issue.
  • JG RFC1900 Closed
    Issue: Read RFC 1900 and denigrate IP addresses
  • JG DEPENDENCIES Closed
    Issue: monitor dependencies of many drafts
  • JG DNS Draft
    Issue: spec is silent about clients/servers caching of DNS information.
    Status: resolution is to add verbiage that implementers who cache DNS information inside an implementation, rather than using DNS lookups each time MUST obey DNS TTL rules. Add words as well to security considerations. Current status, argument is whether requirement is must, or is should. Polling W.G. and security experts.
  • JG DELETE Closed
    Issue: Should DELETE be left in 1.1? Yes
    Status: implemented, but only by NaviPress. Editorial committee believed delete should be left in 1.1
  • JG CODES Closed
    Issue: spec needs new error codes to handle new facilities.
    Status: Closed
• Roy Fielding Issues
  • RF TRACE Closed
    Issues: various problems with trace. It is felt it would be very useful for diagnosing client server and cache problems.
    * RF Remove 8.12 TRACE Closed
    Was discussed, some controversy about form, which was apparently resolved.
    * RF ENTITYBODY Closed
    Issue: Can TRACE take an entity body? If so, can server transform encoding before returning?
    Status: yes, servers should be able to transform the entity, else if there were some requirement that the entity must be returned verbatim, implementation would be quite difficult in many servers, and it is likely implementations would then cheat, resulting in a test that would not test anything, defeating trace's usefulness.
    * RF TRACE MAXFORWARD Closed
    Should have a Max-Forwards field to return information even from loops.
• Status: Closed TRACE and Max-Forwards have been updated to fix issues.
  • RF PROTOVERSION DraftSection 9.5
    Add 5xx error: "I don't support your protocol version" for HTTP/2.x request.
    Status: Draft505 HTTP Version Not Supported
  • RF: HOSTDEST Closed
    Issue: Host: is destination, or next hop?
    Status: Closed, see Host consensus wording
  • RF HOSTPORT Closed Section 10.22
    Host: header. Is :port allowed/required?
    Response: required if not 80.
    Status: Closed, see Host consensus wording
  • AH/RF RENAMELB Pending
    Issue: Content-Location
    Content-Base
    MIME requires that meaningful entity headers be prefixed by Content-. Therefore, it makes sense to replace the Location header **on 2xx responses only** with Content-Location, and Base with Content-Base. This will also reduce confusion over what Location means in 3xx responses.
    This update will be made to RFC 1808, regardless of the HTTP decision.
    Status: In progress -- this is a difficult change due to frequent reference in the spec; may need to wait until after this week's draft. This is an editorial headache, rather than controversy.
  • RF REPS? Closed
• MORE? rename representations header?
• Status: Closed. Now called "Alternates" in Koen's draft.
  • RF PADDING Pending
    Issue: some URL-encoded data was being padded in POSTs in order to work with some CGI.
    Status: Editorial group thought that by defining extra CR/LF's as noop in protocol, we get a clean solution to the problem. We were wrong, if you don't succeed, try, try again.
  • RF URI
    Issue: URI header reset., same as MIRRORQUOT
  • RF MIRRORQUOT
    Issue: What do the "mirror" and "name" forms in the URI header say exactly?
    Status: URI header needs to revert to former syntax now that negotiation stuff is in Alternates. RF is drafting.
  • RF FORWARDED Closed
    Issue: Forwarded header needs to have compact syntax, and should indicate what version a request may have been upgraded from.
    Status: Closed, see Via Header Field (replaces Forwarded)
• General Issues
  • PL REWRITE Closed
• Issue: Should proxies rewrite URL's?
• Status: closed, NO, they should not. Closed
  • All: INTEROP Review Section 3.1
    Issue: Do the version handling rules for servers and proxies need to be changed? Interoperability between HTTP/1.0 and HTTP/1.1 software.
    Status: review the whole specification for interoperability problems in April; add whatever information is required to document
  • KH: INTEROP Closed Section 3.1
    Issue: interoperability between HTTP/1.0 and HTTP/1.1
    Do version handling rules for servers and proxies need to be changed? No. Review the whole spec for interoperability problems.
  • LM: URIINT
    Issue: URI internationalization
  • KH HEADEQUAL Draft
    When a resource varies by a header, how does a proxy know how to compare?
    New headers must specify an equivalence relationship; in lieu of knowing it, the proxy can use string equality. Header order never matters.
    Status: OK?
  • KH QMXB Closed
    The delimiter between media type and q or mxb should be : and not ;
    Status: subgroup decided, in 02 draft
  • LM CHARSET Section 3.4
    Issue: character set model in MIME is wrong. ("sequence => character"). The only UNICODE-1-1 registered is UTF7 (without dash).
    Status: need editor, revised text, WG review
  • LM OCTET Section 3.2.1
    Issue: specify URI syntax as octets. issue.
  • HF UPGRADE Draft
    Clarify UPGRADE: and 101 Switching
    Status: Draft
  • SHH VER12
    Rename version to 1.97, because some fools are shipping 1.1? (And rename http/1.2 to http/1.98, etc.)
    Status: Probably not. Fools will suffer.
  • PL Content-MD5Duplicate
    Issue: Content-MD5 is listed in the index of the HTTP/1.1 draft but no detailed spec has been given. Are caches allowed to check data integrity?
    Status: Content-MD5 is inherited from MIME, and its use is as a message checksum, rather than other cryptographic uses. The issue PHB raises will need to be addressed if/when other cryptographic functions are needed, and the suggestion for a Content-Digest header for such purposes is a good one when the issue arises, but for now, it seems like leaving Content-MD5 in is useful. Caches can use them for integrity checking, but must not generate them, and should forward them unchanged to end systems, else end to end problems will ensue.
  • PL INTEGOK Redraft
    Closed(same as Content-MD5)
• PL ENDHEAD Closed Duplicate of CHUNKED
  Issue: need Headers at end, for signature use
  hallam@w3.org asked for mechanism for headers at end
• PL CHUNKED Closed
  Issue: Definition of chunked encoding as presently stated may require unreasonable and unnecessary modification of client/server software architectures. Future revisions may need to transmit attributes on a per chunk basis and proxies/gateways should be prepared to deal with such messages even if they do not generate them. PHB's mail message on topic has more detail.
  Status: Closed
• Persist issues:
  • AH, RF, JM, JG PERSIST Closed
    Issue: Feb. 21 draft does NOT reflect the consensus output of the subgroup.
    Status: Alex is working on it.
  • AH PERSIST Closed
    Section 10.9, 10.24: Connection, persistent
    Draft: draft-ietf-http-ses-ext-01.txt
    Discussed at 3/14 teleconference. Draft needs updating to W.G. consensus, and in particular sticky headers needs separation from the rest of the document. Report of subgroup; remaining issues:
  • RF/AH TIMEOUT Keep-alive's max and timeout now gone. OK?
  • RF/AH BACKWARD Backward compatibility with HTTP/1.1 Keep-alive: is mechanism in draft sufficient?
  • RF/AH PROXYEDIT Section 8.1 "Options", 10.5 "Allow", 10.32 "Public": proxies should edit all three headers to reflect their capabilities. When using a persistent connection, it makes a lot of sense to know the methods possible for the current connection. A separate mechanism to find the Options for the OriginServer as well as the connection?
  • See Original issues list.
  • CHUNKEDVSMULTI (chunked only) Require chunked? or Multipart? Or both? (argument on persist) Status: require chunked, do not require multipart.
• PL URLEN Closed
  Is there a maximum length for URLs?
  Proposal:
  All client and proxy implementations MUST be able to handle a URL of any finite length. Servers MUST be able to handle any URL that they explicitly provide and SHOULD be able to handle URLs of unbounded length if they provide GET-based forms that could generate such URLs. A server MAY return a status code of
  [TBS] URL too long
  if a form-generated URL is longer than the server can handle.
  Servers should be cautious about depending on URL lengths above 255 bytes, because some older client or proxy implementations may not properly support these.
  Status: need error #. WG seems to agree.
• PL Caching of PUTs and POSTs
• Status: not agreed
  • Two Phase methods:
    * JM Section 8.4 POST Slushy
    Two-phase POST removed.
    Status: text may say the right thing, but it is confusing to many, WG review
    * AH CLOSING What are the semantics of closing the connection at various times?
    Draft does not say.
  • JM ARANGE
    draft-ietf-http-range-retrieval-00.txt
    Issue: Are accept ranges header needed or not?
    Status: yes, they are, interactions being discussed. Believe we have solution, but understandable words are still being drafted, or implementors will get it wrong.
  • Caching - overview:
    * JM Issue: transparency vs. performance Closed
    * JM CACHECONTROL add cache-control: flush-URI (e.g., for MOVE) Probably not 1.1, but Jeff will think about.
    * JM TERMINOLOGY Section 1.4: Overall Operation Closed
    Issue: Resolve terminology against cache subgroup's model of 'fresh' vs 'stale'. Status: general terminology problems need looking into, and in particular, JG will look into DNS terminology to see if anything can be improved there. WG review
    * JM FRESHMODEL Slushy
    It's a simplification to say that as soon as any one piece of information associated with a URI becomes stale, all of the rest of the information should become stale too.
    If we make that simplification, 'freshness' applies to "the URI's information" in general, rather than any particular piece of it. This means that dates and expires etc. apply to any cached info that a proxy might have with a URI and not just the one particular piece of data.
    Status: Draft 02 has wording to this effect. Need WG review
    * JM OVERRIDE MUST/SHOULD override for caches Pending
    * JM/PL COMBINE Closed
    "Combining headers from old cached responses and refreshed 304 should use more recent value for fields present in both responses."
  • Caching - validators
    * JM IMSTIME Closed
    Section 10.23: add a warning to section 10.23 for clients to be aware that I-M-S times are interpreted with the server's local understanding of time?
    Status: why not?
    * JM CACHEDATE Closed
    Issue: Dates in If-Modified-Since headers
    Status: unresolved? use dates unchanged?
    The realistic things that can be done are: (1) put appropriate caveats in the description of I-M-S, and (2) provide the alternative opaque validator mechanism that we've been working on.
    * JM IMSDATE Slushy
    Add: " Note: If clients use an arbitrary date in the If-Modified-Since header instead of a date taken from a Last-Modified header for the same request, they should be aware of the fact that this arbitrary date is interpreted in the server's local understanding of time. [The client should consider unsynchronized clocks and rounding problems, in different representations of local time, on computing the arbitrary date of the If-Modified-Since header.]" ??
    Put a couple of caveats in the description of I-M-S that discuss the perils of using I-M-S dates other than the L-M date associated with a document. This includes the possibility of race conditions if the requested document has changed between the time it was first requested and the I-M-S date of a subsequent request, and the possibility of clock-skew-related problems if the I-M-S date is derived from the client's clock without correction to the server's clock (which is always approximate anyway due to latency).
    Status: words are drafted in 02 document, but need careful review
    * JM OPACITY Closed
    Issue: Shall Opaque validators (If-invalid/If-valid) and If-modified-since: be the only cache-validation conditions?
    Status: ??
    * JM OPACITY2 Closed
    Issue: opacity of validators
    Validators, or entity ID's, or whatever they end up being called, are opaque.
  • Caching - expiration:
    * JM Closed
    Expires overrides cache-control
    Status: agreed by subgroup, except "do assumptions change with version"
    * JM EXPIRES Closed
    What does expires mean?
    Status: agreed principle by subgroup, disagree syntax or explicitness
    * JM Closed
    Add an Age: header
    Status: agreed by subgroup
  • Caching - cache-control:
    * JM CACHECONTROL Pending
    Section 10.8: Cache control
    Revise by cache group semantics
    Status: review proposed mechanisms in 02 spec
    * JM PRIVATE Closed
    Cache-control: private vs no-cache
    Status: agreed by subgroup
    * JM MAXAGE Closed
    Use 'max-age' and 'private' directives in both request and response, or use four different directive names.
    Status: agreed by subgroup
    * JM PUBLIC Closed
    Cache-control: public overrides auth restriction
    Status: agreed? Use vary?
    * JM MINMAX Closed
    Cache-control: stale-max=NNN, fresh-min=NNN or something similar Necessary for user-centric control over freshness parameters.
    * JM RELOAD Closed
    reload operation semantics. Status: agreement on semantics, no objections about terminology, disagreement over Pragma/Cache-control header and value names.
  • Caching - content-negotiation:
    * JM Pending
    content negotiation issues for caching
    * JM/KH CNURI Closed
    Section 10.42: URI Modify as per [holtman 4.5]?
    Status: URI now obsolete, moved to appendix.
  • JM/KH ALTERNATES Slushy
    * Isssue: Add Alternates, as per [holtman] 4.6?
    Status: in W.G. review real facility NOT in base 1.1.
    * JM/KH ALTHEADER Slushy
    Issue: Add Alt-Header, as per [holtman] 4.7?
    Status: in W.G. review
  • JM/KH CONTENT Closed
    full content negotiation in separate draft. Hooks only in base specification of 1.1/.
  • Content Negotiation
  • Modify, as per [holtman]
    * JM/KH CNREVIEW Caching: Section 13
    Review against [holtman] 5.3.
    Write as per Mogul's framework
    * JM VARIANT-ID Closed
    What is the mechanism by which variants are identified and content validated?
    Issues: constraint on variant-ids when vary on multiple content.
  • Caching - Range:
    * JM RANGE Closed
    draft-ietf-http-range-retrieval-00.txt
    Issue: update of large object
    validators, etc.
    Issue: interaction with validation headers?
    Status: being debated
  • Content Negotiation
    * KH CONENC Not in 1.1
    Issue: Must content-encoding negotiation be described as part of content negotiation? It seems transparent and hasn't much to do with quality values. Status: not decided by 1.1.
    * DC, TBL ALTCONTENT
    Issue: Content negotiation per current draft has serious problems. Status: Dan Connolly and Tim Berners-Lee to draft alternative conneg proposal by 3/21/96 to clarify/illustrate/present alternative to W.G.
    * KH MULTCHOICES Closed
    Section 9.3 300 Multiple Choices, modify per [holtman]
    * KH NONEACCPT Closed
    Section 9.4 406 None Acceptable, modify per [holtman]
    * KH NOTACCEPT Closed
    400 Not Acceptable, modify per [holtman]
    * KH LANGUAGETAGS Closed
    Section 3.10 Language Tags:
    Modify per [holtman] 3.1.
    Status: subgroup agreement; need revised text
    * KH ACCEPT Closed
    Section 10.1 Accept
    Modify per [holtman] 4.1?
    Status: Draftfor WG review
    * KH ACCEPTCHARSET Closed
    10.2 Accept-charset
    Modify per Holtman 4.2?
    Status: Draftfor WG review
    * KH ACCEPTENCODING Closed
    10.3 Accept-encoding
    Modify per holtman 4.3
    Status: Draftfor WG review
    * KH ACCEPTLANGUAGE Closed
    10.4: accept-language matching rules:
    Issue: accept: us doesn't match us-en. Resolution in [holtman 4.4]:
    1) Accept-language: A matches Content-language: A
    2) Accept-language: A matches Content-language: A-B, if A has more than one character
    3) Longest match determines the quality value.
    Also:
    No Accept-Language matches Content-language: anything
    and
    "Accept-Language:" (i.e. only the header with an empty field) assigns ql=0 to all languages. User agents that do not want to send a complete Accept-Language header in every request can use an empty header to force reactive negotiation if the resource is multilingual. (Servers that only offer one version in one language for a resource are still allowed to send this a version.)
    Status: OK?
    Review 02 draft wording.
    * KH BOTH Closed
    Does "Content-Language: mi, en" mean that content is intended for both audiences that speak Maori and audiences that speak English, or for an audience that speaks both. The 1.1 draft seems to contradict itself.
    Status: pick the first
    * KH VARYHEADER Slushy
    add a vary headerreview of 02 draft.
    * KH SPOOF Not in 1.1
    Spoofing in LocationWhat is the limit for which a server can supply and a client can trust the named URIs in a resource list to match?
    Proposal: "up to the last slash in the negotiable resource"
    Review against [holtman] 6.1. Status: ? still being discussed. Not believed relevant for base 1.1 system
    * KH ACCEPT-PRIVACY Closed
    Koen's proposed some wording on privacy issues in Accept headers. Are these acceptable?
    Status: review 02 draft security considerations section
  • Warning mechanism:
    * JM WARNING Slushy
    Add a "Warning:" header to the HTTP/1.1 protocol, allowing a server (origin or cache) to provide machine-readable and human-readable information to supplement the HTTP status code.
    Status: agreed in principle, working on wording.
  • Security Considerations
    * BB SECCONS HTTP security considerations:
    What else should the 'Security Considerations' say?
    * SECMORE Closed
    Issue: Add text about escaped new lines, CGI security, etc.: http://www.cerf.net/\~paulp/cgi-security/safe-cgi.txt
    * JG SECFILE Closed
    Issue: include missing section from HTTP/1.0.
    * JG PRIVACY Closed
    Issue: add privacy considerations
    * BB USERTRACKING Privacy from user tracking based on accept ([holtman 6.2, 6.3])
    * JF CGIHIJACK Closed
  • Issue:need paragraph to warn server implementers to make it impossible to hijack persistent connections.
  • Closed by JF's paragraph.
    * JF BASICWARNING Closed
  • need paragraph warning of (ab)use of basic authentication.
  • JF, PL DIGEST Draft out for W.G.'s review
  • draft-ietf-http-digest-aa-0?.txt
    Issue: How should Digest authentication be progressed?
    Status: Draft is in pretty good shape. Being reissued as updated draft, and both WTS and HTTP working groups should be asked to comment on it. If consensus can be reached quickly, may end up docking with core 1.1, else will be issued when closure is reached as separate RFC.

Issues for beyond HTTP/1.1

• Content-Description
  This is a drop-in replacement for Title.
  Status: Not in 1.1 [Title should also be removed].
• REFRESH
  Raised by Ulf Kronman on www-talk, 28 Apr 1995 Netscape misuses the notion of a Refresh header field which would indicate that the client should re-request the resource after some period of delta-seconds. The problem is that they defined it as a combination of a Link redirection rather than how we originally defined it. E.g.,
  • Refresh: 20; URL=http:/site/file
• or
  • would cause the user agent to request "http://site/file" 20 seconds after receiving that response. Status: Not in 1.1, due to unexplored security implications.
  • ISO DATE [raised by Markus Kuhn in private mail]
    Should HTTP allow/require the use of ISO 8601 format for dates 1994-11-06 08:49:37Z or in case compactness is more important than human readability 19941106T084937Z
    Status: defer until HTTP/2.0
  • Access-Control
    [raised by Roger Gonzalez on http-wg, 6 Jun 1995]
    Roger's implementation of PUT includes a rudimentary form of access control using an X-header. For example:
    X-Access: "public"=GH "user12345"=*
    Where "public" and "user12345" are realms, and "GH" and "*" correspond to a terse form of allowed methods (G,H,P,O,L,U,D, or * for all)
    It would be nice if we had a general mechanism (with a better syntax).
• Status: Not in 1.1 [can be delegated to researchers]
  • Accept-Hash [raised by Larry Masinter on http-wg, 10 Jul 1995]
    It might improve net efficiency (and possibly allow servers to precompute information or ignore these headers if they don't care) to package together those things that are configuration specific (accept,accept-encoding, accept-charset, accept-language and user-agent:) and send them by reference, e.g., the client sends
    accept-hash: NNNNNNNNNNNNNNN
    where NNNNNNNNNNNNNN is the MD5 of the omitted headers; the server sends back an error return if it actually needs the fields.
    Status: Not in 1.1
  • (Not 1.1) DERIVEDFROM Section 10.16, 10.18: remove content-version/Derived-from?
    Status: moved to experimental appendix.
  • (not 1.1) ROBOTS
    Should there be a request header that robots should use when indexing a site?
    Should there be a response code that indicates "robots forbidden"
    Status: no consensus to add. Mechanism at http://info.webcrawler.com/mak/projects/robots/norobots.htmlenough?
  • (not 1.1) HISTORY
    Do we need HTTP protocol elements to control history buffers? Or just to disnguish them in the overview? Status: Shel asked to propose wording
  • (Not 1.1) STATE
    Not currently in HTTP/1.1 draft
    State management subgroup produced draft-kristol-http-state-mgmt-00.txt. Some perceiption of conflict with session-id
    Status: converging, can be dealt with as separate document, authors unavailable until April, so will likely be independent document or integral to HTTP-1.2.
  • (Not in 1.1) STATECACHE Issue: state and caching
    Status: ???
  • (not 1.1) HIT-METER-OPTION
    Issue: hit metering
    Should protocol include a mechanism for proxies to inform servers whether or not they plan to do hit metering? This would let the origin server decide whether to disable caching if hit counts must be collected. Status: three I-Ds
  • BULK Bulk validation (verifying lots of cache entries at once.)
  • (Not 1.1) FPIPTD
    FPI PTD draft, also by Murray Altheim.
    Lays out some ways in which HTML feature set negotiation might be managed. Status: ??? needs review
  • (Not 1.1) FEATURES
    There's a need to negotiate features, especially modular features in HTML.
    Proposal: Modular DTD draftby Murray Altheim.
    Issue: how does this get expressed in HTTP content negotiation?
    [holtman]
    Issue: is this adequate for what people currently use user agent negotiation for?
    Status: needs review.
  • (Not 1.1) Caching cookies
    an issue
    Resolution?
  • (not 1.1) EXTEND
    Rohit Khare PEP doc. </TR/WD-http-pep.html>
    Status: not for 1.1 (?)
  • (Not 1.1) TEXTCHARSET
    Require charset on all text types to put HTTP in line w/MIME? Register itext/* for ucs2 use?
    Status: ???
  • (Not 1.1) Sticky headers: what's the list? Is the list in the draft OK?
  • (Not 1.1) Remove 8.13 WRAPPED
    Status: confusion with WTS. Discuss after WTS meeting.
  • (Not 1.1) Remove 8.6 PATCH 8.7 COPY 8.8 MOVE 8.10 LINK 8.11 UNLINK
    Status: ??? objections ???
  • Not 1.1 Section 3.11 Logic Bags
    Issue: To Logic Bag or Not
    Issue: Is one extensible precondition syntax better than six non-extensible precondition headers?
    Issue: What is the minimum generic precondition syntax? Status: debate ongoing, no consensus apparent
  • (Not 1.1) Section 10.28: remove MIME-Version
    Status: yes
  • (Not 1.1) (DISPOSITION)
    Issue: Content-Disposition. Seems like it may be useful; defined in MIME, implemented by Netscape. Don't have time to deal with it in 1.1.

Rejected Outright

• (Not here) Media type registration: review new Internet Media Type registration procedure to see if it's adequate for HTTP media types.
  Status: review in MIME community
• NO RECORDTRANSFER
  19 Feb 96: Peter Churchyard proposes adding 'record' as a transfer-encoding, as in SSL draft.
  Status: no WG support, do not add.
• NO DOTSTUFF
  19 Feb 96: Peter Churchyard proposes adding 'dot-stuffed' as a transfer-encoding, as in RFC1725.
  Status: no WG support, do not add.
• NO PROXYAUTH
  Issue: The current auth protocol allows a server to send WWW-Authenticate and for the proxy nearest the client to use Proxy-Authenticate.
  We are seeing situations where between the client and the server are a number of proxies (caching, firewall bridges etc) The current spec does not allow a proxy in the middle of the chain to do any authentication of the user.
  Status: No WG support at this time for more than the proposed facilities. Might be revisited someday if better case can be made.
• NO HTTPURIS
  Issue: Problems with HTTP URI's.
  Status: RFC 1738 needs updating someday to reflect errors caught and described in RFC 1808.
• (Not 1.1) 3.6 transfer coding [Leach] Allow multiplexing of responses in chunked encoding.
  Hoppman: "bad idea- Simon & I (& others) are working on a combination of HTTP/1.1 with Simon's SCP that will handle this in a much more powerful fashion.
  Status: no WG support, do not add. Alternate multiplexing work underway that requires no HTTP protocol changes.

Confused issue

• JM CONFUSED Closed Section 10.17, 10.19, 10.20, 10.23, 10.25, 10.27 Location, 10.29 Pragma: revise as per caching group. See Section 13 issues.