Re: Sticky stuff.

>Specialized compression schemes always beat general ones, usually hands
>down, as they know much more about the content of messages than a general
>one can.  The algorithms in modems can't use the best compression algorithms
>in any case, due to constraints on modem's behavior.

Agreed, however the question which I was raising was whether 
compressing the body of the message was more relevant than
compressing the headers. Modem compression may well be OK(ish)
for HTML but most internet lines don't have compression.

I think that the "sticky headers" issue should be considered
in conjunction with the user-agent capabilities issue. It is
the capabilities of the user agent which represent the bulk
of the headers - or rather did when Accept headers were 1.4K.

As noted in Jim's other message URLs etc are very compact 
mechanisms for including an arbitrary quantity of data by
reference. I think that the security issue has to be considered.
E.g consider that the Republicrat home page uses background
MPEGs extensively if the Naviplorer browser is used. A 
Dempublican attempts to sabotage this by connecting to the 
Republicrat site and downloading a bogus set of capabilities
for Naviplorer.

I favour mechanisms that include some deterministic mechanism
for forming a URI from the referent. E.g. using MD5/SHA to
form the identifier. The recipient can then verify that the
referent is correct even if it is not received from an
authoratative source. This also neatly avoids various
kludgey solutions such as requiring the browser capabilities to 
be downloaded from the browser vendor's site - somethin that might
not be possible on an intranet and something that would
limit the number of tags possible.


Note also that there is a degree of convergence between Paul's
"session" concept and the "referenced headers" concept.

There may be a degree of unwillingness to accept this scheme
amongst people who have written multiple process servers on poorly
designed operating systems with inefficient process-process
communication.


		Phill

Received on Monday, 12 August 1996 10:18:13 UTC