Transparent content negotiation pointers & status

This is to announce the availability of HTML versions of the
transparent content negotiation documents, which will be discussed at
the HTTP-WG sessions of the upcoming IETF in Memphis:

     1. draft-ietf-http-negotiation-01.txt

        `Transparent Content Negotiation in HTTP'

        Defines the core mechanism. Standards track.

       ABSTRACT

        HTTP allows web site authors to put multiple versions of the
        same information under a single URL.  Transparent content
        negotiation is a mechanism, layered on top of HTTP, for
        automatically selecting the best version when the URL is
        accessed.  This enables the smooth deployment of new web data
        formats and markup tags.


     2. draft-ietf-http-rvsa-v10-01.txt

        `HTTP Remote Variant Selection Algorithm -- RVSA/1.0'

        Defines the remote variant selection algorithm version 1.0.
        Standards track.

       ABSTRACT

        [...] A remote variant
        selection algorithm can be used to speed up the transparent
        negotiation process. This document defines the remote variant
        selection algorithm with the version number 1.0.


The txt version of the first document is already 14 days old, the txt
version of the second one is new, but only has very small revisions.
All documents can be found at the usual place:

     http://gewis.win.tue.nl/~koen/conneg/


For those not deep into content negotiation, here is some background
info in Q&A form.

Q: What is the status of these documents?

A: They are not discussion drafts.  They are finished, complete specs of
a protocol on top of HTTP/1.x.  If you don't know HTTP/1.x, you may have
a hard time reading them, especially the caching sections.

Q: Should I read these documents?

A: Yes, if:
   1. you are a http-wg member
   2. or a browser/server/proxy implementer,
and
   a. you want to get your technical comments in
   b. or want to let us know whether you consider implementation.

We hope to do a last call on (a revision of) the main document 
soon after Memphis.

Q: Why are these documents so long?

A: They are only 1/3th of the length of the HTTP/1.1 specification.
They could have been 1/6th of HTTP/1.1 if all examples were left out.

Q: What is transparent content negotiation anyway?

A: HTTP allows web site authors to put multiple versions of the same
information under a single URL.  Content negotiation is the process of
choosing among them.  Transparent content negotiation (TCN) is the
first HTTP content negotiation mechanism which scales well enough to
be useful. This enables the smooth deployment of new web data formats
and markup tags.

Q: What does it negotiate on?

A: TCN only negotiates on _content_, it does not negotiate on
protocols or services.  The PEP protocol does that.

TCN negotiates on three of the dimensions which were formalised in
the HTTP/1.1 spec:

     1. Media type (MIME type)
     2. Charset
     3. Language

Note that the http-wg is _not_ interested in revising the
specifications of the above three dimensions in HTTP/1.1.

If you want something new or different, TCN adds a fourth dimension for
you:

     4. Features

Feature negotiation intends to provide for all areas of negotiation
not covered by the type, charset, and language dimensions.  Examples
are negotiation on

       * HTML extensions
       * Extensions of other media types
       * Color capabilities of the user agent
       * Screen size
       * Output medium (screen, paper, ...)
       * Preference for speed vs. preference for graphical detail

The feature negotiation framework is the principal means by which
transparent negotiation offers extensibility; a new dimension of
negotiation (really a sub-dimension of the feature dimension) can be
added without the need for a new standards effort by the simple
registration of a `feature tag'.

Q: How do I register a feature tag?

A: We are still working on it.  There is a discussion draft:
draft-ietf-http-feature-reg-00.txt, but we want to finish the main
mechanism before we start discussing registration.  But, as with the
revised MIME type registration process, registration is basically open
to everybody, and acceptance of a registered dimension will be
determined by market forces, not the IETF.

Q: How can feature negotiation do all this and still scale?

A: It is based on some stuff which was developed by mathematicians in
the 1920s.  Don't worry, you won't have to be a mathematician to use
feature negotiation.  But if you want to understand *why* it works,
some background in formal logic will be helpful.

Q: What if feature negotiation won't work for what I have in mind?

A: TCN was built with extensibility in mind, so there would be no
problem in extending it at some point in the future.

Q: Why is TCN important?

A: There are a number of reasons:

  1. It is good for internationalisation

  2. It eliminates the need to choose between a `state of the art
     multimedia homepage' and one which can be viewed by all web
     users: simply make both and negotiate between them

  3. It is good for spreading the web to other media besides 256 color
     high-res monitors

  4. Feature negotiation eliminates the need for cache-unfriendly and
     error-prone user-agent based negotiation

  5. It enables the smooth deployment of new web data formats and
     markup tags, which is important because

    a. New formats are more fun

    b. New formats are generally smaller, so we can expect bandwidth
       savings.

       Some figures from a 1995 proxy cache study I did:

                                           media type of object
                                      ------------------------------
                                      text,  gif  jpeg other (gif
                                      html                   +jpeg)

  share in traffic on off-campus link: 30%   22%   20%  28%  (42%)

  campus proxy cache efficiency      : 48%   25%   14%   8%  (20%)

       Note that graphics (gif+jpeg) take a large share (42%) of the
       total backbone traffic, and that they do not cache well (20%
       efficiency).  So if TCN allows the smooth transition from
       gif+jpeg to something smaller (png? CSS? vector graphics?), we
       can expect considerable savings.  The same is true for other
       formats.

  6. `Content negotiation was planned from the early days as a
     flexibility point which separated HTTP and HTML, and would allow
     evolution of the web in ways we do not yet envision.' <--- Actual
     TimBL quote

Koen.

Received on Sunday, 23 March 1997 08:50:46 UTC