[要約] RFC 2913は、メディア機能表現でのMIMEコンテンツタイプの使用に関する規格です。このRFCの目的は、メディア機能表現を使用してコンテンツタイプを指定するための一貫性と互換性を提供することです。
Network Working Group G. Klyne
Request for Comments: 2913 Content Technologies
Category: Standards Track September 2000
MIME Content Types in Media Feature Expressions
メディア機能の表現のMIMEコンテンツタイプ
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このメモは、値が多目的インターネットメールエクステンション（MIME）コンテンツタイプであるメディア機能タグを定義します。これにより、対応するデータのMIMEコンテンツタイプを考慮した機能式の構築が可能になります。
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
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.
「メディア機能セットを説明するための構文」[1]では、「メディア機能タグ登録手順」[2]に従って登録されているシンプルなメディア機能タグの組み合わせとしてメディア機能機能を説明するための式形式が提示されています。これにより、メッセージ処理エージェントが処理できるメッセージのメディア機能コンテンツを説明する形式が提供されます。
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.
このメモは、値がMIMEコンテンツタイプであるメディア機能タグを定義します。これにより、対応するデータのMIMEコンテンツタイプを考慮した機能式の構築が可能になります。
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.
コンテンツタイプの機能値にはパラメーターが含まれている場合がありますが、これは落胆していることに注意してください。この点についての議論については、セクション3および付録A、「示されているメディア機能の要約」を参照してください。
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.)
機能「メディア機能セットを説明するための構文」で説明されているように、メディア機能のアサーションで説明されているメディア機能のセットセット[1]。（この用語のより正式な定義については、そのメモを参照してください。）
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).
機能セット式式「メディア機能セットを記述するための構文」のルールに従って定式化されたいくつかの機能セットを記述する文字列[1]（おそらく他の仕様によって拡張される可能性があります）。
This specification uses syntax notation and conventions described in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].
この仕様では、RFC 2234で説明されている構文表記と規則「構文仕様のためにBNFの増強：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.
注：このようなコメントは、このドキュメントの背後にある根拠に関する追加の非必須情報を提供します。このような情報は、適切な実装を構築するために必要ではありませんが、設計をより深く理解したい人を助けるかもしれません。
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:
メディア機能表現の構文[1]および機能タグ[2]は、基本的なMIMEコンテンツタイプ情報を増強するコンテンツメディア情報を提供するために設計されました。メディア機能式にそのコンテンツタイプ情報を含めることができることが役立つ状況がいくつかあります。
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.
o メディア機能の詳細は、使用されているコンテンツタイプに依存する場合があります。代数と構文[1]を組み合わせたメディア機能は、機能式に表示されない限り、コンテンツタイプ情報に適用できません。
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.
たとえば、透明なコンテンツネゴシエーション（TCN）[5]許容可能なコンテンツタイプおよびその他のメディア機能を備えたHTTP 1.1 [4]では、特定の組み合わせでのみ受け入れられる可能性があることを明確に示す方法はありません。
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 すべてのメディア機能情報を単一の式に含めるのが役立つ場合があります。たとえば、受信者がメディア機能を示すことを可能にするDSNおよびMDN拡張機能[6]は、この情報を伝えるための単一のフィールドを提供します。
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.
o メディア機能を使用してメッセージコンテンツを説明する場合、Mime Compositeの内側の部分を参照する場合があります。例えば「マルチパート」のコンポーネント部分、圧縮アーカイブのファイル、または暗号化されたメッセージデータ。
Feature tag name Legal values
---------------- ------------
type <string>
containing a MIME content-type value.
Reference: this document, appendix A.
参照：このドキュメント、付録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.
「タイプ」機能タグは、MIMEメディアのコンテンツタイプを示します（つまり、「コンテンツタイプ：「対応するMIME形式のデータ」のヘッダー）に表示されます）。「タイプ/サブタイプ」の形式でなければなりません。ここで、「タイプ」と「サブタイプ」はMIME仕様[7]によって定義されます。低ケースの文字のみを使用する必要があります。
The content type must be given without any content-type parameter values.
コンテンツタイプのパラメーター値なしでコンテンツタイプを指定する必要があります。
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].
それ以外の場合はMIMEコンテンツタイプのパラメーターで伝えられるメディア機能式に情報を含めるには、個別のメディア機能タグを登録し[2]、メディア機能表現に使用する必要があります。これは、下の4.1の例で「charset」を使用することによって示されています。「charset」タグは、個別の登録[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].
注：コンテンツタイプのパラメーターがタイプタグ値の一部になるようにすることが考慮されましたが、標準化、順序付け、ケース感度などについての懸念のために拒否されました。]。
(& (type="text/plain") (charset=US-ASCII)
(color=binary) (paper-size=A4) )
(& (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) )
（＆（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 =文房具））
(& (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) )
（＆（type = "multipart/voice-message"）（vpim-version = "3.0"）（audio-codec = [g726-32、gsm-610]）（audio-file-structure = [none、wav]））（ua-terminal = mobilehandset）（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.
注：この場合、一部のメディア機能は、宣言された「マルチパート/ボイスメッセージ」コンテンツタイプに含まれるMIME部品に適用されます。ここでの目標は、（可能な）メッセージコンテンツに関する有用な情報を伝えるために、マイム構造をミラーリングすることではありません。
(& (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.
この例では、限られた数のカラーテキストタグを扱うことができるHTMLビューアー、マッピングされた色をサポートするGIFビューアー、および色をサポートするJPEGビューアーを説明します。
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]).
このドキュメントの付録Aでは、「メディア機能タグ登録手順」[2]のセクション3.1.1で定義されている「IETFツリー」の機能タグの登録が必要です（つまり、これらの機能タグは「IETFコンセンサス」の対象となります。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.
ASN.1識別子1.3.6.1.8.1.30は、この登録機能タグのためにIANAによって割り当てられ、登録の本文に配置されています。
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].
このメモは、メディア機能タグと式の使用にまだ固有のものではないセキュリティ上の考慮事項を導入するとは考えられていません[1,2]。
This proposal draws from discussions in the IETF 'conneg' working group. The voice message example is based on some ideas by Glen Parsons.
この提案は、IETF「コネグ」ワーキンググループでの議論から引き出されます。音声メッセージの例は、グレンパーソンズによるいくつかのアイデアに基づいています。
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.
著者は、大幅な改善につながったコメントを提供してくれた以下の人々に感謝したいと思います：テッド・ハーディ、ラリー・マスインター、ポール・ホフマン、ジェイコブ・パーマ、ネッド・フリード。
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[1] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[2] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[2] Holtman、K.、Mutz、A。、およびT. Hardie、「メディア機能タグ登録手順」、RFC 2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[4] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2068、1997年1月。
[5] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[5] Holtman、K。およびA. Mutz、「HTTPの透明なコンテンツ交渉」、RFC 2295、1998年3月。
[6] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[6] Wing、D。、「DSNおよびMDNへの拡張機能を使用したサポートされているメディア機能を示す」、RFC 2530、1999年3月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[7] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[8] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[9] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、RFC 2434、1998年10月。
[10] Hoffman, P., "Registration of Charset and Languages Media Features Tags", Work in Progress.
[10] Hoffman、P。、「Charset and Languages Media機能のタグの登録」、進行中の作業。
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
Graham Klyne Content Technologies Ltd. 1220 Parkview、アーリントンビジネスパークシールリーディング、RG7 4SAイギリス
Phone: +44 118 930 1300
Fax: +44 118 930 1301
EMail: GK@ACM.ORG
Appendix A: 'Type' feature tag registration
付録A：「タイプ」機能タグ登録
- Media Feature tag name(s):
- メディア機能タグ名：
Type
タイプ
- ASN.1 identifier associated with this feature tag:
- この機能タグに関連付けられているasn.1識別子：
1.3.6.1.8.1.30
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.
この機能タグは、メッセージエージェントが処理できるMIMEコンテンツタイプ、または一部のメッセージデータに含まれることを示します。
The content type consists of the MIME media type and subtype, presented using all lower case letters and with any whitespace characters removed.
コンテンツタイプは、MIMEメディアタイプとサブタイプで構成され、すべての小文字を使用して表示され、削除された空白文字を使用して表示されます。
- 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.
メディア機能表現でMIMEコンテンツタイプ情報を伝えたいアプリケーション。
- Examples of typical use:
- 典型的な使用の例：
(type="image/tiff")
（type = "image/tiff"）
(& (type="text/plain") (charset=US-ASCII) )
- Related standards or documents:
- 関連標準またはドキュメント：
MIME, RFC 2045 [7]
Mime、RFC 2045 [7]
MIME, RFC 2046 [8]
Mime、RFC 2046 [8]
Registration of Charset and Languages Media Features Tags [10]
CharsetおよびLanguages Mediaの登録には、タグが機能します[10]
- Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms:
- 個々のアプリケーション、プロトコル、サービス、または交渉メカニズムで使用することに特に考慮してください。
(N/A)
（n/a）
- 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.
文字列の特徴マッチングはケースに敏感であるため、コンテンツタイプの値マッチングがMIMEコンテンツタイプのマッチングと一致するファッションで達成される場合、コンテンツタイプの値とパラメーターのケースの一貫した使用が不可欠です。
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)
（n/a）
- Intended usage:
- 意図された使用法：
Common
一般
- Author/Change controller:
- 著者/変更コントローラー：
IETF
IETF
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。