RFC 3886

RFC 3886

An Extensible Message Format for Message Tracking Responses

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.

Abstract

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

メッセージ追跡は未配電子メイルの状態を要求に応じて調べるために使うことが想定されています。 追跡は配送状態通知 (DSN) やメッセージ配置通知 (MDN) と併用します。通常、メッセージ追跡要求は DSN や MDN を適当な期限内に受信しなかった時にのみ行います。

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo.

このメモは RFC 3464 配送状態通知用拡張可能メッセージ書式 と同じようにメッセージ追跡状態の MIME 内容型を定義します。 これはメッセージ追跡照会プロトコルで説明されているように要求に応じて発行されます。 このメモは状態情報の書式のみを定義します。更なる追跡のためにメッセージに札付けしたり状態追跡を要求したりするための SMTP 拡張は別のメモで定義します。

1. Introduction

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) [RFC-DSN-SMTP] and Message Disposition Notifications (MDN) [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

メッセージ追跡は要求に応じて未配電子メイルの状態を調べるために使うことが想定されています。 追跡は配達状態通知 (DSN) やメッセージ配置通知 (MDN) と併用します。通常、メッセージ要求は DNS や MDN を適当な期限内に受信しなかった時にのみ発行します。

This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications" [RFC-DSN-STAT]. It is to be issued upon a request as described in "Message Tracking Query Protocol" [RFC-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [RFC-MTRK-SMTPEXT].

このメモは RFC 3464 配送状態通知用拡張可能メッセージ書式 と同じようにメッセージ追跡状態の MIME 内容型を定義します。 これはメッセージ追跡照会プロトコルで説明されているように要求に応じて発行されます。 このメモは状態情報の書式のみを定義します。更なる追跡のためにメッセージに札付けしたり状態追跡を要求したりするための SMTP 拡張は別のメモで定義します。

2. Other Documents and Conformance

The model used for Message Tracking is described in [RFC-MTRK-MODEL].

メッセージ追跡に使用する模型は RFC 3888 で説明しています。

Message tracking is intended for use 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 no response is received from either of these mechanisms would Message Tracking be used.

メッセージ追跡は最終手段として使用することを想定しています。 通常、配送状態通知 (DSN) とメッセージ配置通知 (MDN) が本来の配送状態を知らせます。どちらの仕組みでも応答を受信しなかった場合にのみメッセージ追跡を使用します。

This document is based on [RFC-DSN-STAT]. Sections 1.3 (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2 ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 822) of [RFC-DSN-STAT] are included into this document by reference. Other sections are further incorporated as described herein.

この文書は RFC 3464 を基にしています。 RFC 3464 の 1.3 節 (用語), 2.1.1 節 (DSN 欄の一般規則), 2.1.2節 (*-type 部分欄), 2.1.3節 (RFC 822 から輸入した字句) を参照し、この文書に取込みます。 他の章も更にここで説明するように取込みます。

Syntax notation in this document conforms to [RFC-ABNF].

この文書の構文記法は RFC 2234 に適合します。

The following lexical tokens, defined in [RFC-MSGFMT], are used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [RFC-HOSTREQ].

RFC 2822 で定義されている字句 atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text を MTSN の ABNF 文法で使います。 字句 date-timeRFC 1123 で定義されています。

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 RFC 2119 [RFC-KEYWORDS].

3. Format of a Message Tracking Status Notification

A Message Tracking Status Notification (MTSN) is intended to be returned as the body of a Message Tracking request [RFC-MTRK-MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] with type parameter of "message/tracking-status"; each subpart MUST be of type "message/tracking-status" as described herein. The multipart/related body can include multiple message/tracking-status parts if an MTQP server chains requests to the next server; see [RFC-MTRK-MODEL] and [RFC-MTRK-MTQP] for more information about chaining.

メッセージ追跡状態通知 (MTSN) はメッセージ追跡要求の本体として返されることを想定しています。 実際の本体は type 引数が message/tracking-statusmultipart/related でなければなりません。 その亜部分はここで定義する型 message/tracking-status のものでなければなりませんMTQP 鯖が次の鯖に要求を連鎖させたのであれば、 multipart/related 本体は複数の message/tracking-status 部分を含めることができます。連鎖について詳しくは RFC 3888RFC 3887 をご覧下さい。

3.1. The message/tracking-status content-type

The message/tracking-status content-type is defined as follows:

message/tracking-status 内容型は次のように定義します。

MIME type name
message
MIME subtype name
tracking-status
Optional parameters
none
Encoding considerations
"7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.

7bit 符号化が十分であり、非 MIME メイル読取り器で表示する時の可読性を維持するために 7bit を使わなければなりません

Security considerations
discussed in section 4 of this memo.

The body of a message/tracking-status is modeled after [RFC-DSN-STAT]. That body consists of one or more "fields" formatted to according to the ABNF of RFC 2822 header "fields" (see [RFC-MSGFMT]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Note that there will be a blank line between the final per-recipient field and the MIME boundary, since one CRLF is necessary to terminate the field, and a second is necessary to introduce the MIME boundary. Formally, the syntax of the message/tracking-status content is as follows:

message/tracking-status の本体は RFC 3464 のものを基にしています。本体は RFC 2822 頭欄の ABNF fields に従って書式付けした一つ以上のから成ります。 まずはじめにメッセージ毎の欄が来て、空行が続きます。 その後に一つ以上の受信者毎の欄の群が来ます。受信者毎の欄群それぞれの前には空行が来ます。 なお、欄の最後に1つ CRLF が必要であり、 MIME 境界線の最初にも1つ必要ですから、 最後の受信者毎欄と MIME 境界線の間には空行が入ります。正式には message/tracking-status 内容の構文は次の通りです。

   tracking-status-content =
             per-message-fields 1*( CRLF per-recipient-fields )

The per-message fields are described in section 3.2. The per-recipient fields are described in section 3.3.

メッセージ毎欄は3.2節で説明します。受信者毎欄は3.3節で説明します。

3.1.1. General conventions for MTSN fields

Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definition of xtext is identical to that of that document.

RFC 3464 の2.1.1節 (DSN 欄の一般的記法) をここに参照により取込みます。 特に、 xtext の定義は RFC 3464 のものと同一です。

3.1.2. *-type subfields

Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definitions of address-type, diagnostic-type, and MTA-name type are identical to that of RFC 3464.

RFC 3464 の 2.1.2節 (*-type 部分欄) をここに参照により取込みます。 特に、 address-type, diagnostic-type, MTA-name 型の定義は RFC 3464 のものと同一です。

3.2. Per-Message MTSN Fields

Some fields of an MTSN apply to all of the addresses in a single envelope. These fields may appear at most once in any MTSN. These fields are used to correlate the MTSN with the original message transaction and to provide additional information which may be useful to gateways.

MTSN 欄の幾つかは一つの封筒の中の番地すべてに適用します。 そのような欄群は MTSN に高々一度出現し得ます。 これらの欄は MTSN を元のメッセージ取引と関係付けるためと、 関門に有用かもしれない追加情報を提供するために使います。

      per-message-fields =
                original-envelope-id-field CRLF
                reporting-mta-field CRLF
                arrival-date-field CRLF
                *( extension-field CRLF )

3.2.1. The Original-Envelope-Id field

The Original-Envelope-Id field is defined as in section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED.

Original-Envelope-Id 欄は RFC 3464 の2.2.1節で定義されています。 この欄は必須です。

3.2.2. The Reporting-MTA field

The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN-STAT]. This field is REQUIRED.

Reporting-MTA 欄は RFC 3464 の2.2.2節で定義されています。 この欄は必須です。

3.2.3. The Arrival-Date field

The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN-STAT]. This field is REQUIRED.

