Network Working Group E. Allman
Request for Comments: 3885 Sendmail, Inc.
Updates: 3461 T. Hansen
Category: Standards Track AT&T Laboratories
September 2004
SMTP Service Extension
for Message Tracking
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking.
このメモは、クライアントが将来の追跡のためのメッセージをマークすることができることにより、SMTPサービスへの拡張を定義します。
The model used for Message Tracking is described in [RFC-MTRK-MODEL].
メッセージ追跡のために使用されるモデルは、[RFC-MTRK-MODEL]に記載されています。
Doing a Message Tracking query is intended as a "last resort" mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if the message is not received, or there is no response from either of these mechanisms should a Message Tracking query be issued.
メッセージ追跡クエリを実行すると、「最後の手段」のメカニズムとして意図されています。通常、配信状態通知（DSN）[RFC-DSN-SMTP]とメッセージ気質通知（開封通知）[RFC-MDNは、一次配信ステータスを提供するであろう。メッセージを受け取った、またはメッセージ追跡クエリを発行する必要があり、これらのメカニズムのいずれかからの応答がないされていない場合のみ。
The definition of the base64 token is imported from section 6.8 of [RFC-MIME]. Formally,
BASE64トークンの定義は、[RFC-MIME]のセクション6.8からインポートされています。正式には、
base64 = %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a
4％= Basit Kassab /％Ksav /％Ksa0-39 /％Ks41-5a /％Kst1-7a
The definition of the DIGIT token is imported from [RFC-MSGFMT]. Formally,
数字トークンの定義は、[RFC-MSGFMT]からインポートされています。正式には、
DIGIT = %x30-39
DIGIT =％x30-39
Syntax notation in this document conforms to [RFC-ABNF].
この文書の構文記法は、[RFC-ABNF]に従います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC-KEYWORDS]に記載されているように解釈されます。
The Message Tracking SMTP service extension uses the SMTP service extension mechanism described in [RFC-ESMTP]. The following service extension is hereby defined:
メッセージ追跡SMTPサービス拡張は、[RFC-ESMTP]に記載のSMTPサービス拡張メカニズムを使用します。以下のサービス拡張は、ここに定義されています。
(1) The name of the SMTP service extension is "Message Tracking".
（1）SMTPサービス拡張の名前は、「メッセージ追跡」です。
(2) The EHLO keyword value associated with this extension is "MTRK".
（2）この拡張子に関連付けられているEHLOキーワード値は「MTRK」です。
(3) No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying parameters to this keyword value.
（3）何のパラメータは、このEHLOキーワード値で許可されません。将来の文書は、このキーワードの値にパラメータを指定することで、この仕様を拡張することができます。
(4) One optional parameter using the keyword "MTRK" is added to the MAIL command. In addition, the ENVID parameter of the MAIL command (as defined in RFC 3461) MUST be supported, with extensions as described below. The ORCPT parameter of the RCPT command (as defined in RFC 3461) MUST also be supported. All semantics associated with ENVID and ORCPT described in RFC 3461 MUST be supported as part of this extension.
（4）キーワード「MTRK」を用いて一つのオプションのパラメータは、MAILコマンドに付加されます。また、MAILコマンドのENVIDパラメータは、（RFC 3461で定義されるように）、以下に記載のように拡張して、サポートしなければなりません。 RCPTコマンドのORCPTパラメータは、（RFC 3461で定義されている）もサポートしなければなりません。 ENVIDとORCPTに関連付けられたすべての意味論は、この拡張機能の一部としてサポートされなければならないRFC 3461に記載しました。
(5) The maximum length of a MAIL command line is increased by 40 characters by the possible addition of the MTRK keyword and value. Note that the 507 character extension of RCPT commands for the ORCPT parameter and the 107 character extension of MAIL commands for the ENVID parameter as mandated by RFC 3461 [RFC-DSN-SMTP] must also be included.
（5）MAILコマンドラインの最大長はMTRKキーワードと値の可能な添加により40文字だけ増加させます。 RCPTの507文字の拡張子がORCPTパラメータにコマンドおよびRFC 3461によって義務付けとしてMAILの107文字の拡張子がENVIDパラメータにコマンドことに留意されたい[RFC-DSN-SMTP]も含まれていなければなりません。
(6) No SMTP verbs are defined by this extension.
（6）無SMTP動詞はこの拡張によって定義されていません。
The extended MAIL command is issued by an SMTP client when it wishes to inform an SMTP server that message tracking information should be retained for future querying. The extended MAIL command is identical to the MAIL command as defined in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear after the address.
拡張されたMAILコマンドは、メッセージ追跡情報は、将来の照会のために保持する必要があるSMTPサーバーに通知したい場合、SMTPクライアントによって発行されます。 [RFC-SMTP]で定義されるように拡張されたMAILコマンドは、MTRK除き、ORCPT、およびENVIDパラメータはアドレスの後に表示される、MAILコマンドと同じです。
Any sender wishing to request the retention of data for further tracking of message must first tag that message as trackable by creating two values A and B:
メッセージの更なる追跡用データの保存を要求することを望む任意の送信者は、最初の2つの値AとBを作成することによって追跡可能としてそのメッセージをタグ付けする必要があります。
A = some-large-random-number B = SHA1(A)
=いくつかのラージ乱数B = SHA1（A）
The large random number A is calculated on a host-dependent basis. See [RFC-RANDOM] for a discussion of choosing good random numbers. This random number MUST be at least 128 bits but MUST NOT be more than 1024 bits.
大規模な乱数Aは、ホスト依存に基づいて計算されます。良い乱数を選ぶの議論については、[RFC-RANDOM]を参照してください。このランダムな数は、少なくとも128ビットでなければなりませんが、以上の1024ビットにすることはできません。
The 128-bit hash B of A is then computed using the SHA-1 algorithm as described in [NIST-SHA1].
[NIST-SHA1]に記載のようにAの128ビットハッシュBは、その後、SHA1アルゴリズムを使用して計算されます。
The sender then base64 encodes value B and passes that value as the mtrk-certifier on the MAIL command:
送信者は、次いで、BASE64は、値Bを符号化し、MAILコマンドのMTRK、認証者としてその値を渡します。
mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ] mtrk-certifier = base64 ; authenticator mtrk-timeout = 1*9DIGIT ; seconds until timeout
MTRKパラメータ= "MTRK =" MTRK-認証者[ "：" MTRKタイムアウト] MTRK-認証= BASE64。オーセンティケータMTRKタイムアウト= 1 * 9DIGIT。タイムアウトまでの秒
A is stored in the originator's tracking database to validate future tracking requests as described in [RFC-MTRK-MTQP]. B is stored in tracking databases of compliant receiver MTAs and used to authenticate future tracking requests.
Aは、[RFC-MTRK-MTQP]に記載されているように、将来の追跡要求を検証するために発信者の追跡データベースに格納されています。 Bは準拠したレシーバのMTAの追跡データベースに保存され、今後の追跡要求を認証するために使用されます。
The mtrk-timeout field indicates the number of seconds that the client requests that this tracking information be retained on intermediate servers, as measured from the initial receipt of the message at that server. Servers MAY ignore this value if it violates local policy. In particular, servers MAY silently enforce an upper limit to how long they will retain tracking data; this limit MUST be at least one day.
MTRKタイムアウトフィールドは、クライアントがそのサーバーでのメッセージの最初の受信から測定して、この追跡情報は、中間サーバ上に保持するように要求した秒数を示します。それはローカルポリシーに違反した場合、サーバーが、この値を無視するかもしれません。具体的には、サーバは静かに彼らが、追跡データを保持する期間の上限を強制かもしれません。この制限は、少なくとも1日でなければなりません。
If no mtrk-timeout field is specified then the server should use a local default. This default SHOULD be 8-10 days and MUST be at least one day. Notwithstanding this clause, the information MUST NOT be expired while the message remains in the queue for this server: that is, an MTQP server MUST NOT deny knowledge of a message while that same message sits in the MTA queue.
何MTRKタイムアウトフィールドが指定されていない場合、サーバは、ローカルのデフォルトを使用する必要があります。このデフォルトは8〜10日でなければならず、少なくとも1日でなければなりません。その同じメッセージがMTAキューに座っている間、つまり、MTQPサーバは、メッセージの知識を否定してはならない：メッセージがこのサーバーのキューに残っている間、この句にもかかわらず、情報の有効期限が切れてはなりません。
If the message is relayed to another compliant SMTP server, the MTA acting as the client SHOULD pass an mtrk-timeout field equal to the remaining life of that message tracking information. Specifically, the tracking timeout is decremented by the number of seconds the message has lingered at this MTA and then passed to the next MTA. If the decremented tracking timeout is less than or equal to zero, the entire MTRK parameter MUST NOT be passed to the next MTA; essentially, the entire tracking path is considered to be lost at that point.
メッセージが別の準拠したSMTPサーバーに中継されている場合は、クライアントとして動作するMTAはそのメッセージ追跡情報の残存期間に等しいMTRKタイムアウトフィールドを渡す必要があります。具体的には、トラッキングタイムアウトは、メッセージがこのMTAに残った秒数だけデクリメントされた後、次のMTAに渡されます。デクリメントトラッキングタイムアウトがゼロ以下である場合、全体MTRKパラメータは次のMTAに渡されてはいけません。本質的に、全体のトラッキング経路がその時点で失われると考えられます。
See [RFC-DELIVERYBY] section 4 for an explanation of why a timeout is used instead of an absolute time.
参照[RFC-DELIVERYBY]タイムアウトが絶対時間の代わりに使用されている理由を説明するためのセクション4。
To function properly, Message Tracking requires that each message have a unique identifier that is never reused by any other message. For that purpose, if the MTRK parameter is given, an ENVID parameter MUST be included, and the syntax of ENVID from RFC 3461 is extended as follows:
正常に機能するには、メッセージ追跡は、各メッセージが他のメッセージで再利用されることはありません一意の識別子を持っていることが必要です。その目的のために、MTRKパラメータが与えられた場合、ENVIDパラメータを含まなければなりません、そして次のようにRFC 3461からENVIDの構文が拡張されます。
envid-parameter = "ENVID=" unique-envid unique-envid = local-envid "@" fqhn local-envid = xtext fqhn = xtext
ENVIDパラメータ= "ENVID =" ユニーク-ENVIDユニーク-ENVID =ローカル-ENVID "@" ローカル-ENVID = XTEXT FQHN = XTEXT FQHN
The unique-envid MUST be chosen in such a way that the same ENVID will never be used by any other message sent from this system or any other system. In most cases, this means setting fqhn to be the fully qualified host name of the system generating this ENVID, and local-envid to an identifier that is never re-used by that host.
一意ENVIDは同じENVID、このシステムまたは他のシステムから送信された他のメッセージで使用されることがないように選択されなければなりません。ほとんどの場合、これはそのホストで再利用されることはありません識別子にこのENVIDを生成するシステムの完全修飾ホスト名、およびローカル・ENVIDするFQHN設定を意味します。
In some cases, the total length of (local-envid + fqhn + 1) (for the `@' sign) may exceed the total acceptable length of ENVID (100). In this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into BASE64. After encoding, the 160 bit SHA-1 will be a 27 octet string, which limits local-envid to 72 octets. Implementors are encouraged to use an algorithm for the local-envid that is reasonably unique. For example, sequential integers have a high probability of intersecting with sequential integers generated by a different host, but a SHA-1 of the current time of day concatenated with the host's IP address and a random number are unlikely to intersect with the same algorithm generated by a different host.
いくつかのケースでは、（ `@」記号の場合）（ローカルENVID + FQHN + 1）の全長はENVID（100）の合計の許容される長さを超えてもよいです。この場合、FQHNは、BASE64にエンコードSHA1（FQHN）によって置き換えられるべきです。符号化の後に、160ビットSHA-1は、72個のオクテットにローカルENVIDを制限27オクテットストリング、あろう。実装者は、合理的にユニークなローカル・ENVIDためのアルゴリズムを使用することをお勧めします。例えば、連続的な整数は別のホストによって生成される連続する整数と交差する可能性が高いが、ホストのIPアドレスと連結現在の時刻と乱数のSHA-1は、生成された同じアルゴリズムと交差する可能性は低いです別のホストによります。
Any resubmissions of this message into the message transmission system MUST assign a new ENVID. In this context, "resubmission" includes forwarding or resending a message from a user agent, but does not include MTA-level aliasing or forwarding where the message does not leave and re-enter the message transmission system.
メッセージ伝送システムにこのメッセージのいずれかの再送信によって新しいENVIDを割り当てる必要があります。この文脈において、「再送信」は、転送またはユーザーエージェントからのメッセージを再送信を含むが、MTAレベルのエイリアシング又はメッセージを残し、メッセージ伝送システムを再入力しない場合転送を含みません。
MTAs SHOULD forward unexpired tracking certifiers to compliant mailers as the mail is transferred during regular hop-to-hop transfers. If the "downstream" MTA is not MTRK-compliant, then the MTRK= parameter MUST be deleted. If the downstream MTA is DSN-compliant, then the ENVID and ORCPT parameters MUST NOT be deleted.
メールは通常のホップ単位の転送中に転送されるようMTAが準拠したメーラーに期限が切れていないの追跡認証者を転送する必要があります。 「下流」MTAはMTRKに準拠していない場合は、MTRK =パラメータを削除する必要があります。下流のMTAがDSNに準拠している場合は、ENVIDとORCPTパラメータは削除しないでください。
If aliasing, forwarding, or other redirection of a recipient occurs, and the result of the redirection is exactly one recipient, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified except for decrementing the mtrk-timeout field of the MTRK= value, which MUST be modified as described in section 4.1 above.
エイリアシング、転送、または受信者の他のリダイレクトが発生し、リダイレクトの結果は、1つの宛先である場合、MTAは、通常のホップ・ツー・ホップ転送としてこれを扱うとMTRK =、ENVID =、およびORCPTを転送する必要がある場合=値。これらの値は、上記のセクション4.1に記載されるように修正されなければならないMTRK =値、のMTRKタイムアウトフィールドを減分を除いて改変してはいけません。
MTAs MUST NOT copy MTRK certifiers when a recipient is aliased, forwarded, or otherwise redirected and the redirection results in more than one recipient. However, an MTA MAY designate one of the multiple recipients as the "primary" recipient to which tracking requests shall be forwarded; other addresses MUST NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certifiers when doing mailing list expansion.
MTAが受信者がエイリアスであるとき、MTRK認証者をコピー、転送、またはそれ以外の場合はリダイレクトされ、複数の受信者でのリダイレクトの結果てはなりません。しかし、MTAは、追跡要求が転送されなければならないため、「一次」受信者として複数の受信者のいずれかを指定することができます。他のアドレスは、トラッキング認証者を受信することもできません。メーリングリストの展開を行っているときのMTAはMTRK認証者を転送してはなりません。
An attacker could attempt to flood the database of a server by submitting large numbers of small, tracked messages. In this case, a site may elect to lower its maximum retention period retroactively.
攻撃者は、小さな多数を提出することによって、サーバーのデータベースをあふれしようとする可能性があり、メッセージを追跡しました。この場合、サイトは遡及的にその最大保存期間を下げるために選ぶことができます。
The mtrk-authenticator value ("A") must be hard to predict and not reused.
MTRK・オーセンティケータ値（「A」）は、予測することは困難ではなく再利用しなければなりません。
The originating client must take reasonable precautions to protect the secret. For example, if the secret is stored in a message store (e.g., a "Sent" folder), the client must make sure the secret isn't accessible by attackers, particularly on a shared store.
元のクライアントは、秘密を守るために合理的な予防措置を講じなければなりません。秘密は、メッセージストア（例えば、「送信済み」フォルダ）に格納されている場合、クライアントは特に共有ストアに、秘密が攻撃者によってアクセス可能ではないことを確認しなければなりません。
Many site administrators believe that concealing names and topologies of internal systems and networks is an important security feature. MTAs need to balance such desires with the need to provide adequate tracking information.
多くのサイト管理者は社内システムやネットワークの名前やトポロジを隠すことは、重要なセキュリティ機能であると信じています。 MTAが、十分な追跡情報を提供する必要性と、そのような欲望のバランスを取る必要があります。
In some cases site administrators may want to treat delivery to an alias as final delivery in order to separate roles from individuals. For example, sites implementing "postmaster" or "webmaster" as aliases may not wish to expose the identity of those individuals by permitting tracking through those aliases. In other cases, providing the tracking information for an alias is important, such as when the alias points to the user's preferred public address.
いくつかのケースでは、サイト管理者は、個人からの役割を分離するために、最終的な配信などのエイリアスに配達を治療することをお勧めします。たとえば、別名として「ポストマスター」または「ウェブマスター」を実施サイトは、これらのエイリアスを通じて追跡可能にすることにより、それらの個人の身元を公開したくないことがあります。他の場合には、別名のトラッキング情報を提供することなど、重要である場合に、ユーザの好みのパブリックアドレスにエイリアスポイント。
Therefore, implementors are encouraged to provide mechanisms by which site administrators can choose between these alternatives.
そのため、実装者は、サイト管理者は、これらの選択肢の間で選択することが可能な機構を提供することが奨励されています。
IANA has registered the SMTP extension defined in section 3.
IANAはセクション3で定義されたSMTP拡張を登録しました。
Several individuals have commented on and enhanced this document, including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, and Gregory Neil Shapiro.
いくつかの個人がコメントしましたし、フィリップ・ヘーゼル、アレクセイ・メルニコフ、リンドンNerenberg、クリス・ニューマン、およびグレゴリー・ニールシャピロ含め、この文書を強化しました。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004.
[RFC-MTRK-MODEL]ハンセン、T.、 "メッセージ追跡モデルと要件"、RFC 3888、2004年9月。
[RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC 3887, September 2004.
[RFC-MTRK-MTQP]ハンセン、T.、 "メッセージ追跡照会プロトコル"、RFC 3887、2004年9月。
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC-ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-ESMTP] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-MIME]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard" National Institute of Standards and Technology, U.S. Department of Commerce, May 1994.
[NIST-SHA1] NIST FIPS PUB 180-1の、標準技術の「セキュアハッシュ標準」国立研究所、米国商務省が、1994年5月。
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-SMTP] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC-MSGFMT]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC-DELIVERYBY] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC-DELIVERYBY]ニューマン、D.、2000年6月、RFC 2852 "SMTPサービス拡張により、お届け"。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC-DSN-SMTP]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[RFC-MDN]ハンセン、T.およびG.ボードルイ、編、 "メッセージ気質通知"、RFC 3798、2004年5月。
[RFC-RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC-RANDOM]イーストレイク、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
Eric Allman Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 U.S.A.
エリック・オールマンのSendmail社6425クリスティアベニュー、4階エメリービル、CA 94608 U.S.A.
Phone: +1 510 594 5501 Fax: +1 510 594 5429 EMail: eric@Sendmail.COM
電話：+1 510 594 5501ファックス：+1 510 594 5429 Eメール：eric@Sendmail.COM
Tony Hansen AT&T Laboratories Middletown, NJ 07748 U.S.A.
トニー・ハンセンAT＆T研究所ミドルタウン、NJ 07748 U.S.A.
Phone: +1 732 420 8934 EMail: tony+msgtrk@maillennium.att.com
電話：+1 732 420 8934 Eメール：tony+msgtrk@maillennium.att.com
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。