- From: Albert Lunde <albert-lunde@nwu.edu>
- Date: Wed, 27 Aug 1997 16:36:16 CDT
- To: w3c-dist-auth@w3.org
> 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