Arrival-Date 欄は RFC 3464 の2.2.5節で定義されています。 この欄は必須です。

3.3. Per-Recipient MTSN fields

An MTSN contains information about attempts to deliver a message to one or more recipients. The delivery information for any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line.

MTSN は一人以上の受信者にメッセージを配送しようとした試行についての情報を含みます。 ある特定の受信者についての配送情報は続く受信者毎の欄の群に含まれます。 受信者毎の欄の群それぞれは空行が前に来ます。

The syntax for the group of per-recipient fields is as follows:

受信者毎の欄の群の構文は次の通りです。

      per-recipient-fields =
                original-recipient-field CRLF
                final-recipient-field CRLF
                action-field CRLF
                status-field CRLF
                [ remote-mta-field CRLF ]
                [ last-attempt-date-field CRLF ]
                [ will-retry-until-field CRLF ]
                *( extension-field CRLF )

3.3.1. Original-Recipient field

The Original-Recipient field is defined as in section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED.

Original-Recipient 欄は RFC 3464 の2.3.1節で定義されています。 この欄は必須です。

3.3.2. Final-Recipient field

The required Final-Recipient field is defined as in section 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED.

Final-Recipient 欄は RFC 3464 の2.3.2節で定義されています。 この欄は必須です。

3.3.3. Action field

