idnits 2.17.1 draft-ietf-conneg-feature-reg-03.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-03-29) 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 579 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 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. == There are 1 instance 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2048 (ref. '1') (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '3') == Outdated reference: A later version (-05) exists of draft-ietf-conneg-media-features-00 == Outdated reference: A later version (-05) exists of draft-iesg-iana-considerations-04 ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2068 (ref. '7') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '9') Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CONNEG Working Group Koen Holtman, TUE 2 Internet-Draft Andrew Mutz, Hewlett-Packard 3 Expires: January, 1999 Ted Hardie, NASA/STX 4 July, 1998 6 Media Feature Tag Registration Procedure 8 draft-ietf-conneg-feature-reg-03.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), ftp.ietf.org (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 CONNEG 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 media 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 media feature identification and negotiation mechanisms 44 require a common vocabulary in order to positively identify media 45 features. A registration process and authority for media 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 media 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 media feature vocabulary. 54 TABLE OF CONTENTS 56 1 Introduction 58 2 Media feature tag definitions 59 2.1 Media feature tag purpose 60 2.2 Media feature tag syntax 62 3 Media 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 media feature tag list 69 3.3 IANA procedures for registering media 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 media 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 media feature identification and negotiation mechanisms 92 require a common vocabulary in order to positively identify media 93 features. A registration process and authority for media 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 media 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 media feature vocabulary. 102 This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT 103 and MAY according to usage described in [8]. 105 2 Media feature tag definitions 107 2.1 Media feature tag purpose 109 Media feature tags represent individual and simple characteristics 110 related to media capabilities or properties associated with the 111 resource to which they are applied. Examples of such features are: 113 * the color depth of the screen on which something is to be displayed 114 * the type of paper available in a printer 115 * the support of the `floating 5 dimensional tables' feature 116 * the fonts which are available to the recipient 117 * the capability to display graphical content 119 Each media feature tag identifies a single characteristic. 120 Values associated with a specific tag must use the data type 121 defined for that tag. The list of allowed data types is 122 presented below, in section 2.3. 124 Examples of media feature tags with values are: 126 * the width of a display in pixels per centimeter represented as an 127 integer value. 128 * a font available to a recipient, selected from an enumerated list. 129 * the version of a protocol composed of integers "i.j.k", defined as 130 either a value in an enumerated list or with a defined mapping to 131 make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, 132 assuming j<=9 and k<=9). 134 Further examples of media feature tags are defined in detail 135 elsewhere [4]. 137 Feature collections may be composed using a number of individual 138 feature tags [2]. Composition of feature collections is described 139 elsewhere [2]. Examples of feature collections requiring multiple 140 media feature tags are: 142 * teh set of all fonts used by a document 143 * the width and height of a display 144 * the combination of color depth and resolution a display can support 146 This registry presumes the availability of the MIME media type 147 registry, and MIME media types MUST NOT be re-registered as 148 media feature tags. Media feature tags which are currently in use by 149 individual protocols or applications MAY be registered with this 150 registry if they might be applied outside of their current domain. 152 The media feature tag namespace is not bound to a particular transport 153 protocol or capability exchange mechanism. The registry is limited, 154 however, to feature tags which express a capability or preference 155 related to how content is presented. Feature tags related to 156 other axes of negotiation are not appropriate for this registry. 157 Capability exchange mechanisms may, of course, be used to express 158 a variety of capabilities or preferences. 160 2.2 Media feature tag syntax 162 A media feature tag is a string consisting of one or more of the following 163 US-ASCII characters: uppercase letters, lowercase letters, digits, 164 colon (":"), slash ("/"), dot (".") percent ("%"), and dash 165 ("-"). Feature tags are case-insensitive. Dots are understood to 166 potentially imply heirarchy; a feature can be subtyped by describing 167 it as tree.feature.subfeature and by indicating this in the 168 registration. Tags should begin with an alphabetic character. 170 In ABNF [6], this may be represented as: 172 Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" ) 174 Registrants should take care to avoid creating tags which might 175 conflict with the creation of new registration trees; in general 176 this means avoiding tags which begin with an alphabetic character 177 followed by a dot. The current registration trees are described 178 in section 3 below. 180 2.3 Media feature tag values 182 The registry will initially support the use of the following data 183 types as tag values: 185 - signed integers 186 - rational numbers 187 - tokens, with equality relationship 188 - tokens, with defined ordering relationship 189 - strings, with standard (octet-by-octet) equality relationship 190 - strings, with defined equality and/or comparison relationship 192 "Token" here means the token data type as defined by [7], 193 which may be summarized as: 195 token = 1* 197 tspecials = "(" / ")" / "<" / ">" / "@" 198 / "," / ";" / ":" / "\" / <"> 199 / "/" / "[" / "]" / "?" / "=" 200 / "{" / "}" / SP / HT 202 At the time of registration, each tag must be associated with 203 a single data type. If that data type implies a defined 204 comparison or an ordering, the registrant must define the ordering 205 or comparison. For ordered tokens, this may be by full enumeration 206 of the tokens and their order or by reference to an ordering 207 mechanism. For defined comparisons, a full description of the 208 rules for comparison must be provided or included by reference. 210 Media feature tags related to spatial or temporal characteristics 211 must be registered with a single canonical unit. It is strongly 212 preferred that units be in the SI system; where current practice 213 has defined units in other systems (such as pixels per inch), 214 a conversion method to SI units must be provided. Conversion 215 methods should include a defined rounding practice. 217 2.3 ASN.1 identifiers for media feature tags 219 Certain protocols use ASN.1 identifiers rather than human-readable 220 representations for capability exchange. In order to allow both 221 systems to interoperate, registrants may provide an ASN.1 identifier 222 or ask that IANA assign an ASN.1 identifier during registration. 223 These identifiers are not required for registration, but may provide 224 assistance to those building gateways or other cross-protocol 225 systems. Note that ASN.1 identifiers assigned by IANA will be 226 treated as tokens, not as elements from which sub-delegated 227 identifiers may be created or derived. 229 3 Media feature tag registration 231 Media feature tags can be registered in several different registration 232 trees, with different requirements as discussed below. The 233 vocabulary for these requirements is taken from [5]. In general, a 234 feature tag registration proposal is circulated and reviewed in a 235 fashion appropriate to the tree involved. The feature tag is then 236 registered if the proposal is accepted. 238 Review of a feature tag in the URI tree is not required. 240 3.1 Registration trees 242 The following subsections define registration "trees", distinguished 243 by the use of faceted names (e.g., names of the form "tree.feature- 244 name"). 246 3.1.1 IETF tree 248 The IETF tree is intended for media feature tags of general interest 249 to the Internet Community, and proposals for these tags must meet 250 the "IETF Consensus" policies described in [5]. 252 Registration in the IETF tree requires approval by the IESG and 253 publication of the feature tag specification as an RFC. 254 Submissions for feature tag registration in the IETF tree can 255 originate in any WG of the IETF or as an individual submission 256 to the IESG. 258 Feature tags in the IETF tree normally have names that are not 259 explicitly faceted, i.e., do not contain period (".", full stop) 260 characters. 262 3.1.2 Global tree 264 Tags in the global tree will be distinguished by the leading facet 265 "g.". An organization may propose either a designation indicative 266 of the feature, (e.g., "g.blinktags") or a faceted designation 267 including the organization name (e.g., "g.organization.blinktags"). 268 Organizations which have registered media types under the MIME 269 vendor tree should use the same organizational name for media 270 feature tags if they propose a faceted designation. The acceptance 271 of the proposed designation is at the discretion of the IANA. 272 If the IANA believes that a designation needs clarification 273 it may request a new proposal from the proposing organization 274 or otherwise coordinate the development of an appropriate 275 designation. 277 Registrations of feature tags in the global tree must meet the 278 "Expert Review" policies described in [5]. In this case, 279 a designated area expert will review the proposed tag, consulting 280 with the members of a related mailing list. A registration may be 281 proposed for the global tree by anyone who has the need to allow for 282 communication on a particular capability or preference. 284 3.1.3 URI tree 286 A feature tag may be defined as a URI using the restricted character 287 set defined above. Feature tags in the URI tree are identified by the 288 leading facet "u.". The leading facet u. is followed by a URI [9] 289 which conforms to the character limitations specified in this 290 document. The author of the URI is assumed to be registration 291 authority regarding features defined and described by the content 292 of the URI. These tags are considered unregistered for the 293 purpose of this document. 295 3.1.4 Additional registration trees 297 From time to time and as required by the community, the IANA may, with 298 the advice and consent of the IESG, create new top-level registration 299 trees. These trees may be created for external registration and 300 management by (for example) well-known permanent bodies, such as 301 scientific societies for media feature types specific to the 302 sciences they cover. Establishment of these new trees will be 303 announced through RFC publication approved by the IESG. 305 3.2 Location of registered feature tag list 307 Feature tag registrations will be posted in the anonymous FTP 308 directory: 309 "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" 310 and all registered feature tags will be listed in the periodically 311 issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The 312 feature tag description and other supporting material may also be 313 published as an Informational RFC by sending it to 314 "rfc-editor@isi.edu". 316 3.3 IANA procedures for registering feature tags 318 The IANA will only register feature tags in the IETF tree in response 319 to a communication from the IESG stating that a given registration has 320 been approved. 322 Global tags will be registered by the IANA after review by a designated 323 expert. That review will serve to ensure that the tag meets the 324 technical requirements of this specification. 326 3.4 Registration template 328 To: ietf-media-feature-tags@iana.org (Media feature tags mailing list) 329 (or directly to iana@iana.org) 330 Subject: Registration of media feature tag XXXX 332 | Instructions are preceded by `|'. Some fields are optional. 334 Media feature tag name: 336 ASN.1 identifier associated with feature tag: [optional] 338 | To have IANA assign an ASN.1 identifier, 339 | use the value "New assignment by IANA" here. 341 Summary of the media feature indicated by this feature tag: 343 | Include a short (no longer than 4 lines) description or summary 344 | Examples: 345 | `Use of the xyzzy feature is indicated by ...' 346 | `Support of color display is indicated by ...' 347 | `Number of colors in a palette which can be defined ...' 349 Values appropriate for use with this feature tag: 351 [ ] 1. The feature tag is Boolean and may have values of 352 TRUE or FALSE. A value of TRUE indicates an available 353 capability. A value of FALSE indicates the capability 354 is not available. 356 | If you wish to indicate two mutually exclusive possiblities 357 | that cannot be expressed as the availability or lack of a 358 | capability, use a two-token list, rather than a Boolean value. 360 [ ] 2. The feature has an associated numeric or enumerated value. 362 For case 2: Indicate the data type of the value: 364 [ ] 2a. Signed Integer 365 [ ] 2b. Rational number 366 [ ] 2c. Token (equality relationship) 367 [ ] 2d. Token (ordered) 368 [ ] 2e. String (equality relationship) 369 [ ] 2f. String (defined comparison) 371 |IMPORTANT: You may only chose one of the above data types. 373 (Only for case 2) Detailed description of the feature value meaning, 374 and of the format and meaning of the feature tag values 375 for the alternative results. 377 | If you have selected 2d you must provide the ordering mechanism 378 | or a full and ordered enumeration of possible values. If you 379 | have selected 2f, you must provide a defintion of the comparison. 380 | Definitions by included reference must be to stable and readily 381 | available specifications: 382 | 383 | If the number of alternative results is small, you may 384 | enumerate the identifiers of the different results and describe 385 | their meaning. 386 | 387 | If there is a limited useful numeric range of result (2b, 2c), 388 | indicate the range. 389 | 390 | The identifiers of the alternative results could also be 391 | described by referring to another IANA registry, for example 392 | the paper sizes enumerated by the Printer MIB. 394 The feature tag is intended primarily for use in the following 395 applications, protocols, services, or negotiation mechanisms: 396 [optional] 398 | For applications, also specify the number of the first version 399 | which will use the tag, if applicable. 401 Examples of typical use: [optional] 403 Related standards or documents: [optional] 405 Considerations particular to use in individual applications, 406 protocols, services, or negotiation mechanisms: [optional] 408 Interoperability considerations: [optional] 410 Security considerations: 412 Privacy concerns, related to exposure of personal information: 414 Denial of service concerns related to consequences of specifying 415 incorrect values: 417 Other: 419 Additional information: [optional] 421 Keywords: [optional] 423 Related feature tags: [optional] 425 Related media types or data formats: [optional] 427 Related markup tags: [optional] 429 Name(s) & email address(es) of person(s) to contact for 430 further information: 432 Intended usage: 434 | one of COMMON, LIMITED USE or OBSOLETE 436 Author/Change controller: 438 Requested IANA publication delay: [optional] 440 | A delay may only be requested for final placement in the global 441 | or IETF trees, with a maximum of two months. Organizations 442 | requesting a registration with a publication delay should note 443 | that this delays only the official publication of the tag 444 | and does not prevent information on it from being disseminated 445 | by the members of the relevant mailing list. 447 Other information: [optional] 449 | Any other information that the author deems interesting may be 450 | added here. 452 4 Security considerations 454 Negotiation mechanisms reveal information about one party to other 455 parties. This may raise privacy concerns, and may allow a malicious 456 party to make better guesses about the presence of specific security 457 holes. 459 5 Acknowledgments 461 The details of the registration procedure in this document were 462 directly adapted from [1]. Much of the text in section 3 was 463 directly copied from this source. 465 The idea of creating a vocabulary of areas of media features, 466 maintained in a central open registry, is due to discussions on 467 extensible negotiation mechanisms [3] in the IETF HTTP working group. 469 The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, 470 Dan Wing, Jacob Palme, and Martin Duerst for their contributions 471 to discussions about media feature tag registration. 473 6 References 475 [1] N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail 476 Extensions (MIME) Part Four: Registration Procedures. RFC 2048, 477 BCP 13, Network Working Group, November 1996 479 [2] G. Klyne, An algebra for describing media feature sets, Internet 480 Draft: Work in progress 481 March 1998 483 [3] Holtman, K., et al, Transparent Content Negotiation in HTTP. 484 RFC 2295, Network Working Group, March 1998. 486 [4] Masinter, L., et al, "Media Features for Display, Print, and Fax", 487 Internet-Draft draft-ietf-conneg-media-features-00.txt, Work in 488 progress, March 1998. 490 [5] Norten, T., et al, "Guidelines for Writing an IANA Considerations 491 Section in RFCs", Internet Draft draft-iesg-iana-considerations-04.txt, 492 Work in progress, May 1998. 494 [6] Crocker, D., Ed., Augmented BNF for Syntax Specifications: ABNF. 495 RFC 2234, Network Working Group, November 1997. 497 [7] Fielding, R. et al, Hypertext Transfer Protocol -- HTTP/1.1. 498 RFC 2068, Network Working Group, January 1997. 500 [8] Bradner, S. Key words for use in RFCs to Indicate Requirement 501 Levels. RFC 2119, Network Working Group, March 1997. 503 [9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 504 1630, Network Working Group, June 1994. 506 7 Authors' addresses 508 Koen Holtman 509 Technische Universiteit Eindhoven 510 Postbus 513 511 Kamer HG 6.57 512 5600 MB Eindhoven (The Netherlands) 513 Email: koen@win.tue.nl 515 Andrew H. Mutz 516 Hewlett-Packard Company 517 11000 Wolfe Rd. 42UO 518 Cupertino CA 95014 USA 519 Fax +1 408 447 4439 520 Email: andy_mutz@hp.com 522 Edward Hardie 523 NASA/STX 524 MS 204-14 525 Moffett Field, CA 94035 USA 526 hardie@archimedes.nasa.gov 528 Appendix A: IANA and RFC editor to-do list 530 VERY IMPORTANT NOTE: This appendix is intended to communicate 531 various editorial and procedural tasks the IANA and the RFC 532 Editor should undertake prior to publication of this document 533 as an RFC. This appendix should NOT appear in the actual RFC 534 version of this document! 536 This document refers to the feature tags mailing list 537 ietf-media-feature-tags@iana.org. This list does not exist at the 538 present time and needs to be created. 540 The ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/ 541 area does not exist at the present time and needs to be created. 543 Expires: September 11, 1998