1. There are many types of things that is lumped into this common
idea of "content-negotiation" that I have read, and it may be easier
to identify them and see whether they require slightly different
solutions.
a. Media/Format types indications [Basic Types]
b. Various Extensions to the basic Media/Format types, due to
i. New Versions of a format vs Older Versions [Version Types]
ii. Vendor Created "bright ideas." [Extensions Types]
c. User specific decisions or preferences
For eg, I prefer JPG to GIF, or even language differences.
I note that this is probably very difficult (not proven intractable).
[Pref Types]
2. There are multiple-parties involved in content negotiation and the
"knowledge acquired" and "implicit knowledge" of each is dissimilar
a. The Server which knows what information it can deliver and the
media/format/extensions ("type" for simplicity) that it can deliver.
[Knowledge of The Source]
b. The Browser which knows what information it can itself handle.
[Knowledge of The Basics]
c. The PlugIns/Addons/Helper-apps (PAH) associated with the Browser
where the Browser has a rudimentary knowledge of what the (PAH)
*may* be able to handle. For eg, if the Helper apps puts "image/*"
doesn't mean it can handle
"image/some-new-and-improved-format-with-wonderful-extensions"
and the PAH knows what it can itself handle.
There may also be more than 1 PAH (in combi) that can handle "image/*".
I note that this is probably also very difficult (npi).
[Knowledge of The "Others"]
d. The User of the "Browser" who may have some knowledge on what he
wants and what his system can handle.
I note that this is, again, probably very difficult (npi).
[Unquantifiable Knowledge]
Content Negotiation may be considered the sharing of knowledge to allow
information to be delivered to be only those "meaningful" and "allowed/
acceptable" to the recipient. [We've developed a similar one for our
systems as an experiment, we called it "Capability Negotiation", since
"Content Negotiation" went a bit further in our original interpretation]
3. Perhaps several partial solutions working together is what we want:
(Note: I leave actual *negotiation* later)
a. [Basic Types] can be shared implicitly or explicitly or both.
i. In the information already delivered that references new info
that can be delivered, the [Basic Types] can be indicated.
Thus, the proposal of an attribute extension:
"<img src=... mimetype=...>" (Ref Russell Holt's E-mail).
ii. In the case of delivery, the server can indicate the [BT] of
info that it intends to deliver, but the Browser/client should
be free to end or *negotiate* at this point.
Both of these involves increasing the knowledge of the Browser
with regards to [Knowledge of the Source].
I'm personally against telling the Server the Browser's and my
Helper Apps' [Basic Types] for several reasons (need, time, space,
capabilities, privacy) -- increasing Server's knowledge of the other
3 types of knowledge (2b-2d).
b. [Version Types] can be similarly handled. What is needed, however,
is the "compatibility" knowledge that may need to be built in at
the server end for negotiation purposes, or the browser end for
intelligent acceptance.
c. [Extension Types] requires Browser identification of being able to
adhere to certain groups. Simple 1 step *negotiation* may be used.
d. [Pref Types] -- restrictions on what is allowed for [3a-3c]??
I don't have any idea how to do this well.
Actual Negotiation seems to me, unless otherwise, the point of contention:
everyone's got their favorite schemes. This usually has the following
properties:
a. Protocol Based Step-Down/Step-Up Knowledge Exchange Negotiation
(eg Minimum-knowledge capability establishment)
b. Raw Dump of Knowledge from one end to another
(eg Bitmap dump of my supported types)
c. Fail/Try Another (eg stupid server, smart browser)
d. Grab and Worry Later (eg get it anyways and save it)
In all this, I think the hard part is still knowing about how to compile
a good set of capabilities for [Knowledge of Others] and [Unqualifiable
Knowledge] (former is easier, of course).
Alright, let me leave off, since I may be talking nonsense or stating the
obvious. Thanks for reading :).
-- [Daneel Pang Swee Chee] | There are never enough hours in a day, E-mail: daneel@ncb.gov.sg | but there always seems to be too many days Tel: (65)770-3801 | before a weekend.