idnits 2.17.1 draft-ietf-conneg-content-features-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 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 218: '... Implementations MUST NOT assume a one...' 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 8788 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 492, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 510, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 Indicating media features for MIME content 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 1999. 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 MIME 'Content-features:' header that can be 40 used to annotate a MIME message part using this expression format, 41 and indicates some ways it might be used. 43 Internet draft Indicating media features for MIME content 44 Table of contents 46 1. Introduction ............................................2 47 1.1 Terminology and document conventions 3 48 1.2 Discussion of this document 3 49 2. Motivation and goals ....................................4 50 3. The 'Content-features:' MIME header .....................4 51 3.1 Whitespace and folding long headers 4 52 3.2 Usage considerations 5 53 3.2.1 Simple message parts 5 54 3.2.2 Multipart and other composites 5 55 3.2.3 Reference to external data 6 56 4. Examples ................................................6 57 4.1 Simple message 6 58 4.2 Fax message 6 59 4.3 Multipart/alternative data 7 60 4.4 Reference to external message data 8 61 4.5 Compressed data 8 62 4.6 Multipart/related data 9 63 5. Security considerations .................................9 64 6. Acknowledgements ........................................10 65 7. References ..............................................10 66 8. Author's address ........................................12 67 Full copyright statement ...................................12 68 Revision history ...........................................13 70 1. Introduction 72 In "A syntax for describing media feature sets" [1], an expression 73 format is presented for describing media feature capabilities as a 74 combination of simple media feature tags, registered according to 75 "Media Feature Tag Registration Procedure" [2]. This provides a 76 format for message handling agents to describe the media feature 77 content of messages that they can handle. 79 This memo defines a MIME 'Content-features:' header that can be 80 used to annotate a MIME message part using these feature 81 expressions. This header provides a means to indicate media- 82 related features of message content that go beyond the MIME content 83 type. 85 Consideration is also given to how it may be used to present 86 message media content information that is problematic to express 87 within the basic MIME framework. 89 Internet draft Indicating media features for MIME content 90 1.1 Terminology and document conventions 92 This section defines a number of terms and other document 93 conventions, which are used with specific meaning in this memo. 95 media feature 96 information that indicates facilities assumed to be 97 available for the message content to be properly rendered 98 or otherwise presented. Media features are not intended 99 to include information that affects message transmission. 101 feature set 102 some set of media features described by a media feature 103 assertion, as described in "A syntax for describing media 104 feature sets" [1]. (See that memo for a more formal 105 definition of this term.) 107 feature set expression 108 a string that describes some feature set, formulated 109 according to the rules in "A syntax for describing media 110 feature sets" [1] (and possibly extended by other 111 specifications). 113 This specification uses syntax notation and conventions described 114 in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3]. 116 NOTE: Comments like this provide additional nonessential 117 information about the rationale behind this document. 118 Such information is not needed for building a conformant 119 implementation, but may help those who wish to understand 120 the design in greater depth. 122 1.2 Discussion of this document 124 Discussion of this document should take place on the content 125 negotiation and media feature registration mailing list hosted by 126 the Internet Mail Consortium (IMC): 128 Please send comments regarding this document to: 130 ietf-medfree@imc.org 132 To subscribe to this list, send a message with the body 'subscribe' 133 to "ietf-medfree-request@imc.org". 135 To see what has gone on before you subscribed, please see the 136 mailing list archive at: 138 http://www.imc.org/ietf-medfree/ 139 Internet draft Indicating media features for MIME content 140 2. Motivation and goals 142 It is envisaged that media feature labelling of message parts may 143 be used in the following ways: 145 o to supply more detailed media feature information about a message 146 content than can be provided by the 'Content-type:' header. 148 o to provide summary media feature information (possibly including 149 MIME content types) about the content of a composite MIME message 150 part (e.g. 'multipart' or 'message'), without having to open up 151 the inner content of the message. 153 o to supply media feature information about external data 154 referenced by a message part (e.g. 'message/external-body' MIME 155 type). This information would not be available by examination of 156 the message content. 158 o to describe the content of a message that is encrypted or encoded 159 using some application-specific file structure that hides the 160 content from a MIME processor. This information also would not 161 be generally available by examination of the message content. 163 3. The 'Content-features:' MIME header 165 A new header field is defined that extends the allowable formats 166 for 'optional-field' [4] with the following syntax: 168 optional-field =/ "Content-features" ":" Feature-expr 169 Feature-expr = filter ; See [1], section 4.1 171 where 'filter' is the media feature expression format defined by "A 172 syntax for describing media feature sets" [1]. 174 This header provides additional information about the message 175 content directly contained or indirectly referenced in the 176 corresponding MIME message part. 178 3.1 Whitespace and folding long headers 180 In some circumstances, media feature expressions can be very long. 182 According to "A syntax for describing media feature sets" [1], 183 whitespace is allowed between lexical elements of a media feature 184 expression. Further, RFC822/MIME [4,5] allows folding of long 185 headers at oints where whitespace appears to avoid lione length 186 restrictions. 188 Internet draft Indicating media features for MIME content 189 Therefore, it is recommended that whitespace is included as 190 permitted, especialy in long media feature expressions, to 191 facilitate the folding of headers by agents that do not otherwise 192 understand the syntax of this field. 194 3.2 Usage considerations 196 3.2.1 Simple message parts 198 When applied to a simple MIME message part, the header should 199 appear just once and is used to convey additional information about 200 the message part content that goes beyond that provided by the MIME 201 'Content-type:' header field. The 'Content-features:' header may 202 indicate a content type that is different than that given by the 203 MIME 'Content-type:' header. This is possible but not recommended 204 when applied to a non-composite body part: in any case, MIME 205 content type processing must be performed in accordance with the 206 'Content-type:' header. 208 NOTE: Once the message content has been delivered to an 209 application, it is possible that subsequent processing 210 may be affected by content type information indicated by 211 the media feature expression. See example 4.5 below. 213 3.2.2 Multipart and other composites 215 'Content-features:' headers may be applied to a MIME multipart 216 indicating information about the inner content of the multipart. 218 Implementations MUST NOT assume a one-to-one relationship between 219 'Content-features' headers and contained body parts. Headers may 220 appear on a containing multipart wrapper in a different order than 221 the body parts to which they refer; a single header may refer to 222 more than one contained body part; several headers may refer to 223 the same contained body part. 225 If it is important to relate specific media features to specific 226 contained MIME body parts, then the 'Content-features:' header 227 should be applied directly to the body part concerned, rather than 228 the surrounding composite. 230 NOTE: The intent here is to allow summary media feature 231 information to be provided without having to open up and 232 examine the inner content of the MIME message. 234 Similar usage may apply when the message format is a non-MIME or 235 opaque composite; e.g. 'application/zip', or an encrypted message. 236 In these cases, the option of examining the message content to 237 discover media feature information is not available. 239 Internet draft Indicating media features for MIME content 240 3.2.3 Reference to external data 242 Media feature information about data indirectly referenced by a 243 MIME body part rather than contained within message can be conveyed 244 using one or more 'Content-features:' headers. 246 For example, media information --including contained MIME content 247 type(s)-- about the data referenced by a MIME 'Message/external- 248 body' may be conveyed. 250 4. Examples 252 4.1 Simple message 254 Mime-Version: 1.0 255 Content-type: text/plain;charset=US-ASCII 256 Content-features: (& (paper-size=A4) (ua-media=stationery) ) 258 : 259 (data) 260 : 262 4.2 Fax message 264 Mime-Version: 1.0 265 Content-Type: multipart/mixed; boundary="break" 266 Content-features: 267 (& (Type="image/tiff") 268 (color=Binary) 269 (image-file-structure=TIFF-S) 270 (dpi=200) 271 (dpi-xyratio=200/100) 272 (paper-size=A4) 273 (image-coding=MH) (MRC-mode=0) 274 (ua-media=stationery) ) 276 --break 277 Content-Type: image/tiff; name="coverpage.tiff" 278 Content-Transfer-Encoding: base64 279 Content-Description: This part is a coverpage 280 Content-Disposition: attachment; filename="coverpage.tiff" 282 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA 283 AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD//////////////////// 284 : 285 (more data) 286 : 287 --break 288 Internet draft Indicating media features for MIME content 289 Content-Type: image/tiff; name="document.tiff" 290 Content-Transfer-Encoding: base64 291 Content-Disposition: attachment; filename="document.tiff" 293 AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg 294 GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA 295 : 296 (more data) 297 : 298 --break-- 300 4.3 Multipart/alternative data 302 This example illustrates three points: 304 o Information about the various parts in a multipart/alternative 305 can be made available before the alternative body parts are 306 processed. This may facilitiate optimum one-pass processing of 307 multipart/alternative data. 309 o There may be alternatives having the same basic MIME content- 310 type, but differing in the content features that they use. 312 o There is NO defined correspondence between Content-feature 313 headers and contained body parts. 315 Mime-Version: 1.0 316 Content-Type: multipart/alternative; boundary="break" 317 Content-features: (& (Type="text/plain") (charset=US-ASCII) ) 318 Content-features: 319 (& (Type="text/html") (charset=ISO-8859-1) (color=limited) ) 320 Content-features: 321 (& (Type="text/html") (charset=ISO-8859-1) (color=binary) ) 323 --break 324 Content-type: "text/plain";charset="US-ASCII" 325 Content-features: (color=binary) 327 : 328 (data) 329 : 330 --break 331 Content-type: "text/plain";charset="US-ASCII" 332 Content-features: (color=limited) 334 : 335 (data) 336 : 337 --break 338 Internet draft Indicating media features for MIME content 339 Content-type: text/html;charset="iso-8859-1" 340 Content-features: (color=binary) 342 : 343 (data) 344 : 345 --break 346 Content-type: text/html;charset="iso-8859-1" 347 Content-features: (color=limited) 349 : 350 (data) 351 : 352 --break-- 354 4.4 Reference to external message data 356 Mime-Version: 1.0 357 Content-type: message/external-body; access-type=URL; 358 URL="http://www.foo.com/file1.html" 360 Content-type: Multipart/mixed 361 Content-features: (& (Type="text/plain") (charset=US-ASCII) ) 362 Content-features: (& (Type="image/tiff") (color=limited) ) 364 366 4.5 Compressed data 368 This example shows how the "Content-features" header can be used to 369 overcome the problem noted in the MIME registration for 370 "Application/zip" regarding information about the data content. 372 Mime-Version: 1.0 373 Content-type: application/zip 374 Content-features: (& (Type="text/plain") (charset=US-ASCII) ) 375 Content-features: (& (Type="image/tiff") (color=limited) ) 376 Content-transfer-encoding: base64 378 : 379 (data) 380 : 381 382 Internet draft Indicating media features for MIME content 383 4.6 Multipart/related data 385 (See also: RFC 2387, "The MIME Multipart/Related Content-type" [8]) 387 Mime-Version: 1.0 388 Content-Type: multipart/related; boundary="boundary-example"; 389 type="text/html"; start="" 390 Content-features: (& (type="text/html") (charset=US-ASCII) ) 391 Content-features: (type="image/gif") 393 --boundary-example 394 Content-Type: text/html;charset="US-ASCII" 395 Content-ID: 397 ... text of the HTML document, which might contain a URI 398 referencing a resource in another body part, for example 399 through a statement such as: 400 IETF logo 403 --boundary-example 404 Content-Location: 405 http://www.ietf.cnri.reston.va.us/images/ietflogo.gif 406 Content-Type: IMAGE/GIF 407 Content-Transfer-Encoding: BASE64 409 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 410 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A 411 etc... 413 --boundary-example-- 415 5. Security considerations 417 When applied to simple or multipart MIME formatted data, a media 418 feature expression provides summary information about the message 419 data, which in many cases can be determined by examination of the 420 message content. Under these circumstances, no additional security 421 considerations appear to be raised. 423 When applied to other message composites, especially encrypted 424 message content, feature expressions may disclose information that 425 is otherwise unavailable. In these cases, some security 426 considerations associated with media content negotiation [1,2] may 427 have greater relevance. 429 Internet draft Indicating media features for MIME content 430 It is suggested here that media feature descriptions may be 431 usefully employed with encrypted message content. In doing this, 432 take care to ensure that the purpose of encryption is not 433 compromised (e.g. encryption might be intended to conceal the fact 434 that a particular application data format is being used, which fact 435 might be disclosed by an injudiciously applied Content-features 436 header). 438 If a 'Content-features' header is applied to a multipart/signed 439 object (or indeed outside any other form of signed data) the media 440 feature information is not protected. This unprotected information 441 could be tampered with, possibly fooling implementations into doing 442 inappropriate things with the contained material. (Putting the 443 media feature information inside the signed information would 444 overcome this, at the cost of requiring implementations to parse 445 the inner structure to find it.) 447 6. Acknowledgements 449 This proposal draws from discussions with Dan Wing. The fax 450 message example was taken from a proposal by Mike Ruhl. The 451 multipart/related example is developed from RFC 2557. 453 The author would like to thank the following people who offered 454 comments that led to significant improvements: Mr Hiroshi Tamura, 455 Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed. 457 7. References 459 [1] RFC 2533, "A syntax for describing media feature sets" 460 Graham Klyne, 5GM/Content Technologies 461 March 1999. 463 [2] RFC 2506, "Media Feature Tag Registration Procedure" 464 Koen Holtman, TUE 465 Andrew Mutz, Hewlett-Packard 466 Ted Hardie, NASA 467 March 1999. 469 [3] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 470 D. Crocker (editor), Internet Mail Consortium 471 P. Overell, Demon Internet Ltd. 472 November 1997. 474 Internet draft Indicating media features for MIME content 475 [4] RFC 822, "Standard for the format of ARPA Internet text messages" 476 D. Crocker, Department of Electrical Engineering, University of 477 Delaware 478 August 1982. 480 To be replaced by: 481 "Internet Message Format Standard" 482 P. Resnick (editor), QUALCOMM Incorporated 483 Internet draft: 484 Work in progress, January 1999. 486 [5] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 487 Part 1: Format of Internet message bodies" 488 N. Freed, Innosoft 489 N. Borenstein, First Virtual 490 November 1996. 492 [6] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 493 Part 2: Media types" 494 N. Freed, Innosoft 495 N. Borenstein, First Virtual 496 November 1996. 498 [7] RFC 2017, "Definition of the URL MIME External-Body Access-Type" 499 N. Freed, Innosoft 500 K. Moore, University of Tennessee 501 A. Cargille, WG Chair 502 October 1996 503 (Non-normative) 505 [8] RFC 2387, "The MIME Multipart/Related Content-type" 506 E. Levinson 507 August 1998 508 (Non-normative) 510 [9] "Registration of Charset and Languages Media Features Tags" 511 Paul Hoffman, IMC 512 Internet draft: 513 Work in progress, July 1999. 514 (Non-normative) 515 Internet draft Indicating media features for MIME content 516 8. Author's address 518 Graham Klyne 519 Content Technologies Ltd. 520 1220 Parkview, 521 Arlington Business Park 522 Theale 523 Reading, RG7 4SA 524 United Kingdom. 525 Telephone: +44 118 930 1300 526 Facsimile: +44 118 930 1301 527 E-mail: GK@ACM.ORG 529 Full copyright statement 531 Copyright (C) The Internet Society 1999. All Rights Reserved. 533 This document and translations of it may be copied and furnished to 534 others, and derivative works that comment on or otherwise explain 535 it or assist in its implementation may be prepared, copied, 536 published and distributed, in whole or in part, without restriction 537 of any kind, provided that the above copyright notice and this 538 paragraph are included on all such copies and derivative works. 539 However, this document itself may not be modified in any way, such 540 as by removing the copyright notice or references to the Internet 541 Society or other Internet organizations, except as needed for the 542 purpose of developing Internet standards in which case the 543 procedures for copyrights defined in the Internet Standards process 544 must be followed, or as required to translate it into languages 545 other than English. 547 The limited permissions granted above are perpetual and will not be 548 revoked by the Internet Society or its successors or assigns. 550 This document and the information contained herein is provided on 551 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 552 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 553 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Internet draft Indicating media features for MIME content 558 Revision history 560 [[[RFC editor: please remove this section on publication]]] 562 00a 10-Feb-1999 Initial draft. 564 01a 16-Feb-1999 Added pointers to mailing list for discussion. 566 01b 04-Mar-1999 Various editorial changes. Added placeholder for 567 multipart/related example. 569 01c 13-Apr-1999 Separated multipart/alternative and 570 message/external-body into separate examples. 571 Added example for compressed data. Added example 572 for multipart/related data. Updated references. 574 02a 20-Jul-1999 Incorporated review comments -- editorial changes. 576 02b 29-Nov-1999 Added (charset=...) to (type=text/*) examples. 577 Added citation to charset and language feature 578 registration document. 580 02c 29-Nov-1999 Indicated motivation for multipart/alternative 581 example. Moved copyright section to end of text. 583 03a 04-Apr-2000 Clarification of Content-feaures on outer wrapper 584 of a multipart. Recommend use of whitespace in 585 feature expressions to facilitate MIME header 586 wrapping. Add discussion of Content-features on 587 multipart/signed data.