draft-ietf-http-feature-scenarios-00.txt   draft-ietf-http-feature-scenarios-01.txt 
HTTP Working Group Koen Holtman, TUE HTTP Working Group Koen Holtman, TUE
Internet-Draft Andrew Mutz, Hewlett-Packard Internet-Draft Andrew Mutz, Hewlett-Packard
Expires: January 7, 1998 July 7, 1997 Expires: January 28, 1998 July 28, 1997
Feature Tag Scenarios Feature Tag Scenarios
draft-ietf-http-feature-scenarios-00.txt draft-ietf-http-feature-scenarios-01.txt
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 69 skipping to change at line 69
of this vocabulary, which is the vocabulary of feature tags. of this vocabulary, which is the vocabulary of feature tags.
Feature tag registration is foreseen as an ongoing, open process Feature tag registration is foreseen as an ongoing, open process
which will keep pace with the introduction of new features by which will keep pace with the introduction of new features by
software vendors, and other parties such as standards bodies. software vendors, and other parties such as standards bodies.
TABLE OF CONTENTS TABLE OF CONTENTS
1 Introduction 1 Introduction
2 Basic concepts and definitions 2 Basic concepts and definitions
2.1 Dimensions of negotiation 2.1 Areas of negotiation and feature tags
2.2 Feature tags 2.2 Complexity of negotiation
2.3 The result in an area of negotiation
3 Extensible negotiation mechanisms 3 Extensible negotiation mechanisms
3.1 Non-extensible negotiation mechanisms: the case of the Web 3.1 The need for extensible negotiation mechanisms: the case of the Web
3.2 Extensible negotiation mechanisms for the Web 3.2 Extensible negotiation mechanisms for the Web
3.3 Extensible negotiation mechanisms for other Internet protocols 3.3 Extensible negotiation mechanisms for other Internet protocols
4 Feature tag registration 4 Feature tag registration
4.1 IANA registration procedures 4.1 IANA registration procedures
4.2 Parties who would want to register feature tags 4.2 Examples of parties who would want to register feature tags
4.3 Feature tag registration scenario 4.3 Feature tag registration scenario
4.4 Volume considerations 4.4 Volume considerations
4.5 Danger of excessive registration 4.5 Danger of excessive registration
5 Security considerations 5 Security considerations
6 Acknowledgments 6 Acknowledgments
7 References 7 References
skipping to change at line 116 skipping to change at line 117
manner. manner.
This document discusses requirements and scenarios the registration This document discusses requirements and scenarios the registration
of this vocabulary, which is the vocabulary of feature tags. of this vocabulary, which is the vocabulary of feature tags.
Feature tag registration is foreseen as an ongoing, open process Feature tag registration is foreseen as an ongoing, open process
which will keep pace with the introduction of new features by which will keep pace with the introduction of new features by
software vendors, and other parties such as standards bodies. software vendors, and other parties such as standards bodies.
2 Basic concepts and definitions 2 Basic concepts and definitions
2.1 Dimensions of negotiation 2.1 Areas of negotiation and feature tags
Negotiation can be done on many things, and sometimes negotiation
must be done on multiple things at the same time. For example, in
a World Wide Web application, a negotiation process might need to
simultaneously select an appropriate media type and an appropriate
language for the page which is to be transmitted.
Such negotiation on multiple things can be seen as searching
process, in which a permitted or optimal point has to be found in a
multi-dimensional solution space.
Dimensions can be simple, usually reflecting a simple yes/no
choice, or more complex, reflecting a choice among many potential
alternatives, for example the choice of a particular media type.
2.2 Feature tags
A feature tag identifies a single dimension of negotiation, i.e. Something which can be negotiated on is called an `area of
something which can be negotiated on. Examples of things which can negotiation' in this document. Examples of areas of negotiation
be negotiated on are: are:
* the MIME media type of the data which is transmitted * the MIME media type of the data which is transmitted
* the language of the text document which is transmitted * the language of the text document which is transmitted
* the color depth of the screen on which something is to be * the color depth of the screen on which something is to be
displayed displayed
* whether the recipient supports the `floating 5 dimensional * whether the recipient supports the `floating 5 dimensional
tables' feature tables' feature
* the fonts which are available to the recipient * the fonts which are available to the recipient
* whether a Web user prefers speed over graphical detail * whether a Web user prefers speed over graphical detail
* whether the recipient is capable of displaying graphical * whether the recipient is capable of displaying graphical
content content
* whether the user prefers a blue background with purple dots over * whether the user prefers a blue background with purple dots over
a green background with pictures of small furry animals, except a green background with pictures of small furry animals, except
on Fridays. on Fridays.
It is expected that the majority of feature tags will label A feature tag identifies a single area of negotiation.
features in protocols or applications, the use of which needs to be
negotiated on. This explains the name `feature tag'. It is expected that the majority of feature tags will identify new
areas of negotiation, in which the object of negotiation is to
decide on the presence or use of some new feature in a software
product. This explains the name `feature tag'.
It is recognized that there is continuous growth in the number of It is recognized that there is continuous growth in the number of
things for which some form of negotiation is desirable, in areas in which some form of negotiation is desirable. To keep up
particular because there is continuous growth in the feature set of with this growth, extensible negotiation mechanisms are needed,
Internet software. By using the feature tag vocabulary, rather which refer to the feature tag vocabulary to identify new areas of
than an internal set of hard-coded values, to identify dimensions, negotiation, rather than relying on hard-coded knowledge about a
negotiation mechanisms can keep up with this growth. few areas.
To avoid the duplication of work, and to promote the interoperable To avoid the duplication of work, and to promote the interoperable
naming of areas of negotiation across protocols and applications, naming of areas of negotiation across protocols and applications,
the feature tag namespace should not be bound to a particular the feature tag namespace should not be bound to a particular
protocol or negotiation mechanism. Also, there should be no prior protocol or negotiation mechanism. Also, there should be no prior
restriction on the things which may be identified by a feature tag, restriction on the areas of negotiation which may be identified by
other than that it must be conceivable to negotiate on them in some a feature tag, other than that it must be conceivable to negotiate
Internet application. in these areas in the context of some Internet application.
2.2 Complexity of negotiation
Negotiation processes can often be complex. Two frequent sources
of complexity are:
1. An area of negotiation may be inherently complex. For
example, negotiating on the use of a particular media type is
inherently more complex than negotiating on the presence of a
single feature, because there are more possible outcomes.
2. There may be complex of interdependencies between the choices
in different areas of negotiation. For example, if the
following versions of a document are available on a Web server:
* text/html, English
* text/plain, French
* audio/x-wav, German
then the content negotiation mechanism cannot treat the areas
of `MIME media type negotiation' and `language negotiation' as
separate.
It is recognized that extensible negotiation mechanisms will often
differ in the type and amount of complexity they can handle. Thus,
though negotiation mechanisms share the feature tag namespace, it
will not be the case that every tag is usable in every negotiation
mechanism, or that every negotiation mechanism will be able to
handle all possible interdependencies.
2.3 The result in an area of negotiation
During negotiation, negotiation mechanisms will often need to
transmit (canonical representations of) the possible results in
various areas of negotiation over the wire. Also, at the end of a
negotiation process, the mechanism may need to return (a
canonical representation of) the result to the application which
invoked it.
In many areas of negotiation, there will be a natural, canonical
representation of the result. For example, in the area
* whether the recipient supports the `floating 5 dimensional
tables' feature
the canonical representation of the result is a boolean value (yes,
the feature is supported, or no, the feature is not supported). In
the area
* the MIME media type of the data which is transmitted
the canonical representation of the result will be a MIME media
type identifier like text/html or application/postscript. In some
areas of negotiation, the result could be a compound value (e.g. a
coordinate in a 3D space).
To promote interoperability, the registration entry of a feature
tag can include a definition of the canonical representations of
the possible results in the corresponding area of negotiation.
3 Extensible negotiation mechanisms 3 Extensible negotiation mechanisms
We call a negotiation mechanism extensible if the set of dimensions We call a negotiation mechanism extensible if the set of areas
on which the mechanism can negotiate is extensible, in stead of on which the mechanism can negotiate is extensible, in stead of
hard-coded inside the mechanism. hard-coded inside the mechanism.
3.1 Non-extensible negotiation mechanisms: the case of the Web 3.1 The need for extensible negotiation mechanisms: the case of the Web
An example of a non-extensible negotiation mechanism is HTTP HTTP [2] has traditionally recognized four areas of negotiation:
content negotiation mechanism which is based on the four Accept
headers defined in HTTP/1.1 [2]. This mechanism is referred to as
`HTTP/1.0 style negotiation' in [3], and it has the following
dimensions hard-coded:
1. MIME media type 1. MIME media type
2. Charset 2. Charset
3. Language 3. Language
4. Encoding 4. Encoding
Experience with the Web has shown that this mechanism is HTTP provides support for these areas of negotiation by defining
insufficient for meeting the negotiation needs. Among other identifiers (Accept headers) for these areas, and defining
things, the Web has a great need to negotiate on things which do canonical representations of the possible results in these areas.
not fit the four dimensions above. The existence of this need is
shown by a large number of cases in which people have creatively Experience with the Web has shown there is a great need to
abused HTTP protocol elements, which were not intended for that negotiate on things which do not fit the four areas above. This
purpose, to extend the dimensions of negotiation. Examples of this need has shown itself in a number of ways:
are the encoding of negotiation related information in `dynamic
URLs' or cookies. As an other example the HTTP User-Agent header - Web servers routinely use (abuse) other headers than the Accept
has been widely abused by web sites to detect the presence of headers for negotiation purposes. In particular, the HTTP
certain features in browsers, and by browsers to trigger certain User-Agent header has been widely used by web sites to detect
features in web sites. the presence of certain features in browsers, and by browsers
to trigger certain features in web sites, even though such use
is error-prone, and conflicts with the original purpose of the
User-Agent header.
- Web servers routinely use `dynamic URLs' and cookies to encode
negotiation related information like user preferences. This
can be cache-unfriendly, in particular in the case of `dynamic
URLs'.
- During the standardization of HTTP, several proposals for
additional Accept headers, matching additional areas of
negotiation, were made. These proposals have been rejected in
favor of developing an extensible negotiation mechanism.
- There has been pressure to extend the MIME media type parameter
mechanism to allow for the naming of, and negotiation on, new
features in media types already registered, something which is
explicitly disallowed in the MIME type registration rules. It
was recognized that this pressure would be better addressed by
creating a new namespace independent from the MIME media type
space.
3.2 Extensible negotiation mechanisms for the Web 3.2 Extensible negotiation mechanisms for the Web
In the IETF HTTP working group, it has been recognized that the In the IETF HTTP working group, it has been recognized that the
number of needed dimensions for Web content negotiation is growing number of areas for Web content negotiation is growing so rapidly
so rapidly that the IETF would never be able to keep up with this that the IETF would never be able to keep up with this growth by by
growth by by continually revising a negotiation mechanism with a continually revising a negotiation mechanism with a hard-coded set
hard-coded set of dimensions. In stead, a number of extensible of areas. Instead, a number of extensible content negotiation
content negotiation mechanisms have been proposed. All of these mechanisms have been proposed. All of these mechanisms share the
mechanisms share the need for an external vocabulary to identify need for an external vocabulary to identify areas, a vocabulary
dimensions, a vocabulary which can be updated quickly enough to which can be updated quickly enough to keep pace with the
keep pace with the introduction of new features by Web software introduction of new features by Web software vendors.
vendors.
The proposed extensible content negotiation mechanisms are The proposed extensible content negotiation mechanisms are
transparent content negotiation [2], and negotiation mechanisms transparent content negotiation [2], and negotiation mechanisms
based on various forms of "active content". In "active content" based on various forms of "active content". In "active content"
negotiation, the web server returns an executable program which is negotiation, the web server returns an executable program which is
run by the browser. This program then accesses a database of run by the browser. This program then accesses a database of
negotiation related settings inside the browser, and chooses and negotiation related settings inside the browser, and chooses and
renders the most appropriate content. Note that there are several renders the most appropriate content. Note that there are several
existing and proposed forms of active content. existing and proposed forms of active content.
To tie everything together, a browser architecture with a central To tie everything together, a browser architecture with a common
database for negotiation related information has been proposed. internal database for negotiation related information has been
The database would be filled to reflect the capabilities of all proposed. The database would be filled to reflect the capabilities
browser components, both native components and plugins, and the of all browser components, both native components and plugins, and
preference settings made by the user. Then, individual negotiation the preference settings made by the user. Feature tags would serve
mechanisms could access the central database through some API. The as the keys under which the database entries for different areas of
architecture is shown in the following picture. negotiation are stored. Individual negotiation mechanisms could
access the central database through some API. The architecture is
+------------------+ +----------+ +----------+ +-----------+ shown in the following picture.
| Native browser | | Plugin 1 | | Plugin 2 | |User |
| rendering engine | +----------+ +----------+ |preferences|
+------------------+ | | +-----------+
| | | |
V V V V
+------------------------------------------------------+
| Central database for negotiation related information |
+------------------------------------------------------+
| | | |
API API API API
| | | |
V V V V
+---------+ +---------+ +-------------+
| Java | | JScript | | transparent |
| based | | based | ..etc | content |
| active | | active | | negotiation |
| content | | content | | engine |
+---------+ +---------+ +-------------+
In this architecture, the central database needs a vocabulary, +-----------------------------------------------------------------+
independent from any particular negotiation mechanism, to identify | BROWSER |
individual dimensions of negotiation. The proposed feature tag | |
registry would offer this vocabulary. | +------------------+ +----------+ +----------+ +-----------+ |
| | Native browser | | Plugin 1 | | Plugin 2 | |User | |
| | rendering engine | +----------+ +----------+ |preferences| |
| +------------------+ | | +-----------+ |
| | | | | |
| V V V V |
| +------------------------------------------------------+ |
| | Common internal database for negotiation information | |
| +------------------------------------------------------+ |
| | | | | |
| API API API API |
| | | | | |
| V V V V |
| +---------+ +---------+ +-------------+ |
| | Java | | JScript | | transparent | |
| | based | | based | ..etc | content | |
| | active | | active | | negotiation | |
| | content | | content | | engine | |
| +---------+ +---------+ +-------------+ |
| |
+-----------------------------------------------------------------+
3.3 Extensible negotiation mechanisms for other Internet protocols 3.3 Extensible negotiation mechanisms for other Internet protocols
Extensible negotiation mechanisms for Internet printing and Extensible negotiation mechanisms for Internet printing and
Internet fax are currently under investigation in the IETF. Internet fax are currently under investigation in the IETF.
It has been proposed to make multipart/alternative negotiation in It has been proposed to make multipart/alternative negotiation in
Internet mail more extensible, in particular if the mail client is Internet mail more extensible, in particular if the mail client is
part of a Web browser, by adapting some of the protocol elements part of a Web browser, by adapting some of the protocol elements
developed for transparent content negotiation [2] to Internet mail. developed for transparent content negotiation [2] to Internet mail.
skipping to change at line 305 skipping to change at line 370
of development in the Web, a type b) registration process for of development in the Web, a type b) registration process for
feature tags seems necessary, if only because the IETF does not feature tags seems necessary, if only because the IETF does not
have the manpower required for a review process which can keep up have the manpower required for a review process which can keep up
with the speed of Web development. with the speed of Web development.
It is proposed that feature tag registration closely mimics the new It is proposed that feature tag registration closely mimics the new
MIME media type registration rules in [1], providing both type a) MIME media type registration rules in [1], providing both type a)
and b) namespaces. This proposal is based on the observation that and b) namespaces. This proposal is based on the observation that
the rules in [1] seem to be working nicely. the rules in [1] seem to be working nicely.
4.2 Parties who would want to register feature tags 4.2 Examples of parties who would want to register feature tags
Feature registration allows for the quick introduction of new Feature registration allows for the quick introduction of new areas
dimensions of negotiation in extensible negotiation mechanisms. In of negotiation in extensible negotiation mechanisms. In a Web
a Web context, the following parties might want to introduce new context, examples of parties which might want to introduce new
dimensions of negotiation: areas of negotiation are:
1. Browser and browser component vendors, when inventing and 1. Browser and browser component vendors, when inventing and
implementing new features or components. implementing new features or components.
2. The IETF or some other standards body, when creating a new 2. The IETF or some other standards body, when creating a new
standard for a content format, or when identifying a new type standard for a content format, or when identifying a new type
of user preference (for example a preference for of user preference (for example a preference for
representations without animated gifs). representations without animated gifs).
3. Content authors, when identifying a new type of user 3. Content authors, when identifying a new type of user
skipping to change at line 424 skipping to change at line 489
5 Security considerations 5 Security considerations
When used, negotiation mechanisms usually reveal some information When used, negotiation mechanisms usually reveal some information
about one party to other parties. This may raise privacy concerns, about one party to other parties. This may raise privacy concerns,
and may allow a malicious party to make more educated guesses about and may allow a malicious party to make more educated guesses about
the presence of security holes in the other party. the presence of security holes in the other party.
6 Acknowledgments 6 Acknowledgments
The idea of creating a vocabulary of dimensions of negotiation, The idea of creating a vocabulary of areas of negotiation, which is
which is maintained in a central open registry, is due to maintained in a central open registry, is due to discussions on
discussions on extensible negotiation mechanisms in the IETF HTTP extensible negotiation mechanisms in the IETF HTTP working group.
working group. The authors wish to thank Larry Masinter for The authors wish to thank Larry Masinter and Graham Klyne for
contributing to early discussions of feature tag registration. contributing to discussions about feature tag registration.
7 References 7 References
[1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures. RFC Extensions (MIME) Part Four: Registration Procedures. RFC
2048, BCP 13, Network Working Group, November 1996 2048, BCP 13, Network Working Group, November 1996
[2] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and [2] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC
2068, HTTP Working Group, January, 1997. 2068, HTTP Working Group, January, 1997.
[3] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. [3] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP.
Internet-Draft draft-ietf-http-negotiation-02.txt, HTTP Working Internet-Draft draft-ietf-http-negotiation-03.txt, HTTP Working
Group. Group. July 1997.
8 Authors' addresses 8 Authors' addresses
Koen Holtman Koen Holtman
Technische Universiteit Eindhoven Technische Universiteit Eindhoven
Postbus 513 Postbus 513
Kamer HG 6.57 Kamer HG 6.57
5600 MB Eindhoven (The Netherlands) 5600 MB Eindhoven (The Netherlands)
Email: koen@win.tue.nl Email: koen@win.tue.nl
Andrew H. Mutz Andrew H. Mutz
Hewlett-Packard Company Hewlett-Packard Company
1501 Page Mill Road 3U-3 1501 Page Mill Road 3U-3
Palo Alto CA 94304, USA Palo Alto CA 94304, USA
Fax +1 415 857 4691 Fax +1 415 857 4691
Email: mutz@hpl.hp.com Email: mutz@hpl.hp.com
Expires: January 7, 1998 Expires: January 28, 1998
 End of changes. 22 change blocks. 
108 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/