W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: Content negotiation

From: Daneel Pang Swee Chee <daneel@nii.ncb.gov.sg>
Date: Thu, 9 Nov 1995 10:54:06 +0800 (SST)
Message-Id: <9511090254.AA06850@nii.ncb.gov.sg>
To: www-talk@w3.org
If I may be so bold, I'd like to suggest the following:
[sorry it got longer than I thought, excuse the bandwidth]

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.
Received on Wednesday, 8 November 1995 21:49:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT