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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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.)
「メディア機能セットを記述するためのA構文」で説明したような特徴は、[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.
例えば、HTTP 1.1の[4]透明コンテンツネゴシエーション（TCN）と[5]に許容されるコンテンツタイプと他のメディア機能は、それらが特定の組み合わせのみに許容可能であり得ることを示すために、明確な方法で、異なる要求ヘッダに示されています。
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複合体の内側部分を指すことができます。例えば「マルチパート」、圧縮されたアーカイブ内のファイル、または暗号化されたメッセージデータの構成部品。
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での例では「文字セット」を用いて示されている - 「文字セット」タグは、別の登録[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].
注：コンテンツタイプのパラメータは、タグの値が考慮されたタイプの一部であることを許可しますが、理由は正規化、発注、大文字と小文字の区別などの懸念の拒否だけ正確に、大文字と小文字を区別し、文字のマッチングがメディア機能表現のために定義された[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="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.
注：この場合には、いくつかのメディア機能は、宣言 "マルチパート/ voice-メッセージのコンテンツタイプに含まれるMIMEの部品に適用されます。ここでの目標は、（可能）メッセージの内容に関する有用な情報を伝達するよう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.
この例では、カラーテキストタグの数が限られ、マッピングされた色をサポートGIFビューア、および色をサポートJPEGビューアを扱うことができるHTMLビューアを説明します。
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「メディア特徴タグの登録手順」のセクション3.1.1で定義されているように、「IETFツリー」にフィーチャータグの登録を求めて[2]（つまり、これらの機能のタグは、「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のconneg "ワーキンググループでの議論から描画します。音声メッセージの例は、グレン・パーソンズによっていくつかのアイデアに基づいています。
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.
テッドハーディー、ラリーMasinter、ポール・ホフマン、ヤコブパルメ、ネッドフリード：著者は大幅な改善につながったコメントを提供した以下の方々に感謝したいと思います。
[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.ハーディ、 "メディア特徴タグの登録手順"、RFC 2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3]クロッカー、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ウイング、D.、RFC 2530、1999年3月 "サポートされているメディアを示すには、DSNとMDNに拡張機能を使用しています"。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[7]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[8]フリード、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]ホフマン、P.、進行中で働いて「文字セットと言語メディアの登録はタグ機能します」。
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
グラハムKlyneコンテンツテクノロジ株式会社1220パークビュー、アーリントンビジネスパークTheale読書、RG7 4SAイギリス
Phone: +44 118 930 1300 Fax: +44 118 930 1301 EMail: GK@ACM.ORG
電話：+44 118 930 1300ファックス：+44 118 930 1301 Eメール：GK@ACM.ORG
Appendix A: 'Type' feature tag registration
付録A：「種類」機能のタグ登録
- Media Feature tag name(s):
- メディア特徴タグ名（S）：
Type
タイプ
- ASN.1 identifier associated with this feature tag:
- この機能のタグに関連するASN.1識別子：
- 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.
コンテンツタイプが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.
- Examples of typical use:
- 典型的な使用例：
(type="image/tiff")
（タイプ= "画像/ TIFF"）
(& (type="text/plain") (charset=US-ASCII) )
（＆（タイプ= "text / plainの"）（文字セット= 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]
文字セットと言語メディアの登録タグ機能[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.
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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。