The required Action field indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient address. This field MUST be present for each recipient named in the MTSN. The syntax is as defined in RFC 3464. This field is REQUIRED.

必須の Action 欄は Reporting-MTA がメッセージをこの受信番地に配送しようと試みた結果行った動作を示します。 この欄は MTSN に挙げられた受信者それぞれに示さなければなりません。 構文は RFC 3464 で定義されています。この欄は必須です。

Valid actions are:

妥当な動作は次の通りです。

failed
The message could not be delivered. If DSNs have been enabled, a "failed" DSN should already have been returned.
failed
メッセージは配送できませんでした。 DSN が有効であれば、 failed DSN が既に返されているはずです。
delayed
The message is currently waiting in the MTA queue for future delivery. Essentially, this action means "the message is located, and it is here."
delayed
メッセージは現在 MTA 待ち行列で将来の配送を待っています。 本質的にこの動作はメッセージが位置付けられ、ここにある ことを意味します。
delivered
The message has been successfully delivered to the final recipient. This includes "delivery" to a mailing list exploder. It does not indicate that the message has been read. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
delivered
メッセージは最終受信者に配送成功しました。 これはメイリング・リスト展開器への配送も含みます。 しかし、メッセージが読まれたことは示しません。 これ以上の情報はありません。特に、追跡エージェントは更に 下流の追跡要求を試みるべきではありません
expanded
The message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. However, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
expanded
メッセージは送信者により指定された受信番地に配送成功し、 Reporting-MTA によって更に追加の受信番地複数に転送されました。 しかし、これら追加の番地は追跡可能ではなく、追跡エージェントは更に 下流の追跡要求を試みるべきではありません
relayed
The message has been delivered into an environment that does not support message tracking. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
relayed
メッセージはメッセージ追跡に対応していない環境に配送されました。 これ以上の情報はありません。特に、 追跡エージェントは更に下流の追跡要求を試みるべきではありません
transferred
The message has been transferred to another MTRK-compliant MTA. The tracking agent SHOULD attempt further "downstream" tracking requests unless that information is already given in a chaining response.
transferred
メッセージは他の MTRK 適合 MTA に転送されました。追跡エージェントは既に情報が連鎖応答で示されていない限り更に 下流の追跡要求を試みるべきです
opaque
The message may or may not have been seen by this system. No further information is available or forthcoming.
opaque
メッセージはこのシステムが見たかもしれませんし、 見てないかもしれません。これ以上の情報は利用できませんし、 やって来もしません。

There may be some confusion between when to use "expanded" versus "delivered". Whenever possible, "expanded" should be used when the MTA knows that the message will be sent to multiple addresses. However, in some cases the delivery occurs to a program which, unknown to the MTA, causes mailing list expansion; in the extreme case, the delivery may be to a real mailbox that has the side effect of list expansion. If the MTA cannot ensure that this delivery will cause list expansion, it should set the action to "delivered".

expandeddelivered をいつ使うかで混乱するかもしれません。 MTA がメッセージは複数の番地に送られると知っていれば可能な限り expanded を使うべきです。しかし、 場合によってはメイリング・リスト展開を行う MTA が知らないプログラムに配送されることもあります。極端な場合、 配送は副作用としてメイリング・リスト展開が起こる実メイル箱に配送されるかもしれません。 MTA がメイリング・リスト展開が行われると確認できなければ、動作は delivered とするべきです。

3.3.4. Status field

