draft minutes, HTTP-WG meetings April 7

Minutes reported by Ted Hardie. Please send corrections,
additions, or requests for clarifications to me, so that
I can incorporate them in the final minutes.

Note that there are a large number of "action items"
that various people committed to do, and that we need
to see these items completed quickly, since we also still
have a large number of unresolved issues.

Thanks,

Larry

Minutes, HTTP Working Group, April 7, 1997, Memphis, TN.

The group concentrated on closing outstanding issues.  Jim Gettys led
a point-by-point review of the issues list
(http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/).
   
In the discussion, the following issues seemed to have sufficient
consensus in the meeting that "last call" will be sent to the 
mailing list for each of them:
   "chunked encoding" clarification
   the caching issue raised by Dingle
   accept-charset wildcarding
   proxy authorization
   the FIN-WAIT2 issue
   Jeff Mogul's resolution for connection
   and the impermissability of CRLF in a quoted string

Jeff Mogul's drafts on HTTP versions and proxy-revalidate will also go
to last call in their current forms.

The following issues are resolved in principle, but require language
to cover the needed editorial changes or clarifications:

-- Content-Disposition will be added to the Appendix, as one
   of a group of common MIME headers about which implementors should
   be aware; Koen Holtman will draft the addition.

-- The draft by Gettys et al on who should close the connection
   represents valuable information and advice, but needs some
   continued development.  A new version is expected shortly.

-- Richard Gray will provide language on sending 100 series response
   codes with no date headers; Jim Gettys will then fold these into
   the main document.  

-- Jeff Mogul will draft an explanation of how to cache resources
   containing a "?" in the context of HTTP 1.1.

-- Paul Leach will provide an examination of the use of byte-ranges
   with PUT, with the understanding that there was mild applause in
   the working group for eliminating the possibility of PUT with
   byte-ranges.

-- Ted Hardie will draft a missive on how to respond to a request for
   a range of bytes for a resource which contains none of the bytes in
   the range.

-- Roy Fielding's solution for how to define max-age for responses is
   accepted in principle, subject to minor wording changes to be
   worked out between Jeff Mogul and Roy.

-- Larry Masinter will author an implementation note on the
   desirability of including charsets in responses.

-- Paul Leach will pen a note on a proxy being able to serve a
   resource with a content-length when it received that resource with
   chunked-encoding.

-- Scott Lawrence will provide a sentence or two which will cover the
   possibility of leading zeros in a content-length.

-- Koen Holtman
   will draft a clarification that a qvalue of 0.0 means "Don't send
   me this."

-- After consulting the language in use in RFC822, Koen Holtman will
   also draft an editorial correction on the use of LWS in headers
   like VIA.

-- Jeff Mogul will respond to syntactic changes proposed by Koen
   Holtman for the HTTP-warning draft; if appropriate, a new version
   of the draft will appear.

-- The Hit-metering draft will go last call after Jeff checks it for
   one last set of editorial revisions.

Not all issues reached closure.  For those which did not, particular
individuals may have accepted responsibility for providing next steps.
In all cases, however, input from others is solicited.

Josh Cohen will take responsibility for re-raising the issue of using an
equality check for Date If Modified on the list.

While there is general agreement that 305 should be limited to use by
origin servers, the proposal by Josh Cohen for 306 needs both concrete
language and further discussion of the implications of a proxy-managed
proxy redirect.  Josh Cohen will provide a draft explaining Netscape's
vision for 306.

The issue of how to handle age calculations remains contentious; Jim
Gettys has suggested that a small group interested in the problem should
get together and work out a solution.  Those interested in being part of
that group should volunteer on the list; implementors of proxy caches
are particularly encouraged to share their experience.  To help minimize
this issue, Jim will draft language which strongly encourages proxies to
run with synchronized clocks.

Jeff and Henrik raised the issue of inappropriate client behavior on
receipt of a content-encoding that it does not understand.  Henrik will
draft a document a proposal to fix the problem; since this touches on
the difference between different content- header types, careful review
of the proposal by the working group will be needed.

Josh and Henrik will work off-line on the question of what a client
should use in the HOST: header when it has a url with a host part that
is not a fully qualified domain name.  Regardless of the outcome of that
discussion, Paul Hoffman will draft language proposing that the client
be allowed to chop the host part out of the URL and use that.
Discussion of the two proposals should consider in particular the
difficulties faced by clients which would have to resolve hosts into
fully-qualified domains and the difficulties faced by proxies without
access to fqdns as identifiers.

