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,v 1.12 1996/03/26 20:56:17 jg Exp
jg $ Updated to reorganize list.
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 specification
and 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 page
for pointers to the draft.
We believe all significant issues have been resolved, with the
exception of any raised after Friday, June 9.
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.
- unassigned IANAREG Unassigned Closed
Issue: need new rules for IANA to register things, including
HTTP charset name.
- 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
- 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),
Status: other than what Jeff has in caching spec and
review as sections come in, 1.1 will not have explicit statements
- 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
Status: J.G. review of options sent to W.G.
John Klensin's opinion of preferable
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.
- 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
- 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
- RF PROTOVERSION Draft
Add 5xx error: "I don't support your protocol version"
for HTTP/2.x request.
505 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
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
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
- 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
Status: Closed, see Via Header Field (replaces
- General Issues
- 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
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
- 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
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
- 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
(same as Content-MD5)
- PL ENDHEAD Closed Duplicate of CHUNKED
Issue: need Headers at end, for signature use
email@example.com 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.
- 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
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.
- 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
- PL URLEN Closed
Is there a maximum length for URLs?
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,
- AH CLOSING What are the semantics of closing the connection
at various times?
Draft does not say.
- JM ARANGE
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
- 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
- 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
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?
- JM OPACITY2 Closed
Issue: opacity of validators
Validators, or entity ID's, or whatever they end up being called,
- Caching - expiration:
- 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/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:
- 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
- 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?
for WG review
- KH ACCEPTCHARSET Closed
Modify per Holtman 4.2?
for WG review
- KH ACCEPTENCODING Closed
Modify per holtman 4.3
for WG review
- KH ACCEPTLANGUAGE Closed
10.4: accept-language matching rules:
Issue: accept: us doesn't match us-en. Resolution in [holtman
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.
No Accept-Language matches Content-language: anything
"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.)
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 header
review of 02 draft.
- KH SPOOF Not in 1.1
Spoofing in Location
What 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,
- 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.
- need paragraph warning of (ab)use of basic authentication.
- JF, PL DIGEST Draft out for W.G.'s review
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
This is a drop-in replacement for Title.
Status: Not in 1.1 [Title should also be removed].
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.
- Refresh: 20; URL=http:/site/file
- <META HTTP-EQUIV=REFRESH CONTENT="20; URL=http://site/file">
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
[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
- 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
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
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.html
- (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
- (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
- (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
Proposal: Modular DTD draft
by Murray Altheim.
Issue: how does this get expressed in HTTP content negotiation?
Issue: is this adequate for what people currently use user agent
Status: needs review.
- (Not 1.1) Caching cookies
- (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?
- (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
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
Issue: What is the minimum generic precondition syntax? Status:
debate ongoing, no consensus apparent
- (Not 1.1) Section 10.28: remove MIME-Version
- (Not 1.1) (DISPOSITION)
Seems like it may be useful; defined in MIME, implemented by Netscape.
Don't have time to deal with it in 1.1.
- (Not here) Media type registration: review new Internet Media
Type registration procedure to see if it's adequate for HTTP media
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.
- 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.