idnits 2.17.1 draft-ietf-conneg-content-features-00.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? ** 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 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 (15 February 1999) is 9195 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) == Unused Reference: '5' is defined on line 370, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 376, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) Summary: 9 errors (**), 0 flaws (~~), 4 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 5GM/Content Technologies 4 Category: Work-in-progress 15 February 1999 5 Expires: August 1999 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 15 February 1999 46 Table of contents 48 1. Introduction ............................................2 49 1.1 Terminology and document conventions 3 50 2. Motivation and goals ....................................3 51 3. The 'Content-features:' MIME header .....................4 52 3.1 Usage considerations 4 53 3.1.1 Simple message parts 4 54 3.1.2 Multipart and other composites 4 55 3.1.3 Reference to external data 5 56 4. Examples ................................................5 57 4.1 Simple message 5 58 4.2 Fax message 6 59 4.3 Reference to external message data 6 60 4.4 Compressed data 6 61 5. Security considerations .................................7 62 6. Full copyright statement ................................7 63 7. Acknowledgements ........................................8 64 8. References ..............................................8 65 9. Author's address ........................................9 66 Appendix A: Revision history ...............................9 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 MIME 'Content-features:' header that can be 78 used to annotate a MIME message part using these feature 79 expressions. This header provides a means to indicate media- 80 related features of message content that go beyond the MIME content 81 type. 83 Along with the new MIME header definition, consideration is also 84 given to how it may be used to present message media content 85 information that is problematic to express within the basic MIME 86 framework. 88 Internet draft Indicating media features for MIME content 89 15 February 1999 91 1.1 Terminology and document conventions 93 This section defines a number of terms and other document 94 conventions, which are used with specific meaning in this memo. 95 The terms are listed in alphabetical order. 97 feature set 98 some set of media features described by a media feature 99 assertion, as described in "A syntax for describing media 100 feature sets" [1]. (See that memo for a more formal 101 definition of this term.) 103 feature set expression 104 a string that describes some feature set, formulated 105 according to the rules in "A syntax for describing media 106 feature sets" [1] (and possibly extended by other 107 specifications). 109 media feature 110 information that indicates facilities assumed to be 111 available for the message content to be properly rendered 112 or otherwise presented. Media features are not intended 113 to include information that affects message transmission. 115 This specification uses syntax notation and conventions described 116 in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3]. 118 NOTE: Comments like this provide additional nonessential 119 information about the rationale behind this document. 120 Such information is not needed for building a conformant 121 implementation, but may help those who wish to understand 122 the design in greater depth. 124 2. Motivation and goals 126 It is envisaged that media feature labelling of message parts may 127 be used in the following ways: 129 o to supply more detailed media feature about a message content 130 than can be provided by the 'Content-type:' header. 132 o to provide summary media feature information (possibly including 133 MIME content types) about the content of a composite MIME message 134 part (e.g. 'multipart' or 'message'), without having to open up 135 the inner content of the message. 137 o to supply media feature information about external data 138 referenced by a message part (e.g. 'message/external-body' MIME 139 type). This information would not be available by examination of 140 the message content. 142 Internet draft Indicating media features for MIME content 143 15 February 1999 145 o to describe the content of a message that is encrypted or encoded 146 using some application-specific file structure that hides the 147 content from a MIME processor. This information also would not 148 be generally available by examination of the message content. 150 [[[I am assuming that a new feature tag will be registered to carry 151 MIME content-type information in a media feature expression]]]. 153 3. The 'Content-features:' MIME header 155 A new header field is defined that extends the allowable formats 156 for 'optional-field' [4] with the following syntax: 158 optional-field =/ "Content-features" ":" Feature-expr 159 Feature-expr = filter ; See [1], section 4.1 161 where 'filter' is the media feature expression format defined by "A 162 syntax for describing media feature sets" [1]. 164 This header provides additional information about the message 165 content directly contained or indirectly referenced in the 166 corresponding MIME message part. 168 3.1 Usage considerations 170 3.1.1 Simple message parts 172 When applied to a simple MIME message part, the header should 173 appear just once and is used to convey additional information about 174 the message part content that goes beyond that provided by the MIME 175 'Content-type:' header field.The 'Content-features:' header may 176 suggest a content type that is different than that given by the 177 MIME 'Content-type:' header. This is possible but not recommended: 178 In such cases, MIME content type processing must be performed in 179 accordance with the MIME 'Content-type:' header. 181 NOTE: Once the message content has been delivered to an 182 application, it is possible that subsequent processing 183 may be affected by content type information indicated by 184 the media feature expression. 186 3.1.2 Multipart and other composites 188 'Content-features:' headers may be applied to a MIME multipart 189 indicating information about the inner content of the multipart. 190 No one-to-one relationship between headers and contained body parts 191 is assumed. 193 Internet draft Indicating media features for MIME content 194 15 February 1999 196 If it is important to relate specific media features to specific 197 MIME body parts, then the 'Content-features:' header should be 198 applied directly to the body part concerned, rather than the 199 surrounding composite. 201 NOTE: The intent here is to allow summary media feature 202 information to be provided without having to open up and 203 examine the inner content of the MIME message. 205 Similar usage may apply when the message format is a non-MIME or 206 opaque composite; e.g. 'application/zip', or an encrypted message. 207 In these cases, the option of examining the message content to 208 discover media feature information is not available. 210 3.1.3 Reference to external data 212 Media feature information about data indirectly referenced by a 213 MIME body part rather than contained within message can be conveyed 214 using one or more 'Content-features:' headers. 216 For example, media information --including MIME content type(s)-- 217 about the data referenced by a MIME 'Message/external-body' may be 218 conveyed. 220 4. Examples 222 4.1 Simple message 224 Mime-Version: 1.0 225 Content-type: text/plain 226 Content-features: 227 (& (paper-size=A4) 228 (ua-media=stationery) ) 230 : 231 (data) 232 : 234 Internet draft Indicating media features for MIME content 235 15 February 1999 237 4.2 Fax message 239 Mime-Version: 1.0 240 Content-type: multipart/fax-message;boundary=break 241 Content-features: 242 (& (Type=image/tiff) 243 (color=Binary) 244 (image-file-structure=TIFF-S) 245 (dpi=200) 246 (dpi-xyratio=[200/100,200/200]) 247 (paper-size=A4) 248 (image-coding=MH) (MRC-mode=0) 249 (ua-media=stationery) ) 251 --break 252 Content-Type: image/tiff; fax-coverpage=yes;name="coverpage.tiff" 253 Content-Transfer-Encoding: base64 254 Content-Description: This part is a coverpage 255 Content-Disposition: attachment; filename="coverpage.tiff" 257 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB 258 AAAAAQAAAAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD///////////// 259 : 260 (more data) 261 : 262 --break 263 Content-Type: image/tiff; name="document.tiff" 264 Content-Transfer-Encoding: base64 265 Content-Disposition: attachment; filename="document.tiff" 267 AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA 268 AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA 269 : 270 (more data) 271 : 272 --break-- 274 4.3 Reference to external message data 276 [[[TODO]]] 278 4.4 Compressed data 280 [[[TODO]]] 282 Internet draft Indicating media features for MIME content 283 15 February 1999 285 5. Security considerations 287 When applied to simple or multipart MIME formatted data, a media 288 feature expression provides summary information about the message 289 data, which in many cases can be determined by examination of the 290 message content. Under these circumstances, no additional security 291 considerations appear to be raised. 293 When applied to other message composites, especially encrypted 294 message content, feature expressions may disclose information that 295 is otherwise unavailable. In these cases, some security 296 considerations associated with media content negotiation [1,2] may 297 have greater relevance. 299 It is suggested here that media feature descriptions may be 300 usefully employed with encrypted message content. In doing this, 301 take care to ensure that the purpose of encryption is not 302 compromised. 304 6. Full copyright statement 306 Copyright (C) The Internet Society 1999. All Rights Reserved. 308 This document and translations of it may be copied and furnished to 309 others, and derivative works that comment on or otherwise explain 310 it or assist in its implementation may be prepared, copied, 311 published and distributed, in whole or in part, without restriction 312 of any kind, provided that the above copyright notice and this 313 paragraph are included on all such copies and derivative works. 314 However, this document itself may not be modified in any way, such 315 as by removing the copyright notice or references to the Internet 316 Society or other Internet organizations, except as needed for the 317 purpose of developing Internet standards in which case the 318 procedures for copyrights defined in the Internet Standards process 319 must be followed, or as required to translate it into languages 320 other than English. 322 The limited permissions granted above are perpetual and will not be 323 revoked by the Internet Society or its successors or assigns. 325 This document and the information contained herein is provided on 326 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 328 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Internet draft Indicating media features for MIME content 333 15 February 1999 335 7. Acknowledgements 337 This proposal draws from discussions with Dan Wing. The fax 338 message example was taken from a proposal by Mike Ruhl. 340 8. References 342 [1] "A syntax for describing media feature sets" 343 Graham Klyne, 5GM/Content Technologies 344 Internet draft: " 345 Work in progress, September 1998. 347 [2] "Media Feature Tag Registration Procedure" 348 Koen Holtman, TUE 349 Andrew Mutz, Hewlett-Packard 350 Ted Hardie, NASA 351 Internet draft: 352 Work in progress, July 1998. 354 [3] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 355 D. Crocker (editor), Internet Mail Consortium 356 P. Overell, Demon Internet Ltd. 357 November 1997. 359 [4] RFC 822, "Standard for the format of ARPA Internet text messages" 360 D. Crocker, Department of Electrical Engineering, University of 361 Delaware 362 August 1982. 364 To be replaced by: 365 "Internet Message Format Standard" 366 P. Resnick (editor), QUALCOMM Incorporated 367 Internet draft: 368 Work in progress, January 1999. 370 [5] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 371 Part 1: Format of Internet message bodies" 372 N. Freed, Innosoft 373 N. Borenstein, First Virtual 374 November 1996. 376 [6] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 377 Part 2: Media types" 378 N. Freed, Innosoft 379 N. Borenstein, First Virtual 380 November 1996. 382 Internet draft Indicating media features for MIME content 383 15 February 1999 385 9. Author's address 387 Graham Klyne 388 5th Generation Messaging Ltd. Content Technologies Ltd. 389 5 Watlington Street Forum 1, Station Road 390 Nettlebed Theale 391 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 392 United Kingdom United Kingdom. 393 Telephone: +44 1491 641 641 +44 118 930 1300 394 Facsimile: +44 1491 641 611 +44 118 930 1301 395 E-mail: GK@ACM.ORG 397 Appendix A: Revision history 399 00a 10-Feb-1999 Initial draft. 401 TODO: 403 o Complete examples