Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/http/http-minutes-96dec.txt

Text File | 1997-01-30 | 9KB | 199 lines

Editor's note:  These minutes have not been edited.

HTTP Working Group Meeting, Dec 9-10
Notes recorded by Henrik Frystyk Nielsen, edited by Larry Masinter.

1. HTTP/1.1 implementation issues
- Performance Evaluation of HTTP/1.1 pipelining (Henrik Frystyk
Nielsen and Jim Gettys) (Slides submitted independently.)  In
experimentation, HTTP pipelining resulted in a factor of 5 improvement
as measured by number of packets. (A paper is also available at
http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html)

- What should a server respond to an HTTP/1.0 request?
There are both clients and servers that choke on HTTP/1.1.  It's too
late to fix existing implementations.  If we don't say that we can do
HTTP/1.1 then a client may never find out that a HTTP server can speak
1.1 and we can't make any progress.  It doesn't seem to be headers but
merely that broken 1.0 apps look for the string "HTTP/1.0" in order to
distinguish it from HTTP/0.9. The issue was not resolved at the
meeting, but was to be (has been) continued on the mailing list.

- Content-Disposition?
We'd discussed on the list a means to give a proposed filename for
downloaded files. Since Content-Disposition is an experimental MIME
header, this may be added in a non-normative appendix.  There is a
generic security warning in the equivalent MIME document.  Alex
Hopmann volunteered to write up a note about Content Disposition.

- Warning Headers
If you have cascaded proxies then warning headers may be cached and
passed to the client even though the document has been revalidated and
is valid. The rules for how and when to strip warning headers should
be made more explicit. Simon Spero has a pointer. [??]

- 305 Response code Underdefined?
The current draft does not define 305 well. If you are behind a
firewall then a 305 response will fail on all future requests. That is
it has to be a hop by hop and not end to end return code.  There
should be a proxy configuration mechanism so that it can be handled
with proxies. Ari volunteered to write up a spec about how to use
305.

- Proxy Authentication Underdefined?
The issuse is that if you have cascaded proxies then the "collapsing"
of proxy authentication may fail. It is a different model than
originally intended where proxy authentication was a hop-by-hop
mexchanism.  Josh Cohen proposed a change to the current draft. He
would like to add a realm id. He committed to send a draft to the
mailing list.  This would also have an impact on www-authenticate.  We
agreed to review Josh's draft and decide whether to do this inside
HTTP/1.1 or outside of it.

- Should IMS and IUS be "==" or "<="
If-modified-since and if-unmodified-since are defined as
inequalities. But there may be race conditions where a client can get
a stale document. There are also problems in broken client and
daylight saving time and clock skew. There had been some belief that
an equality check instead of the current less than or equal would be
safer.  We could recommend that date stamps are not used at all but
this will not change existing clients.  Clients may reformat the
date/time stamp when revalidating.

- Who should close the Connection?
It is not clear at this point in time and we need more implementation
experience. We may want to come up with an implementation advice.

2. Content negotiation
- Transparent Content Negotiation

Andy Mutz gave an overview of the current draft: How to handle
multiple variants is an important issue in i18n.  How does this
interact with proxies and caches?  Having the clients telling its
preferences does not scale. Instead the server can ennumerate the
choices.  There are at least two implementations of TCN that can
interoperate.  Request for moving this to proposed standard in January
and hook up to HTTP/1.1? What should we do?

Implementation problems: charset, MIME types are not orthogonal!
It is still not clear how useful the current spec is in practice.
It is problematic to specify the algorithm for how to do content
negotiation, q values should be relative and not absolute.

It was proposed to isolate the alternate part from the rest of the
current spec, and progress the part of transparent negotiation that
has alternatives, but not the multiplication of q factors.

There are still some open issues: Server rendering machanisms?,
Quality values on feature tags?

- Feature Tag Registration
Andy Mutz gave an overview. We need more review from the working
group. Larry committed to make sure that the draft is added to the wg
home page.

- User Agent Display Attributes
Where should this go? It could be part of a transparent content
negotiotaion or it can be part of a feature tag negotiation.  Yaron
Goland referred to the draft to describe the feature tags that
Microsoft would like to have. It is not a proposal for a core set.
Yaron will work with rest of the draft authors to converge the
documents.