The Status field is defined as in RFC 3464. A new code is added to RFC 3463 [RFC-EMSSC], "Enhanced Mail System Status Codes",

Status 欄は RFC 3464 で定義されています。 新しい符号を RFC 3463 強化メイル・システム状態符号に追加します。

X.1.9 Message relayed to non-compliant mailer"
The mailbox address specified was valid, but the message has been relayed to a system that does not speak this protocol; no further information can be provided.
X.1.9 メッセージは非適合メイル器に中継されました
指定されたメイル箱番地は妥当でしたが、メッセージはこのプロトコルを話さないシステムに中継されました。 これ以上の情報を提供することはできません。

A 2.1.9 Status field MUST be used exclusively with a "relayed" Action field. This field is REQUIRED.

2.1.9 Status 欄を排他的に relayed Action 欄と使用しなければなりません。 この欄は必須です。

3.3.5. Remote-MTA field

The Remote-MTA field is defined as in section Reference 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if no delivery attempts have been made or if the Action field has value "opaque". If delivery to some agent other than an MTA (for example, a Local Delivery Agent) then this field MAY be included, giving the name of the host on which that agent was contacted.

Remote-MTA 欄は RFC 3464 の2.3.5節で定義されています。 この欄は配送試行がなされていない場合や Action 欄の値が opaque の時に含めてはなりません。 MTA 以外のエージェント (例えば局所配送エージェント) への配送が行われた場合は、そのエージェントに接触したホストの名前でこの欄を含めても構いません

3.3.6. Last-Attempt-Date field

The Last-Attempt-Date field is defined as in section Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt has been made and the Action field does not have value "opaque", in which case it will specify when it last attempted to deliver this message to another MTA or other Delivery Agent. This field MUST NOT be included if no delivery attempts have been made.

Last-Attempt-Date 欄は RFC 3464 の2.3.7節で定義されています。 この欄は配送が試みられ、 Action 欄が opaque という値を持たない場合には必須であり、 この場合このメッセージをいつ最後に他の MTA や他の配送エージェントに配送しようとしたかを指定します。 この欄は配送が試みられなかった場合には含めてはなりません

3.3.7. Will-Retry-Until field

The Will-Retry-Until field is defined as in section Reference 2.3.9 of [RFC-DSN-STAT]. If the message is not in the local queue or the Action field has the value "opaque" the Will-Retry-Until field MUST NOT be included; otherwise, this field SHOULD be included.

Will-Retry-Until 欄は RFC 3464 の2.3.9節で定義されています。 メッセージが局所待ち行列にないか、 Action 欄が opaque という値を持つ場合には Will-Retry-Until 欄を含めてはなりません。 層でない場合には、この欄は含めるべきです

3.4. Extension fields

Future extension fields may be defined as defined in section 2.4 of [RFC-DSN-STAT].

将来拡張欄が RFC 3464 の2.4節で定義されているように定義されるかもしれません。

3.5. Interaction Between MTAs and LDAs

