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

Text File | 1996-06-03 | 13KB | 313 lines

CURRENT MEETING REPORT


Minutes of the HyperText Transfer Protocol Working Group (HTTP)

Reported by Phill Hallam-Baker, W3 Consortium,  and Rohit Khare,
W3 Consortium


The meeting was held as two sessions, one in the morning and one in the
evening.  Minutes for the morning session were taken by Phill Hallam-
Baker and those for the evening session by Rohit Khare.


Session 1

Larry Masinter has become co-chair of the Working Group along with
Dave Raggett.

Roy Fielding presented the status and plans of the Working Group.  A
discussion resulted from his presentation.

HTTP/1.0 was proposed as Best Current Practice but was rejected by the
IESG because it didn't describe people's view of what was ╘best,╒ and
thus it was deemed an inappropriate status.

Roy described his proposal that HTTP 1.1 be 'fast track' and that HTTP
1.2 contain the extension mechanism and those bits that didn't make
HTTP 1.1.  He explained that he wrote things into the HTTP 1.1
specification even though they might be controversial because it was
easier to take things out than to add them to the specification.

After some back and forth about a variety of options, the desire for a
stable core, and so on, the discussion led to the proposal that HTTP/1.0
be re-written as an Informational RFC describing current practice.

'Current practice,' however, does not mean that we should document all
50 versions of content negotiation as practices. Instead, we should
merely use the core of the 1.0 document as it stands for the parts that
are specified, and note that other features are not implemented
consistently.

Some other points raised included:

o  1.0 is actually not any simpler than 1.1.  1.0, however, does ignore
   proxies and gateways;
o  all current clients/servers/proxies claim HTTP/1.0 in their headers.
   If we were to create a 'best current practice' document for HTTP/1.0,
   there becomes something for clients/servers proxies to conform to, but
   then there is no way for an agent to tell whether it is talking to a
   peer that claims conformance;
o  the 1.0 specification has been useful as it is because it is stable and
   consistent despite the fact that it is incomplete: and,
o  it is a bad idea to make something a standards track document and
   then obsolete it immediately.  1.0 should not be a proposed standard;
   1.1 should be.

Dave Kristol discussed his draft, draft-kristol-http-state-info-01.txt.

Dave presented the following ideas:

o  To support state full sessions in a stateless protocol such an idea is
   similar to netscape cookies).  Examples include shopping basket,
   subscription library system (for this remembers what has been looked
   at); and,
o  define new header State-info that carries state information between
   user agent and origin server.

Requirements:

o  Cache friendly
o  simple to implement
o  simple to use
o  can be deployed quickly
o  downward compatibility
o  reliable
o  protect privacy
o  support complex dialogues
o  enough cache control possible
o  minimal risks when used with non conforming caches

Dave went through the proposal.  There is some belief that this may
'compete' with the Netscape 'cookies' method, but that is claimed not
to be sufficiently documented. Comments during the meeting inluded:

The privacy concern is not that the site that initiated the session might
know things about the user, but that other non-related sites might be
able to find out things about your sessions. (Larry Masinter)

The security concern of allowing server to store data on the clients disk
should be addressed explicitly.  (Ed: this was a subtle point) (Phill
Hallam-Baker)

There is an issue with regard to servers with multiple CGI services
which do not wish to share state information. (Alex Hopman)

This is a server implementation issue. (Dave Kristol)

Rohit Khare gave an overview of his PEP proposal, draft-khare-http-
pep-00.txt.

1. History
"Motivation; Existing Practice of Adding Headers;
Extension/Negotiation experience in other IETF work areas"

2. How "extensions" work
o  feature present
o  "Modes activated by mere presence of a header: e.g. keep-alive,
   etc."
o  reprocess body
o  "Filter message through program with <args>: e.g. encryption"

3. PEP features
o  naming
o  "Packaging a standard into a single name; a la ESMTP"
o   addressing
o  "Explaining which HTTP agents need to act on extensions; a la
    Ipv6 option faulting and scoping"
o  negotiation
o  "Advertising which extensions (at which settings) HTTP agents
   will accept; lessons from TELNET Option Negotiation"
o  processing
o  "Order-of-application; reuse of Content-Encoding header to form
   pipe"

4. Directions
o  "W3C is developing this for security, payments application; PEP
   will be HTTP 1.2; May form the basis for integrating work of
   HTTP sub-working-groups"

Comments:

The trend in the IETF has been to strict versions something that people
can read on the back of a box. Once an extension list is in a protocol we
have a checklist. We have never handled a transition from an
extensions mechanism to a real verb well. PEP should consider
migration to real verb properly. (John Klensin, speaking personally and
not as A.D.)

Typically the view is that an extension mechanism allows negotiation
of optional features.  A different view is to say we want to move from
here to this one place, and that the negotiation mechanism allows
movement of a functional core to a new base.  This is Dave's view of the
ESMTP work. Negotiation for combinatorial choices does not seem to
work but as a migration strategy it does. (Dave Crocker)

Don Eastlake described his Internet Draft, draft-eastlake-internet-
payment-00.txt

He has reviewed the problem of doing payments on the Internet.  What
is needed is a mechanism for specifying payment systems so that once
there is an idea of prices it can be decided what type of system is most
effective.  He noted that there is no attempt to constrain the payments
system.  This draft allows a payment or receipt to be put into the
header and allows for payments to be made over the Internet using a
common framework.  The current plan is to recast in terms of PEP.

Larry Masinter noted that in order to complete reliable payments you
need real (ACID) transactions.  HTTP, however, does not seem to have
any transaction mechanisms; e.g., you do not have the ability to find
out where an aborted transaction has been placed.  We might expect to
provide a transaction mechanism on top of HTTP to permit this to be
used.

