Re: Comments please on agenda for HTTP working group BOF

Dave Raggett <dsr@hplb.hpl.hp.com> says:
(> >> is Dave Raggett's original.
> > are my comments on that.
>  are Dave Raggett's comments on my comments.) 

  > My reactions to Dave Kristol's comments:
[...]
  > 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.
Okay.  I was thinking of a different kind of copyright protection, namely
a technological approach like document marking.  (See
http://www.research.att.com/#docmark for one example.)
  > 
  > >> 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.
I agree.  My quibble was with the specific use of IP address, not a basic
authentication mechanism.

[...]
  > > 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.
There are a couple of aspects:
1) Anonymous payment mechanisms help to preserve privacy:  DigiCash,
anonymous credit cards.  I don't see how we can preserve privacy using a
billing model for payment.
2) Caching proxy servers help obscure identity (to the information service
provider).
3) I can imagine proxy TCP services that establish connections in a way
analogous to the anonymous reEmailers in Finland.  These would obscure
the original requester.

Note the effect that (2) and (3) have on IP address authentication!

  > 
  > >> 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.
Umm.  Let me be pedantic and note that digital cash is not a security
extension (at least in my book) but a payment extension.  That said, I
agree that we should be working toward a framework that allows
compatible extensions to HTTP.
[...]
  > > 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.

I support the use of existing work.  I think you and I are agreeing that
we want to define a framework in which all these things can co-exist.  The
WG would define the framework, not necessarily the specific extensions.

David M. Kristol
AT&T Bell Laboratories

Received on Wednesday, 5 October 1994 20:36:38 UTC