Re: Comments please on agenda for HTTP working group BOF

First off:  thanks for taking the initiative to establish an HTTP
working group.  You've set a very ambitious timetable for getting
things done.  I have my doubts whether the timetable is feasible, but
I'm more often a pessimist than an optimist.

My comments appear below.
Dave Kristol
==========

[...]

  > Proposed Charter for the IETF Hypertext Transfer Protocol Working Group
  > -----------------------------------------------------------------------
  > 
  > Right now HTTP is in a mess. The internet draft has expired and needs
  > updating to bring into line with current practice. The performance is
  > widely perceived to be poor, particularly for modem users, and various
  > groups are working on disparate approaches for adding security and payment
  > mechanisms.
Bear in mind that the standards process usually ratifies existing practice.
Therefore, updating the old Internet draft ought to be the first order of
business.  Addressing well-known problems, while important, should come
afterward.

  > 
[De facto, closed standards are a bad thing....]
[W3O and IETF should facilitate open WWW standards.]
[Use Internet drafts and RFCs to define open protocols and APIs.]
  > 
  > Our suggested focus is on the short term. In particular, we want:
  > 
  >     a)  to tap into the 30% of US homes with PCs/Macs and provide
  >         the incentives for them to connect to the Web
I think this is possibly beyond our control.  If there's interesting stuff,
people will connect.  Otherwise they won't.  I agree we should have the
technology for them to use the Web at acceptable speed and cost.
  > 
  >     b)  to make it easy to pay for goods and services on the Web
Yes.
  > 
  >     c)  to protect the copyright interests of information providers
Yes.  But I doubt this can be solved in the short term.  There are many
ideas around, but I don't see any consensus on how to do this.
  > 
  > To meet these objectives, we need to build on existing work and scale
  > our action plan to what is feasible in the short term.
  > 
  > 
  > Security and Electronic Payments
  > --------------------------------
  > 
  > The suggested timetable for this is to first concentrate on what is needed
  > to securely send order details and receipts. Credit card payments can be
  > authenticated offline by the credit card companies, but the next step is
  > to provide support for authenticating servers, and subsequently clients.
  > Basic authentication is possible using the IP address. Other mechanisms

IP address is dicey if you're trying to serve those folks with their Macs
and PCs who get a new IP address each time they connect to their Internet
provider.
  > include Kerberos, and public key certificates. We shouldn't overlook
  > encryption of arbitrary HTTP requests and responses.
  > 
  > Smart cards have a bright future for payments based on credit/debit models
  > and digital cash. In the short term, no one has card readers and we need
  > to consider how to get things off the ground. In transitioning from here
  > to there, we need to make it very simple for end-users and financial
  > institutions. Some of the issues this raises include: how users register
  > with an authentication server; if public key mechanisms are used, who
  > generates the public key/secret key pairs and certificates; do the credit
  > card companies store the certificate information as well; and are the
  > transactions themselves are protected for both secrecy and integrity?
Some transactions will surely be protected.  Otherwise an eavesdropper
could capture for free what someone else bought.

Don't forget privacy.  I think it will be important for people to make
requests anonymously and/or to feel comfortable that servers do not
accumulate dossiers on their information buying habits.

  > 
[Different security approaches being developed....]
  > 
  > 
  > Improved Performance
  > --------------------
[Good proposals omitted.]


  > Suggested Workplan
  > ------------------
  > 
  > October '94:
  >     We meet in Chicago and seek agreement that a common
  >     framework is needed for security and payment mechanisms,
  >     as well as brainstorming the problems/issues that the
  >     framework should address. We agree a numbering scheme
  >     for subsequent HTTP releases, and get interested people
  >     to sign-up to take an active role.
The numbering scheme may be premature -- it may depend on who gets what
done (and accepted by the community) first.  My guess is that
development will be breadth-first, which works against the usual
numbering schemes.  What I mean is this:  after people agree on the
state of current practice, folks will go off in different directions
that, I hope, are largely orthogonal:  performance improvement,
security, payment.  A linear numbering system won't accommodate that
diversity well.  You might have to say "HTTP 1.1 with performance
improvements", or "HTTP 1.1 with security".
  > 
  > November '94:
  >     Work starts on a revised Internet Draft covering HTTP as in
  >     current use. The http-wg mailing list may be appropriate for
  >     exchanging detailed comments on this document as it is written.
  > 
  >     We use the www-security mailing list to continue brainstorming
  >     ideas on the common security framework. One or more people
  >     nominated at the October BOF write this up as an initial draft.

Please please use www-buyinfo for discussions of commercial issues.
(An interesting question is whether security and payment can be treated
separately, or whether authentication connected to payment must be
bundled with other kinds of authentication.  I'm hoping for
orthogonality, but I certainly haven't demonstrated it yet.)
  > 
  >     The objective for November is to finalize the charter and initial
  >     workplan for the IETF working group. The group uses the http-wg
  >     mailing list to work together on this document.
Yes.
  > 
  > December '94:
  >     IETF HTTP WG BOF - we present the charter and workplan. This meeting
  >     should be used to build the consensus and to look forward to the next
  >     set of actions and milestones. The work group is formally established,
  >     and people are signed up to write particular Internet Drafts.
Yes.  I would expect people to agree to the formation of a working group.
Getting them to agree to a draft charter will perhaps be tougher.  Who
knows about a workplan?
  > 
  > Spring '95:
  >     We present Internet Drafts for the revamped HTTP spec describing
  >     current practice; the framework for security; and for improved
  >     performance. This will coincide with the Internet Draft for HTML 3.0.
Describing current practice may be possible by Spring '95.  The other two
are less likely.  It would be better to have developed working prototypes
of security and improved performance features.  Remember that the IETF
expects working code in conjunction with paper specs.  It will be hard to
have both polished code and a polished draft ready in that timespan.
  > 
  > WWW'95:
  >     Demonstrations of working implementations of these Internet Drafts.
  >     The HTTP working group starts looking at new issues such as the
  >     framework needed for digital cash, collaborative hypermedia, and
  >     scaling issues for information access and the implications for HTTP.
(When is WWW '95?  Where?)
  > 
  > 
  > IETF HTTP BOF in December
  > -------------------------
[Meeting placed on schedule.]
Great!

Received on Wednesday, 5 October 1994 16:54:05 UTC