DRAFT Minutes, 35th IETF HTTP-WG

Many thanks to Ted Hardie for taking notes at the session. I've
reviewed and revised his notes, and added my own recollection of what
happened in the Thursday afternoon session. (Credit to Ted, complaints
to me.) If there are no additional editors or corrections, I'd like to
send this on as the official minutes in the next few days.

Minutes of the HTTP Working Group at the 35th IETF (Los Angeles, March
4-8, 1996).  Reported by Ted Hardie (hardie@nasa.gov), revised by
Larry Masinter (masinter@parc.xerox.com).

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 Jim's selection as
editor; as is expected of WG editors, Jim confirmed that he would act
on behalf of the working and that he did not see his role at Digital
or in the W3C as 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 was 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.


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 had 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

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 crate 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

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:


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 sesne 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.


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.  If 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.


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.


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.


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 group then reviewed the issues list:


and assigned 'owners' to shepherd the issue through and propose
revised text within the next week.

Received on Tuesday, 12 March 1996 01:07:07 UTC