A message that has been delivered to a Local Delivery Agent (LDA) that understands message tracking (in particular, an LDA speaking LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the tracking request to the LDA. In this case, the Action field for the MTA->LDA exchange will look the same as a transfer to a compliant MTA; that is, a "transferred" tracking status will be issued.

メッセージ追跡を理解する局所配送エージェント (LDA)、 特に MTRK 拡張に対応した LMTP を話す LDA に配送されたメッセージは、追跡要求を LDA に渡すべきです。 この場合、 MTA→LDA 交換の Action 欄は適合 MTA へ転送するのと同じようにします。 つまり、 transferred 追跡状態とします。

4. Security Considerations

4.1. Forgery

Malicious servers may attempt to subvert message tracking and return false information. This could result in misdirection or misinterpretation of results.

悪意ある鯖がメッセージ追跡を妨害して虚偽の情報を返そうとするかもしれません。 その結果、結果の誤解・誤指示が起こるかもしれません。

4.2. Confidentiality

Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding messages but does not wish to divulge the address to which the messages are autoforwarded. The desire for such confidentiality will probably be heightened as wireless mailboxes", such as pagers, become more widely used as autoforward addresses.

安全性の別の側面が機密性です。メッセージの受信者がメッセージを自動転送していて、 その転送先の番地を秘密にしておきたいという場合があるかもしれません。 このような機密性の要求はポケベルのような無線メイル箱が転送番地として広く使われるようになるにつれておそらく高まるはずです。

MTA authors are encouraged to provide a mechanism which enables the end user to preserve the confidentiality of a forwarding address. Depending on the degree of confidentiality required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of:

MTA の著者は末端利用者が転送番地の機密性を保持することができるような仕組みを用意することを推奨します。 これは必要な機密性の度合いとメッセージが転送される環境の性質に応じて、 次のどちらかか両方によって達成できるかもしれません。

  • (a) respond with a "relayed" tracking status when a message is forwarded to a confidential forwarding address, and disabling further message tracking requests.
  • (b) declaring the message to be delivered, issuing a "delivered" tracking status, re-sending the message to the confidential forwarding address, and disabling further message tracking requests.
  • メッセージが機密転送番地に転送された時に relayed 追跡状態で応答し、それ以上のメッセージ追跡要求は無効化する。
  • メッセージが配送されたとして delivered 追跡状態とし、機密転送番地にメッセージを転送し、 それ以上のメッセージ追跡要求は無効化する。

The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list.

追跡の算法はメイリング・リスト展開をこえて追跡することを認めてはなりません。 メッセージがリストに配送された時に、転送要求は expanded 追跡状態で応答しなければなりませんし、 リストの内容を表示してはなりません

5. IANA Considerations

IANA has registered the SMTP extension defined in section 3.

IANA は 3章で定義した SMTP 拡張を登録しています。

6. Acknowledgements

Several individuals have commented on and enhanced this document, including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.

7. References

7.1. Normative References

   [RFC-MTRK-MODEL]     Hansen, T., "Message Tracking Model and
                        Requirements", RFC 3888, September 2004.
   [RFC-MTRK-MTQP]      Hansen, T., "Message Tracking Query Protocol",
                        RFC 3887, September 2004.
   [RFC-MTRK-SMTPEXT]   Allman, E., "SMTP Service Extension for Message
                        Tracking", RFC 3885, September 2004.
   [RFC-ABNF]           Crocker, D., Ed. and P. Overell, "Augmented BNF
                        for Syntax Specifications: ABNF", RFC 2234,
                        November 1997.
   [RFC-EMSSC]          Vaudreuil, G., "Enhanced Mail System Status
                        Codes", RFC 3463, January 2003.
   [RFC-HOSTREQ]        Braden, R., Ed., "Requirements for Internet
                        Hosts -- Application and Support", STD 3, RFC
                        1123, October 1989.
   [RFC-KEYWORDS]       Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14, RFC 2119,
                        March 1997.
   [RFC-MIME]           Freed, N. and N. Borenstein, "Multipurpose
                        Internet Mail Extensions (MIME) Part One: Format
                        of Internet Message Bodies", RFC 2045, November
                        1996.
   [RFC-MSGFMT]         Resnick, P., Ed., "Internet Message Format", RFC
                        2822, April 2001.
   [RFC-RELATED]        Levinson, E., "The MIME Multipart/Related
                        Content-type", RFC 2387, August 1998.

7.2. Informational References

   [RFC-DSN-SMTP]       Moore, K., "Simple Mail Transfer Protocol (SMTP)
                        Service Extension for Delivery Status
                        Notifications (DSNs)", RFC 3461, January 2003.
   [RFC-DSN-STAT]       Moore, K. and G. Vaudreuil, "An Extensible
                        Message Format for Delivery Status
                        Notifications", RFC 3464, January 2003.
   [RFC-ESMTP]          Rose, M., Stefferud, E., Crocker, D., Klensin,
                        J., and N. Freed, "SMTP Service Extensions", STD
                        10, RFC 1869, November 1995.
   [RFC-LMTP]           Myers, J., "Local Mail Transfer Protocol", RFC
                        2033, October 1996.
   [RFC-MDN]            Hansen, T. and G. Vaudreuil, Eds., "Message
                        Disposition Notifications", RFC 3798, May 2004.

8. Author's Address

   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

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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and 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.
   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

メモ