idnits 2.17.1 draft-ietf-conneg-feature-type-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Work-in-progress', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (4 April 2000) is 8781 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) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2068 (ref. '4') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '5') ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF conneg working group Graham Klyne 3 Internet draft Content Technologies 4 Category: Work-in-progress 4 April 2000 5 Expires: October 2000 7 MIME content types in media feature expressions 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society 2000. All Rights Reserved. 33 Abstract 35 In "A syntax for describing media feature sets", an expression 36 format is presented for describing media feature capabilities using 37 simple media feature tags. 39 This memo defines a media feature tag whose value is a MIME content 40 type. This allows the construction of feature expressions that 41 take account of the MIME content type of the corresponding data. 43 Internet draft MIME content types in media feature expressions 44 Table of contents 46 1. Introduction ............................................2 47 1.1 Terminology and document conventions 2 48 1.2 Discussion of this document 3 49 2. Motivation and goals ....................................4 50 3. MIME content type feature tag ...........................4 51 4. Examples ................................................5 52 4.1 Simple text 5 53 4.2 Fax image 5 54 4.3 Voice message 5 55 4.4 Web browser capabilities 6 56 5. IANA considerations .....................................6 57 6. Security considerations .................................6 58 7. Acknowledgements ........................................6 59 8. References ..............................................6 60 9. Author's address ........................................8 61 Appendix A: 'Type' feature tag registration ................8 62 Full copyright statement ...................................10 63 Revision history ...........................................11 65 1. Introduction 67 In "A syntax for describing media feature sets" [1], an expression 68 format is presented for describing media feature capabilities as a 69 combination of simple media feature tags, registered according to 70 "Media Feature Tag Registration Procedure" [2]. This provides a 71 format for message handling agents to describe the media feature 72 content of messages that they can handle. 74 This memo defines a media feature tag whose value is a MIME content 75 type. This allows the construction of feature expressions that 76 take account of the MIME content type of the corresponding data. 78 Note that a content type feature value may contain parameters, but 79 this is discouraged. See section 3 and appendix A "Summary of the 80 media features indicated" for discussion of this point. 82 1.1 Terminology and document conventions 84 This section defines a number of terms and other document 85 conventions, which are used with specific meaning in this memo. 87 media feature 88 information that indicates facilities assumed to be 89 available for the message content to be properly rendered 90 or otherwise presented. Media features are not intended 91 to include information that affects message transmission. 93 Internet draft MIME content types in media feature expressions 94 feature set 95 some set of media features described by a media feature 96 assertion, as described in "A syntax for describing media 97 feature sets" [1]. (See that memo for a more formal 98 definition of this term.) 100 feature set expression 101 a string that describes some feature set, formulated 102 according to the rules in "A syntax for describing media 103 feature sets" [1] (and possibly extended by other 104 specifications). 106 This specification uses syntax notation and conventions described 107 in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3]. 109 NOTE: Comments like this provide additional nonessential 110 information about the rationale behind this document. 111 Such information is not needed for building a conformant 112 implementation, but may help those who wish to understand 113 the design in greater depth. 115 1.2 Discussion of this document 117 Discussion of this document should take place on the content 118 negotiation and media feature registration mailing list hosted by 119 the Internet Mail Consortium (IMC): 121 Please send comments regarding this document to: 123 ietf-medfree@imc.org 125 To subscribe to this list, send a message with the body 'subscribe' 126 to "ietf-medfree-request@imc.org". 128 To see what has gone on before you subscribed, please see the 129 mailing list archive at: 131 http://www.imc.org/ietf-medfree/ 132 Internet draft MIME content types in media feature expressions 133 2. Motivation and goals 135 The media feature expression syntax [1] and feature tags [2] were 136 designed with a view to providing content media information that 137 augments basic MIME content type information. There are some 138 situations where it is useful to be able include that content type 139 information in a media feature expression: 141 o Media feature details may depend upon the content type being 142 used. The media feature combining algebra and syntax [1] cannot 143 apply to content type information unless it appears in the 144 feature expression. 146 For example, in HTTP 1.1 [4] with Transparent Content Negotiation 147 (TCN) [5] acceptable content types and other media features are 148 indicated in different request headers, with no clear way to 149 indicate that they may be acceptable only in certain 150 combinations. 152 o It is sometimes useful for all media capability information to be 153 included in a single expression. For example, DSN and MDN 154 extensions [6] that allow a recipient to indicate media 155 capabilities provide a single field for conveying this 156 information. 158 o When media features are used to describe a message content, they 159 may refer to inner parts of a MIME composite; e.g. the component 160 parts of a 'multipart', files in a compressed archive, or 161 encrypted message data. 163 3. MIME content type feature tag 165 Feature tag name Legal values 166 ---------------- ------------ 167 type 168 containing a MIME content-type value. 170 Reference: this document, appendix A. 172 The 'type' feature tag indicates a MIME media content type (i.e. 173 that appears in a 'Content-type:' header of the corresponding MIME- 174 formatted data). It must be a string of the form "type/subtype", 175 where 'type' and 'subtype' are defined by the MIME specification 176 [7]. Only lower-case letters should be used. 178 The content type must be given without any content-type parameter 179 values. 181 Internet draft MIME content types in media feature expressions 182 To include information in media feature expressions that is 183 otherwise conveyed in a MIME content-type parameter, a separate 184 media feature tag should be registered [2] and used in the media 185 feature expression. This is illustrated by the use of 'charset' in 186 the example at 4.1 below -- the 'charset' tag is defined by a 187 separate registration [10]. 189 NOTE: Allowing content-type parameters to be part of a 190 type tag value was considered, but rejected because of 191 concerns about canonicalization, ordering, case 192 sensitivity, etc. Only exact, case-sensitive, character 193 matching is defined for media feature expressions [1]. 195 4. Examples 197 4.1 Simple text 199 (& (type="text/plain") (charset=US-ASCII) 200 (color=binary) (paper-size=A4) ) 202 4.2 Fax image 204 (& (type="image/tiff") 205 (color=binary) 206 (image-file-structure=TIFF-S) 207 (dpi=200) 208 (dpi-xyratio=[200/100,200/200]) 209 (paper-size=A4) 210 (image-coding=MH) (MRC-mode=0) 211 (ua-media=stationery) ) 213 4.3 Voice message 215 (& (type="multipart/voice-message") 216 (VPIM-version="3.0") 217 (audio-codec=[G726-32,GSM-610]) 218 (audio-file-structure=[None,WAV]) 219 (ua-terminal=mobile-handset) 220 (audio-channels=1) ) 222 NOTE: in this case, some media features apply to MIME 223 parts contained within the declared 'multipart/voice- 224 message' content type. The goal here is not so much to 225 mirror the MIME structure as to convey useful information 226 about the (possible) message content. 228 Internet draft MIME content types in media feature expressions 229 4.4 Web browser capabilities 231 (& (pix-x<=800) (pix-y<=600) 232 (| (& (type="text/html") (charset=iso-8859-1) 233 (color=limited) ) 234 (& (type="text/plain") (charset=US-ASCII) ) 235 (& (type="image/gif") (color=mapped)) 236 (& (type="image/jpeg") (color=full) ) ) ) 238 This example describes an HTML viewer that can deal with a limited 239 number of color text tags, a gif viewer that supports mapped color, 240 and a jpeg viewer that supports color. 242 5. IANA considerations 244 Appendix A of this document calls for registration of a feature tag 245 in the "IETF tree", as defined in section 3.1.1 of "Media Feature 246 Tag Registration Procedure" [2] (i.e. these feature tags are 247 subject to the "IETF Consensus" policies described in RFC 2434 248 [9]). 250 An ASN.1 identifier should be assigned for this registered feature 251 tag and replaced in the body of the registration. 253 6. Security considerations 255 This memo is not believed to introduce any security considerations 256 that are not already inherent in the use of media feature tags and 257 expressions [1,2]. 259 7. Acknowledgements 261 This proposal draws from discussions in the IETF 'conneg' working 262 group. The voice message example is based on some ideas by Glen 263 Parsons. 265 The author would like to thank the following people who offered 266 comments that led to significant improvements: Ted Hardie, Larry 267 Masinter, Paul Hoffman, Jacob Palme, Ned Freed. 269 8. References 271 [1] RFC 2533, "A syntax for describing media feature sets" 272 Graham Klyne, 5GM/Content Technologies 273 March 1999. 275 Internet draft MIME content types in media feature expressions 276 [2] RFC 2506, "Media Feature Tag Registration Procedure" 277 Koen Holtman, TUE 278 Andrew Mutz, Hewlett-Packard 279 Ted Hardie, NASA 280 March 1999. 282 [3] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 283 D. Crocker (editor), Internet Mail Consortium 284 P. Overell, Demon Internet Ltd. 285 November 1997. 287 [4] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 288 R. Fielding, UC Irvine 289 J. Gettys, 290 J. Mogul, DEC 291 H. Frytyk, 292 T. Berners-Lee, MIT/LCS 293 January 1997. 294 (Non-normative) 296 [5] RFC 2295, "Transparent Content Negotiation in HTTP" 297 Koen Holtman, TUE 298 Andrew Mutz, Hewlett Packard 299 March 1998. 300 (Non-normative) 302 [6] RFC 2530, "Indicating Supported Media Features Using Extensions 303 to DSN and MDN" 304 Dan Wing, Cisco Systems 305 March 1999. 306 (Non-normative) 308 [7] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 309 Part 1: Format of Internet message bodies" 310 N. Freed, Innosoft 311 N. Borenstein, First Virtual 312 November 1996. 314 [8] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 315 Part 2: Media types" 316 N. Freed, Innosoft 317 N. Borenstein, First Virtual 318 November 1996. 320 [9] RFC 2434, "Guidelines for Writing an IANA Considerations Section 321 in RFCs" 322 T. Narten, IBM 323 H. Alvestrand, Maxware 324 October 1998. 326 Internet draft MIME content types in media feature expressions 327 [10] "Registration of Charset and Languages Media Features Tags" 328 Paul Hoffman, IMC 329 Internet draft: 330 Work in progress, July 1999. 331 (Non-normative) 333 9. Author's address 335 Graham Klyne 336 Content Technologies Ltd. 337 1220 Parkview, 338 Arlington Business Park 339 Theale 340 Reading, RG7 4SA 341 United Kingdom. 342 Telephone: +44 118 930 1300 343 Facsimile: +44 118 930 1301 344 E-mail: GK@ACM.ORG 346 Appendix A: 'Type' feature tag registration 348 - Media Feature tag name(s): 350 Type 352 - ASN.1 identifier associated with this feature tag: 354 [[[New assignment by IANA]]] 356 - Summary of the media features indicated: 358 This feature tag indicates a MIME content type that a message 359 agent is capable of handling, or that is contained within some 360 message data. 362 The content type consists of the MIME media type and subtype, 363 presented using all lower case letters and with any whitespace 364 characters removed. 366 - Values appropriate for use with this feature tag: 368 String 370 - The feature tag is intended primarily for use in the following 371 applications, protocols, services, or negotiation mechanisms: 373 Any application that wishes to convey MIME content type 374 information in a media feature expression. 376 Internet draft MIME content types in media feature expressions 377 - Examples of typical use: 379 (type="image/tiff") 381 (& (type="text/plain") (charset=US-ASCII) ) 383 - Related standards or documents: 385 MIME, RFC 2045 [7] 387 MIME, RFC 2046 [8] 389 Registration of Charset and Languages Media Features Tags [10] 391 - Considerations particular to use in individual applications, 392 protocols, services, or negotiation mechanisms: 394 (N/A) 396 - Interoperability considerations: 398 String feature matching is case sensitive, so consistent use of 399 case for content type values and parameters is essential if 400 content type value matching is to be achieved in a fashion 401 consistent with MIME content type matching. 403 Similarly, white space must be used consistently. 405 This registration specifies a canonical form to be used for 406 content type values (lower case letters and remove all 407 whitespace). 409 - Related feature tags: 411 (N/A) 413 - Intended usage: 415 Common 417 - Author/Change controller: 419 IETF 420 Internet draft MIME content types in media feature expressions 421 Full copyright statement 423 Copyright (C) The Internet Society 2000. All Rights Reserved. 425 This document and translations of it may be copied and furnished to 426 others, and derivative works that comment on or otherwise explain 427 it or assist in its implementation may be prepared, copied, 428 published and distributed, in whole or in part, without restriction 429 of any kind, provided that the above copyright notice and this 430 paragraph are included on all such copies and derivative works. 431 However, this document itself may not be modified in any way, such 432 as by removing the copyright notice or references to the Internet 433 Society or other Internet organizations, except as needed for the 434 purpose of developing Internet standards in which case the 435 procedures for copyrights defined in the Internet Standards process 436 must be followed, or as required to translate it into languages 437 other than English. 439 The limited permissions granted above are perpetual and will not be 440 revoked by the Internet Society or its successors or assigns. 442 This document and the information contained herein is provided on 443 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 444 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 445 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Internet draft MIME content types in media feature expressions 450 Revision history 452 [[[RFC editor: please reove this section on publication]]] 454 00a 16-Feb-1999 Initial draft. 456 01a 16-Feb-1999 Added pointers to mailing list for discussion. 458 01b 04-Mar-1999 Various editorial improvements. 460 01c 29-Apr-1999 Improved web browser example. 462 02a 29-Apr-1999 Highlight and forward reference the content-type 463 parameter issue in the introduction. 465 02b 20-Jul-1999 Incorporate review comments. Also cite charset 466 feature type registration work-in-progress. 468 02c 14-Nov-1999 Fix RFC 2533 number in references. 470 02d 30-Nov-1999 Add note about 'charset' feature tag to 471 registration template. Moved copyright notice to 472 end of document text. 474 03a 04-Apr-2000 Restrict type tag value to content-type, without 475 parameters. Add text explaining how to deal with 476 content-type parameters in media feature 477 expressions.