idnits 2.17.1 draft-ietf-conneg-feature-type-01.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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 (29 April 1999) is 9121 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 2253 (ref. '1') (Obsoleted by RFC 4510, RFC 4514) ** 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) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF conneg working group Graham Klyne 2 Internet draft 5GM/Content Technologies 3 Category: Work-in-progress 29 April 1999 4 Expires: October 1999 6 MIME content types in media feature expressions 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society 1999. All Rights Reserved. 35 Abstract 37 In "A syntax for describing media feature sets", an expression 38 format is presented for describing media feature capabilities using 39 simple media feature tags. 41 This memo defines a media feature tag whose value is a MIME content 42 type. This allows the construction of feature expressions that 43 take account of the MIME content type of the corresponding data. 45 Internet draft MIME content types in media feature expressions 47 Table of contents 49 1. Introduction ............................................2 50 1.1 Terminology and document conventions 2 51 1.2 Discussion of this document 3 52 2. Motivation and goals ....................................3 53 3. MIME content type feature tag ...........................4 54 4. Examples ................................................5 55 4.1 Simple text 5 56 4.2 Fax image 5 57 4.3 Voice message 5 58 4.4 Web browser capabilities 5 59 5. IANA considerations .....................................6 60 6. Security considerations .................................6 61 7. Full copyright statement ................................6 62 8. Acknowledgements ........................................6 63 9. References ..............................................7 64 10. Author's address .......................................8 65 Appendix A: 'Type' feature tag registration ................9 66 Appendix B: Revision history ...............................10 68 1. Introduction 70 In "A syntax for describing media feature sets" [1], an expression 71 format is presented for describing media feature capabilities as a 72 combination of simple media feature tags, registered according to 73 "Media Feature Tag Registration Procedure" [2]. This provides a 74 format for message handling agents to describe the media feature 75 content of messages that they can handle. 77 This memo defines a media feature tag whose value is a MIME content 78 type. This allows the construction of feature expressions that 79 take account of the MIME content type of the corresponding data. 81 1.1 Terminology and document conventions 83 This section defines a number of terms and other document 84 conventions, which are used with specific meaning in this memo. 86 media feature 87 information that indicates facilities assumed to be 88 available for the message content to be properly rendered 89 or otherwise presented. Media features are not intended 90 to include information that affects message transmission. 92 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/ 133 Internet draft MIME content types in media feature expressions 135 2. Motivation and goals 137 The media feature expression syntax [1] and feature tags [2] were 138 designed with a view to providing content media information that 139 augments basic MIME content type information. There are some 140 situations where it is useful to be able include that content type 141 information in a media feature expression: 143 o Media feature details may depend upon the content type being 144 used. The media feature combining algebra and syntax [1] cannot 145 be apply to content type information unless it appears in the 146 feature expression. 148 For example, in HTTP 1.1 [4] with Transparent Content Negotiation 149 (TCN) [5] acceptable content types and other media features are 150 indicated in different request headers, with no clear way to 151 indicate that they may be acceptable only in certain 152 combinations. 154 o It is sometimes useful for all media capability information to be 155 included in a single expression. For example, DSN and MDN 156 extensions [6] that allow a recipient to indicate media 157 capabilities provide a single field for conveying this 158 information. 160 o When media features are used to describe a message content, they 161 may refer to inner parts of a MIME composite; e.g. the component 162 parts of a 'multipart', files in a compressed archive, or 163 encrypted message data. 165 3. MIME content type feature tag 167 Feature tag name Legal values 168 ---------------- ------------ 169 type 170 containing any MIME content type value. 172 Reference: this document, appendix A. 174 The 'type' feature tag indicates a MIME media content type (i.e. 175 that appears in a 'Content-type:' header in the corresponding MIME- 176 formatted data). 178 The media type should be given without any parameter values. The 179 intention here is that information that is conveyed in MIME content 180 type parameters is more usefully handled in a media feature 181 expression by separate feature tags. 183 Internet draft MIME content types in media feature expressions 184 NOTE: content type parameters in a 'type' value are 185 strongly discouraged, but not prohibited. In deciding 186 whether or not to include a parameter value, implementers 187 should bear in mind the feature set matching rules [1]. 188 These would cause 'type' values with and without 189 parameters to be treated as completely distinct values, 190 which may lead to unexpected results. 192 4. Examples 194 4.1 Simple text 196 (& (type="text/plain") (color=binary) (paper-size=A4) ) 198 4.2 Fax image 200 (& (type="image/tiff") 201 (color=binary) 202 (image-file-structure=TIFF-S) 203 (dpi=200) 204 (dpi-xyratio=[200/100,200/200]) 205 (paper-size=A4) 206 (image-coding=MH) (MRC-mode=0) 207 (ua-media=stationery) ) 209 4.3 Voice message 211 (& (type="multipart/voice-message") 212 (VPIM-version="3.0") 213 (audio-codec=[G726-32,GSM-610]) 214 (audio-file-structure=[None,WAV]) 215 (ua-terminal=mobile-handset) 216 (audio-channels=1) ) 218 NOTE: in this case, some media features apply to MIME 219 parts contained within the declared 'multipart/voice- 220 message' content type. The goal here is not so much to 221 mirror the MIME structure as to convey useful information 222 about the (possible) message content. 224 Internet draft MIME content types in media feature expressions 226 4.4 Web browser capabilities 228 (& (pix-x<=800) (pix-y<=600) 229 (| (& (type="text/html") (color=limited)) 230 (type="text/plain") 231 (& (type="image/gif") (color=mapped)) 232 (& (type="image/jpeg") (color=full)))) 234 This example describes an HTML viewer that can deal with a limited 235 number of color text tags, a gif viewer that supports mapped color, 236 and a jpeg viewer that supports color. 238 5. IANA considerations 240 Appendix A of this document calls for registrations of feature tags 241 in the "IETF tree", as defined in section 3.1.1 of "Media Feature 242 Tag Registration Procedure" [2] (i.e. these feature tags are 243 subject to the "IETF Consensus" policies described in RFC 2434 244 [9]). 246 ASN.1 identifiers should be assigned for each of these registered 247 feature tags and replaced in the body of the registration. 249 6. Security considerations 251 This memo is not believed to introduce any security considerations 252 that are not already inherent in the use of media feature tags and 253 expressions [1,2]. 255 7. Full copyright statement 257 Copyright (C) The Internet Society 1999. All Rights Reserved. 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain 261 it or assist in its implementation may be prepared, copied, 262 published and distributed, in whole or in part, without restriction 263 of any kind, provided that the above copyright notice and this 264 paragraph are included on all such copies and derivative works. 265 However, this document itself may not be modified in any way, such 266 as by removing the copyright notice or references to the Internet 267 Society or other Internet organizations, except as needed for the 268 purpose of developing Internet standards in which case the 269 procedures for copyrights defined in the Internet Standards process 270 must be followed, or as required to translate it into languages 271 other than English. 273 The limited permissions granted above are perpetual and will not be 274 revoked by the Internet Society or its successors or assigns. 276 Internet draft MIME content types in media feature expressions 277 This document and the information contained herein is provided on 278 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 279 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 280 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 8. Acknowledgements 286 This proposal draws from discussions in the IETF 'conneg' working 287 group. The voice message example is based on some ideas by Glen 288 Parsons. 290 The author would like to thank the following people who offered 291 comments that led to significant improvements: Ted Hardie, Larry 292 Masinter. 294 9. References 296 [1] RFC 2253, "A syntax for describing media feature sets" 297 Graham Klyne, 5GM/Content Technologies 298 March 1999. 300 [2] RFC 2506, "Media Feature Tag Registration Procedure" 301 Koen Holtman, TUE 302 Andrew Mutz, Hewlett-Packard 303 Ted Hardie, NASA 304 March 1999. 306 [3] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 307 D. Crocker (editor), Internet Mail Consortium 308 P. Overell, Demon Internet Ltd. 309 November 1997. 311 [4] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 312 R. Fielding, UC Irvine 313 J. Gettys, 314 J. Mogul, DEC 315 H. Frytyk, 316 T. Berners-Lee, MIT/LCS 317 January 1997. 319 [5] RFC 2295, "Transparent Content Negotiation in HTTP" 320 Koen Holtman, TUE 321 Andrew Mutz, Hewlett Packard 322 March 1998. 324 Internet draft MIME content types in media feature expressions 326 [6] RFC 2530, "Indicating Supported Media Features Using Extensions 327 to DSN and MDN" 328 Dan Wing, Cisco Systems 329 March 1999. 331 [7] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 332 Part 1: Format of Internet message bodies" 333 N. Freed, Innosoft 334 N. Borenstein, First Virtual 335 November 1996. 337 [8] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 338 Part 2: Media types" 339 N. Freed, Innosoft 340 N. Borenstein, First Virtual 341 November 1996. 343 [9] RFC 2434, "Guidelines for Writing an IANA Considerations Section 344 in RFCs" 345 T. Narten, IBM 346 H. Alvestrand, Maxware 347 October 1998. 349 10. Author's address 351 Graham Klyne 352 5th Generation Messaging Ltd. Content Technologies Ltd. 353 5 Watlington Street Forum 1, Station Road 354 Nettlebed Theale 355 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 356 United Kingdom United Kingdom. 357 Telephone: +44 1491 641 641 +44 118 930 1300 358 Facsimile: +44 1491 641 611 +44 118 930 1301 359 E-mail: GK@ACM.ORG 361 Internet draft MIME content types in media feature expressions 363 Appendix A: 'Type' feature tag registration 365 - Media Feature tag name(s): 367 Type 369 - ASN.1 identifiers associated with this feature tag: 371 [[[New assignments by IANA]]] 373 - Summary of the media features indicated: 375 This feature tag indicates a MIME content type that a message 376 agent is capable of handling, or contained within some message 377 data. 379 The content type consists of the MIME media type and subtype, 380 presented using all lower case letters and with any whitespace 381 characters removed. 383 In exceptional cases, content type parameters may be included, in 384 which case the parameter name is also presented in lower case 385 letters, with all whitespace surrounding the ';' and '=' removed. 386 The parameter value should be presented in some canonical form. 388 - Values appropriate for use with this feature tag: 390 String 392 - The feature tag is intended primarily for use in the following 393 applications, protocols, services, or negotiation mechanisms: 395 Any application that wishes to convey MIME content type 396 information in a media feature expression. 398 - Examples of typical use: 400 (type="text/plain") 401 (type="text/plain;charset=iso-8859-1") 403 The second example is not a recommended form. But note that all 404 spaces around the 'charset' parameter are removed, and the name 405 and value are presented in lower case. 407 - Related standards or documents: 409 MIME, RFC 2045 [7] 411 MIME, RFC 2046 [8] 413 Internet draft MIME content types in media feature expressions 415 - Considerations particular to use in individual applications, 416 protocols, services, or negotiation mechanisms: 418 (N/A) 420 - Interoperability considerations: 422 String feature matching is case sensitive, so consistent use of 423 case for content type values and parameters is essential if 424 content type value matching is to be achieved in a fashion 425 consistent with MIME content type matching. 427 Similarly, white space must be used consistently. 429 This registration specifies a canonical form to be used for 430 content type values (lower case letters and remove all 431 whitespace). If content type parameters are introduced, all 432 letters and whitespace that are not part of the parameter value 433 are treated similarly. The canonical form for parameter values 434 must be appropriate to the equivalence rules for that value. 436 - Related feature tags: 438 (N/A) 440 - Intended usage: 442 Common 444 - Author/Change controller: 446 IETF 448 Internet draft MIME content types in media feature expressions 450 Appendix B: Revision history 452 00a 16-Feb-1999 Initial draft. 454 01a 16-Feb-1999 Added pointers to mailing list for discussion. 456 01b 04-Mar-1999 Various editorial improvements. 458 01c 29-Apr-1999 Improved web browser example. 460 TODO: 462 o Discuss: should the feature syntax be extended to allow content 463 types to be "unstringed", hence providing more relaxed matching 464 rules?