DRAFT combined minutes for HTTP-WG

I combined the minutes for Monday & Wednesday. Please let me know
if you think I did any violence to them or the intent.

Larry

HTTP Working Group Meeting, December 8, 10, 1997
Chair: Larry Masinter

Minutes were recorded by Jim Whitehead, Daniel Veillard and Rohit Khare,
edited by Larry Masinter. These minutes combine the notes from Monday
December 8 and Wednesday December 10.

We reviewed issues from the issue list.  Most of these issues reflect
edits that were already in the 'rev-01' draft but needed additional
review.

New issue AUTH-INFO-SYNTAX: New issue, reviewed for the group, but no
conculsion.

New issue DIGEST-PROBS: Reviewed briefly, but take to the list.

Henrik presented CONTENT-ENCODING and a proposed solution: add to
accept-encoding "*" (meaning all encodings), "identity" (meaning no
encoding), and qvalues (for yes and no).  There are some proxy issues
with respect to content-encoding, and transfer encoding: a
Content-Encoding can go through proxies, but a Transfer-Encoding
cannot. Dropping q values would avoid 406 codes from existings HTTP/1.1
servers, but would not fix some current problems.  After discussion on
whether any clients will support this, and a proposal of a
"Decline-Encodings" header, the preferred solution is to use the
solution in the issues list. This will be discussed more on the mailing
list.

Issue PUT-RANGE: Few people had reviewed the rev-01 draft. There was no
implementation experience with this in the room ( Henrik claims that he
might have implemented something similar, once). On Wednesday, we
discussed that the use might be in a proxy which updates a byterange of
its _cached_ copy at the same time it passes back to the origin. But 1)
in WebDAV, many proxies may have partial views of the update
changes. So, you'd have to recheck e-tags to update caches -- and
redownload all that material. 2) more to the point, editing ususally
adds and removes material, which put-range does not do. This feature
requires a robust version number to detect the feature; a server that
did PUT but not byteranges would REPLACE the whole resource; thus it
should be forbidden, not just discouraged.  We agreed to leave PUT with
byte-ranges out of HTTP/1.1 (discouraged or forbidden). The WebDAV group
may propose a PATCH method to handle this capability instead.

Issue DIGEST_SYNTAX: was reviewed, but will be discussed on the list.

Issue PROTECTION-SPACE: People are happy with the current language, but
current implementations don't behave as specified; the spec doesn't
break any existing implementation. We'll go forward with the current
language in rev-01.

Issue CONTRADICTION: The Proxy-Length change introduced an error. The
proposal in rev-01 was accepted.

Issue IMS_INM_MISMATCH: The proposal in rev-01 was accepted.

Issue BYTERANGE_SYNTAX: This is a subtle problem; some implementors seem
to want to be too smart. We need to specify that you should do the
"dumb" thing, not the "smart" thing.  The proposal in rev-01 was
accepted.

Issue PROXY-REDIRECT: The functionality is desirable (e.g., for
switching to a new protocol in the future, via use of proxies), but
someone from needs to develop a draft to address this
problem. Resolution: add note to spec. to deprecate 305, and note that
it should not be implemented.  Document security problem with this
status code.

Issue RE-AUTHENTICATION-REQUESTED: Most current clients do not discard
credentials when they receive a 4xx status code.  Roy Fielding had
suggested that an extra header should be used to inform the client to
discard credentials.  One problem with this approach is the server does
not know if the client really has discarded credentials. Resolution: add
a note to the security considerations indicating that this issue exists,
but has not been addressed in the specification.  This should not be in
the Draft Standard 1.1 spec. Scott Lawrence may develop an
Internet-Draft to address this issue outside of the Draft Standard.

Issue RANGE_WITH_CONTENTCODING: Should range requests apply before or
after content coding?  On Wednesday, we agreed to "last call" the
resolution in rev-01.

Issue TRAILER_FIELDS: Discussion on why this is needed, and whether
clients are likely to support this. On Wednesday, we agreed to "last call"
the resolution in rev-01.

Issue HOST: Resolution in rev-01 is closed.

