One document matched: draft-ietf-http-feature-scenarios-00.txt
HTTP Working Group Koen Holtman, TUE
Internet-Draft Andrew Mutz, Hewlett-Packard
Expires: January 7, 1998 July 7, 1997
Feature Tag Scenarios
draft-ietf-http-feature-scenarios-00.txt
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress".
To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
West Coast).
Distribution of this document is unlimited. Please send
comments to the HTTP working group at
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
discussions about HTTP and the applications which use HTTP
should take place on the <www-talk@w3.org> mailing list.
A HTML version of this document can be found at
<URL:http://gewis.win.tue.nl/~koen/conneg/>.
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.
TABLE OF CONTENTS
1 Introduction
2 Basic concepts and definitions
2.1 Dimensions of negotiation
2.2 Feature tags
3 Extensible negotiation mechanisms
3.1 Non-extensible negotiation mechanisms: the case of the Web
3.2 Extensible negotiation mechanisms for the Web
3.3 Extensible negotiation mechanisms for other Internet protocols
4 Feature tag registration
4.1 IANA registration procedures
4.2 Parties who would want to register feature tags
4.3 Feature tag registration scenario
4.4 Volume considerations
4.5 Danger of excessive registration
5 Security considerations
6 Acknowledgments
7 References
8 Authors' addresses
1 Introduction
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.
2 Basic concepts and definitions
2.1 Dimensions of negotiation
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. Examples of things which can
be negotiated on are:
* the MIME media type of the data which is transmitted
* the language of the text document which is transmitted
* the color depth of the screen on which something is to be
displayed
* whether the recipient supports the `floating 5 dimensional
tables' feature
* the fonts which are available to the recipient
* whether a Web user prefers speed over graphical detail
* whether the recipient is capable of displaying graphical
content
* whether the user prefers a blue background with purple dots over
a green background with pictures of small furry animals, except
on Fridays.
It is expected that the majority of feature tags will label
features in protocols or applications, the use of which needs to be
negotiated on. This explains the name `feature tag'.
It is recognized that there is continuous growth in the number of
things for which some form of negotiation is desirable, in
particular because there is continuous growth in the feature set of
Internet software. By using the feature tag vocabulary, rather
than an internal set of hard-coded values, to identify dimensions,
negotiation mechanisms can keep up with this growth.
To avoid the duplication of work, and to promote the interoperable
naming of areas of negotiation across protocols and applications,
the feature tag namespace should not be bound to a particular
protocol or negotiation mechanism. Also, there should be no prior
restriction on the things which may be identified by a feature tag,
other than that it must be conceivable to negotiate on them in some
Internet application.
3 Extensible negotiation mechanisms
We call a negotiation mechanism extensible if the set of dimensions
on which the mechanism can negotiate is extensible, in stead of
hard-coded inside the mechanism.
3.1 Non-extensible negotiation mechanisms: the case of the Web
An example of a non-extensible negotiation mechanism is HTTP
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
2. Charset
3. Language
4. Encoding
Experience with the Web has shown that this mechanism is
insufficient for meeting the negotiation needs. Among other
things, the Web has a great need to negotiate on things which do
not fit the four dimensions above. The existence of this need is
shown by a large number of cases in which people have creatively
abused HTTP protocol elements, which were not intended for that
purpose, to extend the dimensions of negotiation. Examples of this
are the encoding of negotiation related information in `dynamic
URLs' or cookies. As an other example the HTTP User-Agent header
has been widely abused by web sites to detect the presence of
certain features in browsers, and by browsers to trigger certain
features in web sites.
3.2 Extensible negotiation mechanisms for the Web
In the IETF HTTP working group, it has been recognized that the
number of needed dimensions for Web content negotiation is growing
so rapidly that the IETF would never be able to keep up with this
growth by by continually revising a negotiation mechanism with a
hard-coded set of dimensions. In stead, a number of extensible
content negotiation mechanisms have been proposed. All of these
mechanisms share the need for an external vocabulary to identify
dimensions, a vocabulary which can be updated quickly enough to
keep pace with the introduction of new features by Web software
vendors.
The proposed extensible content negotiation mechanisms are
transparent content negotiation [2], and negotiation mechanisms
based on various forms of "active content". In "active content"
negotiation, the web server returns an executable program which is
run by the browser. This program then accesses a database of
negotiation related settings inside the browser, and chooses and
renders the most appropriate content. Note that there are several
existing and proposed forms of active content.
To tie everything together, a browser architecture with a central
database for negotiation related information has been proposed.
The database would be filled to reflect the capabilities of all
browser components, both native components and plugins, and the
preference settings made by the user. Then, 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
individual dimensions of negotiation. The proposed feature tag
registry would offer this vocabulary.
3.3 Extensible negotiation mechanisms for other Internet protocols
Extensible negotiation mechanisms for Internet printing and
Internet fax are currently under investigation in the IETF.
It has been proposed to make multipart/alternative negotiation in
Internet mail more extensible, in particular if the mail client is
part of a Web browser, by adapting some of the protocol elements
developed for transparent content negotiation [2] to Internet mail.
4 Feature tag registration
4.1 IANA registration procedures
Examples of IANA registration procedures can be found in [1].
There has been some confusion over what the IANA will register.
Jon Postel told us that:
The IANA is pretty good at keeping lists. It is not so good at
evaluating the merits (or lack thereof) of the requests to add
things to lists. [...] So, yes the IANA would keep the list of
"feature tags" provided that that there is either a very simple
way to decide if requests pass muster, or a designated someone
else will be available to make that decision.
So two types of registration namespaces can be created:
a) a space with feature tag review process performed by the IETF
b) a space with very basic registration rules which do not take
the merit of the feature tag into account. To quote [1],
this type of registration "does not imply endorsement,
approval, or recommendation by the IANA or IETF or even
certification that the specification is adequate."
If extensible negotiation mechanisms are to keep up with the speed
of development in the Web, a type b) registration process for
feature tags seems necessary, if only because the IETF does not
have the manpower required for a review process which can keep up
with the speed of Web development.
It is proposed that feature tag registration closely mimics the new
MIME media type registration rules in [1], providing both type a)
and b) namespaces. This proposal is based on the observation that
the rules in [1] seem to be working nicely.
4.2 Parties who would want to register feature tags
Feature registration allows for the quick introduction of new
dimensions of negotiation in extensible negotiation mechanisms. In
a Web context, the following parties might want to introduce new
dimensions of negotiation:
1. Browser and browser component vendors, when inventing and
implementing new features or components.
2. The IETF or some other standards body, when creating a new
standard for a content format, or when identifying a new type
of user preference (for example a preference for
representations without animated gifs).
3. Content authors, when identifying a new type of user
preference and creating new content to match.
A fast registration process is mainly needed for registration by
group 1 and 3. For 2, a slower process would suffice.
4.3 Feature tag registration scenario
Below is a scenario, in a Web context, for the registration of a
feature tag which succeeds in being generally used.
Time Action
(months)
t+0 Browser vendor A invents the new feature XY.
t+1 Vendor A starts implementing XY, and completes a
feature tag registration form for the `g.xy' tag.
t+2 Vendor A submits the form and the IANA registers the `g.xy'
feature tag.
t+2.1 Vendor A releases a new browser version, which
a) implements the feature XY
b) has an entry under `g.xy' in its negotiation database,
which tells extensible negotiation mechanisms that this
feature is present
t+2.5 `Early adopter' content authors start making content
representations which use XY.
t+3 Vendor B starts implementing XY in their own browser.
t+3 The `g.xy' tag appears in lists of useful tags maintained by
third parties.
t+3.5 Vendor B releases a new browser version, which
a) implements the feature XY
b) has an entry under `g.xy' in its negotiation database,
which tells extensible negotiation mechanisms that this
feature is present
t+3.5 Many content authors start making content representations
which use XY.
t+4 Vendor C starts implementing XY, and invents the extension
XY_COLOR.
t+4.5 Vendor C registers the `g.xy_color' feature tag.
t+4.5 Vendor C releases a new browser version, which
a) implements the features XY and XY_COLOR
b) has appropriate entries under `g.xy' and `g.xy_color'
in its database
t+10 90% of all deployed browsers support XY. Content authors
start using XY it without bothering to provide an alternate
representation.
4.4 Volume considerations
Feature tag registration which will have to keep pace with the
introduction of new features by vendors.
In particular in the Web domain, vendors are moving fast, and this
will inevitably lead to a feature tag namespace which contains a
lot of tags. Also, a lot of tags will be `dead' tags, tags related
to features which failed to take off and gain widespread use.
Compare this to the situation in the USENET newsgroup namespace.
Like a list of all MIME media types, a list of all registered
feature tags will generally be too long to be useful to any content
author. Third parties could filter the feature tag namespace and
compile short lists of useful tags. In the Web domain, Web
indexing robots could, while traversing the web, gather statistics
about actual use of feature tags; these statistics could help in
compiling lists.
4.5 Danger of excessive registration
One danger for the feature tag namespace is the emergence of
excessive registration as seen in the internet domain name system
(DNS) namespace.
We speculate that the various forces which contributed to the DNS
registration problems are absent for feature tags: feature tags
will not be very visible to end users, and registration of a
feature tag does not mean you get exclusive use.
We therefore do not expect excessive registration to occur. We
note it has not occured (so far) in the MIME media type namespace.
Of course it is possible to update the registration procedure if
excessive registration _does_ occur. A necessary precaution is to
reserve a part of the feature tag namespace for future use.
5 Security considerations
When used, negotiation mechanisms usually reveal some information
about one party to other parties. This may raise privacy concerns,
and may allow a malicious party to make more educated guesses about
the presence of security holes in the other party.
6 Acknowledgments
The idea of creating a vocabulary of dimensions of negotiation,
which is maintained in a central open registry, is due to
discussions on extensible negotiation mechanisms in the IETF HTTP
working group. The authors wish to thank Larry Masinter for
contributing to early discussions of feature tag registration.
7 References
[1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures. RFC
2048, BCP 13, Network Working Group, November 1996
[2] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC
2068, HTTP Working Group, January, 1997.
[3] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP.
Internet-Draft draft-ietf-http-negotiation-02.txt, HTTP Working
Group.
8 Authors' addresses
Koen Holtman
Technische Universiteit Eindhoven
Postbus 513
Kamer HG 6.57
5600 MB Eindhoven (The Netherlands)
Email: koen@win.tue.nl
Andrew H. Mutz
Hewlett-Packard Company
1501 Page Mill Road 3U-3
Palo Alto CA 94304, USA
Fax +1 415 857 4691
Email: mutz@hpl.hp.com
Expires: January 7, 1998
| PAFTECH AB 2003-2026 | 2026-04-24 14:07:44 |