RFC2912 日本語訳
2912 Indicating Media Features for MIME Content. G. Klyne. September 2000. (Format: TXT=20618 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne Request for Comments: 2912 Content Technologies Category: Standards Track September 2000
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2912年の満足している技術カテゴリ: 標準化過程2000年9月
Indicating Media Features for MIME Content
MIME内容のためのメディア機能を示します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
このメモはマルチパーパスインターネットメールエクステンション(MIME)が'以下を内容で特集する'というこの式形式を使用することでMIMEメッセージ部分を注釈するのに使用できて、それが使用されるかもしれないいくつかの方法を示すヘッダーを定義します。
Klyne Standards Track [Page 1] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[1ページ]RFC2912
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. 序論… 2 1.1 用語とドキュメントコンベンション… 2 2. 動機と目標… 3 3. '満足している特徴: 'MIMEヘッダー… 4 3.1個の空白と折りたたみの長いヘッダー… 4 3.2 用法問題… 4 3.2 .1 簡単なメッセージ部分… 4 3.2 .2個の複合の、そして、他の合成物… 5 3.2 外部のデータの.3参照… 5 4. 例… 5 4.1の簡単なメッセージ… 5 4.2 ファックスで、メッセージを送ってください… 6 4.3 複合の、または、代替のデータ… 6 外部のメッセージデータの4.4参照… 8 4.5 データを圧縮します… 8 4.6 複合の、または、関連するデータ… 8 5. セキュリティ問題… 9 6. 承認… 10 7. 参照… 10 8. 作者のアドレス… 10 完全な著作権宣言文… 11
1. Introduction
1. 序論
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 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.
このメモはMIMEが'以下を内容で特集する'というこれらの特徴式を使用することでMIMEメッセージ部分を注釈するのに使用できるヘッダーを定義します。 このヘッダーは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.
また、それが基本的なMIMEフレームワークの中で言い表すために問題が多い満足している情報をメッセージメディアに提示するのにどう使用されるかもしれないかに対して考慮を払います。
1.1 Terminology and document conventions
1.1 用語とドキュメントコンベンション
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
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[2ページ]RFC2912
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]の規則に従って(ことによると他の仕様で広げられます)の何らかの特徴について説明するセット式aストリングを特徴としてください。
This specification uses syntax notation and conventions described in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3].
この仕様がRFC2234で説明された構文記法とコンベンションを使用する、「構文仕様のための増大している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.
以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実装を築き上げるのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。
2. Motivation and goals
2. 動機と目標
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 以上を供給するために、詳細なメディアは'文書内容で提供できるよりメッセージ内容の情報を特徴とします: 'ヘッダー。
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 合成MIMEメッセージの内容に関して特徴情報を概要メディアに提供する(ことによると、MIME content typeを含んでいる)には、離れる必要はなくて、メッセージの内側の内容に開かれるのに離れてください(例えば、'複合'か'メッセージ')。
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 メッセージによって参照をつけられる外部のデータの特徴情報をメディアに提供するには、(例えば、'外部のメッセージ/ボディー'MIMEの種類)を分けてください。 この情報はメッセージ内容の調査で利用可能でないでしょう。
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.
o メッセージの内容について説明するために、それは、MIMEプロセッサから内容を隠す何らかのアプリケーション特有のファイル構造を使用することで暗号化されるか、またはコード化されます。 一般に、この情報もメッセージ内容の調査で利用可能でないでしょう。
Klyne Standards Track [Page 3] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[3ページ]RFC2912
3. The 'Content-features:' MIME header
3. '満足している特徴: 'MIMEヘッダー
A new header field is defined that extends the allowable formats for 'optional-field' [4] with the following syntax:
以下の構文で'任意の分野'[4]のための許容できる形式を広げる新しいヘッダーフィールドは定義されます:
optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter ; See [1], section 4.1
「任意の分野=/「満足している特徴」」:、」 特徴-expr Feature-exprはフィルタと等しいです。 [1]、セクション4.1を見てください。
where 'filter' is the media feature expression format defined by "A Syntax for Describing Media Feature Sets" [1].
'フィルタ'がメディアであるところでは、「特徴が設定するメディアを説明するための構文」[1]によって定義された式書式を特徴としてください。
This header provides additional information about the message content directly contained or indirectly referenced in the corresponding MIME message part.
このヘッダーは直接含まれたか、または対応するMIMEメッセージ部分で間接的に参照をつけられたメッセージ内容に関する追加情報を提供します。
3.1 Whitespace and folding long headers
3.1 空白と折りたたみの長いヘッダー
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.
「特徴が設定するメディアを説明するための構文」[1]によると、空白はメディア特徴式の字句要素の間に許容されています。 さらに、RFC822/MIME[4、5]は、空白が行長制限を避けるように見えるポイントに長いヘッダーに折り重なるのを許容します。
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 用法問題
3.2.1 Simple message parts
3.2.1 簡単なメッセージ部分
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.
簡単なMIMEメッセージ部分に付けられると、ヘッダーは、一度だけ現れるべきであり、MIME'文書内容によって提供されたそれを越えるメッセージ部分内容に関する追加情報を伝えるのに使用されます: 'ヘッダーフィールド。 '満足している特徴: 'ヘッダーはMIME'文書内容によって与えられたそれと異なったcontent typeを示すかもしれません: 'ヘッダー。 非合成している身体の部分に付けられる場合、これは、可能ですが、お勧めではありません: どのような場合でも、'文書内容によると、MIME content type処理を実行しなければなりません: 'ヘッダー。
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.
以下に注意してください。 その後の処理がメディア特徴式によって示されたcontent type情報で影響を受けるのは、一度、メッセージ内容がアプリケーションに提供されたことがあるのが可能です。 以下の例4.5を見てください。
Klyne Standards Track [Page 4] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[4ページ]RFC2912
3.2.2 Multipart and other composites
3.2.2 複合の、そして、他の合成物
'Content-features:' headers may be applied to a MIME multipart indicating information about the inner content of the multipart.
'満足している特徴:'ヘッダーは複合の内側の内容のMIMEの複合表示情報に適用されるかもしれません。
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.
実装は'満足している特徴'ヘッダーと含まれた身体の部分との1〜1つの関係を仮定してはいけません。 ヘッダーはそれらが参照する身体の部分より異なったオーダーにおける含有複合のラッパーに現れるかもしれません。 独身のヘッダーは1つ以上の含まれた身体の部分について言及するかもしれません。 数個のヘッダーが同じ含まれた身体の部分について言及するかもしれません。
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.
特定の含まれたMIME身体の部分に特定のメディア機能に関連するのが重要であるなら、'満足している特徴: 'ヘッダーは直接周囲の合成物よりむしろ関する身体の部分に付けられるべきです。
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.
以下に注意してください。 ここの意図はMIMEメッセージの内容を開けて、試験する必要はなくて提供するために概要メディアに特徴情報を許容することです。
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.
メッセージ・フォーマットが非MIMEの、または、不透明な合成物であるときに、同様の用法は適用されるかもしれません。 例えば、'アプリケーション/ファスナ'、または暗号化メッセージ。 これらの場合では、メディアが情報を特徴とすると発見するためにメッセージ内容を調べるオプションは利用可能ではありません。
3.2.3 Reference to external data
3.2.3 外部のデータの参照
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.
1つ以上の'満足している特徴を使用することでMIME身体の部分に従ってデータの特徴情報が間接的にメッセージの中に含んでいるよりむしろ参照をつけたメディアを伝えることができます: 'ヘッダー。
For example, media information --including contained MIME content type(s)-- about the data referenced by a MIME 'Message/external-body' may be conveyed.
例えば、MIME'外部のメッセージ/ボディー'によって参照をつけられるデータのメディア情報(含まれたMIME content typeを含んでいる)は伝えられるかもしれません。
4. Examples
4. 例
4.1 Simple message
4.1 簡単なメッセージ
Mime-Version: 1.0
Content-type: text/plain;charset=US-ASCII
Content-features: (& (paper-size=A4) (ua-media=stationery) )
パントマイムバージョン: 1.0文書内容: テキスト/平野; charsetは米国のASCIIの満足している特徴と等しいです: ((紙サイズ=A4)(ua-メディア=文房具))
:
(data)
:
: (データ) :
Klyne Standards Track [Page 5] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[5ページ]RFC2912
4.2 Fax message
4.2 ファックス通信
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) )
パントマイムバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界は「中断」のContent-特徴と等しいです: ((タイプ=「イメージ/いさかい」)(=を着色して、2進にします)(イメージファイル構造はいさかいSと等しいです)(dpi=200)(dpi-xyratio=200/100)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディアは文房具と等しいです))
--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"
--コンテントタイプを壊してください: イメージ/いさかい。 ="coverpage.tiff"Content転送コード化を命名してください: base64 Content-記述: この部分はcoverpage Content-気質です: 付属。 ファイル名="coverpage.tiff"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
:
(more data)
:
--break
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD//////////////////// : (より多くのデータ) : --中断
Content-Type: image/tiff; name="document.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.tiff"
コンテントタイプ: イメージ/いさかい。 ="document.tiff"Content転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
:
(more data)
:
--break--
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA: (より多くのデータ) : --壊れてください--
4.3 Multipart/alternative data
4.3 複合の、または、代替のデータ
This example illustrates three points:
この例は3ポイントを例証します:
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.
o 代替の身体の部分を処理する前に複合/代替手段による様々な部分に関する情報を利用可能にすることができます。 これは複合の、または、代替のデータのfacilitiateの最適な1パスの処理がそうするかもしれません。
Klyne Standards Track [Page 6] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[6ページ]RFC2912
o There may be alternatives having the same basic MIME content-type,
but differing in the content features that they use.
o 同じ基本的なMIME content typeを持っていますが、それらが使用する満足している特徴において異なる代替手段は、あるかもしれません。
o There is NO defined correspondence between 'Content-features'
headers and contained body parts.
o '満足している特徴'ヘッダーと含まれた身体の部分との通信は定義されません。
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) )
パントマイムバージョン: 1.0コンテントタイプ: 複合/代替手段。 境界は「中断」のContent-特徴と等しいです: ((タイプ=「テキスト/平野」)(charsetは米国-ASCIIと等しいです)) 満足している特徴: ((タイプ=「テキスト/html」)(charset=ISO-8859-1)(制限された色=)) 満足している特徴: ((タイプ=「テキスト/html」)(charset=ISO-8859-1)(=を着色して、2進にします))
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=binary)
--文書内容を知らせてください: 「テキスト/平野」; charsetは米国のASCIIの満足している特徴と等しいです: (色=バイナリー)
:
(data)
:
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=limited)
: (データ) : --文書内容を知らせてください: 「テキスト/平野」; charsetは米国のASCIIの満足している特徴と等しいです: (制限された色=)
:
(data)
:
--break
: (データ) : --中断
Content-type: text/html;charset=iso-8859-1
Content-features: (color=binary)
文書内容: テキスト/html; charset=iso-8859-1 Content-特徴: (色=バイナリー)
:
(data)
:
--break
Content-type: text/html;charset=iso-8859-1
Content-features: (color=limited)
: (データ) : --文書内容を知らせてください: テキスト/html; charset=iso-8859-1 Content-特徴: (制限された色=)
:
(data)
:
--break--
: (データ) : --壊れてください--
Klyne Standards Track [Page 7] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[7ページ]RFC2912
4.4 Reference to external message data
4.4 外部のメッセージデータの参照
Mime-Version: 1.0
Content-type: message/external-body; access-type=URL;
URL="http://www.foo.com/file1.html"
パントマイムバージョン: 1.0文書内容: 外部のメッセージ/ボディー。 アクセス型は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) )
文書内容: 複合の、または、複雑な満足している特徴: ((タイプ=「テキスト/平野」)(charsetは米国-ASCIIと等しいです)) 満足している特徴: ((タイプ=「イメージ/いさかい」)(制限された色=))
<end>
<終わりの>。
4.5 Compressed data
4.5 圧縮されたデータ
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登録で注意した問題を克服するのにどう'満足している特徴'ヘッダーを使用できるかを示しています。
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
パントマイムバージョン: 1.0文書内容: アプリケーション/ファスナのContent-特徴: ((タイプ=「テキスト/平野」)(charsetは米国-ASCIIと等しいです)) 満足している特徴: ((タイプ=「イメージ/いさかい」)(制限された色=)) 満足している転送コード化: base64
:
(data)
:
<end>
: (データ) : <終わりの>。
4.6 Multipart/related data
4.6 複合の、または、関連するデータ
(See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])
(参照: RFC2387、「MIMEの複合の、または、関連の文書内容」[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")
パントマイムバージョン: 1.0コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。 =「<foo3@foo1@bar.net>」のContent-特徴を始めてください: ((タイプ=「テキスト/html」)(charsetは米国-ASCIIと等しいです)) 満足している特徴: (タイプ=「イメージ/gif」)
--boundary-example
Content-Type: text/html;charset=US-ASCII
Content-ID: <foo3@foo1@bar.net>
--境界例のコンテントタイプ: テキスト/html; charsetは米国のASCIIのコンテント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">
別のボディーでリソースに参照をつけて、例えば、以下などの声明を通して離れてください。 <IMG SRCが" http://www.ietf.cnri.reston.va.us/images/ietflogo.gif "ALT=と等しい、「IETFロゴ">"
Klyne Standards Track [Page 8] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[8ページ]RFC2912
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例のContent-位置: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example--
--境界例--
5. Security Considerations
5. セキュリティ問題
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.
簡単であるか複合のMIMEフォーマット済みデータ、式が多くの場合、メッセージ内容の調査で決定できるメッセージデータの概要情報を提供するメディア機能に適用されると。 こういう事情ですから、追加担保問題は全く上げられるように見えません。
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.
他のメッセージ合成物、特に暗号化メッセージ内容に適用されると、特徴式はそうでなければ入手できない情報を明らかにするかもしれません。 これらのケース、メディア内容に関連づけられたいくつかのセキュリティ問題では、交渉[1、2]は、よりすばらしい関連性を持っているかもしれません。
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).
ここで、特徴記述がそうするメディアが暗号化メッセージ内容と共に有効に使われることが提案されます。 これをする際に、注意して(例えば、暗号化が特定用途データの形式が使用されていて、その事実が無分別に適用されたContent-特徴ヘッダーによって明らかにされるかもしれないという事実を隠すことを意図するかもしれません)、暗号化の目的が感染されないのを保証してください。
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
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[9ページ]RFC2912
6. Acknowledgements
6. 承認
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].
この提案はダンWingとの議論から描かれます。 マイク・リュールによる提案からファックス通信の例を取りました。 複合の、または、関連する例はRFC2557[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.
作者は、だれがそれをコメントに提供したかがかなりの改善に通じたのを以下の人々に感謝したがっています: Hiroshi田村さん、テッド・ハーディー、マウリジオ・コドーニョ、ヤコブ・パルメ、解放されたネッド。
7. References
7. 参照
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[1]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、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.ハーディー、「メディアはタグ登録手順を特徴とする」RFC2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[4] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[4] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part 1: Format of Internet message bodies",
RFC 2045, November 1996.
解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)第1部:」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[6] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[6] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
[7] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
1999.
[7] パルメ、J.、Hopmann、A.、およびN.シェル、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
8. Author's Address
8. 作者のアドレス
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
全麦のKlyne満足している技術株式会社1220Parkview、アーリントンビジネスはTheale読書、RG7 4SAイギリスを駐車します。
Phone: +44 118 930 1300 Fax: +44 118 930 1301 EMail: GK@ACM.ORG
以下に電話をしてください。 +44 118 930、1300Fax: +44 1301年の118 930メール: GK@ACM.ORG
Klyne Standards Track [Page 10] RFC 2912 Indicating Media Features for MIME Content September 2000
2000年9月にMIME内容のためのメディア機能を示すKlyne標準化過程[10ページ]RFC2912
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Klyne Standards Track [Page 11]
Klyne標準化過程[11ページ]
一覧
スポンサーリンク