Issue RE-VERSION: (Wednesday) If you DON'T upgrade the request, you'll
get a lower-version answer for your cache -- a subsequent 1.1 request
CAN'T be satisfied from a 1.0 cached response. 1.0 requests can be
answered from 1.1 responses. Richer responses can always be used to
answer simpler queries. Henry Sanders will post his remarks to the list,
and then RE-VERSION will be closed.

New issue DIGEST-SCALING: (Wednesday)
RFC 2069 had one concern raised: Digest does not work well with proxies
and not at all across multiple servers. Paul Leach will soon post to the
list a small tweak which addresses both (and issue a new I-D?).

================================================================
State Management:

Dave Kristol reviewed State Management

Timeline: 
- December, 1995 [sic!]
  state management sub-group formed
- April, 1996
  first Internet Draft, http-state-mgmt-00
- July, 1996
  I-D submitted as prospective RFC, minor wording tweaks for
  IESG in Oct., Nov.
- February, 1997 
  RFC 2109 issued

RFC 2109 Issues:
- compatibility (interoperability):
  client behavior on unrecognized attributes 
- privacy
  especially "unverifiable transactions" user
- interface requirements
  arising from support of privacy protection

RFC 2109 Followup, since February:
- compatibility (interoperability)
  Define Set-Cookie2 response header
- privacy and user interface requirements
  temporarily delete contentious parts

Major Changes Since RFC 2109:
- Set-Cookie -> Set-Cookie2
- add CommentURL attribute
- add Discard attribute
- add Port attribute
- fuss with Domain, domain-matching
- clarify behavior for unrecognized or duplicate attributes

State Management Progress Plan
- current draft:  http-state-man-mec-05
  "pure protocol" (more or less)
- do Last Call on -05
- restore privacy/user interface parts
- discuss and seek consensus
- reach Last Call
- submit result to supersede RFC 2109

Where to look:
- DMK's cookie page
    http://portal.research.bell-labs.com/~dmk/cookie.html
- Current draft
    draft-ietf-http-state-man-mec-05.txt
- HTTP-WG mailing list
    http://www.ics.uci.edu/pub/ietf/http/
- http-state mailing list
    http://www.bell-labs.com/mailing-lists/http-state

Following the slide presentation, there was discussion on the privacy
considerations in the draft.  Ted Hardie: In Comment-URL, the URL could
potentially be a non-HTTP URL, and this issue needs to be addressed.
Dan Jaye presented some information on further work on trust labels.

State Management will proceed as an informal working group. There is no
plan to form a formal IETF working group at this point.  On Wednesday,
it was reported that a small group of developers reviewed the
outstanding issues with state management and found one technical and one
political problem left. Technically, domain matching does not work with
flat (intranet) domains where "foo." is an FQDN. The political issue is
user notification of cookies from unverifiable transactions -- should
people be tracked by an external source of inline images or applets or
audio?
================================================================
Extensions

Scott Lawrence gave a presentation on OPTIONS and PEP:
  Motivation - Extensibility
    Both OPTIONS and PEP were intended to provide more robust
    extensibility mechanisms for HTTP/1.1.
  Extensibility of HTTP/1.1
   -Clients can advertise some kinds of capabilities using Accept-*
    headers.
   -Clients and Servers can prevent inappropriate caching by 1.1 Proxies
    using Vary and Cache-Control.  This may result in cache misses that
    could have been hits, but can if used correctly prevent hits that
    should have been misses.
   -Clients have _very_ limited ability to discover whether or not a
    Server implements a given extension.  The response version number
    and the OPTIONS method are the only mechanisms available.
   -No mechanisms for discovering which optional or extension headers
    are supported.
   -No mechanisms for discovering which optional or extension headers
    are supported, or what definition of a given header is implemented.
   -Discovery of Proxy capabilities by either Clients or Origin Servers
    is worse.
  History
   -These issues have been discussed on the WG list since (at least)
    early 1995, insufficient consensus has been reached to incorporate
    stronger general purpose discovery mechanisms into the standard.
  Issues Resolutions for Draft Standard
   -OPTIONS: Incorporate only the minimal definition (no defined body
    for OPTIONS response, only use the Allow header field).
   -PEP: Possibly proceed as an Experimental RFC, nothing in Draft
    Standard.
  Futures
   -Extensions to HTTP are being actively developed, both by and within
    IETF (UAhint, Safe, Content Negotiation, State Management, WEBDAV,
    Hit Metering)
  Guidelines for Extensions
   -HTTP-WG has learned (and relearned) about many problems inherent in
    each of the possible means of extending HTTP (new methods, new
    headers, new values or semantics in existing headers).  Protocol
    mechanisms have not been defined to avoid or mitigate all of these
    possible pitfalls.
    
   -It would seem to be a good idea to develop an archival document
    (FYI, BCP?) to capture some of this knowledge as advise to others
    who will develop and attempt to deploy HTTP extensions.  This will
    not be a work item of the HTTP working group.

