RFC4468 日本語訳
4468 Message Submission BURL Extension. C. Newman. May 2006. (Format: TXT=28614 bytes) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Newman Request for Comments: 4468 Sun Microsystems Updates: 3463 May 2006 Category: Standards Track
コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 4468のサン・マイクロシステムズアップデート: 3463 2006年5月のカテゴリ: 標準化過程
Message Submission BURL Extension
メッセージ服従節拡張子
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server.
シンプルメールトランスファプロトコル(SMTP)の服従プロフィールは、配送への完全なメッセージを提出するためにメールクライアントに標準の道で備えます。 この仕様は、インターネットMessage Accessプロトコル(IMAP)サーバから服従データをとって来るのに使用できる新しいBURLコマンドを加えることによって、服従プロフィールを広げています。これは、メールクライアントがそれをダウンロードすることのないSMTPインフラストラクチャへのIMAPサーバからクライアントとそれが支持するアップロードからサーバまで内容を注入することを許可します。
Newman Standards Track [Page 1] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. BURL Submission Extension .......................................3
3.1. SMTP Submission Extension Registration .....................3
3.2. BURL Transaction ...........................................3
3.3. The BURL IMAP Options ......................................4
3.4. Examples ...................................................5
3.5. Formal Syntax ..............................................6
4. 8-Bit and Binary ................................................7
5. Updates to RFC 3463 .............................................7
6. Response Codes ..................................................7
7. IANA Considerations .............................................9
8. Security Considerations .........................................9
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Acknowledgements .....................................13
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. 節服従拡大…3 3.1. SMTP服従拡大登録…3 3.2. 節トランザクション…3 3.3. 節IMAPオプション…4 3.4. 例…5 3.5. 正式な構文…6 4. 8ビットとバイナリー…7 5. RFC3463に、アップデートします。7 6. 応答コード…7 7. IANA問題…9 8. セキュリティ問題…9 9. 参照…11 9.1. 標準の参照…11 9.2. 有益な参照…12 付録A.承認…13
1. Introduction
1. 序論
This specification defines an extension to the standard Message Submission [RFC4409] protocol to permit data to be fetched from an IMAP server at message submission time. This MAY be used in conjunction with the CHUNKING [RFC3030] mechanism so that chunks of the message can come from an external IMAP server. This provides the ability to forward an email message without first downloading it to the client.
この仕様は、データがメッセージ服従時間にIMAPサーバからとって来られることを許可するために標準のMessage Submission[RFC4409]プロトコルと拡大を定義します。 これは最初にダウンロードしないで転送するメッセージの塊がそうすることができるそうが. これが能力を提供する外部のIMAPサーバからメールメッセージを来させるCHUNKINGに関連して中古[RFC3030]のメカニズムがそれであったならそうするかもしれません。クライアントに。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[RFC2119]で定義されるように本書では解釈されることになっているべきです。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC4234] notation including the core rules defined in Appendix B of RFC 4234.
正式な構文はRFC4234のAppendix Bで定義されたコア規則を含むAugmented BN記法(ABNF)[RFC4234]記法を使用します。
Newman Standards Track [Page 2] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[2ページ]。
3. BURL Submission Extension
3. 節服従拡大
This section defines the BURL submission extension.
このセクションはBURL服従拡張子を定義します。
3.1. SMTP Submission Extension Registration
3.1. SMTP服従拡大登録
1. The name of this submission extension is "BURL". This extends
the Message Submission protocol on port 587 and MUST NOT be
advertised by a regular SMTP [RFC2821] server on port 25 that
acts as a relay for incoming mail from other SMTP relays.
1. この服従拡大の名前は「節」です。 これをポート587でMessage Submissionプロトコルを広げていて、通常のSMTP[RFC2821]サーバは入って来るメールのためのリレーとして他のSMTPリレーから作動するポート25の上に広告を出してはいけません。
2. The EHLO keyword value associated with the extension is "BURL".
2. 拡大に関連しているEHLOキーワード価値は「節」です。
3. The BURL EHLO keyword will have zero or more arguments. The only
argument defined at this time is the "imap" argument, which MUST
be present in order to use IMAP URLs with BURL. Clients MUST
ignore other arguments after the BURL EHLO keyword unless they
are defined by a subsequent IETF standards track specification.
The arguments that appear after the BURL EHLO keyword may change
subsequent to the use of SMTP AUTH [RFC2554], so a server that
advertises BURL with no arguments prior to authentication
indicates that BURL is supported but authentication is required
to use it.
3. BURL EHLOキーワードには、ゼロか、より多くの議論があるでしょう。 このとき定義されている唯一の議論が"imap"議論です。(その議論は、BURLがあるIMAP URLを使用するために存在していなければなりません)。 それらがその後のIETF標準化過程仕様で定義されない場合、クライアントはBURL EHLOキーワードの後に他の議論を無視しなければなりません。 BURL EHLOキーワードがSMTP AUTH[RFC2554]の使用にその後で変化したかもしれない後に現れる議論によって、認証の前に議論なしでBURLの広告を出すサーバは、BURLがサポートされますが、認証がそれを使用するのに必要であることを示します。
4. This extension adds the BURL SMTP verb. This verb is used as a
replacement for the DATA command and is only permitted during a
mail transaction after at least one successful RCPT TO.
4. この拡大はBURL SMTP動詞を加えます。 この動詞は、DATAコマンドに交換として使用されて、少なくとも1うまくいっているRCPT TOの後にメールトランザクションの間、受入れられるだけです。
3.2. BURL Transaction
3.2. 節トランザクション
A simple BURL transaction will consist of MAIL FROM, one or more RCPT TO headers, and a BURL command with the "LAST" tag. The BURL command will include an IMAP URL pointing to a fully formed message ready for injection into the SMTP infrastructure. If PIPELINING [RFC2920] is advertised, the client MAY send the entire transaction in one round trip. If no valid RCPT TO address is supplied, the BURL command will simply fail, and no resolution of the BURL URL argument will be performed. If at least one valid RCPT TO address is supplied, then the BURL URL argument will be resolved before the server responds to the command.
簡単なBURLトランザクションはメールFROM、1個以上のRCPT TOヘッダー、および「最後」のタグによるBURLコマンドから成るでしょう。 BURLコマンドは注射のSMTPインフラストラクチャに準備ができる完全に形成されたメッセージを示すIMAP URLを含むでしょう。 PIPELINING[RFC2920]が広告に掲載されるなら、クライアントは1つの周遊旅行における全体のトランザクションを送るかもしれません。 どんな有効なRCPT TOアドレスも供給しないと、BURLコマンドは単に失敗するでしょう、そして、BURL URL議論の解決は全く実行されないでしょう。 少なくとも1つの有効なRCPT TOアドレスを供給すると、サーバがコマンドに反応する前にBURL URL議論を決議するでしょう。
A more sophisticated BURL transaction MAY occur when the server also advertises CHUNKING [RFC3030]. In this case, the BURL and BDAT commands may be interleaved until one of them terminates the transaction with the "LAST" argument. If PIPELINING [RFC2920] is also advertised, then the client may pipeline the entire transaction in one round-trip. However, it MUST wait for the results of the "LAST" BDAT or BURL command prior to initiating a new transaction.
また、サーバがCHUNKING[RFC3030]の広告を出すとき、より洗練されたBURLトランザクションは起こるかもしれません。 この場合、彼らのひとりが「最後」の議論でトランザクションを終えるまで、BURLとBDATコマンドははさみ込まれるかもしれません。 また、PIPELINING[RFC2920]が広告に掲載されるならクライアントがそうするかもしれない、パイプライン、1つの周遊旅行における全体のトランザクション。 しかしながら、新しいトランザクションを開始する前に、それは「最後」のBDATか節コマンドの結果を待たなければなりません。
Newman Standards Track [Page 3] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[3ページ]。
The BURL command directs the server to fetch the data object to which the URL refers and include it in the message. If the URL fetch fails, the server will fail the entire transaction.
BURLコマンドはURLが参照されるデータ・オブジェクトをとって来て、メッセージでそれを含めるようサーバに指示します。 URLフェッチが失敗すると、サーバは全体のトランザクションに失敗するでしょう。
3.3. The BURL IMAP Options
3.3. 節IMAPオプション
When "imap" is present in the space-separated list of arguments following the BURL EHLO keyword, it indicates that the BURL command supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192] and that the submit server is configured with the necessary credentials to resolve "urlauth=submit+" IMAP URLs for the submit server's domain.
BURL EHLOキーワードに従って、"imap"が議論のスペースで切り離されたリストに存在しているとき、BURLコマンドが、URLAUTH[RFC4467]が拡張型のIMAP URL[RFC2192]とものであるとサポートするのを示す、提出、サーバが「urlauth=は+を提出する」IMAP URLを決議する必要な資格証明書によって構成される、サーバのドメインを提出してください。
Subsequent to a successful SMTP AUTH command, the submission server MAY indicate a prearranged trust relationship with a specific IMAP server by including a BURL EHLO keyword argument of the form "imap://imap.example.com". In this case, the submission server will permit a regular IMAP URL referring to messages or parts of messages on imap.example.com that the user who authenticated to the submit server can access. Note that this form does not imply that the submit server supports URLAUTH URLs; the submit server must advertise both "imap" and "imap://imap.example.com" to indicate support for both extended and non-extended URL forms.
うまくいっているSMTP AUTHコマンドにその後です、服従サーバはフォーム「imap://imap.example.com」のBURL EHLOキーワード引数を含んでいることによって、特定のIMAPサーバとの根回しされた信頼関係を示すかもしれません。 この場合服従サーバがメッセージを示す通常のIMAP URLかimap.example.comの上のメッセージの部分にそれを可能にする、ユーザ、だれ、認証されるか、サーバ缶のアクセサリーを提出してください。 このフォームがそれを含意しないことに注意してください、サーバサポートURLAUTH URLを提出してください。 必須が両方のサポートが広げたのを示すために"imap"と「imap://imap.example.com」の両方の広告を出して、非拡張しているURLが形成するサーバを提出してください。
When the submit server connects to the IMAP server, it acts as an IMAP client and thus is subject to both the mandatory-to-implement IMAP capabilities in Section 6.1.1 of RFC 3501, and the security considerations in Section 11 of RFC 3501. Specifically, this requires that the submit server implement a configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the IMAP server.
提出してください。いつ、サーバがIMAPサーバに接続して、それは、IMAPクライアントとして機能して、その結果、.1セクション6.1RFC3501の実装するために義務的なIMAP能力とRFC3501のセクション11のセキュリティ問題の両方を条件としているか。 明確に、これがそれを必要とする、SASL PLAIN[SASL-PLAIN]で用途STARTTLSがIMAPサーバに認証するために続いたサーバ道具a構成を提出してください。
When the submit server resolves a URLAUTH IMAP URL, it uses submit server credentials when authenticating to the IMAP server. The authentication identity and password used for submit credentials MUST be configurable. The string "submit" is suggested as a default value for the authentication identity, with no default for the password. Typically, the authorization identity is empty in this case; thus the IMAP server will derive the authorization identity from the authentication identity. If the IMAP URL uses the "submit+" access identifier prefix, the submit server MUST refuse the BURL command unless the userid in the URL's <access> token matches the submit client's authorization identity.
サーバ決心a URLAUTH IMAP URLを提出してください、それ。提出してください。いつ、IMAPサーバに認証するとき、用途がサーバ資格証明書を提出するか、認証のアイデンティティとパスワードが使用した、資格証明書は構成可能であるに違いありません。 ストリング「提出」はパスワードのために認証のアイデンティティのためのデフォルト値としてデフォルトなしで示されます。 承認のアイデンティティはこの場合通常、空です。 したがって、IMAPサーバが承認のアイデンティティに認証のアイデンティティに由来しているでしょう。 IMAP URLが「+を提出してください」というアクセス識別子接頭語を使用するなら提出、URL<アクセス>トークンにおけるユーザIDが合っていない場合サーバがBURLコマンドを拒否しなければならない、クライアントの承認のアイデンティティを提出してください。
When the submit server resolves a regular IMAP URL, it uses the submit client's authorization identity when authenticating to the IMAP server. If both the submit client and the submit server's embedded IMAP client use SASL PLAIN (or the equivalent), the submit
提出してください。そして、いつ、提出、サーバが通常のIMAP URLを決議して、それが用途であるか、IMAPサーバに認証するときにはクライアントの承認のアイデンティティを提出してください、両方である、クライアントを提出してください、サーバの埋め込まれたIMAPクライアントがSASL PLAIN(または、同等物)を使用する、提出
Newman Standards Track [Page 4] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[4ページ]。
server SHOULD forward the client's credentials if and only if the submit server knows that the IMAP server is in the same administrative domain. If the submit server supports SASL mechanisms other than PLAIN, it MUST implement a configuration in which the submit server's embedded IMAP client uses STARTTLS and SASL PLAIN with the submit server's authentication identity and password (for the respective IMAP server) and the submit client's authorization identity.
サーバを提出してください。サーバSHOULDがクライアントの資格証明書を進める、唯一、同じ管理ドメインでIMAPサーバがそうであることを知っています。 そして、PLAIN以外のサーバサポートSASLメカニズムを提出してください、中で構成を実装しなければならない、どれ、サーバの埋め込まれたIMAPクライアント用途のSTARTTLSとSASL PLAINを提出するか、サーバの認証のアイデンティティとパスワード(それぞれのIMAPサーバのための)を提出してください、クライアントの承認のアイデンティティを提出してください。
3.4. Examples
3.4. 例
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 シングルである、「C:」 または、「S:」 ラベルが複数の系列に適用されて、そして、それらの系列の間のラインブレイクは、編集の明快だけためにあって、実際のプロトコル交換の一部ではありません。
Two successful submissions (without and with pipelining) follow:
うまくいっている差出(パイプライン処理のはないパイプライン処理と)が続く2:
<SSL/TLS encryption layer negotiated>
C: EHLO potter.example.com
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BURL imap
S: 250-AUTH PLAIN
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
C: MAIL FROM:<harry@gryffindor.example.com>
S: 250 2.5.0 Address Ok.
C: RCPT TO:<ron@gryffindor.example.com>
S: 250 2.1.5 ron@gryffindor.example.com OK.
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 250 2.5.0 Ok.
<SSL/TLS暗号化層の交渉された>C: EHLO potter.example.com S: 250-owlry.example.com S: 250-8BITMIME S: 250-BURL imap S: 250-AUTH平野S: 250-DSN S: 250ENHANCEDSTATUSCODES C: AUTHの明瞭なaGFycnkAaGFycnkAYWNjaW8= S: 235 2.7.0 PLAIN認証うまくいきます。 C: FROM:<harry@gryffindor.example.com に郵送してください、gt;、S: 250 2.5.0 OKを扱ってください。 C: RCPT TO:<ron@gryffindor.example.com 、gt;、S: 250 2.1.5 ron@gryffindor.example.com OK。 C: BURL imap: //harry@gryffindor.example.com/outbox ; uidvalidity=1078863300/; uid=25; urlauth=は:internal: 91354a473744909de610943775f92038 LAST Sを提出するか、または侵略します: 250 2.5.0 OK。
<SSL/TLS encryption layer negotiated> C: EHLO potter.example.com S: 250-owlry.example.com S: 250-8BITMIME S: 250-PIPELINING S: 250-BURL imap S: 250-AUTH PLAIN S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
<SSL/TLS暗号化層の交渉された>C: EHLO potter.example.com S: 250-owlry.example.com S: 250-8BITMIME S: 250パイプライン処理S: 250-BURL imap S: 250-AUTH平野S: 250-DSN S: 250ENHANCEDSTATUSCODES C: AUTHの明瞭なaGFycnkAaGFycnkAYWNjaW8=
Newman Standards Track [Page 5] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[5ページ]。
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<ron@gryffindor.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 235 2.7.0 PLAIN authentication successful.
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 ron@gryffindor.example.com OK.
S: 250 2.5.0 Ok.
C: FROM:<harry@gryffindor.example.com に郵送してください、gt;、C: RCPT TO:<ron@gryffindor.example.com 、gt;、C: BURL imap: //harry@gryffindor.example.com/outbox ; uidvalidity=1078863300/; uid=25; urlauth=は:internal: 91354a473744909de610943775f92038 LAST Sを提出するか、または侵略します: 235 2.7.0 PLAIN認証うまくいきます。 S: 250 2.5.0 OKを扱ってください。 S: 250 2.1.5 ron@gryffindor.example.com OK。 S: 250 2.5.0 OK。
Note that PIPELINING of the AUTH command is only permitted if the selected mechanism can be completed in one round trip, a client initial response is provided, and no SASL security layer is negotiated. This is possible for PLAIN and EXTERNAL, but not for most other SASL mechanisms.
1つの周遊旅行で選択されたメカニズムを完成できて、クライアントの初期の応答を提供して、SASLセキュリティ層を全く交渉しないなら、AUTHコマンドのPIPELININGが受入れられるだけであることに注意してください。 これは、PLAINとEXTERNALに可能ですが、他のほとんどのSASLメカニズムのために可能であるというわけではありません。
Some examples of failure cases:
失敗事件に関するいくつかの例:
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<malfoy@slitherin.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 250 2.5.0 Address Ok.
S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com
S: 554 5.5.0 No recipients have been specified.
C: FROM:<harry@gryffindor.example.com に郵送してください、gt;、C: RCPT TO:<malfoy@slitherin.example.com 、gt;、C: BURL imap: //harry@gryffindor.example.com/outbox ; uidvalidity=1078863300/; uid=25; urlauth=は:internal: 91354a473744909de610943775f92038 LAST Sを提出するか、または侵略します: 250 2.5.0 OKを扱ってください。 S: 550 5.7.1 リレーは許容しませんでした: malfoy@slitherin.example.com S: 554 5.5.0 受取人は全く指定されていません。
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<ron@gryffindor.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:71354a473744909de610943775f92038 LAST
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 ron@gryffindor.example.com OK.
S: 554 5.7.0 IMAP URL authorization failed
C: FROM:<harry@gryffindor.example.com に郵送してください、gt;、C: RCPT TO:<ron@gryffindor.example.com 、gt;、C: BURL imap: //harry@gryffindor.example.com/outbox ; uidvalidity=1078863300/; uid=25; urlauth=は:internal: 71354a473744909de610943775f92038 LAST Sを提出するか、または侵略します: 250 2.5.0 OKを扱ってください。 S: 250 2.1.5 ron@gryffindor.example.com OK。 S: 554 5.7.0 IMAP URL承認は失敗しました。
3.5. Formal Syntax
3.5. 正式な構文
The following syntax specification inherits ABNF [RFC4234] and Uniform Resource Identifiers [RFC3986].
以下の構文仕様はABNF[RFC4234]とUniform Resource Identifier[RFC3986]を引き継ぎます。
burl-param = "imap" / ("imap://" authority)
; parameter to BURL EHLO keyword
節-paramは"imap"/と等しいです(「imap://」権威)。 BURL EHLOキーワードへのパラメタ
burl-cmd = "BURL" SP absolute-URI [SP end-marker] CRLF
節-cmdは「節」SPの絶対URI[SPエンドマーカー]CRLFと等しいです。
end-marker = "LAST"
エンドマーカー=「最終」
Newman Standards Track [Page 6] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[6ページ]。
4. 8-Bit and Binary
4. 8ビットで2進です。
A submit server that advertises BURL MUST also advertise 8BITMIME [RFC1652] and perform the down conversion described in that specification on the resulting complete message if 8-bit data is received with the BURL command and passed to a 7-bit server. If the URL argument to BURL refers to binary data, then the submit server MAY refuse the command or down convert as described in Binary SMTP [RFC3030].
AがBURLコマンドで8ビットのデータを受け取るなら、結果として起こる完全なメッセージにまた、8BITMIME[RFC1652]の広告を出して、その仕様で説明された下に変換を実行して、7ビットのサーバに通過されて、BURL MUSTの広告を出すサーバを提出する、BURLへのURL議論がバイナリ・データ、その時について言及する、Binary SMTP[RFC3030]で説明されるようにコマンドか転向者の下側にサーバ5月の廃物を提出してください。
The Submit server MAY refuse to accept a BURL command or combination of BURL and BDAT commands that result in un-encoded 8-bit data in mail or MIME [RFC2045] headers. Alternatively, the server MAY accept such data and down convert to MIME header encoding [RFC2047].
Submitサーバが、BURLコマンドを受け入れるのを拒否するかもしれませんか、またはBURLとBDATの組み合わせはメールかMIME[RFC2045]ヘッダーで暗号化されていない8ビットのデータのその結果を命令します。 あるいはまた、サーバはデータと下にがMIMEヘッダーコード化[RFC2047]に変換するそのようなものを受け入れるかもしれません。
5. Updates to RFC 3463
5. RFC3463へのアップデート
SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034] use enhanced status codes defined in RFC 3463 [RFC3463]. The BURL extension introduces new error cases that that RFC did not consider. The following additional enhanced status codes are defined by this specification:
SMTPかENHANCEDSTATUSCODES[RFC2034]使用の広告を出すSubmitサーバがRFC3463[RFC3463]で定義されたステータスコードを高めました。 BURL拡張子はそのRFCが考えなかった新しい誤り事件を導入します。 以下の追加高められたステータスコードはこの仕様で定義されます:
X.6.6 Message content not available
利用可能でないX.6.6メッセージ内容
The message content could not be fetched from a remote system.
This may be useful as a permanent or persistent temporary
notification.
リモートシステムからメッセージ内容をとって来ることができませんでした。 これは永久的であるか永続的な一時的な通知として役に立つかもしれません。
X.7.8 Trust relationship required
X.7.8信頼関係が必要です。
The submission server requires a configured trust relationship
with a third-party server in order to access the message content.
服従サーバは、メッセージ内容にアクセスするために第三者サーバとの構成された信頼関係を必要とします。
6. Response Codes
6. 応答コード
This section includes example response codes to the BURL command. Other text may be used with the same response codes. This list is not exhaustive, and BURL clients MUST tolerate any valid SMTP response code. Most of these examples include the appropriate enhanced status code [RFC3463].
このセクションは例の応答コードをBURLコマンドに含んでいます。 他のテキストは同じ応答コードと共に使用されるかもしれません。 このリストは徹底的ではありません、そして、BURLクライアントはどんな有効なSMTP応答コードも許容しなければなりません。 これらの例の大部分は適切な高められたステータスコード[RFC3463]を含んでいます。
554 5.5.0 No recipients have been specified
554 5.5.0 受取人は全く指定されていません。
This response code occurs when BURL is used (for example, with
PIPELINING) and all RCPT TOs failed.
BURLが使用されているとき(例えばPIPELININGと共に)、この応答コードは起こりました、そして、すべてのRCPT TOsが失敗しました。
Newman Standards Track [Page 7] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[7ページ]。
503 5.5.0 Valid RCPT TO required before BURL
503 5.5.0 有効なRCPT TOがBURLの前で必要です。
This response code is an alternative to the previous one when BURL
is used (for example, with PIPELINING) and all RCPT TOs failed.
BURLが使用されているとき(例えばPIPELININGと共に)、この応答コードは前のものへの代替手段です、そして、すべてのRCPT TOsが失敗しました。
554 5.6.3 Conversion required but not supported
554 5.6.3 必要ですが、サポートされなかった変換
This response code occurs when the URL points to binary data and
the implementation does not support down conversion to base64.
This can also be used if the URL points to message data with 8-bit
content in headers and the server does not down convert such
content.
URLがバイナリ・データを示すとき、この応答コードは起こります、そして、実装は下にが変換であることをbase64にサポートしません。 また、8ビットの内容がヘッダーにある状態でURLがメッセージデータを示すならこれを使用できて、サーバは転向者のためにそのような内容ほど倒しません。
554 5.3.4 Message too big for system
554 5.3.4 システムのためにあまりに大きく通信してください。
The message (subsequent to URL resolution) is larger than the
per-message size limit for this server.
メッセージ(URL解決にその後の)はこのサーバのための1メッセージあたりのサイズ限界より大きいです。
554 5.7.8 URL resolution requires trust relationship
554 5.7.8 URL決議は信頼関係を必要とします。
The submit server does not have a trust relationship with the IMAP
server specified in the URL argument to BURL.
サーバを提出してください。URL議論でIMAPサーバとの信頼関係をBURLに指定させません。
552 5.2.2 Mailbox full
552 5.2.2 メールボックス満
The recipient is local, the submit server supports direct
delivery, and the recipient has exceeded his quota and any grace
period for delivery attempts.
提出してください。受取人が地元である、サーバは配送をダイレクトにサポートして、受取人は配送試みのために彼の割当てとどんな据置期間も超えていました。
554 5.6.6 IMAP URL resolution failed
554 5.6.6 IMAP URL解決は失敗しました。
The IMAP URLFETCH command returned an error or no data.
誤りを返しましたが、IMAP URLFETCHコマンドはどんなデータも返しませんでした。
250 2.5.0 Waiting for additional BURL or BDAT commands
250 2.5.0 追加BURLかBDATコマンドを待つこと。
A BURL command without the "LAST" modifier was sent. The URL for
this BURL command was successfully resolved, but the content will
not necessarily be committed to persistent storage until the rest
of the message content is collected. For example, a Unix server
may have written the content to a queue file buffer, but may not
yet have performed an fsync() operation. If the server loses
power, the content can still be lost.
「最後」の修飾語のないBURLコマンドを送りました。 このBURLコマンドのためのURLは首尾よく決議されましたが、メッセージ内容の残りが集められるまで、内容は必ず永続的なストレージに心がけるというわけではないでしょう。 例えば、Unixサーバーは、キューファイルバッファに内容を書きましたが、まだfsync()操作を実行していないかもしれません。 サーバがパワーを失うなら、まだ内容を失うことができます。
451 4.4.1 IMAP server unavailable
451 4.4.1 入手できないIMAPサーバ
The connection to the IMAP server to resolve the URL failed.
URLを決議するIMAPサーバとの接続は失敗しました。
Newman Standards Track [Page 8] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[8ページ]。
250 2.5.0 Ok.
250 2.5.0 OK。
The URL was successfully resolved, and the complete message data
has been committed to persistent storage.
URLは首尾よく決議されました、そして、完全なメッセージデータは永続的なストレージに心がけました。
250 2.6.4 MIME header conversion with loss performed
250 2.6.4 損失が実行されているMIMEヘッダー変換
The URL pointed to message data that included mail or MIME headers
with 8-bit data. This data was converted to MIME header encoding
[RFC2047], but the submit server may not have correctly guessed
the unlabeled character set.
URLは8ビットのデータでメールかMIMEヘッダーを含んでいたメッセージデータを示しました。 サーバを提出してください。しかし、このデータがMIMEヘッダーコード化[RFC2047]に変換されていた、正しく、ラベルされていない文字集合を推測している必要はありません。
7. IANA Considerations
7. IANA問題
The "BURL" SMTP extension as described in Section 3 has been registered. This registration has been marked for use by message submission [RFC4409] only in the registry.
セクション3で説明される「節」SMTP拡張子を登録してあります。 登録だけでのメッセージ提案[RFC4409]でこの登録は使用のためにマークされました。
8. Security Considerations
8. セキュリティ問題
Modern SMTP submission servers often include content-based security and denial-of-service defense mechanisms such as virus filtering, size limits, server-generated signatures, spam filtering, etc. Implementations of BURL should fetch the URL content prior to application of such content-based mechanisms in order to preserve their function.
現代のSMTP服従サーバはしばしばウイルスフィルタリング、サイズ限界、サーバで発生している署名、スパムフィルタリングなどの内容ベースのセキュリティとサービスの否定防衛機構を含んでいます。 BURLの実装は、そのような内容ベースのメカニズムの応用の前にそれらの機能を保存するためにURL内容をとって来るべきです。
Clients that generate unsolicited bulk email or email with viruses could use this mechanism to compensate for a slow link between the client and submit server. In particular, this mechanism would make it feasible for a programmable cell phone or other device on a slow link to become a significant source of unsolicited bulk email and/or viruses. This makes it more important for submit server vendors implementing BURL to have auditing and/or defenses against such denial-of-service attacks including mandatory authentication, logging that associates unique client identifiers with mail transactions, limits on reuse of the same IMAP URL, rate limits, recipient count limits, and content filters.
求められていない大量のメールを作るか、またはウイルスと共にメールするクライアントは、クライアントの間の遅いリンクを補って、サーバを提出するのにこのメカニズムを使用できました。特に、このメカニズムで遅いリンクの上のプログラマブル携帯電話か対向機器が求められていない大量のメール、そして/または、ウイルスの重要な源になるのが可能になるでしょう。 これで、それは、義務的な認証を含むそのようなサービス不能攻撃に監査、そして/または、ディフェンスを抱くためにBURLを実装するサーバベンダーを提出して、メールトランザクションがあるユニークなクライアント識別子(同じIMAP URLの再利用における限界)が限界と、受取人カウント限界と、満足しているフィルタであると評定するその仲間を登録しながら、より重要になります。
Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can expose the authorization token to network eavesdroppers. Implementations that support such URLs can address this issue by using a strong confidentiality protection mechanism. For example, the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501] extensions, in combination with a configuration setting that requires their use with such IMAP URLs, would address this concern.
明確のIMAP URLのURLAUTH[RFC4467]形式の転送はネットワーク立ち聞きする者に承認トークンを暴露することができます。 そのようなURLをサポートする実装は、強い秘密性保護メカニズムを使用することによって、この問題を扱うことができます。 例えば、そのようなIMAP URLとの彼らの使用を必要とする構成設定と組み合わせて、SMTP STARTTLS[RFC3207]とIMAP STARTTLS[RFC3501]拡張子はこの関心を扱うでしょう。
Newman Standards Track [Page 9] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[9ページ]。
Use of a prearranged trust relationship between a submit server and a specific IMAP server introduces security considerations. A compromise of the submit server should not automatically compromise all accounts on the IMAP server, so trust relationships involving super-user proxy credentials are strongly discouraged. A system that requires the submit server to authenticate to the IMAP server with submit credentials and subsequently requires a URLAUTH URL to fetch any content addresses this concern. A trusted third party model for proxy credentials (such as that provided by Kerberos 5 [RFC4120]) would also suffice.
aの間の根回しされた信頼関係の使用はサーバを提出します、そして、特定のIMAPサーバはセキュリティ問題を紹介します。 Aが妥協する、自動的に感染が、IMAPサーバですべて説明するのでスーパーユーザプロキシ資格証明書にかかわる関係が強くがっかりしていると信じるなら、サーバを提出してください。 それが必要とするシステム、IMAPサーバに認証するサーバを提出する、資格証明書を提出して、次に、a URLAUTH URLがどんな満足しているアドレスにもこの関心をとって来るのが必要です。 また、プロキシ資格証明書(ケルベロス5[RFC4120]で提供されたそれなどの)のための信頼できる第三者機関モデルは十分でしょう。
When a client uses SMTP STARTTLS to send a BURL command that references non-public information, there is a user expectation that the entire message content will be treated confidentially. To address this expectation, the message submission server SHOULD use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.
クライアントがそこでその参照非公開情報をBURLコマンドに送るSMTP STARTTLSを使用すると、全体のメッセージ内容をあるユーザ期待は秘密に扱われますか? この期待を扱うために、メッセージ服従サーバSHOULDはそのURLによって参照をつけられる内容をとって来るとき、同等なデータの機密性を提供しながら、STARTTLSかメカニズムを使用します。
A legitimate user of a submit server may try to compromise other accounts on the server by providing an IMAP URLAUTH URL that points to a server under that user's control that is designed to undermine the security of the submit server. For this reason, the IMAP client code that the submit server uses must be robust with respect to arbitrary input sizes (including large IMAP literals) and arbitrary delays from the IMAP server. Requiring a prearranged trust relationship between a submit server and the IMAP server also addresses this concern.
aの正統のユーザが提出する、セキュリティを弱体化させる設計されているそのユーザのコントロールの下にサーバを示すIMAP URLAUTH URLを提供することによってサーバがサーバで他のアカウントに感染しようとするかもしれない、サーバを提出してください; この理由、IMAPクライアントがそれをコード化する. aの間の根回しされた信頼関係を必要とすると提出されるIMAPサーバからの任意の入力サイズ(大きいIMAPリテラルを含んでいる)に関して強健で任意の遅れがサーバであったに違いないならサーバ用途を提出してください。そうすれば、また、IMAPサーバはこの関心を扱います。
An authorized user of the submit server could set up a fraudulent IMAP server and pass a URL for that server to the submit server. The submit server might then contact the fraudulent IMAP server to authenticate with submit credentials and fetch content. There are several ways to mitigate this potential attack. A submit server that only uses submit credentials with a fixed set of trusted IMAP servers will not be vulnerable to exposure of those credentials. A submit server can treat the IMAP server as untrusted and include defenses for buffer overflows, denial-of-service slowdowns, and other potential attacks. Finally, because authentication is required to use BURL, it is possible to keep a secure audit trail and use that to detect and punish the offending party.
提出してください。認定ユーザ、提出、サーバが詐欺的なIMAPサーバに設定して、そのサーバのためのURLを通過するかもしれない、サーバを提出してください、次に力が認証する詐欺的なIMAPサーバに連絡するサーバは、資格証明書を提出して、内容をとって来ます。 この起こり得るかもしれない攻撃を緩和するいくつかの方法があります。 Aはサーバを提出します。用途だけが固定セットの信じられたIMAPサーバで資格証明書を提出するのはそれらの資格証明書の暴露に被害を受け易くならないでしょう。 Aは信頼されていないとしてのIMAPサーバとバッファオーバーフローのためのインクルードディフェンス、サービスの否定スローダウン、および他の可能性が攻撃するサーバ缶の御馳走を提出します。 最終的に、認証がBURLを使用するのに必要であるので、安全な監査証跡を保って、違反した当事者を検出して、罰するのにそれを使用するのは可能です。
Newman Standards Track [Page 10] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[10ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for
8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192,
September 1997.
[RFC2192] ニューマン、C.、「IMAP URL体系」、RFC2192、1997年9月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[RFC2554] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207,
February 2002.
[RFC3207]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[RFC4409] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC4467]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--URLAUTH拡張子」、RFC4467、5月2006日
Newman Standards Track [Page 11] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[11ページ]。
9.2. Informative References
9.2. 有益な参照
[RFC2034] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
解放された[RFC2034]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
解放された[RFC2920]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、STD60、RFC2920、2000年9月。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
RFC 3030, December 2000.
[RFC3030]ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC3030、2000年12月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
[RFC3463] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[SASL-PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
Progress, March 2005.
K.、「明瞭なSASLメカニズム」という[SASL明瞭]のZeilengaは進歩、2005年3月に働いています。
Newman Standards Track [Page 12] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[12ページ]。
Appendix A. Acknowledgements
付録A.承認
This document is a product of the lemonade WG. Many thanks are due to all the participants of that working group for their input. Mark Crispin was instrumental in the conception of this mechanism. Thanks to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave Cridland, Peter Coates, and Mark Crispin for review comments on the document. Thanks to the RFC Editor for correcting the author's grammar mistakes. Thanks to Ted Hardie, Randall Gellens, Mark Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting debates comparing this proposal and alternatives. Thanks to the lemonade WG chairs Eric Burger and Glenn Parsons for concluding the debate at the correct time and making sure this document got completed.
このドキュメントはレモネードWGの製品です。 ありがとうございます、彼らの入力のためのそのワーキンググループの参加者各位への支払われるべきものはそうですか? マーク・クリスピンはこのメカニズムに関する概念で手段になっていました。 ドキュメントのレビューコメントをランドルGellens、Alexeyメリニコフ、サム・ハートマン、ネッド・フリード、デーヴCridland、ピーター・コーツ、およびマーク・クリスピンをありがとうございます。 作者の文法誤りをRFC Editorに修正してくださってありがとうございます。 この提案と代替手段を比較する非常におもしろい討論をテッド・ハーディー、ランドルGellens、マーク・クリスピン、ピートレズニック、およびグレッグ・ボードルイをありがとうございます。 おかげに、レモネードWGは、正しい時に討論を結論づけて、このドキュメントが完成したのを確実にするためにエリックBurgerとグレン・パーソンズをまとめます。
Author's Address
作者のアドレス
Chris Newman Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 US
クリスニューマンサン・マイクロシステムズ3401Centrelakeスイート410オンタリオ、カリフォルニア91761博士(米国)
EMail: chris.newman@sun.com
メール: chris.newman@sun.com
Newman Standards Track [Page 13] RFC 4468 Message Submission BURL Extension May 2006
ニューマンStandardsはメッセージ服従節拡大2006年5月にRFC4468を追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Newman Standards Track [Page 14]
ニューマン標準化過程[14ページ]
一覧
スポンサーリンク
