Re: New Requirements Draft

> To help us ignorant folks out. The variant mechanism in HTTP seems 
> to me from the examples you give me to have to do with language only.
> Is that correct? If so, there are many other variants out there, 
> such as the one Judith gave us. Those are the variants that 
> should be addressed.

I think a lot of this discussion in the http working group has been
around the topic of "content negotiation" and how to deal with
caceing of varients; and if I understand it, varients in general
may span several dimensions, of which language is only one
possiblity.

As I recall, the HTTP 1.1 spec has some features that were
put in as "hooks" for "content negotiation" and varients,
but not fully spelled out in the spec. This is why working
group members can sound like they are talking a private
language ;) ;)

If you look at:
http://www.ics.uci.edu/pub/ietf/http/

There are links to a couple of related internet drafts.

The one on "Transparent Content Negotiation in HTTP" seems the most developed
but may not be the most general definition of "varient" considered.

An html version of it is at:

http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-negotiation-03.html

The definitions of "varient" in the glossary seem a bit circular,
but you can get some idea of the dimensions involved from the
BNF for attributes:

       variant-attribute = "{" "type" media-type "}"
                         | "{" "charset" charset "}"
                         | "{" "language"  1#language-tag "}"
                         | "{" "length" 1*DIGIT "}"
                         | "{" "features" feature-list "}"
                         | "{" "description" quoted-string "}"
                         | extension-attribute

Here are the abstracts of the related drafts:
= =
"Scenarios for the Delivery of Negotiated Content using
HTTP",
Ted Hardie, 15 Jul 1997. 
       Text version of <draft-ietf-http-negotiate-scenario-01.txt>
Abstract 
       This document describes various problems which have arisen in
       attempts to deliver negotiated content using HTTP and examines
       several scenarios by which improvements in delivery might be
       accomplished. This document does not discuss how HTTP might be
       used to negotiate the use of other protocols to deliver content. 

"Transparent Content Negotiation in HTTP",
K. Holtman, A. Mutz, 25 Jul 1997. 
       Text version of <draft-ietf-http-negotiation-03.txt>
       Additional information is available at Koen's site. 
Abstract 
       HTTP allows web site authors to put multiple versions of the same
       information under a single URL. Transparent content negotiation is
       an extensible negotiation 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. 

"HTTP Remote Variant Selection Algorithm -- RVSA/1.0",
K. Holtman, A. Mutz, 28 Jul 1997. 
       Text version of <draft-ietf-http-rvsa-v10-02.txt> 
Abstract 
       HTTP allows web site authors to put multiple versions of the same
       information under a single URL. Transparent content negotiation is
       a mechanism for automatically selecting the best version when the
       URL is accessed. 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. 

"Feature Tag Scenarios",
K. Holtman, A. Mutz, 28 Jul 1997. 
       Text version of <draft-ietf-http-feature-scenarios-01.txt> 
Abstract 
       Recent Internet applications, such as the World Wide Web, tie
       together a great diversity in data formats, client and server
       platforms, and communities. This has created a need for various
       kinds of negotiation mechanisms, which tailor the data which is
       exchanged, or the exchange process itself, to the capabilities and
       preferences of the parties involved. 

       Extensible negotiation mechanisms need a vocabulary to identify
       various things which can be negotiated on. To promote
       interoperability, a registration process is needed to ensure that that
       this vocabulary, which can be shared between negotiation
       mechanisms, is developed in an orderly, well-specified, and public
       manner. 

       This document discusses requirements and scenarios the registration
       of this vocabulary, which is the vocabulary of feature tags. Feature
       tag registration is foreseen as an ongoing, open process which will
       keep pace with the introduction of new features by software
       vendors, and other parties such as standards bodies. 

"Feature Tag Registration Procedures",
K. Holtman, A. Mutz, 28 Jul 1997. 
       Text version of <draft-ietf-http-feature-reg-02.txt> 
Abstract 
       Recent Internet applications, such as the World Wide Web, tie
       together a great diversity in data formats, client and server
       platforms, and communities. This has created a need for various
       kinds of negotiation mechanisms, which tailor the data which is
       exchanged, or the exchange process, to the capabilities and
       preferences of the parties involved. 

       Extensible negotiation mechanisms need a vocabulary to identify
       various things which can be negotiated on. To promote
       interoperability, a registration process is needed to ensure that that
       this vocabulary, which can be shared between negotiation
       mechanisms, is developed in an orderly, well-specified, and public
       manner. 

       This document defines registration procedures which use the
       Internet Assigned Numbers Authority (IANA) as a central registry
       for this vocabulary, which is the vocabulary of feature tags. 
= = =

--
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Wednesday, 27 August 1997 17:36:27 UTC