Don Eastlake noted that we should expect such matters to be handled
by a payment system rather than an http layer, e.g. server allows
interogation of server to find out where transaction has gone.  Some
lightweight payment systems will not provide such guarantees.  Don
attempted to restrict the draft to just messages and receipts.

Dave Kristol expressed reservations about costs being embedded in
documents and URLs.

We deferred further discussion to the Internet Payment BOF.

Alex Hopman was scheduled to discuss draft-ietf-http-ses-ext-00.txt.
However, half of that internet-draft is now in HTTP/1.1.

Ari Luotonen said only a few words about draft-luotonen-ssl-tunneling-
00.txt.  It's been out for half a year.  The Working Group did not come to
any conclusions on this issue.

We then talked about draft-luotonen-http-url-byterange-00.txt.

This draft inspired the work in the HTTP/1.1 draft on ranges.  The
URL-method for byte ranges will be abandoned, although it may go
through an interim release by Adobe/Netscape.  The core HTTP/1.1
draft need not specify this if the methods and additions can be done in a
separate document and linked to 1.1 by reference; this is still an option.

One motivation for this feature was partial retrieval of PDF files.
However, PDF as currently defined in application/pdf does not have
binary offsets or byte ranges.  Apparently this is a feature of a new
version of to-be-released PDF.

John Klensin pointed out that the byte range protocol should look at
checkpoint and restart experience.  It was likely that the real problem
is that the document wants to be returned by parts, and that we need to
devise a way inside the document format to refer to parts and use that
for references.

Roy Fielding then began a discussion of the HTTP 1.1 draft.  Comments
in the first section included:

He thought that caching was meant to be a transparent optimisation
technique.  Nice simple semantics of http is being interfered with by
the clutter of discussing this intermediary optimisation.  The problem
is that there are lots of different types of caches and hence different
types of optimisation between server and intermediaries.  We are
describing cache control headers in terms of operational effect rather
than semantic differentiation; this does not anticipate future cache
techniques. (Larry Masinter)

In response, Roy noted that these were just the header names, and the
semantics were described that way.

Someone suggested putting content negotation outside in a separate
draft.


Session 2

Simon Spero discussed HTTP-NG.

HTTP-NG is the first protocol endorsed by Dogbert.  "Resist and you
will be shot." (Scott Adams cartooned a Dogbert on the HTTP-NG
draft.)

His presentation was a shortened version of the one to be presented at
the WWW4 Conference in Boston.

The primary modifications have been:

Split the document into Architecture and Basics documents.

The basic purpose is: negotiation, meta-information, and control.

Highlights:

o  Uses SCP to multiplex sessions.
o  Transition strategies using DNS CNAME to indicate NG support.
o  Not a superset of HTTP/1.x
o  Just forwarding HTTP1.0 through ng encoding reduces packet count by
   50 and speed by 180%
o  negotiation and profiles. Dictionaries on either side constitute shared
   state, and profiles are predefined dictionaries of preferences.
   Dictionary structure patterns can be reused in different exchanges.
o  Security Key exchange
o  reinventing several secrecy nd signature mechanisms
o  Get put and metainformation
o  HTTP/1.x metainfo + US MARC records.
o  can request metainfo for included or linked objects.
o  speculative sending of data can be enabled, experiments can reduce
   latency to 1/5th

After various discussions, the chairs presented the results of their
dinner planning session:

o  The HTTP/1.0 draft will be revised to become an 'informational RFC'
   which describes common current practice.  Paul Hoffman (maintainer
   of the list of HTTP servers and their features) will help.  This is
   primarily an editorial task, although additional material may be
   added to list features that are widely but inconsistently
   implemented (e.g., accept: headers).

o  The HTTP/1.1 draft will be reviewed independently by separate sub-
   groups. The sub-groups are chartered to review the HTTP/1.1 draft
   for text related to their issue, and propose changes to the HTTP/1.1
   draft that consist of either wording changes, or movement of major
   chunks of HTTP/1.1 to separate documents, as appropriate.

The issues are:

o  Persistent connections (this contains all of the 1.1 proposals for keep-
   alive, and maintaining connections to avoid TCP startup costs.) Alex
   Hoppman, Simon Spero, Mike Cowlishaw, Andy Norman, Scott
   Powers, Brian Swetlund volunteered.

o  Cache-control and proxy behavior-Ari Luotonen, David Morris, Jim
   Gettys volunteered.

o  Content negotiation-Larry Masinter, Simon Spero volunteered.

o  Authentication-Phill Hallam-Baker, Alex Hopman, John
   Marchinoi, Stefek Zaba, Scott Powers volunteered.  (This issue must
   be coordinated with WTS working group drafts.)

o  State management-Dave Kristol, Rohit Khare, Scott Powers
   volunteered.

o  Range retrievals-Stephen Zilles, Ari Luotonen volunteered.

o  Extension mechanisms-Paul Hoffman, Rohit Khare, Daniel
   LaLiberte, Simon Spero, Phill Hallam-Baker volunteered.

o  other new methods and header features (no list of volunteers for this
   was gathered)

o  Subgroups should conclude their work by Jan 96, in time to publish
   their conclusions (or lack thereof) to the rest of the WG by February
   96, so that new internet draft(s) for HTTP/1.1 will be ready in
   March 96 and ready for Proposed Standard RFC status by June 96.

o  Subgroups should document meetings, progress, etc. and are encouraged
   to meet regularly, by conference, phone, etc.

o  Any proposed HTTP/1.1 features not in HTTP/1.0 for which there is
   no consensus will revert to HTTP/1.0 status in 1.1 and be considered
   for inclusion in HTTP/1.2.

Alex wondered where 'logic bags' fit, and Larry suggested it should be
handled by the cache control/proxy group.