[要約] RFC 3885は、SMTPサービス拡張の一つであり、メッセージの追跡を目的としています。このRFCは、メールの送信元と宛先の情報を追跡するための新しいコマンドと応答を定義しています。
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
メッセージ追跡用のSMTPサービス拡張機能
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）The Internet Society（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.
メッセージ追跡クエリを実行することは、「最後のリゾート」メカニズムとして意図されています。通常、配信ステータス通知（DSNS）[RFC-DSN-SMTP]およびメッセージ処分通知（MDNS）[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
The definition of the DIGIT token is imported from [RFC-MSGFMT]. Formally,
桁トークンの定義は[RFC-MSGFMT]からインポートされます。正式に、
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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」を使用した1つのオプションパラメーターがメールコマンドに追加されます。さらに、以下で説明するように、拡張機能を備えた、メールコマンドの環境パラメーター（RFC 3461で定義）をサポートする必要があります。RCPTコマンドのORCPTパラメーター（RFC 3461で定義）もサポートする必要があります。RFC 3461で説明されているEvidおよびORCPTに関連するすべてのセマンティクスは、この拡張機能の一部としてサポートする必要があります。
(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) メールコマンドラインの最大長は、MTRKキーワードと値を追加することにより、40文字増加します。RFC 3461 [RFC-DSN-SMTP]によって義務付けられているEnvidパラメーターのORCPTパラメーターのRCPTコマンドの507文字拡張と、envidパラメーターのメールコマンドの107文字拡張も含める必要があることに注意してください。
(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.
拡張メールコマンドは、SMTPクライアントがSMTPサーバーに、将来のクエリのためにメッセージ追跡情報を保持する必要があることを通知したい場合に発行されます。拡張メールコマンドは、[RFC-SMTP]で定義されているメールコマンドと同じですが、MTRK、ORCPT、およびEnvidパラメーターがアドレスの後に表示されることを除きます。
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)
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はsha-1アルゴリズムを使用して計算されます。
The sender then base64 encodes value B and passes that value as the mtrk-certifier on the MAIL command:
その後、送信者はbase64をbalue bをエンコードし、メールコマンドのmtrkcertifierとしてその値を渡します。
mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
mtrk-certifier = base64 ; authenticator
mtrk-timeout = 1*9DIGIT ; seconds until timeout
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-Timeoutフィールドは、そのサーバーでのメッセージの最初の受信から測定されたように、クライアントがこの追跡情報を中間サーバーに保持することをクライアントが要求する秒数を示します。サーバーは、ローカルポリシーに違反している場合、この値を無視する場合があります。特に、サーバーは、追跡データを保持する期間まで上限を静かに施行する場合があります。この制限は少なくとも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-Timeoutフィールドが指定されていない場合、サーバーはローカルデフォルトを使用する必要があります。このデフォルトは8〜10日でなければならず、少なくとも1日でなければなりません。この条項にもかかわらず、このサーバーのメッセージがキューに残っている間、情報を有効にしてはなりません。つまり、MTQPサーバーは、同じメッセージがMTAキューにある間、メッセージの知識を拒否してはなりません。
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-Timeoutフィールドを渡す必要があります。具体的には、追跡タイムアウトは、この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
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.
ユニークな環境は、このシステムまたは他のシステムから送信された他のメッセージによって同じEvidが決して使用されないように選択する必要があります。ほとんどの場合、これは、FQHNをこのenvidを生成するシステムの完全に適格なホスト名に設定し、そのホストによって再利用されない識別子にローカル環境を設定することを意味します。
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.
場合によっては、（ローカル環境fqhn 1）（「@'標識の場合）の総長さは、envid（100）の総許容長を超える可能性があります。この場合、FQHNはBase64にエンコードされたSHA1（FQHN）に置き換える必要があります。エンコード後、160ビットSHA-1は27のオクテット弦になり、局所環境を72オクテットに制限します。実装者は、合理的に一意のローカル環境にアルゴリズムを使用することをお勧めします。たとえば、シーケンシャル整数は、異なるホストによって生成されたシーケンシャル整数と交差する可能性が高いが、ホストの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.
MTASは、通常のホップツーホップへの転送中にメールが転送されるため、未定の追跡証明書を準拠したメーラーに転送する必要があります。「下流」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-TimeOutフィールドを減少させることを除いて、変更してはなりません。
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は、複数の受信者の1人を、追跡要求を転送する「主要な」受信者として指定する場合があります。他のアドレスは追跡証明書を受け取ってはなりません。MTASは、メーリングリストの拡張を行うときに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-Authenticator値（ "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.
フィリップ・ヘイゼル、アレクセイ・メルニコフ、リンドン・ネレンベルク、クリス・ニューマン、グレゴリー・ニール・シャピロなど、この文書についてコメントして強化しました。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004.
[RFC-Mtrk-Model] Hansen、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] Crocker、D.、ed。および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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、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-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、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、「Secure Hash Standard」国立標準技術研究所、米国商務省、1994年5月。
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-SMTP] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC-MSGFMT] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC-DELIVERYBY] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC-Deliveryby] Newman、D。、「SMTP Service Extensionによる配信」、RFC 2852、2000年6月。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC-DSN-SMTP] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[RFC-MDN] Hansen、T。およびG. Vaudreuil、eds。、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC-RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC-Random] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
Eric Allman Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 U.S.A.
Eric Allman Sendmail、Inc。6425 Christie Ave、4th Floor Emeryville、CA 94608 U.S.A.
Phone: +1 510 594 5501
Fax: +1 510 594 5429
EMail: eric@Sendmail.COM
Tony Hansen AT&T Laboratories Middletown, NJ 07748 U.S.A.
Tony Hansen AT＆T Laboratories Middletown、NJ 07748 U.S.A.
Phone: +1 732 420 8934
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。