summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2912.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2912.txt')
-rw-r--r--doc/rfc/rfc2912.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2912.txt b/doc/rfc/rfc2912.txt
new file mode 100644
index 0000000..55f08bd
--- /dev/null
+++ b/doc/rfc/rfc2912.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group G. Klyne
+Request for Comments: 2912 Content Technologies
+Category: Standards Track September 2000
+
+
+ Indicating Media Features for MIME Content
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ In "A Syntax for Describing Media Feature Sets", an expression format
+ is presented for describing media feature capabilities using simple
+ media feature tags.
+
+ This memo defines a Multipurpose Internet Mail Extensions (MIME)
+ 'Content-features:' header that can be used to annotate a MIME
+ message part using this expression format, and indicates some ways it
+ might be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne Standards Track [Page 1]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+Table of Contents
+
+ 1. Introduction ............................................... 2
+ 1.1 Terminology and document conventions ................... 2
+ 2. Motivation and goals ....................................... 3
+ 3. The 'Content-features:' MIME header ........................ 4
+ 3.1 Whitespace and folding long headers .................... 4
+ 3.2 Usage considerations ................................... 4
+ 3.2.1 Simple message parts ............................... 4
+ 3.2.2 Multipart and other composites ..................... 5
+ 3.2.3 Reference to external data ......................... 5
+ 4. Examples ................................................... 5
+ 4.1 Simple message ......................................... 5
+ 4.2 Fax message ............................................ 6
+ 4.3 Multipart/alternative data ............................. 6
+ 4.4 Reference to external message data ..................... 8
+ 4.5 Compressed data ........................................ 8
+ 4.6 Multipart/related data ................................. 8
+ 5. Security Considerations .................................... 9
+ 6. Acknowledgements ........................................... 10
+ 7. References ................................................. 10
+ 8. Author's Address ........................................... 10
+ Full Copyright Statement ...................................... 11
+
+1. Introduction
+
+ In "A Syntax for Describing Media Feature Sets" [1], an expression
+ format is presented for describing media feature capabilities as a
+ combination of simple media feature tags, registered according to
+ "Media Feature Tag Registration Procedure" [2]. This provides a
+ format for message handling agents to describe the media feature
+ content of messages that they can handle.
+
+ This memo defines a MIME 'Content-features:' header that can be used
+ to annotate a MIME message part using these feature expressions.
+ This header provides a means to indicate media-related features of
+ message content that go beyond the MIME content type.
+
+ Consideration is also given to how it may be used to present message
+ media content information that is problematic to express within the
+ basic MIME framework.
+
+1.1 Terminology and document conventions
+
+ This section defines a number of terms and other document
+ conventions, which are used with specific meaning in this memo.
+
+
+
+
+
+Klyne Standards Track [Page 2]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+ media feature
+ information that indicates facilities assumed to be available
+ for the message content to be properly rendered or otherwise
+ presented. Media features are not intended to include
+ information that affects message transmission.
+
+ feature set
+ some set of media features described by a media feature
+ assertion, as described in "A Syntax for Describing Media
+ Feature Sets" [1]. (See that memo for a more formal definition
+ of this term.)
+
+ feature set expression
+ a string that describes some feature set, formulated according
+ to the rules in "A Syntax for Describing Media Feature Sets"
+ [1] (and possibly extended by other specifications).
+
+ This specification uses syntax notation and conventions described in
+ RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3].
+
+ NOTE: Comments like this provide additional nonessential
+ information about the rationale behind this document. Such
+ information is not needed for building a conformant
+ implementation, but may help those who wish to understand the
+ design in greater depth.
+
+2. Motivation and goals
+
+ It is envisaged that media feature labelling of message parts may be
+ used in the following ways:
+
+ o to supply more detailed media feature information about a message
+ content than can be provided by the 'Content-type:' header.
+
+ o to provide summary media feature information (possibly including
+ MIME content types) about the content of a composite MIME message
+ part (e.g. 'multipart' or 'message'), without having to open up
+ the inner content of the message.
+
+ o to supply media feature information about external data referenced
+ by a message part (e.g. 'message/external-body' MIME type). This
+ information would not be available by examination of the message
+ content.
+
+ o to describe the content of a message that is encrypted or encoded
+ using some application-specific file structure that hides the
+ content from a MIME processor. This information also would not be
+ generally available by examination of the message content.
+
+
+
+Klyne Standards Track [Page 3]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+3. The 'Content-features:' MIME header
+
+ A new header field is defined that extends the allowable formats for
+ 'optional-field' [4] with the following syntax:
+
+ optional-field =/ "Content-features" ":" Feature-expr
+ Feature-expr = filter ; See [1], section 4.1
+
+ where 'filter' is the media feature expression format defined by "A
+ Syntax for Describing Media Feature Sets" [1].
+
+ This header provides additional information about the message content
+ directly contained or indirectly referenced in the corresponding MIME
+ message part.
+
+3.1 Whitespace and folding long headers
+
+ In some circumstances, media feature expressions can be very long.
+
+ According to "A Syntax for Describing Media Feature Sets" [1],
+ whitespace is allowed between lexical elements of a media feature
+ expression. Further, RFC822/MIME [4,5] allows folding of long
+ headers at points where whitespace appears to avoid line length
+ restrictions.
+
+ Therefore, it is recommended that whitespace is included as
+ permitted, especially in long media feature expressions, to
+ facilitate the folding of headers by agents that do not otherwise
+ understand the syntax of this field.
+
+3.2 Usage considerations
+
+3.2.1 Simple message parts
+
+ When applied to a simple MIME message part, the header should appear
+ just once and is used to convey additional information about the
+ message part content that goes beyond that provided by the MIME
+ 'Content-type:' header field. The 'Content-features:' header may
+ indicate a content type that is different than that given by the MIME
+ 'Content-type:' header. This is possible but not recommended when
+ applied to a non-composite body part: in any case, MIME content type
+ processing must be performed in accordance with the 'Content-type:'
+ header.
+
+ NOTE: Once the message content has been delivered to an
+ application, it is possible that subsequent processing may be
+ affected by content type information indicated by the media
+ feature expression. See example 4.5 below.
+
+
+
+Klyne Standards Track [Page 4]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+3.2.2 Multipart and other composites
+
+ 'Content-features:' headers may be applied to a MIME multipart
+ indicating information about the inner content of the multipart.
+
+ Implementations must not assume a one-to-one relationship between
+ 'Content-features' headers and contained body parts. Headers may
+ appear on a containing multipart wrapper in a different order than
+ the body parts to which they refer; a single header may refer to
+ more than one contained body part; several headers may refer to the
+ same contained body part.
+
+ If it is important to relate specific media features to specific
+ contained MIME body parts, then the 'Content-features:' header should
+ be applied directly to the body part concerned, rather than the
+ surrounding composite.
+
+ NOTE: The intent here is to allow summary media feature
+ information to be provided without having to open up and
+ examine the inner content of the MIME message.
+
+ Similar usage may apply when the message format is a non-MIME or
+ opaque composite; e.g. 'application/zip', or an encrypted message.
+ In these cases, the option of examining the message content to
+ discover media feature information is not available.
+
+3.2.3 Reference to external data
+
+ Media feature information about data indirectly referenced by a MIME
+ body part rather than contained within a message can be conveyed
+ using one or more 'Content-features:' headers.
+
+ For example, media information --including contained MIME content
+ type(s)-- about the data referenced by a MIME 'Message/external-body'
+ may be conveyed.
+
+4. Examples
+
+4.1 Simple message
+
+ Mime-Version: 1.0
+ Content-type: text/plain;charset=US-ASCII
+ Content-features: (& (paper-size=A4) (ua-media=stationery) )
+
+ :
+ (data)
+ :
+
+
+
+
+Klyne Standards Track [Page 5]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+4.2 Fax message
+
+ Mime-Version: 1.0
+ Content-Type: multipart/mixed; boundary="break"
+ Content-features:
+ (& (Type="image/tiff")
+ (color=Binary)
+ (image-file-structure=TIFF-S)
+ (dpi=200)
+ (dpi-xyratio=200/100)
+ (paper-size=A4)
+ (image-coding=MH) (MRC-mode=0)
+ (ua-media=stationery) )
+
+ --break
+ Content-Type: image/tiff; name="coverpage.tiff"
+ Content-Transfer-Encoding: base64
+ Content-Description: This part is a coverpage
+ Content-Disposition: attachment; filename="coverpage.tiff"
+
+ 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
+ AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
+ :
+ (more data)
+ :
+ --break
+
+ Content-Type: image/tiff; name="document.tiff"
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename="document.tiff"
+
+ AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
+ GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
+ :
+ (more data)
+ :
+ --break--
+
+4.3 Multipart/alternative data
+
+ This example illustrates three points:
+
+ o Information about the various parts in a multipart/alternative can
+ be made available before the alternative body parts are processed.
+ This may facilitiate optimum one-pass processing of
+ multipart/alternative data.
+
+
+
+
+
+Klyne Standards Track [Page 6]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+ o There may be alternatives having the same basic MIME content-type,
+ but differing in the content features that they use.
+
+ o There is NO defined correspondence between 'Content-features'
+ headers and contained body parts.
+
+ Mime-Version: 1.0
+ Content-Type: multipart/alternative; boundary="break"
+ Content-features: (& (Type="text/plain") (charset=US-ASCII) )
+ Content-features:
+ (& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
+ Content-features:
+ (& (Type="text/html") (charset=ISO-8859-1) (color=binary) )
+
+ --break
+ Content-type: "text/plain";charset=US-ASCII
+ Content-features: (color=binary)
+
+ :
+ (data)
+ :
+ --break
+ Content-type: "text/plain";charset=US-ASCII
+ Content-features: (color=limited)
+
+ :
+ (data)
+ :
+ --break
+
+
+ Content-type: text/html;charset=iso-8859-1
+ Content-features: (color=binary)
+
+ :
+ (data)
+ :
+ --break
+ Content-type: text/html;charset=iso-8859-1
+ Content-features: (color=limited)
+
+ :
+ (data)
+ :
+ --break--
+
+
+
+
+
+
+Klyne Standards Track [Page 7]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+4.4 Reference to external message data
+
+ Mime-Version: 1.0
+ Content-type: message/external-body; access-type=URL;
+ URL="http://www.foo.com/file1.html"
+
+ Content-type: Multipart/mixed
+ Content-features: (& (Type="text/plain") (charset=US-ASCII) )
+ Content-features: (& (Type="image/tiff") (color=limited) )
+
+ <end>
+
+4.5 Compressed data
+
+ This example shows how the 'Content-features' header can be used to
+ overcome the problem noted in the MIME registration for
+ 'Application/zip' regarding information about the data content.
+
+ Mime-Version: 1.0
+ Content-type: application/zip
+ Content-features: (& (Type="text/plain") (charset=US-ASCII) )
+ Content-features: (& (Type="image/tiff") (color=limited) )
+ Content-transfer-encoding: base64
+
+ :
+ (data)
+ :
+ <end>
+
+4.6 Multipart/related data
+
+ (See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])
+
+ Mime-Version: 1.0
+ Content-Type: multipart/related; boundary="boundary-example";
+ type="text/html"; start="<foo3@foo1@bar.net>"
+ Content-features: (& (type="text/html") (charset=US-ASCII) )
+ Content-features: (type="image/gif")
+
+ --boundary-example
+ Content-Type: text/html;charset=US-ASCII
+ Content-ID: <foo3@foo1@bar.net>
+
+ referencing a resource in another body part, for example
+ through a statement such as:
+ <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
+ ALT="IETF logo">
+
+
+
+
+Klyne Standards Track [Page 8]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+ --boundary-example
+ Content-Location:
+ http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
+ Content-Type: IMAGE/GIF
+ Content-Transfer-Encoding: BASE64
+
+ R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+ NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+ etc...
+
+ --boundary-example--
+
+5. Security Considerations
+
+ When applied to simple or multipart MIME formatted data, a media
+ feature expression provides summary information about the message
+ data, which in many cases can be determined by examination of the
+ message content. Under these circumstances, no additional security
+ considerations appear to be raised.
+
+ When applied to other message composites, especially encrypted
+ message content, feature expressions may disclose information that is
+ otherwise unavailable. In these cases, some security considerations
+ associated with media content negotiation [1,2] may have greater
+ relevance.
+
+ It is suggested here that media feature descriptions may be usefully
+ employed with encrypted message content. In doing this, take care to
+ ensure that the purpose of encryption is not compromised (e.g.
+ encryption might be intended to conceal the fact that a particular
+ application data format is being used, which fact might be disclosed
+ by an injudiciously applied Content-features header).
+
+ If a 'Content-features' header is applied to a multipart/signed
+ object (or indeed outside any other form of signed data) the media
+ feature information is not protected. This unprotected information
+ could be tampered with, possibly fooling implementations into doing
+ inappropriate things with the contained material. (Putting the media
+ feature information inside the signed information would overcome
+ this, at the cost of requiring implementations to parse the inner
+ structure to find it.)
+
+
+
+
+
+
+
+
+
+
+Klyne Standards Track [Page 9]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+6. Acknowledgements
+
+ This proposal draws from discussions with Dan Wing. The fax message
+ example was taken from a proposal by Mike Ruhl. The
+ multipart/related example is developed from RFC 2557 [7].
+
+ The author would like to thank the following people who offered
+ comments that led to significant improvements: Mr Hiroshi Tamura,
+ Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed.
+
+7. References
+
+ [1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
+ 2533, March 1999.
+
+ [2] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
+ Registration Procedure", RFC 2506, March 1999.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [4] Crocker, D., "Standard for the format of ARPA Internet text
+ messages", STD 11, RFC 822, August 1982.
+
+ [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part 1: Format of Internet message bodies",
+ RFC 2045, November 1996.
+
+ [6] Levinson, E., "The MIME Multipart/Related Content-type", RFC
+ 2387, August 1998.
+
+ [7] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of
+ Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
+ 1999.
+
+8. Author's Address
+
+ Graham Klyne
+ Content Technologies Ltd.
+ 1220 Parkview,
+ Arlington Business Park
+ Theale
+ Reading, RG7 4SA
+ United Kingdom
+
+ Phone: +44 118 930 1300
+ Fax: +44 118 930 1301
+ EMail: GK@ACM.ORG
+
+
+
+Klyne Standards Track [Page 10]
+
+RFC 2912 Indicating Media Features for MIME Content September 2000
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne Standards Track [Page 11]
+