Henry Sanders will check Microsoft's implementation of chunked encoding
to ascertain whether the Digest Authentication headers can be placed in
the chunked encoding trailer.  If it does and there is no contrary
implementation, the issue is closed; if it does not, the working group
will need to examine the interoperability issues of allowing those
headers in the trailer.

The question of sending a Retry-After with 503 and 3xx response codes
has been tabled, pending Mr. Briscoe's providing a compelling reason for
allowing the Retry-After.

Jeff and Henrik will write up a short draft on how to optimize returns
on range requests by removing meta-data which is not needed to assure
the client that the range returned is part of the correct resource.
Henry Sanders will review based on implementation experience at
Microsoft.

The issue raised by Koen Holtman regarding the asymetry in matching
rule for accept language in 14.4 produced a great deal of debate on the
appropriate matching semantics.  Dirk van Gulik will identify the
appropriate ISO documents which indicate why matching semantics based on
wildcards will not handle all cases.  Since HTTP's use of language tags
is derived from RFC 1766, changes needed in HTTP might, in fact, reflect
changes needed in RFC 1766.  Exactly how much of the matching algorithm
belongs in the protocol is not clear, and further discussion will be
needed on the mailing list.

Discussion of Koen Holtman's draft on Safe Post and Dave Morris' draft
on UA-hint focused on two issues: whether safe post and history list
manipulation belonged in the same mechanism and which of the two
proposals best handled the issue.  No consensus emerged, but interest in
this in certain user communities (Banks etc.) is high enough to warrant
further work.  Some indications were given progress might be faster
after splitting off the history list issue from the safe post issues
required for i18n, but, again, no real consensus emerged.

Dan Connoly presented the new PEP draft.  Three major issues were
raised: PEP can be overkill for some small, lightweight extensions; the
cost of discovering whether or not a server understands PEP and a
particular extension can be significant; and the draft's language for
how to handle these extensions through HTTP 1.0 proxies does not seem
adequate.  Koen Holtman suggests that the language in the hit-metering
draft is a good model for how to handle PEP with 1.0 Proxies.  Dan will
look at that language and the other objections; a new draft is expected.

Koen Holtman presented a portion of the TCN drafts; time constraints
did not allow the group to consider the full set.  The base portion of
TCN is now stable, and there are server side (Apache) and client side
(Tango) implementations.  Preliminary indications from Dirk's
experience as a server implementor are that this is a very successful
mechanism for negotiation on things like image format, but that
language and character set encoding need more implementation before
they can be fully evaluated.  Yaron Golan (not speaking officially for
Microsoft) noted that he did not feel that TCN was rich enough for the
applications he envisioned; he felt that script-based solutions would
be required for any meaningful content negotiation, and these
solutions would both enable better server/author control and would
shift the computational locus to the client.  Scott Lawrence and Ted
Hardie spoke in favor of the TCN framework, noting that it was richer
and leaner than Accept headers while being fully interoperable.  A
counter-proposal by Mr. Briscoe will be sent to the list in the form
of a paper.  The chair ruled after discussion that the working group
is not ready for last call on these drafts.

Dave Kristol presented his new Cookie draft and discussed, briefly,
the controversy which has surrounded the subject. ("In the case of RFC
2109, it was a Request For Comments, and it got some.")  Two classes
of problems were raised: interoperability problems and objections to
the default settings required by 2109.  The interoperability problems
are being addressed in the new draft.  Those objecting have been
invited to present alternative proposals.  Dan Jaye, of Engage
Technologies, has proposed one solution, but it requires a public key
infrastructure that would delay deployment too long.  His work and
other solutions for resolving the tension between user privacy and
traffic can go forward independently, but, based on Area Director
input, we should not repeal what we have in favor of a technology
which will take a year or more to put in place.  Interested parties
should note that the W3C is putting together a forum to address this
issue.

The session closed with the Chair noting that the main work of the
group should be progressing HTTP 1.1 from Proposed to Draft Standard
and that he hopes to close the working group by the next IETF meeting
in Munich.  Other groups working on specific problems may be needed,
but he believes we have reached a stage where they can operate
independently.