CURRENT MEETING REPORT
Reported by Ted Hardie, NASA Ames Research
Center, and Larry Masinter, Xerox Corporation
Minutes of the HyperText Transfer Protocol
Working Group (HTTP)
The HTTP Working Group held two regular
sessions, the first on March 5th and the second on March 7th.
In addition, an extra meeting took place the afternoon of March
7th and is reported here. Larry Masinter chaired the sessions.
The HTTP 1.0 specification has been taken
up by the IESG, and the proposal to move it forward as an Informational
RFC is expected to be processed at their next meeting. The group
applauded Roy Fielding for his work in producing the specification.
Jim Gettys will be taking over as primary
editor of the HTTP 1.1 specification, continuing Roy Fielding's
work and coordinating with others who will aid in the editing
process (including Roy, Henrik Frystyk, and others.) The Area
Directors approved the selection of Jim as editor. As is expected
of WG editors, Jim confirmed that he would act on behalf of the
working group and that he did not see his role at Digital or in
the W3C as being in conflict with his role as editor. One of
the first items Jim will do is to decide on how best to split
the HTTP/1.1 specification into separate documents.
Most of the meeting consisted of reports
from the subgroups constituted at the Dallas IETF. This marks
the formal end point of the subgroups. The members of the individual
subgroups may continue to use those mailing lists to discuss issues,
but further Internet Drafts from the subgroups are not expected.
Caching
Jeff Mogul presented the status report of
the caching subgroup. The group generally agreed on cache control
headers for Expires, Age, and Cache-control; some differences
remain on the exact syntax of the Cache-control headers related
to object "freshness," but the subgroup did not see
these as anything more than a stylistic disagreement. The subgroup
also agreed on the need for a Warning header, and proposed a series
in the 90 range; some disagreement on how to associate text with
the different warnings remains and will have to be worked out
on the list. The subgroup also reached consensus on the need
to distinguish between history buffers and caches; history buffers
are meant to replay pages which have already been seen, as they
were seen, and they should thus not be subject to the same directives
as caches.
The caching subgroup has reached general
agreement on how caching should interact with the Location: header
and the Vary: header, but it has not yet worked out the details.
Still unresolved are: the general question
of semantic transparency vs. performance in default behavior;
the use (or re-use) of opaque validators; whether protocol elements
were needed to control history buffers; what defaults should be
set for caches in the absence of any expiration or age directives;
and, whether or how to cache PUTs and POSTs.
In the course of discussion, the working
group agreed to delay work on bulk validation of cached material
to a release after HTTP 1.1. It was also agreed that we can currently
allow for multiple warnings, but that the issue might need to
be revisited if contradictory warnings were ever introduced (the
current set includes no mutually exclusive statements). Discussion
of Content-id: as validators also took place at the meeting, but
no consensus emerged.
Content Negotiation
Brian Behlendorf presented the status report
of the content negotiation subgroup. The subgroup adopted a strategy
that allows for both pre-emptive and reactive content negotiation
and which will normally progress from pre-emptive to reactive
if the pre-emptive is not immediately successful. As it is now,
the draft proposes content negotiation on four axes: media-type,
charset, language, and encoding. The subgroup had agreed that
to prevent spoofing, all variants would have to be extensions
of the original URL. Discussion at the meeting on this issue
and on the issue of what to do when variant entities don't have
URLs did not come to a resolution, and will have to be worked
out on the list.
From the subgroup's point of view, Koen
Holtmann's draft is ready for comments and implementation experience;
some experimentation has occurred, but more experience on interoperation
is needed. The content negotiation subgroup has not yet addressed
feature set negotiation at the content-level; Koen has just submitted
a draft on that, but it has not yet received much review.
Harald Alvestrand expressed some misgivings
about a draft which allowed for negotiation on only four axes
and which did not have a mechanism for further extendibility.
He felt that it might be possible to create a more open framework
which used the RFC process to declare dimensions for variability.
The group agreed that adding extendibility to the draft would
be considered.
State Management:
David Kristol gave the status report of
the State Management subgroup. The group has adopted a variant
of the Cookie proposal originally proposed by Netscape. A tighter
syntax has been proposed as well as new hostname matching rules
which help protect privacy by avoiding leakage of usage data across
sites. Open issues for the group are: the response header for
Set Cookie: ; whether spaces are allowed around the equals sign
in attribute value pairs; default behavior of the Path attribute;
the domain matching rules; and what to do when multiple matching
cookies are available. On a larger level, interoperability between
the older cookie format and the newer format may force the creation
of a version number for the cookie headers, though every effort
has been made to make the two very similar in usage.
The working group came to the consensus
that cookies were an optional part of the HTTP specification but
that those who created cookies within the HTTP context should
do so according to this document's specifications. The group
also appeared to agree that this would be a separate document
which advanced with the main HTTP 1.1 document (or document set),
rather than being folded into the base document.
THURSDAY SESSION
HTTP MIB
A separate BOF considering a MIB for HTTP
servers met at IETF this week. Carl Kalbfleisch reported on the
meeting of HTTPMIB BOF. That group is interested in extending
the work of the MADMAN group to create a standard way to monitor
the health of a web server. Two draft mibs are already available.
Further information is available at http://http-mib.onramp.net/
; to join the mailing list, send mail to http-mib-request@onramp.net
with "subscribe http-mib Your Name" in the body of the
message.
HOST Redux
John Klensin raised issues about the deployment
of the Host: header field under constraints that appeared in the
HTTP/1.1 draft. He presented an argument for changing the syntax
of the base http methods so that all use fully qualified domain
names and full URLs. This would provide a more elegant solution
to the "vanity domain" problem which is currently consuming
IP addresses than the proposed HOST command, which he believes
might easily be misimplemented. The sense of the meeting was
that, while this was an elegant solution, it would break a large
number of existing servers and the desire for interoperability
with older implementations would force providers to keep associating
vanity domains with unique IP addresses. As an implementation
plan, the group will tighten the wording on HOST to make it clear
that it is a MUST, and plan to make the shift after widespread
deployment of HTTP 1.1.
APPS/TSV
On Monday, there'd been an APP/TSV open
meeting on the impact of the Web on the Net. Jim Gettys reviewed
his presentation. The basic problem is a "tragedy of success".
There are so many users of the web that congestion is becoming
endemic on many links, especially those which are transatlantic
or transpacific. The routing table caches are also being rendered
useless by the relatively short packet trains of http. Possible
long term solutions include multiplexing connections, a multicast
transport layer, and extensive caching networks. Projections
are for an eventual growth in the web of four orders of magnitude,
so we need to address this problem as quickly as possible. Persistent
connections should help to some degree, but there will remain
potential fairness problems in allocating bandwidth.
Web Transaction Security
Larry Masinter reported on the results of
WTS Working Group meeting. The WTS working group will clarify
the relationship of SHTTP and HTTP in their current draft, and
then it will likely move forward as a proposed standard. This
will put some constraints on what the HTTP 1.1 documents can say
about security. As working group chair of HTTP, Larry feels that
the work on security relatives to HTTP is taking place in WTS
and encourages those interested in that area to work with both
groups. Digest Authentication is a special case which will be
finished in this working group; it should, subject to problems
with the wording, be in HTTP 1.1.
Persistent Connections
Alex Hopmann presented the results of the
persistent connection subgroup. The persistent connection subgroup
took as its goals proxy support, simplicity, 1.0 compatibility,
and fast deployment. The subgroup has come to consensus on the
use of Connection: persist as header, along with Persist:<server-name>
(Keepalive: must also be sent to maintain 1.0 compatibility).
These headers must be deleted by proxies; they apply only for
one hop. I f the next hop server replies with the same headers,
it will then keep open the connection after sending its response.
The client may pipeline requests and the server may pipeline
responses. The server must, however, reply to requests in the
order they were received.
Discussion in the working group of marking
entity boundaries came to the consensus that chunked transfer
encoding would be required but not whether support for multi-part
mime would be optional, required, or omitted. Further discussion
on the list will be needed to clarify support level.
Range Retrieval
Ari Loutonen presented the changes to the
Range-retrieval proposal; they are very few--only the if-valid
and if-invalid sections have changed substantially. Discussion
of how range retrieval interacted with caching concentrated on
reducing the number of headers, with the conclusion that logic
bags would not actually reduce the number of possible choices
needed for completeness, even if those choices were squeezed into
a smaller number of headers.
Extensions
Rohit Khare reviewed the status of PEP,
the Protocol Extension Protocol. He believes that the syntax
for PEP is currently complete and ready for review by this group,
but he does not believe that it is a critical path item for HTTP
1.1. The principal changes in PEP are the addition of scope and
the deprecation of a central registration of protocols. PEP does
require a minor version upgrade in HTTP, but only a minor version.
Discussion presented a number of issues related to the association
of related extension protocols (or version of extension protocols);
no resolution was reached, however, and they will be continued
in conversation with the authors.
Demographics
Brian Behlendorf gave an introduction to
the demographics work currently going on in the W3C; this work
would set up a common logging format for proxies and develop methods
for servers to interact with proxies to retrieve information on
transactions they have handled. This system sees the proxies
as acting on behalf of the server; John Klensin challenged this
trust model by noting that historically proxies have acted on
behalf of the user. Legal issues were also raised about both
privacy and legality of storing cached material in the absence
of an agreement; after polling the group, Larry Masinter declared
demographics not on the critical path for 1.1, but within the
scope of the group.
Logistics
In a discussion on logistics led by Jim
Gettys, the group established a timeline which would lead to a
draft being sent to the IESG on May 1st. According to this timeline,
a small group will conduct an immediate triage on issues which
can, might, or cannot be resolved in time for a May 1st draft.
This will be reviewed by the group and sent to the ADs; a feature
list and a structure for the set of documents will be presented
by March 18th. A draft will be ready for working group review
by April 1st. Jim intends for the group to follow the issues
list very closely, and asks that clarifying discussions be conducted
off-list and then reported to the list. Concrete wording for
suggested changes will be essential for this timeframe, and he
encourages us to agree to defer quickly what cannot be resolved,
so that we can accomplish what is needed immediately.
THURSDAY AFTERNOON
A smaller group met on Thursday afternoon
to continue the discussion of logistics. The group reviewed a
calendar and worked backward:
We accepted that it was important to influence
the next release of HTTP products from major vendors; we were
given information that having a proposed standard by May 15 is
important. No product can claim to 'comply' with the draft until
the draft has been accepted by IESG as an action item by the IETF
secretariat. Giving allowance for the web conference, and the
possibility that the first draft might bounce, it seems important
to submit the HTTP/1.1 draft to IESG by May 1. Working backward
from that, this meant having a new draft ready by April 1. The
calendar we came up with was:
March 13 - Review issues
March 15 - Feature list & structure of the document(s) set April 1 - Updated draft to W.G.
April 2 - Start new issue list specifically on updated draft April 24- W.G. last call
May 1 - IESG submission of 1.1 draft.
The group then reviewed the issues list:
http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/http-wg.html
and assigned owners to each item to shepherd the issue through and propose revised text.