[要約] RFC 2530は、DSNとMDNの拡張を使用してサポートされるメディア機能を示すための仕様です。このRFCの目的は、電子メールの配信通知と読み取り通知において、メディア機能のサポート情報を提供することです。
Network Working Group D. Wing
Request for Comments: 2530 Cisco Systems
Category: Standards Track March 1999
Indicating Supported Media Features Using
Extensions to DSN and MDN
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
There is a need in Internet mail and Internet fax for a recipient to indicate the media features it supports so that messages can be generated by senders without exceeding the recipient's abilities.
メッセージが受信者の能力を超えることなく、送信者によって生成することができるように、それがサポートするメディア機能を示すために、受信者のためのインターネットメールやインターネットファックスにおいて必要とされています。
This memo describes a format for generating Message Disposition Notifications [RFC2298] and Delivery Status Notifications [RFC1894] which contain such information. This information can be used by senders to avoid exceeding the recipient's capabilities when sending subsequent messages.
このメモは、そのような情報を含むメッセージ気質通知[RFC2298]及び配信状態通知[RFC1894]を生成するためのフォーマットを記述する。この情報は、後続のメッセージを送信する際に受信者の能力を超えないように送信者によって使用することができます。
The extensions described in this document can be used in Message Disposition Notifications [RFC2298] or Delivery Status Notifications [RFC1894], as appropriate for the implementation.
本書では説明の拡張は、実装に応じて、[RFC2298]または配信状態通知[RFC1894]メッセージ気質通知に使用することができます。
Note that both DSNs and MDNs have drawbacks: DSNs are not available between all senders and receivers, and MDNs require the receiver to disclose message disposition information (or, if using the "denied" disposition-type, the time the disposition notification was generated).
DSNのと開封通知の両方が欠点を有することに注意してください。（配置型、配置通知が生成された時刻を「拒否」を使用した場合、または）のDSNは、すべての送信側と受信側の間で利用可能でない、及び開封通知メッセージの配置情報を開示するために受信機を必要とします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following extension is available to both DSN [RFC1894] and MDN [RFC2298] messages.
次の拡張はDSN [RFC1894]及びMDN [RFC2298]メッセージの両方に利用可能です。
For a DSN message, the following per-recipient fields are defined (section 2.3 of [RFC1894]). For an MDN message, the following extension fields are defined (section 3.1 of [RFC2298]). Using the language of [RFC2234]:
DSNメッセージのために、次の受信者ごとのフィールドは、（[RFC1894]のセクション2.3）に定義されています。 MDNメッセージは、次の拡張フィールドは、（[RFC2298]のセクション3.1）に定義されています。 [RFC2234]の言語を使用します：
extension-field = media-features CRLF
拡張フィールド=メディア機能CRLF
media-features = "Media-Accept-Features" ":" media-feature-tags media-feature-tags = <*text as defined below, with LWSP wrapping>
メディア機能=「メディア-のAccept-機能」「：」メディア機能タグメディア機能タグ= <*テキストLWSPの折り返しを、以下に定義します>
The <media-feature-tags> are defined in separate schema documents which MUST utilize the language described in [SYNTAX]. The schema MUST be registered following the registration requirements of [RFC2506].
<メディア特徴タグ>〔SYNTAX〕に記載の言語を利用しなければならない別個のスキーマ文書で定義されています。スキーマは、[RFC2506]の登録要件次の登録されなければなりません。
The following examples assume there is a schema document which defines the tags shown.
以下の例を示すタグを定義するスキーマ文書が存在すると仮定する。
Assuming there is a schema document which describes the tags paper-size and color, the following example is valid:
タグの用紙サイズと色を記述するスキーマ文書があると仮定すると、次の例は有効です。
Media-Accept-Features: (& (paper-size=a4) (color=binary) )
メディアのAccept-特徴：（＆（用紙サイズ= A4）（色=バイナリ））
Assuming there is a schema document which describes the tags paper-size, color, and grey:
タグ用紙サイズ、カラー、グレーを記述するスキーマ文書が存在すると仮定すると：
Media-Accept-Features: (& (| (paper-size=a4) (paper-size=letter) ) (| (& (color=grey) (dpi=200) (dpi-xyratio=200/100) ) (& (color=limited) (dpi=200) (dpi-xy=200/100) ) )
メディアのAccept-特徴：（＆（|（用紙サイズ= A4）（用紙サイズ=レター））（|（＆（色=グレー）（DPI = 200）（DPI-xyratio = 200/100））（ ＆（色=限られた）（DPI = 200）（DPI-XY = 200/100）））
If the recipient's MTA determines that a message cannot be processed, the recipient's MTA is strongly encouraged to reject the message with a status code of 5.6.1 [RFC1893]. This status code may be returned
受信者のMTAがメッセージを処理できないと判断した場合、受信者のMTAは強く5.6.1 [RFC1893]のステータスコードとメッセージを拒否することが奨励されます。このステータスコードが返されることがあります
in response to the end-of-mail-data indicator if the MTA supports reporting of enhanced error codes [RFC2034], or after message reception by generating a delivery failure DSN ("bounce").
エンドのメールデータインジケータに応答してMTAが拡張エラーコードの報告をサポートしている場合は、[RFC2034]、またはメッセージ受信後に配信失敗DSN（「バウンス」）を生成することによって。
Inaccurate media feature information could cause a denial of service, causing subsequent messages to be sent which the recipient is unable to process.
後続のメッセージを引き起こしてサービス拒否を引き起こす可能性が不正確なメディア機能情報は、受信者が処理することができないその送信されます。
The media feature information could be inaccurate due to a malicious attack (spoofed DSN or MDN) or misconfiguration.
メディア特徴情報が原因悪意のある攻撃（なりすましのDSNまたはMDN）や設定ミスのため不正確である可能性があります。
The author thanks the members of the Internet Fax working group for assistance with this document, and especially Larry Masinter, Graham Klyne, and Ned Freed.
著者のおかげで、この文書の支援のためのインターネットファクスワーキンググループのメンバー、特にラリーMasinter、グラハムKlyne、そしてネッドフリード。
[RFC2506] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506] Holtman、K.、MUTZ、A.およびT.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。
[RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[RFC1894]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 1894、1996年1月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
"強化されたエラーコードを返すためのSMTPサービス拡張" [RFC2034]フリード、N.、RFC 2034、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[RFC2298] Fajman、R.、RFC 2298、1998年3月の "メッセージ処分通知のための広げることができるメッセージフォーマット"。
[SYNTAX] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
"メディア機能セットの記述のための構文" [SYNTAX] Klyne、G.、RFC 2533、1999年3月。
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA
ダン・ウィングシスコシステムズ社101クーパーストリートサンタクルス、CA 95060 USA
Phone: +1 831 457 5200 Fax: +1 831 457 5208 EMail: dwing@cisco.com
電話：+1 831 457 5200ファックス：+1 831 457 5208 Eメール：dwing@cisco.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。