After discussion Monday & Wednesday, a new working group (HTTP EXTEND)
will be chartered. It is important to move forward on this because there
are a large number of working groups that want to layer themselves on
top of HTTP.

There is a need to develop a document which explains both the "dos" and
the "don'ts" of extending HTTP.  This document should start with the
"don'ts" so they can be captured to prevent future bad practice.

The HTTP Extension group will develop PEP, the HTTP extension guidelines
document, and the OPTIONS draft.  The Extensions team reported a
strawman charter for 1) producing an FYI document of guidance on adding
features, headers, and methods to HTTP, 2) extending error response
codes, 3) and simplifying PEP and OPTIONS into a reliable extension
hook. It is NOT an HTTP/1.2 group. Josh Cohen and Scott Lawrence will
chair and edit, respectively, an investigation into how-to-extend, not
what-to-extend.

Other extensions were discussed, e.g., transactional HTTP. People forget
about interaction with proxies in general; it should be explicitly
considered.

The group will also take on Schulzrinne's extened error codes work. (The
arguments against on http-wg were really bogus.)  A report on experience
reading PEP: it was necessary to talk to Henrik to figure it out. A
requirements document may be necessary and will be considered.

There is no formal requirement for a separate BOF, but the IESG
may need to announce the working group.
================================================================
Keith Moore asked for volunteers for a document to integrate TLS &
HTTP. Rohit Khare volunteered.
================================================================
Interoperable implementations:

To advance to Draft Standard, we need to document at least two
independent, interoperable implementations of each feature. It isn't
necessary that the features be in the same implementation, and the
implementations need not be shipping products.

Tuesday night, a half-dozen client, server, and proxy developers sat
down with the chair and editor to walk through the draft section by
section. The main insight was that we'll need much more systematic
support to document the hundreds of requirements in HTTP/1.1. Caching,
in particular, seems to be the most fraught with difficulty. Scott
Lawrence agreed to continue his (very useful) Thursday testing bees; and
there was a survey of interest in face-to-face implementation bake-offs
or conference calls.
================================================================
Web Privacy

User Services sponsored a BOF on Web Privacy. April Marine reported the
broad support for investigating the nexus of trust issues around the
Web. A detailed charter awaits debate, though, on web-priv@nasa.gov. A
second BOF is projected for LA.
================================================================
Content Negotiation

Recipient Feature Profile (nee content-negotiation), weaves together
extensibility threads from HTTP, printing, fax, mail, and many other
application-layer protocols. Ted Hardie reported the conviction the
group will set up a registry as quickly as possible. Then, it may tackle
aggregation of features and a prototypical example of how to store
profiles within LDAP, etc.
================================================================
HTTP-NG

W3C has been working on experiments for HTTP-NG, which had a BOF at 39th
IETF and will surely be heard from in 1998.
================================================================
CONCLUSION

A poll ("Will there be an HTTP/1.2?") had a lot of responses, split
50-50.

This was the last planned meeting of the HTTP working group. The group's
chartered work is nearly complete, and no further meetings will be
necessary. Additional work will happen in other groups or outside a
formal working group. The mailing list will remain open.

We're not really done: one estimate was that 20 more issues will be
raised from the interoperability testing.  But regardless, this was the
LAST meeting. Scott Lawrence commits to continuing Thursday
interoperability tests until such time as testing becomes
uninteresting. The HTTP-WG mailing list will remain open indefinitely
(or until Standard status 2 years from now).