[Prev][Next][Index][Thread]

Transparent content negotiation pointers & status



The following message was posted to the IETF Internationalization group 
on Sunday. As these documents are relevant to our discussions on XML
links those interested in this field should read them.
>
>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.
>
>
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.sgml.u-net.com/