1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
4 |
Expires: January 28, 1998 July 28, 1997 |
5 |
|
6 |
Feature Tag Registration Procedures |
7 |
|
8 |
draft-ietf-http-feature-reg-02.txt |
9 |
|
10 |
|
11 |
STATUS OF THIS MEMO |
12 |
|
13 |
This document is an Internet-Draft. Internet-Drafts are |
14 |
working documents of the Internet Engineering Task Force |
15 |
(IETF), its areas, and its working groups. Note that other |
16 |
groups may also distribute working documents as |
17 |
Internet-Drafts. |
18 |
|
19 |
Internet-Drafts are draft documents valid for a maximum of |
20 |
six months and may be updated, replaced, or obsoleted by |
21 |
other documents at any time. It is inappropriate to use |
22 |
Internet-Drafts as reference material or to cite them other |
23 |
than as "work in progress". |
24 |
|
25 |
To learn the current status of any Internet-Draft, please |
26 |
check the "1id-abstracts.txt" listing contained in the |
27 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
28 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
29 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
30 |
West Coast). |
31 |
|
32 |
Distribution of this document is unlimited. Please send |
33 |
comments to the HTTP working group at |
34 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
35 |
group are archived at |
36 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
37 |
discussions about HTTP and the applications which use HTTP |
38 |
should take place on the <www-talk@w3.org> mailing list. |
39 |
|
40 |
A HTML version of this document can be found at |
41 |
<URL:http://gewis.win.tue.nl/~koen/conneg/>. |
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 various |
48 |
kinds of negotiation mechanisms, which tailor the data which is |
49 |
exchanged, or the exchange process, to the capabilities and |
50 |
preferences of the parties involved. |
51 |
|
52 |
Extensible negotiation mechanisms need a vocabulary to identify |
53 |
various things which can be negotiated on. To promote |
54 |
interoperability, a registration process is needed to ensure that |
55 |
that this vocabulary, which can be shared between negotiation |
56 |
mechanisms, is developed in an orderly, well-specified, and public |
57 |
manner. |
58 |
|
59 |
This document defines registration procedures which use the |
60 |
Internet Assigned Numbers Authority (IANA) as a central registry |
61 |
for this vocabulary, which is the vocabulary of feature tags. |
62 |
|
63 |
|
64 |
TABLE OF CONTENTS |
65 |
|
66 |
1 Introduction |
67 |
|
68 |
2 Basic concepts and definitions |
69 |
2.1 Areas of negotiation and feature tags |
70 |
2.2 Complexity of negotiation |
71 |
2.3 The result in an area of negotiation |
72 |
2.4 Feature tag syntax |
73 |
|
74 |
3 Feature tag registration |
75 |
3.1 Registration trees |
76 |
3.1.1 IETF tree |
77 |
3.1.2 Global tree |
78 |
3.1.3 Local or specialized tree |
79 |
3.1.4 Special `x.' tree |
80 |
3.1.5 Additional registration trees |
81 |
3.2 Registration requirements |
82 |
3.2.1 Functionality requirement |
83 |
3.2.2 Naming requirements |
84 |
3.2.3 Specification requirements |
85 |
3.2.4 Interchange recommendations |
86 |
3.2.5 Security requirements |
87 |
3.2.6 Publication requirements |
88 |
3.3 Registration procedure |
89 |
3.3.1 Present the feature tag to the community for review |
90 |
3.3.2 IESG approval |
91 |
3.3.3 IANA registration |
92 |
3.3.4 Delayed publication |
93 |
3.4 Comments on feature tag registrations |
94 |
3.5 Location of registered feature tag list |
95 |
3.6 IANA procedures for registering feature tags |
96 |
3.7 Change control |
97 |
3.8 Registration template |
98 |
|
99 |
4 Security considerations |
100 |
|
101 |
5 Acknowledgments |
102 |
|
103 |
6 References |
104 |
|
105 |
7 Authors' addresses |
106 |
|
107 |
Appendix A: IANA and RFC editor to-do list |
108 |
|
109 |
|
110 |
|
111 |
1 Introduction |
112 |
|
113 |
Recent Internet applications, such as the World Wide Web, tie |
114 |
together a great diversity in data formats, client and server |
115 |
platforms, and communities. This has created a need for various |
116 |
kinds of negotiation mechanisms, which tailor the data which is |
117 |
exchanged, or the exchange process itself, to the capabilities and |
118 |
preferences of the parties involved. |
119 |
|
120 |
Extensible negotiation mechanisms need a vocabulary to identify |
121 |
various things which can be negotiated on. To promote |
122 |
interoperability, a registration process is needed to ensure that |
123 |
that this vocabulary, which can be shared between negotiation |
124 |
mechanisms, is developed in an orderly, well-specified, and public |
125 |
manner. |
126 |
|
127 |
This document defines registration procedures which use the |
128 |
Internet Assigned Numbers Authority (IANA) as a central registry |
129 |
for this vocabulary, which is the vocabulary of feature tags. |
130 |
|
131 |
|
132 |
2 Basic concepts and definitions |
133 |
|
134 |
2.1 Areas of negotiation and feature tags |
135 |
|
136 |
Something which can be negotiated on is called an `area of |
137 |
negotiation' in this document. Examples of areas of negotiation |
138 |
are: |
139 |
|
140 |
* the MIME media type of the data which is transmitted |
141 |
* the language of the text document which is transmitted |
142 |
* the color depth of the screen on which something is to be |
143 |
displayed |
144 |
* whether the recipient supports the `floating 5 dimensional |
145 |
tables' feature |
146 |
* the fonts which are available to the recipient |
147 |
* whether a Web user prefers speed over graphical detail |
148 |
* whether the recipient is capable of displaying graphical |
149 |
content |
150 |
* whether the user prefers a blue background with purple dots over |
151 |
a green background with pictures of small furry animals, except |
152 |
on Fridays. |
153 |
|
154 |
A feature tag identifies a single area of negotiation. |
155 |
|
156 |
It is expected that the majority of feature tags will identify new |
157 |
areas of negotiation, in which the object of negotiation is to |
158 |
decide on the presence or use of some new feature in a software |
159 |
product. This explains the name `feature tag'. |
160 |
|
161 |
It is recognized that there is continuous growth in the number of |
162 |
areas in which some form of negotiation is desirable. To keep up |
163 |
with this growth, extensible negotiation mechanisms are needed, |
164 |
which refer to the feature tag vocabulary to identify new areas of |
165 |
negotiation, rather than relying on hard-coded knowledge about a |
166 |
few areas. |
167 |
|
168 |
To avoid the duplication of work, and to promote the interoperable |
169 |
naming of areas of negotiation across protocols and applications, |
170 |
the feature tag namespace is not bound to a particular protocol or |
171 |
negotiation mechanism. Also, there is no prior restriction on the |
172 |
areas of negotiation which may be identified by a feature tag, |
173 |
other than that it must be conceivable to negotiate in these areas |
174 |
in the context of some Internet application. |
175 |
|
176 |
|
177 |
2.2 Complexity of negotiation |
178 |
|
179 |
Negotiation processes can often be complex. Two frequent sources |
180 |
of complexity are: |
181 |
|
182 |
1. An area of negotiation may be inherently complex. For |
183 |
example, negotiating on the use of a particular media type is |
184 |
inherently more complex than negotiating on the presence of a |
185 |
single feature, because there are more possible outcomes. |
186 |
|
187 |
2. There may be complex of interdependencies between the choices |
188 |
in different areas of negotiation. For example, if the |
189 |
following versions of a document are available on a Web server: |
190 |
|
191 |
* text/html, English |
192 |
* text/plain, French |
193 |
* audio/x-wav, German |
194 |
|
195 |
then the content negotiation mechanism cannot treat the areas |
196 |
of `MIME media type negotiation' and `language negotiation' as |
197 |
separate. |
198 |
|
199 |
It is recognized that extensible negotiation mechanisms will often |
200 |
differ in the type and amount of complexity they can handle. Thus, |
201 |
though negotiation mechanisms share the feature tag namespace, it |
202 |
will not be the case that every tag is usable in every negotiation |
203 |
mechanism, or that every negotiation mechanism will be able to |
204 |
handle all possible interdependencies. |
205 |
|
206 |
|
207 |
2.3 The result in an area of negotiation |
208 |
|
209 |
During negotiation, negotiation mechanisms will often need to |
210 |
transmit (canonical representations of) the possible results in |
211 |
various areas of negotiation over the wire. Also, at the end of a |
212 |
negotiation process, the mechanism may need to return (a |
213 |
canonical representation of) the result to the application which |
214 |
invoked it. |
215 |
|
216 |
In many areas of negotiation, there will be a natural, canonical |
217 |
representation of the result. For example, in the area |
218 |
|
219 |
* whether the recipient supports the `floating 5 dimensional |
220 |
tables' feature |
221 |
|
222 |
the canonical representation of the result is a boolean value (yes, |
223 |
the feature is supported, or no, the feature is not supported). In |
224 |
the area |
225 |
|
226 |
* the MIME media type of the data which is transmitted |
227 |
|
228 |
the canonical representation of the result will be a MIME media |
229 |
type identifier like text/html or application/postscript. In some |
230 |
areas of negotiation, the result could be a compound value (e.g. a |
231 |
coordinate in a 3D space). |
232 |
|
233 |
To promote interoperability, the registration entry of a feature |
234 |
tag can include a definition of the canonical representations of |
235 |
the possible results in the corresponding area of negotiation. |
236 |
|
237 |
|
238 |
2.4 Feature tag syntax |
239 |
|
240 |
A feature tag is a string consisting of one or more of the |
241 |
following US-ASCII characters: uppercase letters, lowercase |
242 |
letters, digits, the dot (".") and the dash ("-"). Feature tags |
243 |
are case-insensitive. |
244 |
|
245 |
|
246 |
3 Feature tag registration |
247 |
|
248 |
Registration of a new feature tag starts with the construction of a |
249 |
registration proposal. Registration may occur in several different |
250 |
registration trees, which have different requirements as discussed |
251 |
below. In general, the new registration proposal is circulated and |
252 |
reviewed in a fashion appropriate to the tree involved. The |
253 |
feature tag is then registered if the proposal is acceptable. The |
254 |
following sections describe the requirements and procedures used |
255 |
for each of the different registration trees. |
256 |
|
257 |
|
258 |
3.1 Registration trees |
259 |
|
260 |
The following subsections define registration "trees", |
261 |
distinguished by the use of faceted names (e.g., names of the form |
262 |
"tree.feature_name"). |
263 |
|
264 |
|
265 |
3.1.1 IETF tree |
266 |
|
267 |
The IETF tree is intended for feature tags of general interest to |
268 |
the Internet Community. Registration in the IETF tree requires |
269 |
approval by the IESG and publication of the feature tag |
270 |
specification as some form of RFC. |
271 |
|
272 |
Feature tags in the IETF tree normally have names that are not |
273 |
explicitly faceted, i.e., do not contain period (".", full stop) |
274 |
characters. |
275 |
|
276 |
The "owner" of a feature tag in the IETF tree is assumed to be the |
277 |
IETF itself. Modification or alteration of the specification |
278 |
requires the same level of processing (e.g. standards track) |
279 |
required for the initial registration. |
280 |
|
281 |
3.1.2 Global tree |
282 |
|
283 |
The global tree is intended for feature tags of general interest to |
284 |
the Internet Community. Unlike registration in the IETF tree, |
285 |
registration in the global tree does not require approval by the |
286 |
IESG. A registration may be placed in the global tree by anyone |
287 |
who has the need to allow for feature negotiation on a particular |
288 |
capability or preference. |
289 |
|
290 |
Typically, if the creator of an Internet service or product |
291 |
introduces something new to the Internet Community, and if it is |
292 |
meaningful to do negotiation on it, the vendor can register a |
293 |
feature tag in the global tree. |
294 |
|
295 |
The owner of "global" tags and associated specifications is the |
296 |
person or entity making the registration, or one to whom |
297 |
responsibility has been transferred as described below. |
298 |
|
299 |
Tags in the global tree will be distinguished by the leading facet |
300 |
"g.". That may be followed, at the discretion of the registration, |
301 |
by either a designation of an area of negotiation, (e.g., |
302 |
"g.blinktags") or by an IANA-approved designation of the producer's |
303 |
name which is then followed by a designation of an area of |
304 |
negotiation (e.g., g.bigcompany.obscurefeature). |
305 |
|
306 |
While public exposure and review of feature tags to be registered |
307 |
in the global tree is not required, using the ietf-feature-tags |
308 |
list for review is strongly encouraged to improve the quality of |
309 |
those specifications. Registrations in the global tree may be |
310 |
submitted directly to the IANA. |
311 |
|
312 |
3.1.3 Local or specialized tree |
313 |
|
314 |
The local tree is intended for feature tags identifying areas |
315 |
of negotiation which are relevant in a localized, specialized, |
316 |
restricted, or experimental context. |
317 |
|
318 |
The owner of "local" tags and associated specifications is the |
319 |
person or entity making the registration, or one to whom |
320 |
responsibility has been transferred as described below. |
321 |
|
322 |
Tags in the local tree will be distinguished by the leading facet |
323 |
"l.". While public exposure and review of feature tags to be |
324 |
registered in the local tree is not required, using the |
325 |
ietf-feature-tags list for review is strongly encouraged to improve |
326 |
the quality of those specifications. Registrations in the local |
327 |
tree may be submitted directly to the IANA. |
328 |
|
329 |
3.1.4 Special `x.' tree |
330 |
|
331 |
Feature tags with "x." as the first facet are reserved for use in |
332 |
experimental contexts. These tags are unregistered, experimental, |
333 |
and should be used only with the active agreement of the parties |
334 |
exchanging them. |
335 |
|
336 |
However, with the simplified registration procedures described |
337 |
above for vendor and personal trees, it should rarely, if ever, be |
338 |
necessary to use unregistered experimental tags, and as such use of |
339 |
these tags is discouraged. |
340 |
|
341 |
3.1.5 Additional registration trees |
342 |
|
343 |
From time to time and as required by the community, the IANA may, |
344 |
with the advice and consent of the IESG, create new top-level |
345 |
registration trees. It is explicitly assumed that these trees may |
346 |
be created for external registration and management by well-known |
347 |
permanent bodies, such as scientific societies for media types |
348 |
specific to the sciences they cover. In general, the quality of |
349 |
review of specifications for one of these additional registration |
350 |
trees is expected to be equivalent to that which IETF would give to |
351 |
registrations in its own tree. Establishment of these new trees |
352 |
will be announced through RFC publication approved by the IESG. |
353 |
|
354 |
|
355 |
3.2 Registration requirements |
356 |
|
357 |
Feature tag registration proposals are all expected to conform to |
358 |
various requirements laid out in the following sections. Note that |
359 |
requirement specifics sometimes vary depending on the registration |
360 |
tree, again as detailed in the following sections. |
361 |
|
362 |
3.2.1 Functionality requirement |
363 |
|
364 |
A feature tag must function as an actual identifier of an area of |
365 |
negotiation, and it must be conceivable to negotiate in this area |
366 |
in the context of some Internet application. |
367 |
|
368 |
This requirement applies regardless of the registration tree |
369 |
involved. |
370 |
|
371 |
3.2.2 Naming requirements |
372 |
|
373 |
All feature tag names must be unique, and must conform to the |
374 |
syntax in section 2.4. |
375 |
|
376 |
This requirement applies regardless of the registration tree |
377 |
involved. |
378 |
|
379 |
The IANA may reject tag names which are obviously bogus or |
380 |
misleading. Note however that other than in the IETF tree, the |
381 |
acceptance of a feature tag does not imply certification that the |
382 |
tag is adequately named. |
383 |
|
384 |
3.2.3 Specification requirements |
385 |
|
386 |
If a feature tag is registered in the IETF tree, a precise and |
387 |
openly available specification of the indicated area of negotiation |
388 |
is required, and must at a minimum be referenced by, if it isn't |
389 |
actually included in, the feature tag registration proposal itself. |
390 |
For the global and local trees, an openly available description of |
391 |
the area is minimally required. |
392 |
|
393 |
Regardless of the tree, the specification of a feature tag must |
394 |
state whether the choice in the indicated area is a simple yes/no |
395 |
choice, or if it is a choice for a single value among multiple |
396 |
values. |
397 |
|
398 |
If the choice in the indicated area is among multiple values, and |
399 |
it is possible to define canonical representations for the |
400 |
different possible result values, and the tag is registered in the |
401 |
IETF tree, a precise and openly available specification of the |
402 |
canonical format, and the exact meaning of the values is required, |
403 |
and must at a minimum be referenced by, if it isn't actually |
404 |
included in, the feature tag registration proposal itself. For any |
405 |
canonical format which is defined, it must be possible to map this |
406 |
format onto octet strings. |
407 |
|
408 |
If the registration is motivated by the creation of a new feature |
409 |
in a product, it is specifically permitted to name the product |
410 |
involved, and the product version number for which the feature was |
411 |
or will be first implemented. |
412 |
|
413 |
The registration of feature tags referencing patented technology is |
414 |
specifically permitted. However the restrictions set forth in RFC |
415 |
1602 on the use of patented technology in standards-track protocols |
416 |
must be respected when the specification of a feature tag is part |
417 |
of a standards-track protocol. |
418 |
|
419 |
3.2.4 Interchange recommendations |
420 |
|
421 |
Feature tags should, whenever possible, interoperate across as many |
422 |
systems, applications, and negotiation mechanisms as possible. |
423 |
However, some feature tags will by nature be bound to specific |
424 |
systems, and feature tag may indicate areas of negotiation in which |
425 |
the choice is made among types of values which can only be handled |
426 |
by highly specialized negotiation mechanisms. |
427 |
|
428 |
Universal interoperability of feature tags is not required, but |
429 |
known interoperability issues should be identified whenever |
430 |
possible. Publication of a feature tag does not require an |
431 |
exhaustive review of interoperability, and the interoperability |
432 |
considerations section is subject to continuing evaluation. |
433 |
|
434 |
These recommendations apply regardless of the registration tree |
435 |
involved. |
436 |
|
437 |
3.2.5 Security requirements |
438 |
|
439 |
An analysis of security issues is required for all feature tags |
440 |
registered in the IETF tree. (This is in accordance with the basic |
441 |
requirements for all IETF protocols.) A similar analysis for |
442 |
feature tags registered in the global or local trees is encouraged |
443 |
but not required. All descriptions of security issues must be as |
444 |
accurate as possible regardless of registration tree. In |
445 |
particular, a statement that there are "no security issues |
446 |
associated with the indicated feature tag" must not be confused |
447 |
with "the security issues associates with this feature tag have not |
448 |
been assessed". |
449 |
|
450 |
There is absolutely no requirement that systems which negotiate |
451 |
using the feature tags registered in any tree be secure or |
452 |
completely free from risks. Nevertheless, all known security risks |
453 |
must be identified in the registration of a feature tag, again |
454 |
regardless of registration tree. |
455 |
|
456 |
The security considerations section of all registrations is subject |
457 |
to continuing evaluation and modification, and in particular may be |
458 |
extended by use of the "comments on feature tags" mechanism |
459 |
described in subsequent sections. |
460 |
|
461 |
3.2.6 Publication requirements |
462 |
|
463 |
Proposals for feature tags registered in the IETF tree must be |
464 |
published as RFCs. RFC publication of global and local feature tag |
465 |
proposals is not required. In all cases the IANA will retain |
466 |
copies of all feature tag proposals and "publish" them as part of |
467 |
the feature tag registration tree itself. |
468 |
|
469 |
Other than in the IETF tree, the registration of a feature tag does |
470 |
not imply endorsement, approval, or recommendation by the IANA or |
471 |
the IETF or even certification that the specification is adequate. |
472 |
|
473 |
It is neither possible nor necessary for the IANA to conduct a |
474 |
comprehensive review of feature tag registrations. Nevertheless, |
475 |
the IANA has the authority to identify obviously incompetent |
476 |
material and exclude it. |
477 |
|
478 |
|
479 |
3.3 Registration procedure |
480 |
|
481 |
The following procedure has been implemented by the IANA for review |
482 |
and approval of new feature tags. This is not a formal standards |
483 |
process, but rather an administrative procedure intended to allow |
484 |
community comment and sanity checking without excessive time delay. |
485 |
For registration in the IETF tree, the normal IETF processes should |
486 |
be followed, treating posting of an internet-draft and announcement |
487 |
on the ietf-types list (as described in the next subsection) as a |
488 |
first step. For registrations in the global or local trees, the |
489 |
initial review step described below may be omitted and the tag |
490 |
registered directly by submitting the template and an explanation |
491 |
to the IANA (at iana@isi.edu). However, authors of global or local |
492 |
feature tag specifications are encouraged to seek community review |
493 |
and comment whenever that is feasible. |
494 |
|
495 |
3.3.1 Present the feature tag to the community for review |
496 |
|
497 |
Send a proposed feature tag registration to the |
498 |
"ietf-feature-tags@iana.org" mailing list for a two week review |
499 |
period. This mailing list has been established for the purpose of |
500 |
reviewing proposed feature tags. Proposed feature tags are not |
501 |
formally registered and must not be used; the "x." prefix can be |
502 |
used until registration is complete. |
503 |
|
504 |
The intent of the public posting is to solicit comments and |
505 |
feedback on the choice of tag name, the clarity of the tag |
506 |
specification, and a review of any interoperability or security |
507 |
considerations. The submitter may submit a revised registration |
508 |
proposal, or withdraw the registration proposal completely, at any |
509 |
time. |
510 |
|
511 |
3.3.2 IESG approval |
512 |
|
513 |
Feature tags registered in the IETF tree must be submitted to |
514 |
the IESG for approval. |
515 |
|
516 |
3.3.3 IANA registration |
517 |
|
518 |
Provided that the proposed tag meets the requirements for feature |
519 |
tags and has obtained whatever approval is necessary, the |
520 |
author may submit the registration request to the IANA, which |
521 |
will register the feature tag and make the feature tag |
522 |
registration available to the community. |
523 |
|
524 |
3.3.4 Delayed publication |
525 |
|
526 |
By default, feature tag registration proposals are published by the |
527 |
IANA immediately after registration of the tag. |
528 |
|
529 |
In some situations, a vendor may not wish that a specification of a |
530 |
tag for a planned new feature is published before the date at which |
531 |
the software implementing this feature is released to the Internet |
532 |
Community. Therefore, when submitting a feature tag registration |
533 |
proposal for a planned feature, a vendor may request a publication |
534 |
delay of up to two months after registration of the tag by the |
535 |
IANA. After registration, IANA will delay its publication of the |
536 |
registration proposal for at least the duration of the requested |
537 |
period. |
538 |
|
539 |
Immediately after receiving a notification of registration from the |
540 |
IANA, the vendor may release software which recognizes the tag to |
541 |
the Internet Community, and make public the tag specification |
542 |
though his own channels. |
543 |
|
544 |
|
545 |
3.4 Comments on feature tag registrations |
546 |
|
547 |
Comments on registered feature tags may be submitted by members of |
548 |
the community to the IANA. These comments will be passed on to the |
549 |
"owner" of the feature tag if possible. Submitters of comments may |
550 |
request that their comment be attached to the feature tag |
551 |
registration itself, and if the IANA approves of this the comment |
552 |
will be made accessible in conjunction with the tag registration |
553 |
itself. |
554 |
|
555 |
|
556 |
3.5 Location of registered feature tag list |
557 |
|
558 |
Feature tag registrations will be posted in the anonymous FTP |
559 |
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature- |
560 |
tags/" and all registered feature tags will be listed in the |
561 |
periodically issued "Assigned Numbers" RFC [currently STD 2, |
562 |
RFC-1700]. The feature tag description and other supporting |
563 |
material may also be published as an Informational RFC by sending |
564 |
it to "rfc-editor@isi.edu" (please follow the instructions to RFC |
565 |
authors [RFC-1543]). |
566 |
|
567 |
|
568 |
3.6 IANA procedures for registering feature tags |
569 |
|
570 |
The IANA will only register feature tags in the IETF tree in |
571 |
response to a communication from the IESG stating that a given |
572 |
registration has been approved. |
573 |
|
574 |
Global and local tags will be registered by the IANA automatically |
575 |
and without any formal review as long as the following minimal |
576 |
conditions are met: |
577 |
|
578 |
(1) A feature tag must function as an actual identifier of an area |
579 |
of negotiation. |
580 |
|
581 |
(2) All feature tag names must be unique, and must conform to the |
582 |
syntax in section 2.4. |
583 |
|
584 |
(3) An openly available description of the area of negotiation is |
585 |
minimally required. The specification of a feature tag must |
586 |
state whether the choice in the indicated area is a simple |
587 |
yes/no choice, or if it is a choice among multiple values. |
588 |
If the choice is among multiple values, and a canonical |
589 |
format for these values is defined, it must be possible to |
590 |
map this format onto octet strings. |
591 |
|
592 |
(4) Any security considerations given must not be obviously |
593 |
bogus. (It is neither possible nor necessary for the |
594 |
IANA to conduct a comprehensive security review of |
595 |
feature tag registrations. Nevertheless, the IANA has |
596 |
the authority to identify obviously incompetent material |
597 |
and exclude it.) |
598 |
|
599 |
|
600 |
3.7 Change control |
601 |
|
602 |
Once a feature tag has been published by the IANA, the owner may |
603 |
request a change to its definition. The descriptions of the |
604 |
different registration trees above designate the "owners" of each |
605 |
type of registration. The change request follows the following |
606 |
procedure: |
607 |
|
608 |
(1) Publish the revised template on the ietf-feature-tags list. |
609 |
|
610 |
(2) Leave at least two weeks for comments. |
611 |
|
612 |
(3) Publish using the IANA after formal review if required. |
613 |
|
614 |
Changes should be requested only when there are serious omissions |
615 |
or errors in the published specification. When review is required, |
616 |
a change request may be denied if it renders a use of tags that was |
617 |
valid under the previous definition invalid under the new |
618 |
definition. |
619 |
|
620 |
The owner of a feature tag may pass responsibility for the feature |
621 |
tag to another person or agency by informing the IANA and the |
622 |
ietf-feature-tags list; this can be done without discussion or |
623 |
review. |
624 |
|
625 |
The IESG may reassign responsibility for a feature tag. The most |
626 |
common case of this will be to enable changes to be made to tags |
627 |
where the author of the registration has died, moved out of contact |
628 |
or is otherwise unable to make changes that are important to the |
629 |
community. |
630 |
|
631 |
Feature tag registrations may not be deleted; feature tags which |
632 |
are no longer believed appropriate for use can be declared OBSOLETE |
633 |
by a change to their "intended use" field; such feature tags will |
634 |
be clearly marked in the lists published by the IANA. |
635 |
|
636 |
|
637 |
3.8 Registration template |
638 |
|
639 |
To: ietf-feature-tags@iana.org (Feature tags mailing list) |
640 |
(or directly to iana@iana.org) |
641 |
Subject: Registration of feature tag XXXX |
642 |
|
643 |
|
644 |
| Instructions are preceded by `|'. Some fields are optional. |
645 |
|
646 |
Feature tag name: |
647 |
|
648 |
Summary of the area of negotiation indicated by this feature tag: |
649 |
|
650 |
| Include a short (no longer than 4 lines) description or summary |
651 |
| Examples: |
652 |
| `Negotiation on whether to use the xyzzy feature of ...' |
653 |
| `Negotiation on the MIME media type of the data which |
654 |
| is transmitted for ...' |
655 |
| `Negotiation on whether to use colors in displaying ...' |
656 |
| `Negotiation on the number of colors to use in displaying ...' |
657 |
|
658 |
Number of alternative results in this area of negotiation: |
659 |
|
660 |
[ ] 1. Two alternatives, which can be labeled with `yes' and `no' |
661 |
[ ] 2. More than two alternatives, or two alternatives with no |
662 |
natural `yes/no' labeling |
663 |
|
664 |
For case 1: nature of the `yes' and `no' alternatives: |
665 |
|
666 |
[ ] 1a. A particular feature is used/invoked/enabled, or not |
667 |
[ ] 1b. Other |
668 |
|
669 |
For case 2: How is a single alternative result naturally identified? |
670 |
|
671 |
[ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) |
672 |
[ ] 2b. With an integer value |
673 |
[ ] 2c. With a numeric value of a non-integer type (e.g. float) |
674 |
[ ] 2d. Other |
675 |
[ ] 2e. There is no simple way to identify a single result |
676 |
|
677 |
(Only for case 1a) Description of the feature which is used, |
678 |
invoked, or enabled if the result is `yes': |
679 |
|
680 |
| Descriptions may also reference outside material. |
681 |
|
682 |
(Only for case 1b) Description of the effect of the 'yes' result: |
683 |
|
684 |
(Only for case 1b) Description of the effect of the 'no' result: |
685 |
|
686 |
(Only for case 2) Detailed description of the area of negotiation, |
687 |
and (in cases 2a-2d) of the format and meaning of the identifiers |
688 |
for the alternative results: |
689 |
|
690 |
| If the number of alternative results is small, the description |
691 |
| could simply enumerate the identifiers of the different results |
692 |
| and describe their meaning. |
693 |
| |
694 |
| The identifiers of the alternative results could also be |
695 |
| described by referring to another IANA registry, for example |
696 |
| the MIME media type registry. |
697 |
|
698 |
Default negotiation result (if applicable to the intended |
699 |
application domain): |
700 |
|
701 |
The feature tag is intended for use in the applications, protocols, |
702 |
services, or negotiation mechanisms: [optional] |
703 |
|
704 |
| For applications, also specify the number of the first version |
705 |
| which will use the tag, if applicable. |
706 |
|
707 |
Examples of typical use: [optional] |
708 |
|
709 |
Related standards or documents: [optional] |
710 |
|
711 |
Considerations particular to use in individual applications, |
712 |
protocols, services, or negotiation mechanisms: [optional] |
713 |
|
714 |
Interoperability considerations: [optional] |
715 |
|
716 |
Security considerations: |
717 |
|
718 |
Additional information: [optional] |
719 |
|
720 |
Keywords: [optional] |
721 |
|
722 |
Related feature tags: [optional] |
723 |
|
724 |
Related media types or data formats: [optional] |
725 |
|
726 |
Related HTML markup tags: [optional] |
727 |
|
728 |
Person & email address to contact for further information: |
729 |
|
730 |
Intended usage: |
731 |
|
732 |
| one of COMMON, LIMITED USE or OBSOLETE |
733 |
|
734 |
Author/Change controller: |
735 |
|
736 |
Requested IANA publication delay: [optional] |
737 |
|
738 |
| A delay may only be requested for registration in global or |
739 |
| local trees, with a maximum of two months. |
740 |
|
741 |
Other information: [optional] |
742 |
|
743 |
| Any other information that the author deems interesting may be |
744 |
| added here. |
745 |
|
746 |
|
747 |
4 Security considerations |
748 |
|
749 |
When used, negotiation mechanisms usually reveal some information |
750 |
about one party to other parties. This may raise privacy concerns, |
751 |
and may allow a malicious party to make more educated guesses about |
752 |
the presence of security holes in the other party. |
753 |
|
754 |
|
755 |
5 Acknowledgments |
756 |
|
757 |
The details of the registration procedure in this document were |
758 |
directly adapted from [1]. Much of the text in section 3 was |
759 |
directly copied from this source. |
760 |
|
761 |
The idea of creating a vocabulary of areas of negotiation, which is |
762 |
maintained in a central open registry, is due to discussions on |
763 |
extensible negotiation mechanisms in the IETF HTTP working group. |
764 |
The authors wish to thank Larry Masinter and Graham Klyne for |
765 |
contributing to discussions about feature tag registration. |
766 |
|
767 |
|
768 |
6 References |
769 |
|
770 |
[1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail |
771 |
Extensions (MIME) Part Four: Registration Procedures. RFC |
772 |
2048, BCP 13, Network Working Group, November 1996 |
773 |
|
774 |
|
775 |
7 Authors' addresses |
776 |
|
777 |
Koen Holtman |
778 |
Technische Universiteit Eindhoven |
779 |
Postbus 513 |
780 |
Kamer HG 6.57 |
781 |
5600 MB Eindhoven (The Netherlands) |
782 |
Email: koen@win.tue.nl |
783 |
|
784 |
Andrew H. Mutz |
785 |
Hewlett-Packard Company |
786 |
1501 Page Mill Road 3U-3 |
787 |
Palo Alto CA 94304, USA |
788 |
Fax +1 415 857 4691 |
789 |
Email: mutz@hpl.hp.com |
790 |
|
791 |
|
792 |
Appendix A: IANA and RFC editor to-do list |
793 |
|
794 |
VERY IMPORTANT NOTE: This appendix is intended to communicate |
795 |
various editorial and procedural tasks the IANA and the RFC |
796 |
Editor should undertake prior to publication of this document |
797 |
as an RFC. This appendix should NOT appear in the actual RFC |
798 |
version of this document! |
799 |
|
800 |
This document refers to the feature tags mailing list |
801 |
ietf-feature-tags@iana.org. This list does not exist at the |
802 |
present time and needs to be created. |
803 |
|
804 |
The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/" area |
805 |
does not exist at the present time and needs to be created. |
806 |
|
807 |
|
808 |
Expires: January 28, 1998 |
809 |
|