W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Comments please on agenda for HTTP working group BOF

From: Dave Raggett <dsr@dragget.hpl.hp.com>
Date: Wed, 5 Oct 94 17:43:20 BST
Message-Id: <9410051643.AA06058@dragget.hpl.hp.com>
To: http-wg@cuckoo.hpl.hp.com
My reactions to Dave Kristol's comments:

> 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.

Agreed, although I think that we can work on problems in parallel.

>>     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.

The goal is to unlock the business potential, the means to achieving
this are asserted to be improving performance and simple payment mechanisms.

>>     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.

I think there may be short term steps we should take, e.g. passing
limited copyright information in the HTTP header, perhaps along with
contractual restrictions on right to print/save local copies. A related
idea is to allow publishers of "free" information to get some idea of
how many people are accessing it via shared caches.

>> 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.

Good point. None-the-less there is a need for a basic authentication
mechanism in the absence of the infrastructure for a stronger solution.

>> 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.

Agreed. The intent was to raise the distinction between secrecy and integrity.

> 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.

Can we do this in the short term?  I am interested in exploiting the
blinding techniques of David Chaum, but don't yet know enough to get
a clear idea of how feasible it will be to support this widely on the
Web in the short term.

>> We agree a numbering scheme for subsequent HTTP releases,

> The numbering scheme may be premature -- it may depend on who gets what
> done (and accepted by the community) first.

When we produce the revised Internet Draft that describes current practise
we will almost certainly want to change the version number in some way.
That would do for now!

> 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".

I was hoping that say HTTP 2.0 would support the performance improvements
and a framework for plugging in security extensions in a modular way, e.g.
HTTP 2.0 with Shen or HTTP 2.0 with digital cash.

> 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.)

I was too prescriptive here. The intention was to keep the working group
mailing list clear of rambling discussions that are better handled on
a wider forum.

>> 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.

You may be right, but I am hoping that we can build on existing work
rather than having to start from scratch, e.g. EIT would write up how
their modified S-HTTP proposal fits into the open framework, ditto for
Spyglass and others. W3O would enhance the public domain libraries to
demonstrate feasibility of the open framework approach, e.g. with a basic
authentication module (Spyglass have volunteered to provide code for this)
and a module for using Shen. Much of the work has already been done for
handling multipart messages, and plans are in hand for work on reuse of
transactions for follow-on requests.
Best wishes,

Dave Raggett
Hewlett Packard Laboratories              email: dsr@hplb.hpl.hp.com
Filton Road, Stoke Gifford                tel:   +44 272 228046
Bristol BS12 6QZ                          fax:   +44 272 228003
United Kingdom
Received on Wednesday, 5 October 1994 17:46:49 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:08 EDT