- From: <hallam@etna.ai.mit.edu>
- Date: Mon, 12 Aug 96 13:20:29 -0400
- To: jg@zorch.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@etna.ai.mit.edu
>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