Re: Transparency vs. Performance: survey of opinion

 > >  > Jeff Mogul summarized the sense of the subgroup as:
 > >  > > 	Applications in which HTTP is used span a wide space
 > >  > > 	of interaction styles.  For some of those applications,
 > >  > > 	the origin server needs to impose strict controls on
                                           ^^^^^^^^^^^^^^^^^^^^^^
 > >  > > 	when and where values are cached, or else the application
 > >  > > 	simply fails to work properly.

 > On Sun, 25 Feb 1996, Daniel LaLiberte wrote:
 > > It simply can't be done, unless you want signatures on client
 > > applications to verify they are approved software that obey the strict
 > > controls.  Until then, clients can and will do whatever they please.  

David W. Morris writes:
 > Based on that assumption, there is no point in any of our work. 

That would be going too far.  While what I said is true,
it is also true that clients that don't work well with servers, as
far as users are concerned, will not survive in the marketplace.

 > Those of us who disagree with Roy are not so naive as to believe
 > the we can force compliance, 

Imposing strict controls sounds like forcing compliance to me.
That's what I was reacting to.

 > only that we should define failure to follow the server's direction
 > as a non-conforming implementation.

In general, drawing the line is OK, but for some features it is the
wrong thing to do.  Regarding the no-cache directive, it should always
be possible for a client to actually keep and use a copy of anything
it gets, unless you want to impose legal restrictions
(e.g. copyright).  The *behavior* we want is that a user should not
naively use a document the server has declared as obsolete, unless the
user *wants* to use it.

We don't have to declare non-conformance to get this kind of behavior.
(i.e. it's not necessary) We can simply recommend reasonable default
behavior and signals to the user if something else is being done.

If a server really wants to require that a form is never submitted
twice, for example, it really ought to be verifying that fact
(e.g. using hidden data) rather than depending on clients, which may
in fact be non-compliant.  In other words, declaring clients
non-compliant doesn't really help stop the behavior. (i.e. it's not
sufficient)

Although it is not necessary and not sufficient, it won't hurt too bad
- it would be mostly meaningless.  Say, this sounds like "URN:".

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Monday, 26 February 1996 08:45:32 UTC