3. Hit Metering
Jeff Mogul presented the current status of the Hit Metering proposal.
An important note is that the current definition of proxy validate in
HTTP/1.1 needs to be changed. Jeff proposed a fix "Proxy-must-check".
It was noted that cache-busting may not be a growing problem and a hit
metering scheme may make it worse.  The proposal adds additional
requirements on a proxy: It has to know where a document comes from,
for example. It was discussed whether the extra overload was a
problem. The general feeling was no.  The issue of statistical
sampling was been brought up several times but nobody have provided a
draft.  The limitations of the current proposal should be made clear
in the draft. If this is met then the proposal can move forward as
proposed standard.

4. Safe POST / GET-with-body
It was discussed whether HTTP should have more properties for handling
the user-agent. There was a general feeling that HTTP should be kept
orthogonal to what goes on in the user agent. [??]

5. Other groups with work related to HTTP

- HTTP-NG
Jim Gettys talked about the status of the work. Neither of the current
distributed RPC systems IIOP from CORBA nor DCOM from Microsoft is
really suitable for the Web. One of the main problems is scalability.
HTTP-NG is being worked on, but the work is still research.

- Web Server Management
Harrie Haxewinkel reported on definitions of managed objects for WWW
servers. (Look for the APPLMIB working group.)

- SHHTP
Charlie Kaufman (chair of WTS wg) reported on SHTTP.  The wg has not
met for the last two IETF meetings.  SHTTP Was based on HTTP/1.0 and
one of the problems why it has been held up was due to undefined
interactions with HTTP/1.1.  There will be an updated draft coming out
and it will be cross mailed to the HTTP-wg list for review.

- Remote pass-phrase Authentication
Rich Petke gave an overview of the the "Remote pass-phrase
authentication" which has no passwords in clear.  There are four
drafts available as draft-petke-* The system is currently in
production.  Look for "Virtual Key" which is the slogan. There was not
an intention to move this forward in standards track.

- SLL Tunnelling
The current draft for SLL tunnelling through proxies has expired but
Ari would like to resubmit it and make it an RFC.  There are
implementations in NS and MSIE proxies and clients and also in Apache.
It was the overall feeling that the draft should move forward as
standards track.

- Web Distributed Authoring  and Versioning (Webdav)
Jim Whitehead reported. There is a BOF Wednesday.  Web DAV is based on
PUT and adding on new features for locking, link management,
relationship, attributes, etc. The proposals will interact with
containers and webmaps, and include access control and versioning.

- Internet Printing Protocol
Carl-Uno Manros reported. The work started with the same group which
did the printer MIB. The goal is to make printing available over the
internet with more features than are in lpr. An initial proposal looks
like it uses HTTP.

- MMUSIC
There is ongoing work in MMUSIC on RTSP and SIP which looks something
like HTTP. They want to use HTTP but don't want to step on HTTP
version numbers: is there a registry?  As HTTP is getting more complex
it is difficult to role your own stuff anymore. This will make other
people have to reinvent their own protocol. Maybe a layering of HTTP
would solve this.

6. PEP
Dan Connolly report that no new draft has been issued and there was
nothing to discuss at this meeting. People are eagerly awaiting the
next draft. Paul Leach noted that PEP didn't allow extensions for
error messages as MMUSIC noted.

7. Working Group Plans
There a couple of months left before the HTTP/1.1 can go to draft
standard. We should work towards that date!  There are some minor
details that should be incorporated into the current
version. Hopefully it will not have to be recycled as Proposed.  The
alternate stuff should be taken out of the current content negotiation
to be put into a separate draft and moved forward.  Things don't have
to be folded into the current HTTP/1.1 - they can be merged later.
Anything that relies on the version number should be added and stuff
that doesn't should be kept separate.

Proposed milestones:
   o 2/97 Hit Metering to IESG
   o 2/1/97 New drafts on remaining isses and problems in HTTP/1.1
   o 2/1/97 PEP draft
   o 2/1/97 Content Negotiation draft
   o 3/1/97 New 1.1 suite of documents going to IESG