- From: Dave Raggett <dsr@dragget.hpl.hp.com>
- Date: Wed, 5 Oct 94 17:43:20 BST
- 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 UTC