summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2913.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2913.txt')
-rw-r--r--doc/rfc/rfc2913.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2913.txt b/doc/rfc/rfc2913.txt
new file mode 100644
index 0000000..ded8324
--- /dev/null
+++ b/doc/rfc/rfc2913.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group G. Klyne
+Request for Comments: 2913 Content Technologies
+Category: Standards Track September 2000
+
+
+ MIME Content Types in Media Feature Expressions
+
+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 media feature tag whose value is a Multipurpose
+ Internet Mail Extensions (MIME) content type. This allows the
+ construction of feature expressions that take account of the MIME
+ content type of the corresponding data.
+
+Table of Contents
+
+ 1. Introduction .................................................. 2
+ 1.1 Terminology and document conventions ...................... 2
+ 2. Motivation and goals .......................................... 3
+ 3. MIME content type feature tag ................................. 3
+ 4. Examples ...................................................... 4
+ 4.1 Simple text ............................................... 4
+ 4.2 Fax image ................................................. 4
+ 4.3 Voice message ............................................. 4
+ 4.4 Web browser capabilities .................................. 5
+ 5. IANA Considerations ........................................... 5
+ 6. Security Considerations ....................................... 5
+ 7. Acknowledgements .............................................. 5
+ 8. References .................................................... 6
+ 9. Author's Address .............................................. 6
+ Appendix A: 'Type' feature tag registration ...................... 7
+ Full Copyright Statement ......................................... 9
+
+
+
+Klyne Standards Track [Page 1]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+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 media feature tag whose value is a MIME content
+ type. This allows the construction of feature expressions that take
+ account of the MIME content type of the corresponding data.
+
+ Note that a content type feature value may contain parameters, but
+ this is discouraged. See section 3 and appendix A, "Summary of the
+ media features indicated" for discussion of this point.
+
+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.
+
+ 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.
+
+
+
+
+Klyne Standards Track [Page 2]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+2. Motivation and goals
+
+ The media feature expression syntax [1] and feature tags [2] were
+ designed with a view to providing content media information that
+ augments basic MIME content type information. There are some
+ situations where it is useful to be able include that content type
+ information in a media feature expression:
+
+ o Media feature details may depend upon the content type being used.
+ The media feature combining algebra and syntax [1] cannot apply to
+ content type information unless it appears in the feature
+ expression.
+
+ For example, in HTTP 1.1 [4] with Transparent Content Negotiation
+ (TCN) [5] acceptable content types and other media features are
+ indicated in different request headers, with no clear way to
+ indicate that they may be acceptable only in certain combinations.
+
+ o It is sometimes useful for all media capability information to be
+ included in a single expression. For example, DSN and MDN
+ extensions [6] that allow a recipient to indicate media
+ capabilities provide a single field for conveying this
+ information.
+
+ o When media features are used to describe a message content, they
+ may refer to inner parts of a MIME composite; e.g. the component
+ parts of a 'multipart', files in a compressed archive, or
+ encrypted message data.
+
+3. MIME content type feature tag
+
+ Feature tag name Legal values
+ ---------------- ------------
+ type <string>
+ containing a MIME content-type value.
+
+ Reference: this document, appendix A.
+
+ The 'type' feature tag indicates a MIME media content type (i.e.
+ that appears in a 'Content-type:' header of the corresponding MIME-
+ formatted data). It must be a string of the form "type/subtype",
+ where 'type' and 'subtype' are defined by the MIME specification [7].
+ Only lower-case letters should be used.
+
+ The content type must be given without any content-type parameter
+ values.
+
+
+
+
+
+Klyne Standards Track [Page 3]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+ To include information in media feature expressions that is otherwise
+ conveyed in a MIME content-type parameter, a separate media feature
+ tag should be registered [2] and used in the media feature
+ expression. This is illustrated by the use of 'charset' in the
+ example at 4.1 below -- the 'charset' tag is defined by a separate
+ registration [10].
+
+ NOTE: Allowing content-type parameters to be part of a type tag
+ value was considered, but rejected because of concerns about
+ canonicalization, ordering, case sensitivity, etc. Only exact,
+ case-sensitive, character matching is defined for media feature
+ expressions [1].
+
+4. Examples
+
+4.1 Simple text
+
+ (& (type="text/plain") (charset=US-ASCII)
+ (color=binary) (paper-size=A4) )
+
+4.2 Fax image
+
+ (& (type="image/tiff")
+ (color=binary)
+ (image-file-structure=TIFF-S)
+ (dpi=200)
+ (dpi-xyratio=[200/100,200/200])
+ (paper-size=A4)
+ (image-coding=MH) (MRC-mode=0)
+ (ua-media=stationery) )
+
+4.3 Voice message
+
+ (& (type="multipart/voice-message")
+ (VPIM-version="3.0")
+ (audio-codec=[G726-32,GSM-610])
+ (audio-file-structure=[None,WAV])
+ (ua-terminal=mobile-handset)
+ (audio-channels=1) )
+
+ NOTE: in this case, some media features apply to MIME parts
+ contained within the declared 'multipart/voice- message'
+ content type. The goal here is not so much to mirror the MIME
+ structure as to convey useful information about the (possible)
+ message content.
+
+
+
+
+
+
+Klyne Standards Track [Page 4]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+4.4 Web browser capabilities
+
+ (& (pix-x<=800) (pix-y<=600)
+ (| (& (type="text/html") (charset=iso-8859-1)
+ (color=limited) )
+ (& (type="text/plain") (charset=US-ASCII) )
+ (& (type="image/gif") (color=mapped))
+ (& (type="image/jpeg") (color=full) ) ) )
+
+ This example describes an HTML viewer that can deal with a limited
+ number of color text tags, a gif viewer that supports mapped color,
+ and a jpeg viewer that supports color.
+
+5. IANA Considerations
+
+ Appendix A of this document calls for registration of a feature tag
+ in the "IETF tree", as defined in section 3.1.1 of "Media Feature Tag
+ Registration Procedure" [2] (i.e. these feature tags are subject to
+ the "IETF Consensus" policies described in RFC 2434 [9]).
+
+ ASN.1 identifier 1.3.6.1.8.1.30 has been assigned by the IANA for
+ this registered feature tag and has been placed in the body of the
+ registration.
+
+6. Security Considerations
+
+ This memo is not believed to introduce any security considerations
+ that are not already inherent in the use of media feature tags and
+ expressions [1,2].
+
+7. Acknowledgements
+
+ This proposal draws from discussions in the IETF 'conneg' working
+ group. The voice message example is based on some ideas by Glen
+ Parsons.
+
+ The author would like to thank the following people who offered
+ comments that led to significant improvements: Ted Hardie, Larry
+ Masinter, Paul Hoffman, Jacob Palme, Ned Freed.
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne Standards Track [Page 5]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+8. 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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [5] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
+ HTTP", RFC 2295, March 1998.
+
+ [6] Wing, D., "Indicating Supported Media Features Using Extensions
+ to DSN and MDN", RFC 2530, March 1999.
+
+ [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996.
+
+ [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", RFC 2434, October 1998.
+
+ [10] Hoffman, P., "Registration of Charset and Languages Media
+ Features Tags", Work in Progress.
+
+9. 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 6]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+Appendix A: 'Type' feature tag registration
+
+ - Media Feature tag name(s):
+
+ Type
+
+ - ASN.1 identifier associated with this feature tag:
+
+ 1.3.6.1.8.1.30
+
+ - Summary of the media features indicated:
+
+ This feature tag indicates a MIME content type that a message
+ agent is capable of handling, or that is contained within some
+ message data.
+
+ The content type consists of the MIME media type and subtype,
+ presented using all lower case letters and with any whitespace
+ characters removed.
+
+ - Values appropriate for use with this feature tag:
+
+ String
+
+ - The feature tag is intended primarily for use in the following
+ applications, protocols, services, or negotiation mechanisms:
+
+ Any application that wishes to convey MIME content type
+ information in a media feature expression.
+
+ - Examples of typical use:
+
+ (type="image/tiff")
+
+ (& (type="text/plain") (charset=US-ASCII) )
+
+ - Related standards or documents:
+
+ MIME, RFC 2045 [7]
+
+ MIME, RFC 2046 [8]
+
+ Registration of Charset and Languages Media Features Tags [10]
+
+ - Considerations particular to use in individual applications,
+ protocols, services, or negotiation mechanisms:
+
+ (N/A)
+
+
+
+Klyne Standards Track [Page 7]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+ - Interoperability considerations:
+
+ String feature matching is case sensitive, so consistent use of
+ case for content type values and parameters is essential if
+ content type value matching is to be achieved in a fashion
+ consistent with MIME content type matching.
+
+ Similarly, white space must be used consistently.
+
+ This registration specifies a canonical form to be used for
+ content type values (lower case letters and remove all
+ whitespace).
+
+ - Related feature tags:
+
+ (N/A)
+
+ - Intended usage:
+
+ Common
+
+ - Author/Change controller:
+
+ IETF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klyne Standards Track [Page 8]
+
+RFC 2913 MIME Content in Media Feature Expressions September 2000
+
+
+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 9]
+