Re: <math>, <fig>, ... (fwd)

In message <01I50NSOU83M00DV2K@SCI.WFBR.EDU>, Foteos Macrides writes:
>
>I meant to reply that unfortunately -- for that set of assertions in
>Brian's massage -- the May 2, 1996 HTTP/1.1 ID (reference above from
>Dan) expresses intent for support of both opaque and transparent
>negotiation, and their combination, but defers description of the
>transparent negotiation algorithm and their combination to as yet
>unavailable drafts

Ah. I see.

>  Also, in
>it's descriptions of Accept headers for opaque negotiation, it
>indicates the traditional q=qvalue parameter for all content types,
>and level=number for text/html, but does not reference or appear to
>incorporate the wonderful proposals in the February 22, 1996 "Holtman"
>ID:
>	"Proposed Content Negotiation Definitions for HTTP/1.1",
>		K. Holtman
>	ftp://ietf.cnri.reston.va.us/internet-drafts/
>		draft-holtman-http-negotiation-00.txt
>
>most valuable of which, for a client like Lynx, is mxb=maxbytes

Actually, mxb goes all the way back to TimBL's original description
of content negotiation. Anyway...

Henrik, TimBL, Rohit, Anselm, Jim G., Robert Thau, and I have wrestled
with mxb (and q, and other aspects of conneg) at great length (that's
just the time in the office recently -- never mind all the email over
the years), and to date have not come up with something that we really
like. The gotcha's are:

	* How do you keep the size (in bytes) of the average
	request down below the size of a packet?

	* How do we keep the server computation trivial in
	the average case, and manageable in the extreme cases?

	* How much information does a caching proxy server need in
	order to be safe in fulfilling a request without
	contacting the origin server? How much of the conneg
	algorithm has to be shared by all servers, and how
	much can be customized on a per-server basis?

	* How does this interact with authentication?

	* What about negotiation over stuff besides media types?
	e.g. mailto: URLs Do we need a new header for each of
	these, ala Accept-Language?

	* How much of this can be solved via reactive negotiation?

>Accept: text/html
>Accept: text/plain;q=0.9
>Accept: image/jpeg;q=0.9;mxb=1000000
>Accept: image/gif;q=0.8;mxb=1000000
>[...]
>Accept: */*;q=0.001

This is the sort of thing that's too verbose. We need to figure
out how to get clients to send enough stuff to discriminate
between the available types, rather than completely describe
their capabilities.

>	It would be highly desireable for a client such as Lynx if
>what Brian claimed is possible via content negotiation became a useful
>reality.  I therefor wondered if he had modified his server to make it
>truly possible, and if so, perhaps it could be tried with the current
>Lynx developers' code to see if it really works well, or what might be
>done to get it really working well.

As I recall, the CERN server 3.0 implements most of this stuff. I
thought it did mxb too, though I'd have to check with henrik to be
sure. Have you tried the cern server?

Dan

Received on Thursday, 23 May 1996 07:44:39 UTC