idnits 2.17.1 draft-ietf-conneg-feature-reg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 28 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 496 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 1998) is 9541 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-1543' on line 259 ** Obsolete normative reference: RFC 2048 (ref. '1') (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- No information found for draft-ietf-http-alternates - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-05) exists of draft-ietf-conneg-media-features-00 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group Koen Holtman, TUE 2 Internet-Draft Andrew Mutz, Hewlett-Packard 3 Expires: September 11, 1998 Ted Hardie, NASA 4 March 11, 1998 6 Content Feature Tag Registration Procedure 8 draft-ietf-conneg-feature-reg-00.txt 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Copyright (C) The Internet Society (1998). All Rights Reserved. 30 Distribution of this document is unlimited. Please send comments to the 31 MEDFREE working group at . Discussions of the 32 working group are archived at . 34 ABSTRACT 36 Recent Internet applications, such as the World Wide Web, tie 37 together a great diversity in data formats, client and server 38 platforms, and communities. This has created a need for content 39 feature descriptions and negotiation mechanisms in order to identify 40 and reconcile the form of information to the capabilities and 41 preferences of the parties involved. 43 Extensible content feature identification and negotiation mechanisms 44 require a common vocabulary in order to positively identify content 45 features. A registration process and authority for content features 46 is defined with the intent of sharing this vocabulary between 47 communicating parties. In addition, a URI tree is defined to enable 48 sharing of content feature definitions without registration. 50 This document defines a registration procedure which uses the 51 Internet Assigned Numbers Authority (IANA) as a central registry for 52 the content feature vocabulary. 54 TABLE OF CONTENTS 56 1 Introduction 58 2 Feature tag definitions 59 2.1 Feature tag purpose 60 2.2 Feature tag syntax 62 3 Feature tag registration 63 3.1 Registration trees 64 3.1.1 IETF tree 65 3.1.2 Global tree 66 3.1.3 URL tree 67 3.1.4 Additional registration trees 68 3.2 Location of registered feature tag list 69 3.3 IANA procedures for registering feature tags 70 3.4 Registration template 72 4 Security considerations 74 5 Acknowledgments 76 6 References 78 7 Authors' addresses 80 Appendix A: IANA and RFC editor to-do list 82 1 Introduction 84 Recent Internet applications, such as the World Wide Web, tie 85 together a great diversity in data formats, client and server 86 platforms, and communities. This has created a need for content 87 feature descriptions and negotiation mechanisms in order to identify 88 and reconcile the form of information to the capabilities and 89 preferences of the parties involved. 91 Extensible content feature identification and negotiation mechanisms 92 require a common vocabulary in order to positively identify content 93 features. A registration process and authority for content features 94 is defined with the intent of sharing this vocabulary between 95 communicating parties. In addition, a URI tree is defined to enable 96 sharing of content feature definitions without registration. 98 This document defines a registration procedure which uses the 99 Internet Assigned Numbers Authority (IANA) as a central registry for 100 the content feature vocabulary. 102 2 Feature tag definitions 104 2.1 Feature tag purpose 106 Content feature tags represent individual and simple dimensions of 107 feature capability. Examples of content features related to media 108 are: 110 * the color depth of the screen on which something is to be displayed 111 * the support of the `floating 5 dimensional tables' feature 112 * the type of paper available in a printer 113 * the fonts which are available to the recipient 114 * the capability to display graphical content 116 A feature tag identifies a single dimension of characteristic. Feature 117 tag values should be represented as(and must be representable or 118 isomorphic to) boolean, enumerated values, or numeric values. 119 Examples of feature tags are defined in detail elsewhere [4]. 121 Many features are not Boolean and require values to qualify them. 122 Examples of feature tags with values are: 123 * the width of a display in pixels represented as an integer value. 124 * the fonts available to a recipient as an enumerated list. 125 * the version of a protocol composed of integers "i.j.k", defined as 126 either a value in an enumerated list or isomorphic to the integer 127 numeric value ijk. 129 Complex features should be composed using a number of individual 130 content feature tags [2]. Composition of complex features is described 131 elsewhere [2]. Examples of complex features requiring multiple 132 feature tags are: 134 * the width and height of a display 135 * the combination of color depth and resolution a display can support 137 Features of content already described and registered (such as MIME 138 types) should not be registered again. 140 The feature tag namespace is not bound to a particular transport 141 protocol or capability exchange mechanism. There is no restriction on 142 the type of content feature which may be identified by a feature tag, 143 other than the intent of expressing a capability or a preference 144 regarding a presentation-related feature of content. Feature tags 145 indicating political or social context are not appropriate. 147 2.2 Feature tag syntax 149 A feature tag is a string consisting of one or more of the following 150 US-ASCII characters: uppercase letters, lowercase letters, digits, 151 colon (":"), slash ("/"), dot (".") and dash ("-"). Feature tags are 152 case-insensitive. Dots are understood to potentially imply heirarchy; 153 a feature can be subtyped by describing it as tree.feature.subfeature 154 and by indicating this in the feature registration. 156 A feature tag value is a string consisting of one or more of the 157 following US-ASCII characters: uppercase letters, lowercase letters, 158 digits, colon (":"), slash("/"), dot("."), and dash ("-"). Values are 159 case-insensitive. Feature tag values should be simple atomic values 160 of either enumerated or numeric form and must be isomorphic with 161 either enumerated or numeric values. The form of feature tag values 162 is indicated upon feature registration. 164 3 Feature tag registration 166 Feature tags can be registered in several different registration 167 trees, with different requirements as discussed below. In general, a 168 feature tag registration proposal is circulated and reviewed in a 169 fashion appropriate to the tree involved. The feature tag is then 170 registered if the proposal is accepted. Review of a feature tag 171 registration in the URI tree is not required. 173 3.1 Registration trees 175 The following subsections define registration "trees", distinguished 176 by the use of faceted names (e.g., names of the form "tree.feature- 177 name"). 179 3.1.1 IETF tree 181 The IETF tree is intended for feature tags of general interest to the 182 Internet Community. Registration in the IETF tree requires approval 183 by the IESG and publication of the feature tag specification an RFC. 184 Submissions for feature tag registration in the IETF tree can 185 originate in any WG of IETF. 187 Feature tags in the IETF tree normally have names that are not 188 explicitly faceted, i.e., do not contain period (".", full stop) 189 characters. 191 The "owner" of a feature tag in the IETF tree is assumed to be the 192 IETF itself. Modification or alteration of the specification requires 193 the same level of processing (e.g. standards track) required for the 194 initial registration. 196 3.1.2 Global tree 198 Tags in the global tree will be distinguished by the leading facet 199 "g.". That may be followed, at the discretion of the registration, by 200 either a designation indicative of the feature, (e.g., "g.blinktags") 201 or by an IANA-approved designation of the producer's name which is 202 then followed by a designation of the feature (e.g., 203 g.bigcompany.obscurefeature). 205 Registration of a new content feature tag in the global tree is 206 initiated by the submission of a registration proposal to IANA. The 207 global tree is intended for feature tags of general interest to the 208 Internet Community. Unlike registration in the IETF tree, 209 registration in the global tree does not imply or require approval by 210 the IESG. A registration may be placed in the global tree by anyone 211 who has the need to allow for communication on a particular capability 212 or preference. 214 If the creator of an Internet service or product introduces a new 215 content feature to the Internet Community, and if it is meaningful to 216 identify a content feature tag with it, the feature can be associated 217 with a feature tag by registration in the global tree. 219 Registration of a content feature tag does not in itself imply any 220 form of ownership or control of the underlying feature by the 221 originator of the registration. 223 The owner of "global" content feature tag is the person or entity 224 making the registration, or one to whom responsibility has been 225 transferred as described below. 227 While public exposure and review of feature tags to be registered in 228 the global tree is not required, using the ietf-feature-tags@iana.org 229 list for review is strongly encouraged to improve the quality of those 230 specifications. 232 3.1.3 URI tree 234 A feature tag may be defined as a URI using the restricted character 235 set defined above. Feature tags in the URI tree are identified by the 236 leading facet "u.". The author of the URI is assumed to be 237 registration authority regarding features defined and described by the 238 content of the URI. These tags are considered unregistered for the 239 purpose of this document. 241 3.1.4 Additional registration trees 243 From time to time and as required by the community, the IANA may, with 244 the advice and consent of the IESG, create new top-level registration 245 trees. These trees may be created for external registration and 246 management by (for example) well-known permanent bodies, such as 247 scientific societies for content feature types specific to the 248 sciences they cover. Establishment of these new trees will be 249 announced through RFC publication approved by the IESG. 251 3.2 Location of registered feature tag list 253 Feature tag registrations will be posted in the anonymous FTP 254 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/feature- tags/" 255 and all registered feature tags will be listed in the periodically 256 issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The 257 feature tag description and other supporting material may also be 258 published as an Informational RFC by sending it to "rfc- 259 editor@isi.edu" (please follow the instructions to RFC authors [RFC- 260 1543]). 262 3.3 IANA procedures for registering feature tags 264 The IANA will only register feature tags in the IETF tree in response 265 to a communication from the IESG stating that a given registration has 266 been approved. 268 Global tags will be registered by the IANA automatically and without 269 any formal review as long as the following minimal conditions are met: 271 (1) A feature tag must serve as an actual identifier of an area of 272 content feature or capability. 274 (2) A feature tag name must be unique, and must conform to the 275 syntax in section 2. 277 (3) An openly available description of the feature or capability is 278 minimally required. The specification of a feature tag must 279 state whether the choice in the indicated area is a simple yes/no 280 choice, a numeric value, or a choice among enumerated or multiple 281 values. If the choice is among multiple values, and a canonical 282 format for these values is defined, these values must conform to 283 the syntax in section 2. 285 (4) Any security considerations given must not be obviously bogus. 286 (It is neither possible nor necessary for the IANA to conduct a 287 comprehensive security review of feature tag registrations. 288 Nevertheless, the IANA has the authority to identify obviously 289 incompetent material and exclude it.) 291 3.4 Registration template 293 To: ietf-feature-tags@iana.org (Feature tags mailing list) 294 (or directly to iana@iana.org) 295 Subject: Registration of feature tag XXXX 297 | Instructions are preceded by `|'. Some fields are optional. 299 Content feature tag name: 301 Summary of the content feature indicated by this feature tag: 303 | Include a short (no longer than 4 lines) description or summary 304 | Examples: 305 | `Use of the xyzzy feature is indicated by ...' 306 | `Support of color display is indicated by ...' 307 | `Number of colors in a palette which can be defined ...' 309 Number of possible values associated with this feature tag: 311 [ ] 1. The feature tag is Boolean and the feature tag has no 312 associated value. The tag indicates presence (or absence) of 313 the feature. 314 [ ] 2. The feature has an associated numeric or enumerated value. 316 For case 1: describe the nature of the `yes' and `no' alternatives: 318 For case 2: How is a single alternative result naturally identified? 320 [ ] 2a. With a name, keyword, label, or tag (e.g. a language tag) 321 [ ] 2b. With an integer value 322 [ ] 2c. With a numeric value of a non-integer type (e.g. float) 323 [ ] 2d. Other (must be isomorphic to 2a, 2b, or 2c.) 325 (Only for case 2) Detailed description of the feature value meaning, 326 and of the format (for 2a,2d) and meaning of the feature tag values 327 for the alternative results: 329 | If the number of alternative results is small, the description 330 | could simply enumerate the identifiers of the different results 331 | and describe their meaning. 332 | 333 | If there is a limited useful numeric range of result (2b, 2c), 334 | indicate the range. 335 | 336 | The identifiers of the alternative results could also be 337 | described by referring to another IANA registry, for example 338 | the MIME media type registry. 340 Expected value or behavior in the absence of the feature tag (if 341 applicable): 343 The feature tag is intended primarily for use in the following 344 applications, protocols, services, or negotiation mechanisms: 345 [optional] 347 | For applications, also specify the number of the first version 348 | which will use the tag, if applicable. 350 Examples of typical use: [optional] 352 Related standards or documents: [optional] 354 Considerations particular to use in individual applications, 355 protocols, services, or negotiation mechanisms: [optional] 357 Interoperability considerations: [optional] 359 Security considerations: 361 Privacy concerns, related to exposure of personal information: 363 Denial of service concerns related to consequences of specifying 364 incorrect values: 366 Other: 368 Additional information: [optional] 370 Keywords: [optional] 372 Related feature tags: [optional] 374 Related media types or data formats: [optional] 376 Related HTML markup tags: [optional] 378 Person & email address to contact for further information: 380 Intended usage: 382 | one of COMMON, LIMITED USE or OBSOLETE 384 Author/Change controller: 386 Requested IANA publication delay: [optional] 388 | A delay may only be requested for registration in global or 389 | local trees, with a maximum of two months. 391 Other information: [optional] 393 | Any other information that the author deems interesting may be 394 | added here. 396 4 Security considerations 398 When used, negotiation mechanisms usually reveal some information 399 about one party to other parties. This may raise privacy concerns, 400 and may allow a malicious party to make more educated guesses about 401 the presence of security holes in the other party. 403 5 Acknowledgments 405 The details of the registration procedure in this document were 406 directly adapted from [1]. Much of the text in section 3 was 407 directly copied from this source. 409 The idea of creating a vocabulary of areas of content features, 410 maintained in a central open registry, is due to discussions on 411 extensible negotiation mechanisms [3] in the IETF HTTP working group. 412 The authors wish to thank Ted Hardie, Larry Masinter and Graham Klyne 413 for contributing to discussions about feature tag registration. 415 6 References 417 [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail 418 Extensions (MIME) Part Four: Registration Procedures. RFC 2048, 419 BCP 13, Network Working Group, November 1996 421 [2] G. Klyne, An algebra for describing media feature sets, Internet 422 Draft: Work in progress 423 March 1998 425 [3] Holtman, K., et al, "The Alternates Header Field", Internet-Draft 426 draft-ietf-http-alternates-01.txt, Work in progress, November 1997. 428 [4] Masinter, L., et al, "Media Features for Display, Print, and Fax", 429 Internet-Draft draft-ietf-conneg-media-features-00.txt, Work in 430 progress , March 1998. 432 7 Authors' addresses 434 Koen Holtman 435 Technische Universiteit Eindhoven 436 Postbus 513 437 Kamer HG 6.57 438 5600 MB Eindhoven (The Netherlands) 439 Email: koen@win.tue.nl 441 Andrew H. Mutz 442 Hewlett-Packard Company 443 11000 Wolfe Rd. 42UO 444 Cupertino CA 95014 USA 445 Fax +1 408 447 4439 446 Email: andy_mutz@hp.com 448 Edward Hardie 449 NASA NIC 450 hardie@nic.nasa.gov 452 Appendix A: IANA and RFC editor to-do list 454 VERY IMPORTANT NOTE: This appendix is intended to communicate 455 various editorial and procedural tasks the IANA and the RFC 456 Editor should undertake prior to publication of this document 457 as an RFC. This appendix should NOT appear in the actual RFC 458 version of this document! 460 This document refers to the feature tags mailing list 461 ietf-feature-tags@iana.org. This list does not exist at the 462 present time and needs to be created. 464 The ftp://ftp.isi.edu/in-notes/iana/assignments/feature-tags/" 465 area does not exist at the present time and needs to be created. 467 Expires: September 11, 1998