RFC3459 日本語訳
3459 Critical Content Multi-purpose Internet Mail Extensions (MIME)Parameter. E. Burger. January 2003. (Format: TXT=54282 bytes) (Updates RFC3204) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Burger Request for Comments: 3459 SnowShore Networks Updates: 3204 January 2003 Category: Standards Track
コメントを求めるワーキンググループE.バーガー要求をネットワークでつないでください: 3459SnowShoreはアップデートをネットワークでつなぎます: 3204 2003年1月のカテゴリ: 標準化過程
Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter
重要な満足している多目的のインターネットメール拡大(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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content- Disposition, as described by RFC 3204.
このドキュメントはメカニズムの送付者が複合インターネットメール・メッセージで重要であると考える身体の部分を特定する使用について説明します。 RFC3204によって説明されるように説明されたメカニズムはContent気質へのパラメタです。
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process.
より少ない能力のシステムにゲートウェイサービスを供給するとき、送付者が、重要であるとメッセージのどんな部分が考えるかを知っていることによって、満足しているゲートウェイは知的に複合メッセージを扱うことができます。 重要な内容は、満足しているゲートウェイが、どんな部品を進めたらよいかを決めるのを助けることができます。 それは、どれくらい固いゲートウェイが身体の部分を提供しようとするはずであるかを示すことができます。 より少ない能力のシステムがメッセージを受け取るとき静かに削除するために安全な身体の部分を選ぶと、ゲートウェイを助けることができます。 追加、重要な満足している缶の支援におけるゲートウェイは受電方式のための通知戦略を選びました。 同様に、送付者が、目的地が身体の部分における何らかの処理をすると予想するなら、重要な内容で、送付者は受信機が加工処理しなければならない身体の部分を示すことができます。
Burger Standards Track [Page 1] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[1ページ]。
Table of Contents
目次
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Handling Parameter.............................................4
3.1. REQUIRED..................................................4
3.2. OPTIONAL..................................................5
3.3. Default Values............................................5
3.4. Other Values..............................................5
4. Collected Syntax...............................................6
5. Notification...................................................6
5.1. DSN vs. MDN Generation....................................7
5.2. Summary...................................................7
6. Signed Content.................................................8
7. Encrypted Content..............................................9
8. Status Code...................................................10
9. Requirements for Critical Content.............................11
9.1. Needs....................................................11
9.2. Current Approaches.......................................12
10. The Content Gateway...........................................13
10.1. Integrated Content Gateway..............................14
10.2. Disaggregated Delivery Network..........................14
11. Backward Compatibility Considerations.........................15
12. MIME Interactions.............................................15
12.1. multipart/alternative...................................15
12.2. multipart/related.......................................15
12.3. message/rfc822..........................................15
12.4. multipart/signed........................................16
12.5. multipart/encrypted.....................................16
13. Implementation Examples.......................................16
13.1. Content Gateways........................................16
13.2. Disaggregated Content Gateway...........................17
14. OPES Considerations...........................................18
14.1. Consideration (2.1): One-Party Consent..................18
14.2. Consideration (2.2): IP-layer Communications............18
14.3. Consideration (3.1): Notification - Sender..............18
14.4. Consideration (3.2): Notification - Receiver............18
14.5. Consideration (3.3): Non-Blocking.......................18
14.6. Consideration (4.1): URI Resolution.....................18
14.7. Consideration (4.2): Reference Validity.................19
14.8. Consideration (4.3): Architecture Extensions............19
14.9. Consideration (5.1): Privacy............................19
15. Security Considerations.......................................19
16. IANA Considerations...........................................19
17. References....................................................20
17.1 Normative References.....................................20
17.2 Informative Reference....................................21
18. Acknowledgments...............................................22
1. このドキュメントで中古のコンベンション…3 2. 序論…3 3. 取り扱いパラメタ…4 3.1. 必要です…4 3.2. 任意…5 3.3. デフォルト値…5 3.4. 他の値…5 4. 構文を集めます…6 5. 通知…6 5.1. DSN対MDN世代…7 5.2. 概要…7 6. 内容であると署名されます…8 7. 内容を暗号化します…9 8. 状態コード…10 9. 重要な内容のための要件…11 9.1. 必要です。11 9.2. 電流にアプローチします…12 10. 満足しているゲートウェイ…13 10.1. 統合満足しているゲートウェイ…14 10.2. 配送ネットワークをDisaggregatedしました…14 11. 後方の互換性問題…15 12. 相互作用をまねてください…15 12.1. 複合/代替手段…15 12.2. 複合か関連する…15 12.3. メッセージ/rfc822…15 12.4. 複合か署名される…16 12.5. 複合か暗号化される…16 13. 実装の例…16 13.1. 満足しているゲートウェイ…16 13.2. 満足しているゲートウェイをDisaggregatedしました…17 14. 作品問題…18 14.1. 考慮(2.1): 1パーティの同意…18 14.2. 考慮(2.2): IP-層のコミュニケーション…18 14.3. 考慮(3.1): 通知--、送付者…18 14.4. 考慮(3.2): 通知--、受信機…18 14.5. 考慮(3.3): 非ブロッキング…18 14.6. 考慮(4.1): URI解決…18 14.7. 考慮(4.2): 参照の正当性…19 14.8. 考慮(4.3): アーキテクチャ拡大…19 14.9. 考慮(5.1): プライバシー…19 15. セキュリティ問題…19 16. IANA問題…19 17. 参照…20 17.1 標準の参照…20 17.2 有益な参照…21 18. 承認…22
Burger Standards Track [Page 2] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[2ページ]。
19. Intellectual Property Notice..................................23 20. Author's Address..............................................23 21. Full Copyright Statement......................................24
19. 知的所有権通知…23 20. 作者のアドレス…23 21. 完全な著作権宣言文…24
1. Conventions used in this document
1. 本書では使用されるコンベンション
This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
このドキュメントが一般的に男性のメッセージの送付者について言及する、(彼、/、彼、/、彼のもの)、女性のメッセージの受取人、(彼女、/、彼女の/、彼女のもの) このコンベンションは、メッセージ送付者か受取人の性に関して純粋に便宜のためにあって、仮定を全くしません。
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
The word "REQUIRED" in this document does not follow the definition found in RFC 2119. This is because this document defines a parameter named "REQUIRED". There is no requirement in this document that is "REQUIRED", so there is no confusion.
「必要」という言葉は本書ではRFC2119で見つけられた定義に続きません。 これはこのドキュメントが「必要な」状態で指定されたパラメタを定義するからです。 混乱が全く「必要である」ので本書では、ないという要件が全くありません。
In this document, the "sending agent" is the originator of the message. It could be a mail user agent (MUA) for an Internet message, or a SIP User Agent Client (UAC) for a SIP [3] message. The "endpoint" is the receiving device, of lesser capability than the sending agent.
本書では、「送付エージェント」はメッセージの創始者です。 それは、インターネットメッセージのためのメールユーザエージェント(MUA)、またはSIP[3]メッセージのためのSIP UserエージェントClientであるかもしれません(UAC)。 「終点」は送付エージェントより少ない能力の受信デバイスです。
NOTE: Notes, such as this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices.
以下に注意してください。 メモ(これとしてのそのようなもの)は読者が不可欠のものは何も逃さないでスキップするかもしれないという追加不要不急な情報を提供します。 これらの不要不急な注意のプライマリ目的は、このドキュメントの原理に関して情報を伝達するか、または適切な歴史的であるか進化論の関係のこのドキュメントを置くことです。 conformant実装を構成する唯一の目的がことである読者はそのような情報をスキップするかもしれません。 しかしながら、それは私たちがなぜデザイン選択を確実にしたかを理解したがっている人の役に立つかもしれません。
2. Introduction
2. 序論
The specification of Critical Content is small and compact. For the benefit of developers, the specification comes first, the rationale after.
Critical Contentの仕様は、小さくて、コンパクトです。 開発者の利益に、仕様は来ます。最初に、後の原理。
One concept that an implementer must understand is the content gateway. Section 10 describes the content gateway. In brief, a content gateway has knowledge of the receiving system's capabilities. The content gateway passes messages the receiving system can process, render or store. The content gateway can modify a message, for example by deleting unrenderable or storable body parts, for delivery
implementerが分からなければならないという1つの概念が満足しているゲートウェイです。 セクション10は満足しているゲートウェイについて説明します。 要するに、満足しているゲートウェイには、受電方式の能力に関する知識があります。 満足しているゲートウェイは受電方式が処理するか、伝えるか、または保存できるメッセージを通過します。 満足しているゲートウェイは、例えば、配送のために非レンダリング可能か貯蔵できるもの身体の部分を削除することによって、メッセージを変更できます。
Burger Standards Track [Page 3] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[3ページ]。
to the receiving system. Finally, the content gateway can reject a message that the receiving system cannot handle.
受電方式に。 最終的に、満足しているゲートウェイは受電方式が扱うことができないメッセージを拒絶できます。
Although Critical Content processing is not an OPES service, the protocol machinery described in this document meets all of the OPES IAB requirements as stated by RFC 3238 [4]. Section 14 describes this in detail. In particular, unlike the current situation where content gateways silently modified messages, or had abstract rules for modifying them (see the content transformation rules in VPIM, for example), the Critical Content mechanism allows for the sending user to explicitly indicate desired content handling by content gateways
Critical Content処理は作品サービスではありませんが、本書では説明されたプロトコル機械は述べられるとしてのRFC3238[4]によるOPES IAB要件のすべてに会います。 セクション14は詳細にこれについて説明します。 満足しているゲートウェイが静かにメッセージを変更したか、またはそれらを変更するための抽象的ルールを持っていた(例えば、VPIMの満足している変換規則を見てください)現在の状況と異なって、特に、Critical Contentメカニズムは、送付ユーザが満足しているゲートウェイのそばで明らかに必要な満足している取り扱いを示すのを許容します。
NOTE: This document updates RFC 3204 [5] to separate the Handling parameter from the ISUP/QSIG transport mechanism. The protocol described here is identical in functionality to RFC 3204 with respect to SIP. Future versions of RFC 3204 should reference this document for the Handling parameter, as it is orthogonal to the tunneling of signaling.
以下に注意してください。 このドキュメントは、ISUP/QSIG移送機構とHandlingパラメタを切り離すためにRFC3204[5]をアップデートします。 ここで説明されたプロトコルは機能性がSIPに関してRFC3204と同じです。 RFC3204の将来のバージョンはHandlingパラメタのためのこのドキュメントに参照をつけるべきです、それがシグナリングのトンネリングと直交しているとき。
3. Handling Parameter
3. 取り扱いパラメタ
The Handling parameter is a Content-Disposition [6] parameter inserted by the sending agent to indicate to the content gateway whether to consider the marked body part critical.
Handlingパラメタは著しい身体の部分が重要であると考えるかどうかを満足しているゲートウェイに示すために送付エージェントによって挿入されたContent-気質[6]パラメタです。
A REQUIRED body part is one the sender requires the receiving system to deliver for him to consider the message delivered.
REQUIRED身体の部分は送付者が、彼が、メッセージが配送されたと考えるように受電方式が提供するのを必要とする1です。
An OPTIONAL body part is one the sender doesn't care whether the receiving system delivers it or not. A content gateway can silently delete such body parts if the receiving system cannot deliver the part.
OPTIONAL身体の部分は受電方式がそれを提供するか否かに関係なく、送付者が気にかけないものです。 受電方式が部分を提供できないなら、満足しているゲートウェイは静かにそのような身体の部分を削除できます。
The terms "entity" and "body part" have the meanings defined in [6].
用語「実体」と「身体の部分」には、[6]で定義された意味があります。
3.1. REQUIRED
3.1. 必要です。
"Handling=REQUIRED" signifies that this body part is critical to the sender.
「取り扱いはREQUIREDと等しいこと」が、送付者にとって、この身体の部分が重要であることを意味します。
If the content gateway cannot pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action.
満足しているゲートウェイがREQUIREDであることが示される身体の部分を通過できないなら、全体のメッセージは失敗しました。 この場合、満足しているゲートウェイは適切な失敗行動を取らなければなりません。
NOTE: We say "appropriate action", because the sender may have suppressed all notifications. In this case, the appropriate action is to silently discard the message. In addition, as a general MIME parameter, the MIME body part may not be in an Internet Mail message.
以下に注意してください。 送付者がすべての通知を抑圧したかもしれないので、私たちは「適切な行動」を言います。 この場合、適切な行動は静かにメッセージを捨てることです。 さらに、一般的なMIMEパラメタとして、MIME身体の部分がインターネットメールメッセージにないかもしれません。
Burger Standards Track [Page 4] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[4ページ]。
Moreover, in the SIP case, the appropriate notification is a status return code, not a delivery notification.
そのうえ、SIP場合では、適切な通知は配送通知ではなく、状態復帰コードです。
3.2. OPTIONAL
3.2. 任意
"Handling=OPTIONAL" signifies that the sender does not care about notification reports for this body part.
「取り扱いはOPTIONALと等しいこと」が、送付者がこの身体の部分のための通知レポートを心配しないのを意味します。
If the content gateway cannot pass a body part marked OPTIONAL, the receiving system may silently delete the body part. The receiving system MUST NOT return a delivery failure, unless parts marked REQUIRED have also failed.
満足しているゲートウェイがOPTIONALであることが示される身体の部分を通過できないなら、受電方式は静かに身体の部分を削除するかもしれません。 また、REQUIREDであることが示される部品が失敗していないなら、受電方式は配信障害を返してはいけません。
3.3. Default Values
3.3. デフォルト値
The default value for Handling for a given body part is REQUIRED. This enables the existing notification mechanisms to work for sending agents that do not know about the content notification entity. All body parts are critical, because they have the default marking of REQUIRED.
与えられた身体の部分へのHandlingのためのデフォルト値はREQUIREDです。 これは、既存の通知メカニズムが満足している通知実体に関して知らない送付エージェントのために働くのを可能にします。 それらにはREQUIREDをマークするデフォルトがあるので、すべての身体の部分が重要です。
NOTE: In the case of Internet mail, critical content processing is a function of the content gateway and not the mail transfer agent (MTA) or user agent (UA). Often, the entity performing content gateway processing is the receiving UA. However, in this case the UA is acting as a content gateway. Thus the default action for any Content-Disposition [6]-compliant user agent to ignore unrecognized disposition parameters ensures that this mechanism is compatible with the Internet architecture.
以下に注意してください。 インターネット・メールの場合では、重要な満足している処理はメール転送エージェント(MTA)かユーザエージェント(UA)ではなく、満足しているゲートウェイの機能です。 しばしば、満足しているゲートウェイ処理を実行する実体は受信UAです。 しかしながら、この場合、UAは満足しているゲートウェイとして機能しています。 したがって、どんなContent-気質の[6]対応することのユーザエージェントも認識されていない気質パラメタを無視するデフォルト動作は、このメカニズムがインターネットアーキテクチャと互換性があるのを確実にします。
NOTE: This parameter is fully backwards compatible and works as expected for Internet mail and SIP.
以下に注意してください。 このパラメタが完全に遅れている、コンパチブル、そして、インターネット・メールとSIPのために予想される作品。
NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from the Internet. However, these systems are really acting in the capacity of an Internet Voice Mail system. In this case, one would expect the implementation to provide Internet Voice Mail semantics to Internet Voice Mail messages.
以下に注意してください。 いくつかのVPIMv2実装がインターネットから任意のメールを受け取ることができます。 しかしながら、これらのシステムは本当にインターネットVoiceメールシステムの容量で作動しています。 この場合、人は、実装がインターネットVoiceメール意味論をインターネットVoiceメールメッセージに提供すると予想するでしょう。
3.4. Other Values
3.4. 他の値
The content gateway MUST treat unrecognized values as REQUIRED. This is to provide backward compatibility with future uses of the Content-Criticality entity.
満足しているゲートウェイは認識されていない値をREQUIREDとして扱わなければなりません。 これは、Content-臨界実体の将来の用途を後方の互換性に提供するためのものです。
NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is something the sender wants the receiver to get, but would not want the message rejected outright if the IMPORTANT body part fails, but
以下に注意してください。 可能な新しい値はIMPORTANTです。 しかし、IMPORTANT身体の部分が失敗するならメッセージを完全に拒絶して欲しくないだろうというのを除いて、IMPORTANT身体の部分は何か送付者が、受信機に得て欲しいものです。
Burger Standards Track [Page 5] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[5ページ]。
they do want notification of the failure. However, as no implementations do IMPORTANT, it is not important to this version of this document.
彼らは失敗の通知が欲しいです。 しかしながら、どんな実装もIMPORTANTをしないとき、それはこのドキュメントのこのバージョンに重要ではありません。
4. Collected Syntax
4. 集まっている構文
The format of the collected syntax is in accordance with the ABNF of [7]. Note that per RFC 2183 [6], the HANDLING Content-Disposition parameter is not case sensitive. In addition, the notification-type is not case sensitive.
[7]のABNFによると、集まっている構文の形式があります。 HANDLING Content-気質パラメタがRFC2183[6]単位で大文字と小文字を区別していないことに注意してください。 さらに、通知タイプは大文字と小文字を区別していません。
"handling" "=" notification-type CRLF
「取り扱い」は通知タイプCRLFと「等しいです」。
notification-type = "REQUIRED" / "OPTIONAL" /
other-handling / generic-param
通知タイプは「必要である」か「任意」の、または、他に扱っている/ジェネリック-paramと等しいです。
other-handling = token
他に扱っている=トークン
5. Notification
5. 通知
One obvious application of critical content is generating a (non-) delivery notification in the Internet mail environment. If the value of the field is OPTIONAL, the content gateway MUST NOT generate a notification. If the value of the field is REQUIRED, the content gateway MAY generate a notification, based on the normal notification request mechanisms. Normal notification request mechanisms include specifying the NOTIFY parameter to the SMTP RCPT command [8] and the Disposition-Notification-To header [9].
重要な内容のある明白なアプリケーションがaを生成している、(非、)、インターネット・メール環境における配送通知。 分野の値がOPTIONALであるなら、満足しているゲートウェイは通知を生成してはいけません。 分野の値がREQUIREDであるなら、満足しているゲートウェイは通知を生成するかもしれません、正常な通知要求メカニズムに基づいて。そして、正常な通知要求メカニズムが、SMTP RCPTコマンド[8]にNOTIFYパラメタを指定するのを含んでいる、Disposition通知、ヘッダー[9]。
In SIP, all requests have responses. These responses provide notification in the status code of the response. For the RFC 3204 case, a content gateway generates a 415 (Unsupported Media Type) response if the field is REQUIRED.
SIPでは、すべての要求が応答を持っています。 これらの応答は応答のステータスコードに通知を提供します。 3204年のRFCケースのために、満足しているゲートウェイは分野がREQUIREDであるなら415(サポートされないメディアType)応答を生成します。
If the sending system requests a notification, and a REQUIRED part fails, the content gateway MUST generate a notification for the whole message. Conversely, if the gateway cannot pass on a body part marked OPTIONAL, the gateway MUST NOT generate a notification.
送付システムが通知を要求して、REQUIRED部分が失敗するなら、満足しているゲートウェイは全体のメッセージのための通知を生成しなければなりません。 逆に、ゲートウェイがOPTIONALであることが示される身体の部分を伝えることができないなら、ゲートウェイは通知を生成してはいけません。
NOTE: This implies that the content gateway must examine the entire message to determine whether it needs to generate a notification. However, the content gateway need not examine the message if it knows it can store and forward all media types. Said differently, Internet e-mail MTAs or gateways can, by default, handle any arbitrary MIME- encapsulated type. Some voice mail systems, on the other hand, cannot store binary attachments at all, such as application/ms-word. The voice mail content gateway, in this example, would be scanning for non-renderable body parts in any event.
以下に注意してください。 これは、満足しているゲートウェイがそれが、通知を生成する必要であるかどうか決定する全体のメッセージを調べなければならないのを含意します。 しかしながら、すべてのメディアタイプを保存して、進めることができるのを知っているなら、満足しているゲートウェイはメッセージを調べる必要はありません。 異なって言われていて、インターネット電子メールMTAsかゲートウェイがデフォルトでどんな任意のMIME密閉型も扱うことができます。 他方では、いくつかのボイスメールシステムは全くmsアプリケーション/単語などの2進の付属を保存できません。 この例では、ボイスメール内容ゲートウェイはとにかく非レンダリング可能身体の部分にスキャンされているでしょう。
Burger Standards Track [Page 6] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[6ページ]。
5.1. DSN vs. MDN Generation
5.1. DSN対MDN世代
The content gateway generates a delivery status notification (DSN) [9] if it operates as a gateway. The content gateway generates a Message Disposition Notification (MDN) [10] if it operates as a mail user agent. Section 6 describes the operating modes of a content gateway. In short, if there is a MTA that "delivers" the message to the content gateway for processing, the MTA takes responsibility for DSN processing. In this case, the only option available to the content gateway is to generate MDNs. If the content gateway operates as a MTA, then it generates DSNs. DSN generation is the preferred option.
[9] ゲートウェイとして作動するなら、満足しているゲートウェイは、配送状態が通知(DSN)であると生成します。 メールユーザエージェントとして作動するなら、満足しているゲートウェイは、Message Disposition Notification(MDN)が[10]であると生成します。 セクション6は満足しているゲートウェイのオペレーティング・モードを説明します。 要するに、処理のために満足しているゲートウェイにメッセージを「提供する」MTAがあれば、MTAはDSN処理に責任を取ります。 この場合、満足しているゲートウェイに利用可能な唯一のオプションはMDNsを生成することです。 満足しているゲートウェイがMTAとして作動するなら、それはDSNsを生成します。 DSN世代は都合のよいオプションです。
If the content gateway is part of a SIP endpoint, then it generates the appropriate success or error response code.
満足しているゲートウェイがSIP終点の一部であるなら、それは、適切な成功か誤り応答がコードであると生成します。
5.2. Summary
5.2. 概要
The following table summarizes the actions expected of a conforming content gateway.
以下のテーブルは従うことの満足しているゲートウェイに予想された動作をまとめます。
NOTE: This section is normative: it suggests what a content gateway should put into the DSN or MDN.
以下に注意してください。 このセクションは規範的です: それは満足しているゲートウェイがDSNかMDNに置くはずであるものを示します。
NOTE: In the case of SIP, this section is informative. See RFC 3204 for the normative set of actions on failure.
以下に注意してください。 SIPの場合では、このセクションは有益です。 標準のセットの失敗への機能に関してRFC3204を見てください。
Table 1 - Expected Actions
テーブル1--予想された動作
+--------------------------------------+
| Sending UA Has Marked Body Part |
|---------------------+----------------|
| REQUIRED | OPTIONAL |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Deliverable | Appropriate Action | ignore |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Undeliverable | Fail Entire Message | ignore |
+--------------------+--------------------------------------+
+--------------------------------------+ | 送付UAは身体の部分を示しました。| |---------------------+----------------| | 必要です。| 任意| +--------------------+---------------------+----------------+ | ボディーPartはそうです。| | | | 提出物| 適切な行動| 無視します。| +--------------------+---------------------+----------------+ | ボディーPartはそうです。| | | | Undeliverable| 全体のメッセージに失敗してください。| 無視します。| +--------------------+--------------------------------------+
The "Appropriate Action" is the action the content gateway would take given the context of execution. For example, if a sender requests return receipt and the receiver reads a HANDLING body part, the receiving UA must generate the appropriate MDN (following the rules for MDN). Likewise, if the content gateway cannot deliver the body part and the body part is critical, the content gateway generates the appropriate DSN or MDN.
「適切な行動」は実行の文脈を考えて、満足しているゲートウェイが取る行動です。 例えば、送付者が、領収書を返してください。そうすれば、受信機がHANDLING身体の部分を読むよう要求するなら、受信UAは適切なMDNを生成しなければなりません(MDNのために約束を守って)。 同様に、満足しているゲートウェイが身体の部分を提供できないで、身体の部分が重要であるなら、満足しているゲートウェイは適切なDSNかMDNを生成します。
Burger Standards Track [Page 7] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[7ページ]。
"Optional" means the content gateway ignores the disposition of the body part. The content gateway treats the message as if the body part was not present in the message.
「任意」は、満足しているゲートウェイが身体の部分の気質を無視することを意味します。 まるで身体の部分がメッセージに存在していないかのように満足しているゲートウェイはメッセージを扱います。
6. Signed Content
6. 内容であると署名されます。
RFC 1847 [11] describes how to apply digital signatures to a MIME body part. In brief, a multipart/signed body part encapsulates the body part of interest, or the "content object", in a MIME body part and the control information needed to verify the object, or the "protocol" in the lexicon of RFC 1847, in a second MIME body part. Here is an example taken from RFC 1847.
RFC1847[11]はMIME身体の部分にデジタル署名を適用する方法を説明します。 要するに、複合の、または、署名している身体の部分は、ボディーが興味がある部分、または「満足しているオブジェクト」であるとカプセル化します、RFC1847のレキシコンでオブジェクト、または「プロトコル」について確かめるのに必要であるMIME身体の部分と制御情報で、2番目のMIME身体の部分で。 ここに、RFC1847から取られた例があります。
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
コンテントタイプ: 複合か署名される。 =「タイプ/STYPE」について議定書の中で述べてください。 micalgは"MICALG"と等しいです。 「境界であると署名される」境界=
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
--署名している境界コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」
This is some text to be signed although it could be
any type of data, labeled accordingly, of course.
それがそれに従って、ラベルされたどんなタイプに関するデータであるかもしれませんが、これが署名される何らかのテキストである、もちろん。
--Signed Boundary
Content-Type: TYPE/STYPE
--署名している境界コンテントタイプ: タイプ/STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
プロトコル「タイプ/STYPE」へのCONTROL情報がここにあるでしょう。
--Signed Boundary--
--境界であると署名されます--
Figure 1 - Signed Content MIME Type
図1--署名している満足しているMIMEの種類
There are three places where one may place the criticality indicator for a multipart/signed body part. One could mark the multipart/signed object, the content object, the control object, or any combination of the three.
3つの場所が複合の、または、署名している身体の部分に臨界インディケータを置くかもしれないところにあります。 1つは複合の、または、署名しているオブジェクト、満足しているオブジェクト、コントロールオブジェクト、または3つのもののどんな組み合わせもマークするかもしれません。
The disposition of REQUIRED body parts follow the guidelines found in RFC 2480 [12].
REQUIRED身体の部分の気質はRFC2480[12]で見つけられたガイドラインに従います。
A critical content indicator on a multipart/signed body part means the sending party requires true end-to-end signature verification. Thus the gateway needs to pass the enclosure intact. If the system or network of lesser capability cannot do signature verification and the signed enclosure is REQUIRED, the gateway MUST reject the message.
複合の、または、署名している身体の部分の上の重要な満足しているインディケータは、送付パーティーが終わりから終わりへの本当の署名照合を必要とすることを意味します。 したがって、ゲートウェイは、完全な状態で包囲を渡す必要があります。 より少ない能力のシステムかネットワークが署名照合ができないで、署名している包囲がREQUIREDであるなら、ゲートウェイはメッセージを拒絶しなければなりません。
Burger Standards Track [Page 8] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[8ページ]。
A critical content indicator on a signature means that either the receiving endpoint must be able to do signature verification, or the gateway needs to verify the signature before forwarding the message. If the content does not pass verification, the gateway MUST reject the message.
署名での重要な満足しているインディケータは、受信終点が署名照合ができなければならないか、またはゲートウェイが、メッセージを転送する前に署名について確かめる必要を意味します。 内容が検証を通過しないなら、ゲートウェイはメッセージを拒絶しなければなりません。
A critical content indicator on the enclosed material specifies whether that material is critical to the message as a whole. If the signature is marked OPTIONAL and the enclosed material is marked REQUIRED, the gateway MAY strip out the signature information if the system or network of lesser capability cannot do signature verification. However, if possible, we STRONGLY RECOMMEND the gateway do signature verification and indicate tampering to the recipient.
同封の材料の上の重要な満足しているインディケータは、その材料が全体でメッセージに重要であるかどうか指定します。 署名がOPTIONALであるとマークされて、同封の材料がREQUIREDであるとマークされて、より少ない能力のシステムかネットワークが署名照合ができないなら、ゲートウェイは署名情報を取り除くかもしれません。 しかしながら、できれば、私たち、STRONGLY RECOMMEND、ゲートウェイは、署名照合をして、改ざんを受取人に示します。
7. Encrypted Content
7. 暗号化された内容
RFC 1847 [11] describes how to encrypt a MIME body part. In brief, a
multipart/encrypted body part encapsulates the control information
("protocol" in the lexicon of RFC 1847) for the encrypted object and
the second containing the encrypted data (application/octet-stream).
Here is an example taken from RFC 1847.
RFC1847[11]はMIME身体の部分を暗号化する方法を説明します。 要するに、複合の、または、暗号化された身体の部分は、コントロールが暗号化されたオブジェクトと2番目のための暗号化されたデータ(八重奏アプリケーション/ストリーム)を含む情報(RFC1847のレキシコンで「議定書の中で述べる」)であるとカプセル化します。 ここに、RFC1847から取られた例があります。
Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
boundary="Encrypted Boundary"
コンテントタイプ: 複合か暗号化される。 =「タイプ/STYPE」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。
--Encrypted Boundary
Content-Type: TYPE/STYPE
--暗号化された境界コンテントタイプ: タイプ/STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
プロトコル「タイプ/STYPE」へのCONTROL情報がここにあるでしょう。
--Encrypted Boundary
Content-Type: application/octet-stream
--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリーム
Content-Type: text/plain; charset="us-ascii"
All of this indented text, including the indented headers,
would be unreadable since it would have been encrypted by
the protocol "TYPE/STYPE". Also, this encrypted data could
be any type of data, labeled accordingly, of course.
コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」 それはプロトコル「タイプ/STYPE」によって暗号化されたでしょう、したがって、入り込まれたヘッダーを含むこの入り込まれたテキストのAllは読みにくいでしょう。 また、この暗号化されたデータがそれに従って、ラベルされたどんなタイプに関するデータであるかもしれない、もちろん。
--Encrypted Boundary--
--境界を暗号化します--
One may sensibly place a criticality indicator on the encrypted enclosure (multipart/encrypted) body part. If the endpoint can decrypt the message, then the gateway passes the body part in its entirety.
分別よく暗号化された包囲の(複合か暗号化される)の身体の部分に臨界インディケータを置くかもしれません。 終点がメッセージを解読することができるなら、ゲートウェイは身体の部分を全体として通過します。
Burger Standards Track [Page 9] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[9ページ]。
If one marks the control object REQUIRED, then the sending UA requires end-to-end encryption. If the endpoint cannot decrypt the message, then the gateway MUST reject the message.
1つが、コントロールオブジェクトがREQUIREDであるとマークするなら、発信しているUAは終端間暗号化を必要とします。 終点がメッセージを解読することができないなら、ゲートウェイはメッセージを拒絶しなければなりません。
If the control object is OPTIONAL, and the endpoint cannot decrypt the message, and the gateway can decrypt the message, then the gateway MAY decrypt the message and forward the cleartext message. The sending user has explicitly given permission for the gateway to decrypt the message by marking the control object OPTIONAL. Recall that the default indication for MIME body parts is REQUIRED. Thus if the user takes no explicit action, the content gateway will assume the user wished end-to-end encryption.
コントロール目的がOPTIONALであり、終点がメッセージを解読することができないで、ゲートウェイがメッセージを解読することができるなら、ゲートウェイは、メッセージを解読して、cleartextメッセージを転送するかもしれません。 送付ユーザは、コントロールオブジェクトがOPTIONALであるとマークすることによってメッセージを解読するために明らかにゲートウェイに許可しました。 MIME身体の部分のためのデフォルト指示がREQUIREDであると思い出してください。 したがって、ユーザがどんな明白な行動も取らないと、満足しているゲートウェイは終端間暗号化であることが願われていたユーザを仮定するでしょう。
Marking the encrypted content, without marking the encrypted enclosure, is problematic. This is because the gateway has to decrypt the encrypted data to retrieve the header. However, it is unlikely for the gateway to have the capability (e.g., keys) to decrypt the encrypted data. If a sending UA wishes to mark encrypted data as not REQUIRED, the sending UA MUST mark the encrypted content as not REQUIRED. Clearly, if the sending UA marks the encrypted content as REQUIRED, the gateway will apply the REQUIRED processing rules. Moreover, if the sending UA does not mark the encrypted content as REQUIRED, the gateway, unless it can decrypt the data, will treat the encrypted content as REQUIRED. This occurs because gateways always treat unmarked content as REQUIRED (see Section 3.3).
暗号化された包囲をマークしないで暗号化された内容をマークするのは問題が多いです。 これはゲートウェイがヘッダーを救済するために暗号化されたデータを解読しなければならないからです。 しかしながら、ゲートウェイには、それは暗号化されたデータを解読する能力(例えば、キー)がありそうにはありません。 送付UAがどんなREQUIREDとしても暗号化されたデータをマークしたくないなら、送付UaはどんなREQUIREDとしても暗号化された内容をマークしてはいけません。 明確に、発信しているUAがREQUIREDとして暗号化された内容をマークすると、ゲートウェイはREQUIRED処理規則を適用するでしょう。 そのうえ、データを解読することができないで、発信しているUAがREQUIREDとして暗号化された内容をマークしないと、ゲートウェイは暗号化された内容をREQUIREDとして扱うでしょう。 ゲートウェイがいつも無印の内容をREQUIREDとして扱うので(セクション3.3を見てください)、これは起こります。
8. Status Code
8. ステータスコード
The critical content indication, in itself, does not guarantee any notification. Notification follows the rules described in [3], [8], and [9].
重要な満足している指示は本来少しの通知も保証しません。 通知は[3]、[8]、および[9]で説明された規則に従います。
NOTE: The content of actual DSNs or MDNs are beyond the scope of this document. This document only specifies how to mark a critical body part. On the other hand, we do envision sensible DSN and MDN contents. For example, DSNs should include the appropriate failure code as enumerated in [13]. Likewise, MDNs should include the failure code in the MDN "Failure:" field.
以下に注意してください。 実際のDSNsかMDNsの内容はこのドキュメントの範囲を超えています。 このドキュメントは重要なボディーが部分であるとマークする方法を指定するだけです。 他方では、私たちは分別があるDSNとMDNコンテンツを思い描きます。 例えば、DSNsは[13]で列挙されるように適切な失敗コードを含んでいるはずです。 同様に、MDNsがMDNの失敗コードを含んでいるはずである、「失敗:」 さばきます。
If the receiving system is to generate a notification based on its inability to render or store the media type, the notification should use the status code 5.6.1, "Media not supported", from [10].
通知が受電方式がメディアタイプを表すことができないか、保存できないことに基づく通知を生成することであるなら、ステータスコードを使用するべきである、5.6、.1、[10]からの「サポートされなかったメディア。」
For the SIP case, all requests have notification provided by the status response message. Per RFC 3204, a content gateway generates a 415 (Unsupported Media Type) response.
SIPケースのために、すべての要求で、状態応答メッセージは通知を提供します。 RFC3204に従って、満足しているゲートウェイは415(サポートされないメディアType)応答を生成します。
Burger Standards Track [Page 10] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[10ページ]。
9. Requirements for Critical Content
9. 重要な内容のための要件
This section is informative.
このセクションは有益です。
9.1. Needs
9.1. 必要性
The need for a critical content identification mechanism comes about because of the internetworking of Internet mail systems with messaging systems that do not fulfill all of the semantics of Internet mail. Such legacy systems have a limited ability to render or store all parts of a given message. This document will use the case of an Internet mail system exchanging electronic messages with a legacy voice messaging system for illustrative purposes.
重要な満足している識別メカニズムの必要性はインターネット・メールシステムのインターネットワーキングでインターネット・メールの意味論のすべてを実現させないメッセージシステムで生じます。 そのようなレガシーシステムには、与えられたメッセージのすべての部分をレンダリングするか、または保存する限られた能力があります。 このドキュメントは、説明に役立った目的のためにレガシー声のメッセージシステムと電子メッセージを交換しながら、インターネット・メールシステムに関するケースを使用するでしょう。
Electronic mail has historically been text-centric. Extensions such as MIME [14] enable the user agents to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video.
電子メールは歴史的にテキスト中心でした。 MIME[14]などの拡大は、ユーザエージェントが複合マルチメディアメッセージを送って、受け取るのを可能にします。 ポピュラーなマルチメディアデータ型は2進のワープロ文書、2進のビジネスプレゼンテーショングラフィックス、声、およびビデオを含んでいます。
Voice mail has historically been audio-centric. Many voice-messaging systems only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi- part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video.
ボイスメールはオーディオに歴史的に中心でした。 多くの声メッセージシステムが声を表すだけです。 ファックスなどの拡大は、ボイスメールシステムが発信して、ファックスイメージを受け取って、マルチ部分声とファックス通信を引き起こすのを可能にします。 いくつかのボイスメールシステムが、テキストからスピーチかファックスで送るテキスト技術を使用することでテキストを表すことができます。 理論的に可能ですが、今日、なにもビデオをレンダリングできません。
An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice-messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. In most cases, the recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment.
音声メッセージングサービスとデスクトップメール・クライアントアプリケーションの間の置き換えの重要な一面は声メッセージングプラットホームのレンダリング能力がデスクトップメール・クライアントのレンダリング能力よりはるかにしばしば少ないということです。 メール場合では、送付者は期待を持っています。受取人はマルチメディアメッセージのすべての成分を受けます。 したがって、受取人がすべての身体の部分をレンダリングできるというわけではなくても、これはそうです。 多くの場合、受取人は、適切なレンダリングツールを見つけるか、または彼女が特別の付属を読むことができないと送付者に言うことができます。
This is an important issue. By definition, a MIME-enabled user agent, conforming to [15], will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts.
これは切迫した課題です。 定義上、aはユーザエージェントをMIMEで可能にしました、[15]、現在の意志または利用可能な造に受取人への身体の部分のすべてを従わせて。 しかしながら、ボイスメールシステムは非声のオブジェクトを保存できないかもしれません。 そのうえ、ボイスメールシステムは、「非-提出物」メッセージの部品があったことを受取人に通知できないかもしれません。
The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this with the case with normal data delivery. Traditional message
通常、受電方式が身体の部分をレンダリングできないことは永久的な失敗です。 メッセージのRetransmissionは今後のうまくいっている配送の見込みを改良しないでしょう。 通常のデータ配送でこれをケースに対して対照してください。 伝統的なメッセージ
Burger Standards Track [Page 11] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[11ページ]。
failures, such as a garbled message or disabled link will benefit from retransmission.
誤り伝えられたメッセージか障害があるリンクなどの失敗は「再-トランスミッション」の利益を得るでしょう。
This situation is fundamentally different from normal Internet mail. In the Internet mail case, either the system delivered the message, or it didn't. There is no concept of a system partially delivering a message.
この状況は正常なインターネット・メールと基本的に異なっています。 インターネット・メール場合では、メッセージが提供されたシステムかそれのどちらかはそうしませんでした。 部分的に伝言をもたらすシステムの概念が全くありません。
In addition, there are many situations where the sender would not mind if the system did not deliver non-critical parts of a message. For example, the sender's user agent may add body parts to a message unbeknownst to the sender. If the receiving system rejected the message because it could not render a hidden body part, the sender would be understandably confused and upset.
さらに、システムがメッセージの非臨界部分を提供しなかったなら、多くの状況が送付者が気にしないところにあります。 例えば、送付者のユーザエージェントは送付者に知られずに身体の部分をメッセージに追加するかもしれません。 隠された身体の部分をレンダリングできなかったので受電方式がメッセージを拒絶するなら、送付者は、目立って混乱して、動揺しているでしょうに。
Thus, there is a need for a method of indicating to a Mail Transfer Agent (MTA) or User Agent (UA) that the sender considers parts of a message to be critical. From the sender's perspective, he would not consider the message delivered if the system did not deliver the critical parts.
したがって、送付者が、メッセージの部分が重要であると考えるのをメール配達エージェント(MTA)かUserエージェント(UA)に示すメソッドの必要があります。 送付者の見解から、彼はシステムが重要な部品を提供しなかったなら提供されたメッセージを考えないでしょう。
9.2. Current Approaches
9.2. 現在のアプローチ
One method of indicating critical content of a message is to define a profile. The profile defines rules for silently deleting mail body parts based on knowledge of the UA capabilities. Citing the example above, a voice profile can easily declare that MTAs or UAs can silently delete TNEF data and yet consider the message successfully delivered. This is, in fact, the approach taken by VPIMv2 [16].
メッセージの重要な内容を示す1つのメソッドはプロフィールを定義することです。 プロフィールは静かにUA能力に関する知識に基づくメール身体の部分を削除するための規則を定義します。 例を引用して、声のプロフィールは、上では、MTAsかUAsが静かにTNEFデータを削除できると容易に宣言しますが、メッセージが首尾よく提供されていると考えることができます。 事実上、これはVPIMv2[16]によって取られたアプローチです。
Since one aspect of the issue is deciding when to notify the sender that the system cannot deliver part of a message, one could use a partial non-delivery notification mechanism to indicate a problem with delivering a given body part. However, this requires the user request a delivery notification. In addition, the sender may not be aware of parts added by the sending user agent. In this case, a failure notice would mystify the sender.
問題の1つの局面が、システムがメッセージの一部を提供できないようにいつ送付者に通知するかを決めているので、1つは与えられた身体の部分を提供することに関する問題を示すのに部分的な非配送通知メカニズムを使用するかもしれません。 しかしながら、これはユーザ要求a配送通知を必要とします。 さらに、送付者は送付ユーザエージェントによって加えられた部品を意識していないかもしれません。 この場合、失敗通知は送付者を当惑するでしょう。
A straightforward alternative implementation method for marking a body part critical is to use a Critical-Content MIME entity. This has the benefit that criticality is meta information for the body part. However, IMAP servers in particular would need to either put Critical-Content into the BODYSTRUCTURE method or create a new method to retrieve arbitrary MIME entities. Given the experience of trying to get Content-Location accepted by IMAP vendors, we chose not to go that route.
身体の部分が重要であるとマークするための簡単な代替の実装メソッドはCritical-内容MIME実体を使用することです。 臨界は利益ですが、これはそうしました。身体の部分のためのメタ情報。 しかしながら、特にIMAPサーバは、Critical-内容をBODYSTRUCTUREメソッドに入れるか、または任意のMIME実体を検索する新しいメソッドを作成する必要があるでしょう。 IMAPベンダーにContent-位置を受け入れさせようとする経験を考えて、私たちはどんな碁にもそのルートを選びませんでした。
Burger Standards Track [Page 12] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[12ページ]。
What we need is a way of letting the sender indicate what body parts he considers to be critical. The mechanism must not burden the sender with failure notifications for non-critical body parts. The mechanism must conform to the general notification status request mechanism for positive or negative notification. When requested, the mechanism must indicate to the sender when a receiving system cannot deliver a critical body part.
私たちが必要とするものは送付者に彼が、重要であるとどんな身体の部分が考えるかを示させる方法です。 メカニズムは非臨界身体の部分のための失敗通知で送付者を負担してはいけません。 メカニズムは肯定しているか否定している通知のための一般的な通知状態要求メカニズムに一致しなければなりません。 要求されると、メカニズムは、受電方式がいつ重要な身体の部分を提供できないかを送付者に示さなければなりません。
10. The Content Gateway
10. 満足しているゲートウェイ
This section is informative.
このセクションは有益です。
In this section, we use the definition found in RFC 2156 [17] for the term "gateway."
このセクションでは、私たちはRFC2156[17]で見つけられた定義を「ゲートウェイ」という用語に使用します。
We do not strictly use the definition found in RFC 2821 [18] for the term "gateway." In particular, RFC 2821 is discussing a gateway that should not examine the message itself. An RFC 2821 gateway is a transport gateway, that mostly deals with transformations of the SMTP information.
私たちは厳密にRFC2821[18]で見つけられた定義を「ゲートウェイ」という用語に使用しません。 特に、RFC2821はメッセージ自体を調べるはずがないゲートウェイについて議論しています。 RFC2821ゲートウェイが輸送ゲートウェイである、それはSMTP情報の変換にほとんど対処します。
A content gateway is a gateway that connects a first network to a second network. The second network often has lesser capability than the first network. The canonical topology follows. "[MTA]", with square brackets, signifies an optional component.
満足しているゲートウェイは2番目のネットワークに最初のネットワークを接続するゲートウェイです。 2番目のネットワークには、最初のネットワークより少ない能力がしばしばあります。 正準なトポロジーは続きます。 角括弧で、「[MTA]」は任意のコンポーネントを意味します。
+---------+
+---------+ +-----+ | | +-------+ +-----------+
| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
| UA | +-----+ | Gateway | +-------+ | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
+---------+ +---------+ +-----+ | | +-------+ +-----------+ | 発信します。|=...=|[MTA]|===| 内容|=...=| [MTA]|===| 受信します。| | Ua| +-----+ | ゲートウェイ| +-------+ | Ua| +---------+ | | +-----------+ +---------+ 最初に、ネットワーク第2ネットワーク
Figure 2 - Content Gateway Topology
図2--満足しているゲートウェイトポロジー
The content gateway can be the last hop before the receiving MTA. The content gateway can be between networks, and thus not the last hop before the receiving MTA. The content gateway can be the first MTA the sending UA contacts. Finally, the content gateway can be an integrated component of the receiving MTA.
満足しているゲートウェイは受信MTAの前の最後のホップであるかもしれません。 満足しているゲートウェイはネットワークの間のそうであることができ、その結果、受信の前のいずれの最後のホップもMTAではありません。 満足しているゲートウェイは発信しているUAが連絡する最初のMTAであるかもしれません。 最終的に、満足しているゲートウェイは受信MTAの統合部品であるかもしれません。
For the SIP case, consider each MTA as a SIP Proxy, the Sending UA as a SIP User Agent Client, and the Receiving UA as a SIP User Agent Server.
SIPケースには、各MTAがSIP Proxyと、SIP UserエージェントClientとしてのSending UAと、SIP UserエージェントServerとしてReceiving UAであるとみなしてください。
Burger Standards Track [Page 13] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[13ページ]。
10.1. Integrated Content Gateway
10.1. 統合満足しているゲートウェイ
In this situation, the receiving user agent is integrated with the content gateway. The integrated content gateway knows the capabilities of the user agent. The topology is as follows.
この状況で、受信ユーザエージェントは満足しているゲートウェイについて統合しています。 統合満足しているゲートウェイはユーザエージェントの能力を知っています。 トポロジーは以下の通りです。
+---------------------+
+---------+ +-----+ | : |
| Sending |=...=|[MTA]|===| Content : Receiving |
| UA | +-----+ | Gateway : UA |
+---------+ | : |
+---------------------+
First Network Second Network
+---------------------+ +---------+ +-----+ | : | | 発信します。|=...=|[MTA]|===| 内容: 受信します。| | Ua| +-----+ | ゲートウェイ: Ua| +---------+ | : | +---------------------+ 最初に、ネットワーク第2ネットワーク
Figure 3 - Integrated Content Gateway
図3--統合満足しているゲートウェイ
The processing of ISUP and QSIG objects, as described in [5], is an example of an integrated gateway.
[5]で説明されるISUPとQSIGオブジェクトの処理は統合ゲートウェイに関する例です。
10.2. Disaggregated Delivery Network
10.2. Disaggregated配送ネットワーク
A degenerate case, although one that does occur, is where the content gateway sits behind the final MTA. This happens when one implements the content gateway as a post-processing step to a normal delivery. For example, one could configure a mail handling system to deliver the message to a queue or directory, where the content gateway process picks up the message. If there were any directives for DSN processing, the delivering MTA would execute them. For example, the message could have requested notification on successful delivery. The delivering MTA, having delivered the message to the queue, would consider the message delivered and thus notify the sender of such. However, the content gateway process could then discover that the receiving UA cannot render the message. In this case, the content gateway generates a NDN, as it is the only option available.
起こるのが最終的なMTAの後ろに満足しているゲートウェイがあるところであることの堕落したケース。 1つが正常分娩への後工程ステップとして満足しているゲートウェイを実装すると、これは起こります。 例えば、1つは、待ち行列かディレクトリにメッセージを提供するためにメール取り扱いシステムを構成するかもしれません。(そこでは、満足しているゲートウェイプロセスがメッセージを受信します)。 何かDSN処理のための指示があれば、配送しているMTAはそれらを実行するでしょうに。 例えば、メッセージはうまくいっている配送に関する通知を要求したかもしれません。 配送しているMTAは、メッセージを待ち行列に提供したので、メッセージが配送されたと考えて、その結果、そのようなものについて送付者に通知するでしょう。 しかしながら、そして、満足しているゲートウェイプロセスは、受信UAがメッセージを伝えることができないと発見するかもしれません。 この場合、満足しているゲートウェイは、それが利用可能な唯一のオプションであるので、NDNを生成します。
Delivered
| +---------+
+---------+ +-----+ v | | +-----------+
| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
| UA | +-----+ | Gateway | | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
配送します。| +---------+ +---------+ +-----+ v| | +-----------+ | 発信します。|=...=| MTA|-->ファイル-->| 内容|=...=| 受信します。| | Ua| +-----+ | ゲートウェイ| | Ua| +---------+ | | +-----------+ +---------+ 最初に、ネットワーク第2ネットワーク
Figure 4 - Disaggregated Delivery Network
図4--Disaggregated配送ネットワーク
Burger Standards Track [Page 14] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[14ページ]。
11. Backward Compatibility Considerations
11. 後方の互換性問題
DSN requires ESMTP. If MTAs in the path from the sending UA to the receiving UA do not support ESMTP, then that MTA will reject the DSN request. In addition, the message will default to notification on delay or failure. While not ideal, the sender will know that DSN is not available, and that critical content that fails will get notification.
DSNはESMTPを必要とします。 発信しているUAから受信UAまでの経路のMTAsがESMTPをサポートしないと、そのMTAはDSN要求を拒絶するでしょう。 さらに、メッセージは遅れか失敗に関する通知をデフォルトとするでしょう。 理想的でない間、送付者は、DSNが利用可能でなく、失敗する重要な内容が通知を得るのを知るでしょう。
12. MIME Interactions
12. MIME相互作用
12.1. multipart/alternative
12.1. 複合である、または代替です。
As is true for all Content-Disposition parameters, handling is only in effect for the selected alternative. If the selected alternative has the critical content indicator, then the entire alternative takes on the criticality indicated. That is, if the alternative selected has HANDLING=OPTIONAL, then the content gateway MUST NOT generate any delivery notifications.
そのままで、選択された代替手段だけには、本当に、すべてのContent-気質パラメタに関して、取り扱いは有効です。 選択された代替手段に重要な満足しているインディケータがあるなら、全体の代替手段は示された臨界を帯びます。 すなわち、選択された代替手段がHANDLING=OPTIONALを持っているなら、満足しているゲートウェイは少しの配送通知も生成してはいけません。
NOTE: This statement explicitly shows that HANDLING overrides the DSN and MDN request mechanisms.
以下に注意してください。 この声明は、HANDLINGオーバーライドのDSNとMDNがメカニズムを要求するのを明らかに示します。
It is unlikely for a selected alternative to fail, as the content gateway presumably picks the alternative specifically because it can render it.
それは選択された代替手段に失敗しそうにはありません、特にそれをレンダリングできるので満足しているゲートウェイがおそらく代替手段を選ぶとき。
If the selected alternative is a message/rfc822 that encloses a multipart MIME message or the selected alternative is itself a multipart MIME type, the individual top-level body parts follow the HANDLING mechanism described in this document.
選択された代替手段が複合MIMEメッセージを同封するメッセージ/rfc822であるか選択された選択肢がそれ自体で複合MIMEの種類であるなら、個々のトップレベル身体の部分は本書では説明されたHANDLINGメカニズムに従います。
NOTE: This means that a forwarded message's criticality will not affect the forwarding agent's intentions.
以下に注意してください。 これは、転送されたメッセージの臨界が小口運送業者の意志に影響しないことを意味します。
12.2. multipart/related
12.2. 複合である、または関連しています。
Criticality fits in rather well with the multipart/related construction. For example, consider a multipart/related message consisting of a Macintosh data fork and a Macintosh resource fork. For a Microsoft Word document, the data fork is likely to be critical. The receiving system can safely ignore the resource fork.
臨界は複合の、または、関連する工事とかなりよく合っています。 例えば、マッキントッシュデータフォークとマッキントッシュリソースフォークから成る複合の、または、関連するメッセージを考えてください。 マイクロソフトWordドキュメントに関しては、データフォークは重要である傾向があります。 受電方式は安全にリソースフォークを無視できます。
12.3. message/rfc822
12.3. メッセージ/rfc822
Criticality only affects the outermost level of the message or, in the case of multipart/alternative, the outermost level of the selected alternative. Specifically, the receiving system ignores
臨界はメッセージの一番はずれのレベルか複合か代替の場合における、選択された代替手段の一番はずれのレベルに影響するだけです。 明確にシステムが無視する受信
Burger Standards Track [Page 15] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[15ページ]。
criticality indicators in embedded body parts. This avoids the situation of a forwarded message triggering or suppressing undesired reporting. This simply implements the procedures described in [6].
埋め込まれた身体の部分の臨界インディケータ。 これは進められたメッセージの引き金となるか望まれない報告を抑圧する状況を避けます。 これは単に[6]で説明された手順を実装します。
12.4. multipart/signed
12.4. 複合か署名されます。
See Section 6.
セクション6を見てください。
12.5. multipart/encrypted
12.5. 複合か暗号化されています。
See Section 7.
セクション7を見てください。
13. Implementation Examples
13. 実装の例
This section is an informative part of the definition of Criticality. We hope it helps implementers understand the mechanics of the Handling mechanism.
このセクションはCriticalityの定義の有益な部分です。 implementersがHandlingメカニズムの整備士を理解しているのが助けることを願っています。
We will examine two cases. They are how a content gateway processes a message and how a disaggregated content gateway processes a message.
私たちは2つのケースを調べるつもりです。 それらは満足しているゲートウェイがどのようにメッセージを処理するか、そして、「不-集合」満足しているゲートウェイがどのようにメッセージを処理するかということです。
13.1. Content Gateways
13.1. 満足しているゲートウェイ
Content gateways examine the contents of a message from a first network before the gateway forwards the message to a second network. For the purposes of this example, we assume the second network has less capability than the first network. In particular, we expect there will be certain message body types that the gateway cannot pass onto the second network.
2番目のネットワークにメッセージを転送する前に満足しているゲートウェイは最初のネットワークからのメッセージのコンテンツを調べます。 この例の目的のために、私たちは、2番目のネットワークには最初のネットワークより少ない能力があると思います。 特に、私たちは、ゲートウェイが2番目のネットワークに通過できないあるメッセージボディータイプがあると予想します。
Consider a gateway between the Internet and a text-only short message service. A message comes through the gateway containing a text part and a tnef part. The sender marks the text part REQUIRED. The gateway, knowing the capability of the short message service, silently deletes the non-critical, tnef part, passing the critical content to the short message service network. Any subsequent notifications, such as failure notices or delivery notices, follow the normal rules for notification.
インターネットとテキストのみの短いメッセージサービスの間のゲートウェイを考えてください。 メッセージはテキスト部分とtnef部分を含むゲートウェイを通り抜けます。 送付者は、テキスト部分がREQUIREDであるとマークします。 短くメッセージサービスの能力を知っていて、ゲートウェイは静かに非臨界tnef部分を削除します、短いメッセージサービスネットワークに重要な内容を通過して。 失敗通知か引渡通告書などのどんなその後の通知も通知のための正常な規則に従います。
Note the gateway, by silently deleting non-critical content, may affect proprietary message correlation schemes. One can envision the sending UA inserting a body part for tracking purposes. By deleting non-critical content, the content gateway will break such a scheme. If a sending UA understands how to mark critical content, it should use Internet standard mechanisms for tracking messages, such as Message-ID [19].
静かに非臨界内容を削除することによってゲートウェイが独占メッセージ相関関係体系に影響するかもしれないことに注意してください。 人は、発信しているUAが追跡目的のために身体の部分を挿入するのを思い描くことができます。 非臨界内容を削除することによって、満足しているゲートウェイはそのような体系を壊すでしょう。 送付UAが重要な内容をマークする方法を理解しているなら、追跡メッセージにインターネット標準メカニズムを使用するべきです、Message-ID[19]などのように。
Burger Standards Track [Page 16] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[16ページ]。
What if no body parts have critical content indicators? In this case, the entire message is critical. Thus, when the gateway sees the tnef part, it will reject the entire message, generating a DSN with a status code 5.6.1, "Media not supported".
身体の部分がないのに重要な満足しているインディケータがあると、どうなるでしょうか? この場合、全体のメッセージは重要です。 ゲートウェイがtnef部分を見るとき、その結果、全体のメッセージを拒絶するでしょう、ステータスコードでDSNを生成して5.6、.1、「サポートされなかったメディア。」
Likewise, consider a three part message with a text annotation (part 1) to a voice message (part 2) with a vCard [20] (part 3). The sender marks the first two parts REQUIRED. Now, let us assume the receiving MTA (gateway) is a voice mail only system, without even the capability to store text. In this case, the gateway, acting as the receiving MTA, will reject the message, generating a DSN with the status code 5.6.1, "Media not supported".
同様に、vCard[20](パート3)がある音声メール(第2部)とテキスト注釈(第1部)がある3部分メッセージを考えてください。 送付者は、最初の2つの部品がREQUIREDであるとマークします。 今、受信MTA(ゲートウェイ)がボイスメールであると仮定しましょう。テキストを保存する能力さえのないシステムだけ。 受信MTAとして機能して、この場合ゲートウェイはメッセージを拒絶するでしょう、ステータスコードでDSNを生成して5.6、.1、「サポートされなかったメディア。」
13.2. Disaggregated Content Gateway
13.2. 満足しているゲートウェイをDisaggregatedしました。
For this example, we will examine the processing of a three-part message. The first part is a text annotation of the second part, an audio message. The third part is the sender's vCard. The sender marks the first and second parts REQUIRED. In addition, the sender marks the message for read receipt.
この例がないかどうか、私たちは3部分のメッセージの処理を調べるつもりです。 最初の部分は第二部のテキスト注釈、オーディオメッセージです。 3番目の部分は送付者のvCardです。 送付者は、1番目と第二部がREQUIREDであるとマークします。 さらに、送付者は読書領収書へのメッセージをマークします。
For the purposes of example, the telephone user interface (TUI) does not perform text-to-speech conversion. A TUI is a mail user agent (UA) that uses DTMF touch-tone digits for input and audio for output (display).
例の目的のために、電話ユーザーインタフェース(TUI)はテキスト合成を実行しません。 TUIは入力のためのDTMF押しボタン式ケタと出力(ディスプレイ)のためのオーディオを使用するメールユーザエージェント(UA)です。
The TUI is unable to render the first part of the message, the text part. In addition, it is unable to render the third part of the message, the vCard part. Since the sender did not mark the third part of the message REQUIRED, the system ignores the failure of the TUI to render the third part of the message. However, since the sender did mark the first part REQUIRED, and the TUI is unable to render text, the message fails.
TUIはメッセージの最初の部分、テキスト部分をレンダリングできません。 さらに、それはメッセージの3番目の部分、vCard部分をレンダリングできません。 送付者がメッセージREQUIREDの3番目の部分を示さなかったので、システムはTUIがメッセージの3番目の部分をレンダリングしないことを無視します。 しかしながら、送付者が、最初の部分がREQUIREDであるとマークして、TUIがテキストを表すことができないので、メッセージは失敗します。
What happens next is implementation dependent. If the TUI is part of a unified messaging system, a reasonable action is to hold the message for the user. The user can access the message at a later time from a terminal that can render all of the critical body parts. It would be reasonable for the TUI to notify the user about the undeliverable body part.
何が次に起こるかは、実装に依存しています。 TUIがユニファイド・メッセージングシステムの一部であるなら、合理的な動作はユーザへのメッセージを保持することです。 ユーザは後で重要な身体の部分のすべてをレンダリングできる端末からメッセージにアクセスできます。 TUIが「非-提出物」身体の部分に関してユーザに通知するのは、妥当でしょう。
If the TUI is part of a voice messaging system, or if the user does not subscribe to a text-to-speech service, a reasonable action is for the TUI to return a MDN with the disposition "failed" and the failure modifier "5.6.1 (Media not supported)".
ユーザがテキストからスピーチに対するサービスに加入しないならTUIが声のメッセージシステムの一部であるなら、合理的な動作がTUIが気質が「失敗されている」MDNと失敗修飾語を返すことである、「5.6、.1(サポートされなかったメディア)、」
Burger Standards Track [Page 17] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[17ページ]。
14. OPES Considerations
14. 作品問題
Critical Content processing is not a web service. However, some in the Internet community may draw parallels between web services that modify content and an e-mail, SIP, or other MIME-transport service that modifies content.
重要なContent処理はウェブサービスではありません。 しかしながら、インターネットコミュニティの或るものは内容を変更する内容とメールを変更するウェブサービス、SIP、または他のMIME輸送サービスの間に平行線を描くかもしれません。
This section will analyze the Critical Content protocol machinery against the requirements stated in RFC 3238 [4]. The summary is that the protocol described in this document meets all of the requirements of RFC 3238.
このセクションはRFC3238[4]に述べられた要件に対してCritical Contentプロトコル機械を分析するでしょう。 概要は本書では説明されたプロトコルがRFC3238の要件のすべてに会うということです。
14.1. Consideration (2.1): One-Party Consent
14.1. 考慮(2.1): 1パーティの同意
This is the heart of Critical Content. Critical Content enables the sending party to give consent to have the message modified. Gateways that conform to this document will ensure that gateways only modify messages that the sending party has given consent to modify.
これはCritical Contentの中心です。 重要なContentは、送付パーティーがメッセージを変更させるために承諾を与えるのを可能にします。 このドキュメントに一致しているゲートウェイは、ゲートウェイが送付パーティーが変更する同意を与えたというメッセージを変更するだけであるのを確実にするでしょう。
14.2. Consideration (2.2): IP-layer Communications
14.2. 考慮(2.2): IP-層のコミュニケーション
The content gateway is an addressable IP-entity. Moreover, all of the relevant protocols (SMTP, SIP, HTTP, etc.) all explicitly make the presence of the gateway known to the endpoints.
満足しているゲートウェイはアドレス可能なIP-実体です。 そのうえ、関連プロトコル(SMTP、SIP、HTTPなど)のすべてがゲートウェイの存在を終点にすべて明らかに知らせます。
14.3. Consideration (3.1): Notification - Sender
14.3. 考慮(3.1): 通知--送付者
Again, this is the point of this document. The sender explicitly gets notification if the gateway would remove a Critical Content body part.
一方、これはこのドキュメントの先です。 ゲートウェイがCritical Content身体の部分を取り除くなら、送付者は明らかに通知を得ます。
14.4. Consideration (3.2): Notification - Receiver
14.4. 考慮(3.2): 通知--受信機
The nature of the receiving system dictates that end users understand that the messages have been changed.
受電方式の本質は、エンドユーザが、メッセージが変えられたのを理解していると決めます。
14.5. Consideration (3.3): Non-Blocking
14.5. 考慮(3.3): 非ブロッキング
By definition, the endpoint cannot receive non-modified content, so this requirement does not apply.
定義上、終点が非変更された内容を受け取ることができないので、この要件は適用されません。
14.6. Consideration (4.1): URI Resolution
14.6. 考慮(4.1): URI解決
Clearly, one is sending mail (SMTP), a message (SIP), or fetching a document (HTTP). The machinery described in this document does not alter the content itself or the access mechanism. Thus it is compliant with this requirement.
明確に、1つは、発信メール(SMTP)、メッセージ(SIP)、またはドキュメント(HTTP)をとって来ることです。 本書では説明された機械は内容自体かアクセス機構を変更しません。 したがって、それはこの要件で言いなりになっています。
Burger Standards Track [Page 18] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[18ページ]。
14.7. Consideration (4.2): Reference Validity
14.7. 考慮(4.2): 参照の正当性
Since the protocol described in this document does not alter the content itself, inter- and intra-document references are not altered. However, intra-document references to removed body parts will fail. On the other hand, the sender explicitly marked those body parts as being disposable. Thus the sender is aware of the possibility the parts may not arrive at the receiver.
そして、以来本書では説明されたプロトコルが内容自体を変更しない、相互、イントラドキュメント参照は変更されません。 しかしながら、取り除かれた身体の部分のイントラドキュメント参照は失敗するでしょう。 他方では、送付者は使い捨てであるとして明らかにそれらの身体の部分を示しました。 したがって、送付者は部品が受信機に到着しないかもしれない可能性を意識しています。
14.8. Consideration (4.3): Architecture Extensions
14.8. 考慮(4.3): アーキテクチャ拡大
Since the protocol described in this document meets Considerations 4.1 and 4.2, this requirement does not apply.
本書では説明されたプロトコルがConsiderations4.1と4.2に会うので、この要件は適用されません。
14.9. Consideration (5.1): Privacy
14.9. 考慮(5.1): プライバシー
The privacy policy of this protocol is explicit. In particular, the protocol honors end-to-end security.
このプロトコルのプライバシーに関する方針は明白です。 特に、プロトコルは終わりから終わりへのセキュリティを光栄に思います。
15. Security Considerations
15. セキュリティ問題
Sending UA's can use signatures over critical content indicators to ensure the integrity of the indicator.
送付UAのものは、インディケータの保全を確実にするのに重要な満足しているインディケータの上の署名を使用できます。
The gateway MUST honor signature processing. In particular, if the sending UA marks the signature components REQUIRED, and the endpoint cannot do MIME signature processing, the gateway MUST establish an appropriate signature mechanism between the gateway and the endpoint. In this case, the gateway must be secure, as it can become a target point for tampering with the signed components of the message.
ゲートウェイは署名処理を光栄に思わなければなりません。 発信しているUAが、署名コンポーネントがREQUIREDであるとマークして、終点がMIME署名処理ができないなら、特に、ゲートウェイはゲートウェイと終点の間の適切な署名メカニズムを確立しなければなりません。 この場合、ゲートウェイは安全であるに違いありません、メッセージの署名している成分をいじるためのターゲット点になることができるとき。
Receiving systems and users should not place any authentication value on the Handling parameter.
受電方式とユーザは少しの認証値もHandlingパラメタに置くべきではありません。
Note that by design, and under the sending user's request, a content gateway will silently delete unimportant body parts. Critical content gives the sender the ability to determine the acceptable level integrity of the delivered message. That is, the message as the content gateway actually passes it on is, in fact, representative of the sender's intentions.
デザイン、および送付ユーザの要求で、満足しているゲートウェイが静かに重要でない身体の部分を削除することに注意してください。 重要な内容は提供されたメッセージの合格水準保全を決定する能力を送付者に与えます。 満足しているゲートウェイが実際にそれを伝えるとき、事実上、すなわち、メッセージは送付者の意志の代表です。
16. IANA Considerations
16. IANA問題
RFC 3204 already registered the Handling parameter. It is collected here only for reference and as a placeholder for use both for further expansion in the future and as the normative reference for other documents that need to reference the Handling parameter.
RFC3204は既にHandlingパラメタを示しました。 それは使用の将来、Handlingパラメタを参照に必要とする他のドキュメントに関する引用規格とした一層の拡張の両方のために参照だけとプレースホルダとしてここに集められます。
Burger Standards Track [Page 19] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[19ページ]。
Per section 9 of [6], here is the IANA registration for Handling.
[6]のセクション9に従って、HandlingのためのIANA登録がここにあります。
To: IANA@IANA.ORG Subject: Registration of new Content-Disposition parameter
To: IANA@IANA.ORG Subject: 新しいContent-気質パラメタの登録
Content-Disposition parameter name: HANDLING
満足している気質パラメタ名: 取り扱い
Allowable values for this parameter: REQUIRED OPTIONAL
このパラメタのための許容量: 任意の状態で、必要です。
Description: Marks the body part as required for delivery (REQUIRED) or can be silently discarded (OPTIONAL). See RFC <this document> and RFC 3204.
記述: 配送(REQUIRED)のために必要に応じてボディーが部分であるとマークするか、または静かに捨てることができます(OPTIONAL)。 RFC<を見てください。このドキュメント>とRFC3204。
Per RFC 2183, the Content-Disposition parameter name is not case sensitive. Per RFC 3459, the values of the parameter are also not case sensitive.
RFC2183に従って、Content-気質パラメタ名は大文字と小文字を区別していません。 また、RFC3459に従って、パラメタの値も大文字と小文字を区別していません。
17. References
17. 参照
17.1 Normative References
17.1 標準の参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, P., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、P.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[4] IAB, Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[4] IAB、フロイド、S.、およびL.Daigle、「開いているPluggableのためのIAB建築するのと方針問題はサービスを斜めに進みます」、RFC3238、2002年1月。
[5] Zimmerer, E., Peterson, E., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[5]ZimmererとE.とピーターソンとE.とVemuriとA.、オングとL.とAudetとF.とワトソンとM.とM.Zonoun、「ISUPとQSIG ObjectsのためのMIMEメディアタイプ」RFC3204(2001年12月)。
[6] Troost, R., Dorner, S. and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[6]TroostとR.とデルナーとS.とK.ムーア、エド、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「内容気質ヘッダーフィールド」、RFC2183、1997年8月。
[7] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] クロッカーとD.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Burger Standards Track [Page 20] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の重要な内容を追跡します[20ページ]。
[8] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.
[8] ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[9] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.
[9] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[10] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[10]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[11] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[11] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[12] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
January 1999.
[12] フリードと、N.と、「ゲートウェイとMIMEセキュリティMultiparts」、RFC2480、1月1999日
[13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
January 2003.
[13] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[14]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[15]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[16] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2", RFC 2421, September 1998.
[16] ボードルイ、G.、およびG.パーソンズは「バージョン2インチ、RFC2421、1998年インターネットメール--9月のためにProfileを声に出します」。
[17] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[17]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[18] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[18]Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[19] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[19] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。
17.2 Informative Reference
17.2 有益な参照
[20] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
2426, September 1998.
[20] ドーソンとF.とT.ハウズ、「vCard MIMEディレクトリプロフィール」、RFC2426、1998年9月。
Burger Standards Track [Page 21] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の批判的な内容を追跡します[21ページ]。
18. Acknowledgments
18. 承認
Emily Candell of Comverse Network Systems was instrumental in helping work out the base issues in the -00 document in Adelaide.
アデレードの-00ドキュメントのベース問題を解決するのを助ける際にComverse Network SystemsのエミリーCandellは手段になっていました。
Ned Freed pointed out that this mechanism was about criticality, not notification. That insight made the concept and descriptions infinitely more straightforward. If it's still confusing, it's my fault!
ネッド・フリードは、このメカニズムが通知ではなく、臨界に関するものであると指摘しました。 その洞察で、概念と記述は無限に簡単になりました。 まだ混乱させているなら、それは私のせいです!
Ned Freed also was instrumental in crafting the sections on multipart/signed and multipart/encrypted. As AD, he provided invaluable commentary to help progress this document.
ネッド・フリードも複合かサインされるのにセクションを作る際に手段になっていて、複合/はコード化されていました。 ADとして、彼は、このドキュメントを進行するのを助けるために非常に貴重な論評を提供しました。
Keith Moore for helped tighten-up the explanations, and he approved of the use of Content-Disposition.
キース・ムーア、助けられて、-上に説明をきびしくしてください。そうすれば、彼がContent-気質の使用に賛成したので。
Dropping the IMPORTANT critical content type took away one of the reasons for partial non-delivery notification. That makes Jutta Degener very happy!
IMPORTANTの重要な満足しているタイプを落とすと、部分的な非配送通知の理由の1つは持ち去られました。 それで、ユッタDegenerは非常に幸福になります!
Harald Alvestrand and Chris Newman suggested some implementation examples.
ハラルドAlvestrandとクリス・ニューマンはいくつかの実現の例を勧めました。
Greg White asked THE key question that let us realize that critical content processing was a gateway function, and not a MTA or UA function.
グレッグ・ホワイトは私たちが批判的な満足している処理がMTAかUA機能ではなく、ゲートウェイ機能であったとわかることができた肝心かなめの問題を尋ねました。
Jon Peterson cleared up how handling actually does work in the SIP environment.
ジョン・ピーターソンは取り扱いが実際にSIP環境でどう働いているかを掃除しました。
An enormous thank you to Michelle S. Cotton at IANA for helping me craft the original IANA Considerations section in 2000, and for catching the functional overlap with RFC 3204 in January 2002.
私が2000年に元のIANA Considerations部を作るのを助けて、RFC3204との機能的なオーバラップに引っかかるためのIANAのミシェルS.Cotton、ありがとうございます、2002年1月に、莫大です。
Any errors, omissions, or silliness are my fault.
どんな誤り、省略、またはばかも私のせいです。
Burger Standards Track [Page 22] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の批判的な内容を追跡します[22ページ]。
19. Intellectual Property Rights Notice
19. 知的所有権通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
20. Author's Address
20. 作者のアドレス
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
エリックバーガーSnowShoreはInc.285ビルリカ通りをネットワークでつなぎます。 チェルムズフォード、MA01824-4120米国
Phone: +1 978 367 8400 Fax: +1 603 457 5944 EMail: e.burger@ieee.org
以下に電話をしてください。 +1 978 367、8400Fax: +1 5944年の603 457メール: e.burger@ieee.org
Burger Standards Track [Page 23] RFC 3459 Critical Content of Internet Mail January 2003
バーガー規格はメール2003年1月にインターネットのRFC3459の批判的な内容を追跡します[23ページ]。
21. Full Copyright Statement
21. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Burger Standards Track [Page 24]
バーガー標準化過程[24ページ]
一覧
スポンサーリンク
