2004/id/draft-ietf-http-feature-reg-03.txt


HTTP Working Group                                     Koen Holtman, TUE
Internet-Draft                              Andrew Mutz, Hewlett-Packard
Expires: January 28, 1998                               Ted Hardie, NASA      
                                                            Nov 28, 1997

                    Content Feature Tag Registration Procedure

                     draft-ietf-http-feature-reg-03.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.


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 negotiation
   mechanisms in order to tailor the information form 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 facilitate
   sharing this vocabulary between the negotiating parties.

   This document defines a registration procedure which uses the
   Internet Assigned Numbers Authority (IANA) as a central registry
   for this content feature vocabulary.


TABLE OF CONTENTS

   1 Introduction

   2 Feature tag syntax
 
   3 Feature tag registration
    3.1 Registration trees
    3.1.1 IETF tree
    3.1.2 Global tree
    3.1.3 Local or specialized tree
    3.1.4 Special `x.' tree
    3.1.5 Additional registration trees
    3.2 Location of registered feature tag list
    3.3 IANA procedures for registering feature tags
    3.4 Registration template

   4 Security considerations

   5 Acknowledgments

   6 References

   7 Authors' addresses

   Appendix A: IANA and RFC editor to-do list


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 defines registration procedures which use the
   Internet Assigned Numbers Authority (IANA) as a central registry
   for this content feature vocabulary.


2 Feature tag syntax

   A feature tag is a string consisting of one or more of the
   following US-ASCII characters: uppercase letters, lowercase
   letters, digits, colon (":"), slash ("/"), the dot (".") and the 
   dash ("-").  Feature tags are case-insensitive.  Dots are 
   understood to potentially imply heirarchy; a feature can be 
   subtyped by describing it as tree.feature.subfeature and by
   indicating this in the feature registration.


3 Feature tag registration

   Registration of a new feature tag starts with the submission of a
   registration proposal.  Registration may occur in several different
   registration trees, which have different requirements as discussed
   below.  In general, the new registration proposal is circulated and
   reviewed in a fashion appropriate to the tree involved.  The
   feature tag is then registered if the proposal is acceptable.  The
   following sections describe the requirements and procedures used
   for each of the different registration trees.


3.1 Registration trees

   The following subsections define registration "trees",
   distinguished by the use of faceted names (e.g., names of the form
   "tree.feature_name").


3.1.1 IETF tree

   The IETF tree is intended for feature tags of general interest to
   the Internet Community.  Registration in the IETF tree requires
   approval by the IESG and publication of the feature tag
   specification as some form of RFC.

   Feature tags in the IETF tree normally have names that are not
   explicitly faceted, i.e., do not contain period (".", full stop)
   characters.

   The "owner" of a feature tag in the IETF tree is assumed to be the
   IETF itself.  Modification or alteration of the specification
   requires the same level of processing (e.g. standards track)
   required for the initial registration.

3.1.2 Global tree

   The global tree is intended for feature tags of general interest to
   the Internet Community.  Unlike registration in the IETF tree,
   registration in the global tree does not require approval by the
   IESG.  A registration may be placed in the global tree by anyone
   who has the need to allow for feature negotiation on a particular
   capability or preference.

   Typically, if the creator of an Internet service or product
   introduces something new to the Internet Community, and if it is
   meaningful to do negotiation on it, the vendor can register a
   feature tag in the global tree.

   The owner of "global" tags and associated specifications is the
   person or entity making the registration, or one to whom
   responsibility has been transferred as described below.

   Tags in the global tree will be distinguished by the leading facet
   "g.". That may be followed, at the discretion of the registration,
   by either a designation of an area of negotiation, (e.g.,
   "g.blinktags") or by an IANA-approved designation of the producer's
   name which is then followed by a designation of an area of
   negotiation (e.g., g.bigcompany.obscurefeature).

   While public exposure and review of feature tags to be registered
   in the global tree is not required, using the ietf-feature-tags
   list for review is strongly encouraged to improve the quality of
   those specifications.  Registrations in the global tree may be
   submitted directly to the IANA.

3.1.3 Local or specialized tree

   The local tree is intended for feature tags identifying areas
   of negotiation which are relevant in a localized, specialized,
   restricted, or experimental context.

   The owner of "local" tags and associated specifications is the
   person or entity making the registration, or one to whom
   responsibility has been transferred as described below.

   Tags in the local tree will be distinguished by the leading facet
   "l.".  While public exposure and review of feature tags to be
   registered in the local tree is not required, using the
   ietf-feature-tags list for review is strongly encouraged to improve
   the quality of those specifications.  Registrations in the local
   tree may be submitted directly to the IANA.

3.1.4 URL trees

   A feature tag may be defined as a complete URL. The "owner" of the 
   domain is assumed to be registration authority regarding features
   defined and described by URLs within the domain.  These tags are
   considered unregistered for the purpose of this document.  

3.1.5 Additional registration trees

   From time to time and as required by the community, the IANA may,
   with the advice and consent of the IESG, create new top-level
   registration trees.  It is explicitly assumed that these trees may
   be created for external registration and management by well-known
   permanent bodies, such as scientific societies for media types
   specific to the sciences they cover.  In general, the quality of
   review of specifications for one of these additional registration
   trees is expected to be equivalent to that which IETF would give to
   registrations in its own tree.  Establishment of these new trees
   will be announced through RFC publication approved by the IESG.

3.2 Location of registered feature tag list

   Feature tag registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature-
   tags/" and all registered feature tags will be listed in the
   periodically issued "Assigned Numbers" RFC [currently STD 2,
   RFC-1700].  The feature tag description and other supporting
   material may also be published as an Informational RFC by sending
   it to "rfc-editor@isi.edu" (please follow the instructions to RFC
   authors [RFC-1543]).


3.3 IANA procedures for registering feature tags

   The IANA will only register feature tags in the IETF tree in
   response to a communication from the IESG stating that a given
   registration has been approved.

   Global and local tags will be registered by the IANA automatically
   and without any formal review as long as the following minimal
   conditions are met:

    (1)   A feature tag must function as an actual identifier of an area
          of negotiation.

    (2)   All feature tag names must be unique, and must conform to the 
          syntax in section 2.

    (3)   An openly available description of the area of negotiation is
          minimally required.  The specification of a feature tag must
          state whether the choice in the indicated area is a simple
          yes/no choice, or if it is a choice among multiple values.
          If the choice is among multiple values, and a canonical
          format for these values is defined, it must be possible to
          map this format onto octet strings.

    (4)   Any security considerations given must not be obviously
          bogus. (It is neither possible nor necessary for the
          IANA to conduct a comprehensive security review of
          feature tag registrations.  Nevertheless, the IANA has
          the authority to identify obviously incompetent material
          and exclude it.)


3.4 Registration template

   To: ietf-feature-tags@iana.org (Feature tags mailing list)
        (or directly to iana@iana.org)
   Subject: Registration of feature tag XXXX


    | Instructions are preceded by `|'.  Some fields are optional.

   Feature tag name:

   Summary of the area of negotiation indicated by this feature tag:

    | Include a short (no longer than 4 lines) description or summary
    | Examples:
    |   `Negotiation on whether to use the xyzzy feature of ...'
    |   `Negotiation on the MIME media type of the data which
    |    is transmitted for ...'
    |   `Negotiation on whether to use colors in displaying ...'
    |   `Negotiation on the number of colors to use in displaying ...'

   Number of alternative results in this area of negotiation:

     [ ] 1. Two alternatives, which can be labeled with `yes' and `no'
     [ ] 2. More than two alternatives, or two alternatives with no
            natural `yes/no' labeling

   For case 1: nature of the `yes' and `no' alternatives:

     [ ] 1a. A particular feature is used/invoked/enabled, or not
     [ ] 1b. Other

   For case 2: How is a single alternative result naturally identified?

     [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag)
     [ ] 2b. With an integer value
     [ ] 2c. With a numeric value of a non-integer type (e.g. float)
     [ ] 2d. Other
     [ ] 2e. There is no simple way to identify a single result

   (Only for case 1a) Description of the feature which is used,
   invoked, or enabled if the result is `yes':

    | Descriptions may also reference outside material.

   (Only for case 1b) Description of the effect of the 'yes' result:

   (Only for case 1b) Description of the effect of the 'no' result:

   (Only for case 2) Detailed description of the area of negotiation,
   and (in cases 2a-2d) of the format and meaning of the identifiers
   for the alternative results:
   
     | If the number of alternative results is small, the description
     | could simply enumerate the identifiers of the different results
     | and describe their meaning.  
     | 
     | The identifiers of the alternative results could also be
     | described by referring to another IANA registry, for example
     | the MIME media type registry.

   Default negotiation result (if applicable to the intended
   application domain):

   The feature tag is intended for use in the applications, protocols,
   services, or negotiation mechanisms:                   [optional]

    | For applications, also specify the number of the first version
    | which will use the tag, if applicable.

   Examples of typical use:                               [optional]

   Related standards or documents:                        [optional]

   Considerations particular to use in individual applications,
   protocols, services, or negotiation mechanisms:        [optional]

   Interoperability considerations:                       [optional]

   Security considerations:

   Additional information:                                [optional]

     Keywords:                                            [optional]

     Related feature tags:                                [optional]

     Related media types or data formats:                 [optional]

     Related HTML markup tags:                            [optional]

   Person & email address to contact for further information:

   Intended usage:

    | one of COMMON, LIMITED USE or OBSOLETE

   Author/Change controller:

   Requested IANA publication delay:                      [optional]

    | A delay may only be requested for registration in global or
    | local trees, with a maximum of two months.

   Other information:                                     [optional]

    |  Any other information that the author deems interesting may be
    |  added here.


4 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.


5 Acknowledgments

   The details of the registration procedure in this document were
   directly adapted from [1].  Much of the text in section 3 was
   directly copied from this source.  

   The idea of creating a vocabulary of areas 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 Ted Hardie, Larry Masinter and Graham 
   Klyne for contributing to discussions about feature tag 
   registration.


6 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


7 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
   11000 Wolfe Rd. 42UO
   Cupertino CA 95014 USA
   Fax +1 408 447 4439
   Email: andy_mutz@hp.com

   Ted Hardie
   NASA
   hardie@thornhill.arc.nasa.gov
  

Appendix A: IANA and RFC editor to-do list

   VERY IMPORTANT NOTE:  This appendix is intended to communicate
   various editorial and procedural tasks the IANA and the RFC
   Editor should undertake prior to publication of this document
   as an RFC.  This appendix should NOT appear in the actual RFC
   version of this document!

   This document refers to the feature tags mailing list
   ietf-feature-tags@iana.org.  This list does not exist at the
   present time and needs to be created.

   The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/" area
   does not exist at the present time and needs to be created.


Expires: June 1, 1998
1
2	HTTP Working Group Koen Holtman, TUE
3	Internet-Draft Andrew Mutz, Hewlett-Packard
4	Expires: January 28, 1998 Ted Hardie, NASA
5	Nov 28, 1997
6
7	Content Feature Tag Registration Procedure
8
9	draft-ietf-http-feature-reg-03.txt
10
11
12	STATUS OF THIS MEMO
13
14	This document is an Internet-Draft. Internet-Drafts are
15	working documents of the Internet Engineering Task Force
16	(IETF), its areas, and its working groups. Note that other
17	groups may also distribute working documents as
18	Internet-Drafts.
19
20	Internet-Drafts are draft documents valid for a maximum of
21	six months and may be updated, replaced, or obsoleted by
22	other documents at any time. It is inappropriate to use
23	Internet-Drafts as reference material or to cite them other
24	than as "work in progress".
25
26	To learn the current status of any Internet-Draft, please
27	check the "1id-abstracts.txt" listing contained in the
28	Internet-Drafts Shadow Directories on ftp.is.co.za
29	(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
30	Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
31	West Coast).
32
33	Distribution of this document is unlimited. Please send
34	comments to the HTTP working group at
35	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
36	group are archived at
37	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
38	discussions about HTTP and the applications which use HTTP
39	should take place on the <www-talk@w3.org> mailing list.
40
41
42
43	ABSTRACT
44
45	Recent Internet applications, such as the World Wide Web, tie
46	together a great diversity in data formats, client and server
47	platforms, and communities. This has created a need for negotiation
48	mechanisms in order to tailor the information form to the
49	capabilities and preferences of the parties involved.
50
51	Extensible negotiation mechanisms need a vocabulary to identify
52	various things which can be negotiated on. To promote
53	interoperability, a registration process is needed to facilitate
54	sharing this vocabulary between the negotiating parties.
55
56	This document defines a registration procedure which uses the
57	Internet Assigned Numbers Authority (IANA) as a central registry
58	for this content feature vocabulary.
59
60
61	TABLE OF CONTENTS
62
63	1 Introduction
64
65	2 Feature tag syntax
66
67	3 Feature tag registration
68	3.1 Registration trees
69	3.1.1 IETF tree
70	3.1.2 Global tree
71	3.1.3 Local or specialized tree
72	3.1.4 Special `x.' tree
73	3.1.5 Additional registration trees
74	3.2 Location of registered feature tag list
75	3.3 IANA procedures for registering feature tags
76	3.4 Registration template
77
78	4 Security considerations
79
80	5 Acknowledgments
81
82	6 References
83
84	7 Authors' addresses
85
86	Appendix A: IANA and RFC editor to-do list
87
88
89
90	1 Introduction
91
92	Recent Internet applications, such as the World Wide Web, tie
93	together a great diversity in data formats, client and server
94	platforms, and communities. This has created a need for various
95	kinds of negotiation mechanisms, which tailor the data which is
96	exchanged, or the exchange process itself, to the capabilities and
97	preferences of the parties involved.
98
99	Extensible negotiation mechanisms need a vocabulary to identify
100	various things which can be negotiated on. To promote
101	interoperability, a registration process is needed to ensure that
102	that this vocabulary, which can be shared between negotiation
103	mechanisms, is developed in an orderly, well-specified, and public
104	manner.
105
106	This document defines registration procedures which use the
107	Internet Assigned Numbers Authority (IANA) as a central registry
108	for this content feature vocabulary.
109
110
111	2 Feature tag syntax
112
113	A feature tag is a string consisting of one or more of the
114	following US-ASCII characters: uppercase letters, lowercase
115	letters, digits, colon (":"), slash ("/"), the dot (".") and the
116	dash ("-"). Feature tags are case-insensitive. Dots are
117	understood to potentially imply heirarchy; a feature can be
118	subtyped by describing it as tree.feature.subfeature and by
119	indicating this in the feature registration.
120
121
122	3 Feature tag registration
123
124	Registration of a new feature tag starts with the submission of a
125	registration proposal. Registration may occur in several different
126	registration trees, which have different requirements as discussed
127	below. In general, the new registration proposal is circulated and
128	reviewed in a fashion appropriate to the tree involved. The
129	feature tag is then registered if the proposal is acceptable. The
130	following sections describe the requirements and procedures used
131	for each of the different registration trees.
132
133
134	3.1 Registration trees
135
136	The following subsections define registration "trees",
137	distinguished by the use of faceted names (e.g., names of the form
138	"tree.feature_name").
139
140
141	3.1.1 IETF tree
142
143	The IETF tree is intended for feature tags of general interest to
144	the Internet Community. Registration in the IETF tree requires
145	approval by the IESG and publication of the feature tag
146	specification as some form of RFC.
147
148	Feature tags in the IETF tree normally have names that are not
149	explicitly faceted, i.e., do not contain period (".", full stop)
150	characters.
151
152	The "owner" of a feature tag in the IETF tree is assumed to be the
153	IETF itself. Modification or alteration of the specification
154	requires the same level of processing (e.g. standards track)
155	required for the initial registration.
156
157	3.1.2 Global tree
158
159	The global tree is intended for feature tags of general interest to
160	the Internet Community. Unlike registration in the IETF tree,
161	registration in the global tree does not require approval by the
162	IESG. A registration may be placed in the global tree by anyone
163	who has the need to allow for feature negotiation on a particular
164	capability or preference.
165
166	Typically, if the creator of an Internet service or product
167	introduces something new to the Internet Community, and if it is
168	meaningful to do negotiation on it, the vendor can register a
169	feature tag in the global tree.
170
171	The owner of "global" tags and associated specifications is the
172	person or entity making the registration, or one to whom
173	responsibility has been transferred as described below.
174
175	Tags in the global tree will be distinguished by the leading facet
176	"g.". That may be followed, at the discretion of the registration,
177	by either a designation of an area of negotiation, (e.g.,
178	"g.blinktags") or by an IANA-approved designation of the producer's
179	name which is then followed by a designation of an area of
180	negotiation (e.g., g.bigcompany.obscurefeature).
181
182	While public exposure and review of feature tags to be registered
183	in the global tree is not required, using the ietf-feature-tags
184	list for review is strongly encouraged to improve the quality of
185	those specifications. Registrations in the global tree may be
186	submitted directly to the IANA.
187
188	3.1.3 Local or specialized tree
189
190	The local tree is intended for feature tags identifying areas
191	of negotiation which are relevant in a localized, specialized,
192	restricted, or experimental context.
193
194	The owner of "local" tags and associated specifications is the
195	person or entity making the registration, or one to whom
196	responsibility has been transferred as described below.
197
198	Tags in the local tree will be distinguished by the leading facet
199	"l.". While public exposure and review of feature tags to be
200	registered in the local tree is not required, using the
201	ietf-feature-tags list for review is strongly encouraged to improve
202	the quality of those specifications. Registrations in the local
203	tree may be submitted directly to the IANA.
204
205	3.1.4 URL trees
206
207	A feature tag may be defined as a complete URL. The "owner" of the
208	domain is assumed to be registration authority regarding features
209	defined and described by URLs within the domain. These tags are
210	considered unregistered for the purpose of this document.
211
212	3.1.5 Additional registration trees
213
214	From time to time and as required by the community, the IANA may,
215	with the advice and consent of the IESG, create new top-level
216	registration trees. It is explicitly assumed that these trees may
217	be created for external registration and management by well-known
218	permanent bodies, such as scientific societies for media types
219	specific to the sciences they cover. In general, the quality of
220	review of specifications for one of these additional registration
221	trees is expected to be equivalent to that which IETF would give to
222	registrations in its own tree. Establishment of these new trees
223	will be announced through RFC publication approved by the IESG.
224
225	3.2 Location of registered feature tag list
226
227	Feature tag registrations will be posted in the anonymous FTP
228	directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature-
229	tags/" and all registered feature tags will be listed in the
230	periodically issued "Assigned Numbers" RFC [currently STD 2,
231	RFC-1700]. The feature tag description and other supporting
232	material may also be published as an Informational RFC by sending
233	it to "rfc-editor@isi.edu" (please follow the instructions to RFC
234	authors [RFC-1543]).
235
236
237	3.3 IANA procedures for registering feature tags
238
239	The IANA will only register feature tags in the IETF tree in
240	response to a communication from the IESG stating that a given
241	registration has been approved.
242
243	Global and local tags will be registered by the IANA automatically
244	and without any formal review as long as the following minimal
245	conditions are met:
246
247	(1) A feature tag must function as an actual identifier of an area
248	of negotiation.
249
250	(2) All feature tag names must be unique, and must conform to the
251	syntax in section 2.
252
253	(3) An openly available description of the area of negotiation is
254	minimally required. The specification of a feature tag must
255	state whether the choice in the indicated area is a simple
256	yes/no choice, or if it is a choice among multiple values.
257	If the choice is among multiple values, and a canonical
258	format for these values is defined, it must be possible to
259	map this format onto octet strings.
260
261	(4) Any security considerations given must not be obviously
262	bogus. (It is neither possible nor necessary for the
263	IANA to conduct a comprehensive security review of
264	feature tag registrations. Nevertheless, the IANA has
265	the authority to identify obviously incompetent material
266	and exclude it.)
267
268
269	3.4 Registration template
270
271	To: ietf-feature-tags@iana.org (Feature tags mailing list)
272	(or directly to iana@iana.org)
273	Subject: Registration of feature tag XXXX
274
275
276	\| Instructions are preceded by `\|'. Some fields are optional.
277
278	Feature tag name:
279
280	Summary of the area of negotiation indicated by this feature tag:
281
282	\| Include a short (no longer than 4 lines) description or summary
283	\| Examples:
284	\| `Negotiation on whether to use the xyzzy feature of ...'
285	\| `Negotiation on the MIME media type of the data which
286	\| is transmitted for ...'
287	\| `Negotiation on whether to use colors in displaying ...'
288	\| `Negotiation on the number of colors to use in displaying ...'
289
290	Number of alternative results in this area of negotiation:
291
292	[ ] 1. Two alternatives, which can be labeled with `yes' and `no'
293	[ ] 2. More than two alternatives, or two alternatives with no
294	natural `yes/no' labeling
295
296	For case 1: nature of the `yes' and `no' alternatives:
297
298	[ ] 1a. A particular feature is used/invoked/enabled, or not
299	[ ] 1b. Other
300
301	For case 2: How is a single alternative result naturally identified?
302
303	[ ] 2a. With a name, keyword, label, or tag (e.g. a language tag)
304	[ ] 2b. With an integer value
305	[ ] 2c. With a numeric value of a non-integer type (e.g. float)
306	[ ] 2d. Other
307	[ ] 2e. There is no simple way to identify a single result
308
309	(Only for case 1a) Description of the feature which is used,
310	invoked, or enabled if the result is `yes':
311
312	\| Descriptions may also reference outside material.
313
314	(Only for case 1b) Description of the effect of the 'yes' result:
315
316	(Only for case 1b) Description of the effect of the 'no' result:
317
318	(Only for case 2) Detailed description of the area of negotiation,
319	and (in cases 2a-2d) of the format and meaning of the identifiers
320	for the alternative results:
321
322	\| If the number of alternative results is small, the description
323	\| could simply enumerate the identifiers of the different results
324	\| and describe their meaning.
325	\|
326	\| The identifiers of the alternative results could also be
327	\| described by referring to another IANA registry, for example
328	\| the MIME media type registry.
329
330	Default negotiation result (if applicable to the intended
331	application domain):
332
333	The feature tag is intended for use in the applications, protocols,
334	services, or negotiation mechanisms: [optional]
335
336	\| For applications, also specify the number of the first version
337	\| which will use the tag, if applicable.
338
339	Examples of typical use: [optional]
340
341	Related standards or documents: [optional]
342
343	Considerations particular to use in individual applications,
344	protocols, services, or negotiation mechanisms: [optional]
345
346	Interoperability considerations: [optional]
347
348	Security considerations:
349
350	Additional information: [optional]
351
352	Keywords: [optional]
353
354	Related feature tags: [optional]
355
356	Related media types or data formats: [optional]
357
358	Related HTML markup tags: [optional]
359
360	Person & email address to contact for further information:
361
362	Intended usage:
363
364	\| one of COMMON, LIMITED USE or OBSOLETE
365
366	Author/Change controller:
367
368	Requested IANA publication delay: [optional]
369
370	\| A delay may only be requested for registration in global or
371	\| local trees, with a maximum of two months.
372
373	Other information: [optional]
374
375	\| Any other information that the author deems interesting may be
376	\| added here.
377
378
379	4 Security considerations
380
381	When used, negotiation mechanisms usually reveal some information
382	about one party to other parties. This may raise privacy concerns,
383	and may allow a malicious party to make more educated guesses about
384	the presence of security holes in the other party.
385
386
387	5 Acknowledgments
388
389	The details of the registration procedure in this document were
390	directly adapted from [1]. Much of the text in section 3 was
391	directly copied from this source.
392
393	The idea of creating a vocabulary of areas of negotiation, which is
394	maintained in a central open registry, is due to discussions on
395	extensible negotiation mechanisms in the IETF HTTP working group.
396	The authors wish to thank Ted Hardie, Larry Masinter and Graham
397	Klyne for contributing to discussions about feature tag
398	registration.
399
400
401	6 References
402
403	[1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail
404	Extensions (MIME) Part Four: Registration Procedures. RFC
405	2048, BCP 13, Network Working Group, November 1996
406
407
408	7 Authors' addresses
409
410	Koen Holtman
411	Technische Universiteit Eindhoven
412	Postbus 513
413	Kamer HG 6.57
414	5600 MB Eindhoven (The Netherlands)
415	Email: koen@win.tue.nl
416
417	Andrew H. Mutz
418	Hewlett-Packard Company
419	11000 Wolfe Rd. 42UO
420	Cupertino CA 95014 USA
421	Fax +1 408 447 4439
422	Email: andy_mutz@hp.com
423
424	Ted Hardie
425	NASA
426	hardie@thornhill.arc.nasa.gov
427
428
429
430	Appendix A: IANA and RFC editor to-do list
431
432	VERY IMPORTANT NOTE: This appendix is intended to communicate
433	various editorial and procedural tasks the IANA and the RFC
434	Editor should undertake prior to publication of this document
435	as an RFC. This appendix should NOT appear in the actual RFC
436	version of this document!
437
438	This document refers to the feature tags mailing list
439	ietf-feature-tags@iana.org. This list does not exist at the
440	present time and needs to be created.
441
442	The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/" area
443	does not exist at the present time and needs to be created.
444
445
446	Expires: June 1, 1998