Network Working Group T. Hansen
Request for Comments: 3888 AT&T Laboratories
Category: Informational September 2004
Network Working Group T. Hansen
Request for Comments: 3888 AT&T Laboratories
Category: Informational September 2004
Message Tracking Model and Requirements
消息跟踪模型和需求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions.
购买企业消息系统的客户经常会问：我可以跟踪消息吗？消息跟踪是找出特定消息通过消息传递系统的路径以及该消息的当前路由状态的能力。本文档提供了一个消息跟踪模型，可用于了解互联网范围内的消息基础设施，并进一步增强这些功能，以包括消息跟踪，以及建议的消息跟踪解决方案的要求。
Consider sending a package through a package delivery company. Once you've sent a package, you would like to be able to find out if the package has been delivered or not, and if not, where that package currently is and what its status is. Note that the status of a package may not include whether it was delivered to its addressee, but just the destination. Many package carriers provide such services today, often via a web interface.
考虑通过包裹递送公司发送包裹。一旦您发送了一个包，您希望能够了解该包是否已交付，如果未交付，该包当前在哪里以及其状态如何。请注意，包裹的状态可能不包括是否已送达收件人，而只包括目的地。如今，许多包运营商通常通过web界面提供此类服务。
Message tracking extends that capability to the Internet-wide message infrastructure, analogous to the service provided by package carriers: the ability to quickly locate where a message (package) is, and to determine whether or not the message (package) has been delivered to its final destination. An Internet-standard approach will allow the development of message tracking applications that can operate in a multi-vendor messaging environment, and will encourage the operation of the function across administrative boundaries.
消息跟踪将这一能力扩展到互联网范围的消息基础设施，类似于包运营商提供的服务：能够快速定位消息（包）的位置，并确定消息（包）是否已交付到其最终目的地。互联网标准方法将允许开发可在多供应商消息环境中运行的消息跟踪应用程序，并将鼓励跨管理边界运行该功能。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC-关键词]中的描述进行解释。
The following terms are relevant to message tracking. The terms Tracking User Agent and Tracking Server are new, while all other terms have been collected here from other sources.
以下术语与邮件跟踪相关。术语跟踪用户代理和跟踪服务器是新的，而所有其他术语都是从其他来源收集的。
Originating Mail User Agent (MUA) The originating mail user agent is the software used to compose and originate a message. It is the software sitting on a person's desktop.
发起邮件用户代理（MUA）发起邮件用户代理是用于撰写和发起邮件的软件。它是坐在个人桌面上的软件。
Originating Mail Submission Agent (MSA) The Mail Submission Agent accepts a message from a User Agent, adds or modifies it as required for Internet standards and/or site policy, and injects the message into the network. The MSA may be the initial MTA or may hand off the message to an MTA.
原始邮件提交代理（MSA）邮件提交代理接受来自用户代理的邮件，根据Internet标准和/或站点策略的要求添加或修改邮件，并将邮件注入网络。MSA可以是初始MTA，也可以将邮件传递给MTA。
Message Transfer Agent (MTA) A Message Transfer Agent accepts a message and moves it forward towards its destination. That destination may be local or reached via another MTA. It may use a local queue to store the message before transferring it further. Any MTA may generate a Non-Delivery Notification.
消息传输代理（MTA）消息传输代理接受消息并将其向前移动到目标。该目的地可以是本地的，也可以通过其他MTA到达。在进一步传输消息之前，它可以使用本地队列存储消息。任何MTA都可能生成未送达通知。
Intermediate Message Transfer Agent (MTA) An Intermediate MTA is an MTA that accepts a message for transfer somewhere else.
中间邮件传输代理（MTA）中间MTA是接受邮件以在其他地方传输的MTA。
Final Message Transfer Agent (MTA) A Final MTA is an MTA that accepts a message for local delivery. It is the final place that a message is accepted. The final MTA is what sends any Delivery Status Notifications (DSNs). (Intermediate MTA's may also send a DSN if it relays to a non-DSN aware MTA.)
最终邮件传输代理（MTA）最终MTA是接受邮件进行本地传递的MTA。它是接受消息的最终位置。最后一个MTA是发送任何传递状态通知（DSN）的MTA。（如果中间MTA中继到不支持DSN的MTA，则也可以发送DSN。）
Foreign Message Transfer Agent A foreign MTA provides delivery of messages using other protocols than those specified for Internet mail, such as an X.400 mail system.
外部邮件传输代理外部MTA使用Internet邮件指定协议以外的其他协议（如X.400邮件系统）提供邮件传递。
Gateway Message Transfer Agent (GW-MTA) A gateway MTA accepts a message for transfer to a foreign MTA outside of the Internet protocol space.
网关邮件传输代理（GW-MTA）网关MTA接受要传输到Internet协议空间之外的外部MTA的邮件。
Local Delivery Agent (LDA) The local Delivery Agent delivers the message to the local message store. (The MTA and LDA are often combined into the same program.)
本地传递代理（LDA）本地传递代理将邮件传递到本地邮件存储。（MTA和LDA通常合并到同一个计划中。）
Delivery Status Notification (DSN) A Delivery Status Notification [RFC-DSN] is produced by an MTA when a message is unsuccessfully delivered, either to its next hop or the final message store, or when it is successfully delivered, either to a foreign MTA, to a local delivery agent, or a non-DSN aware MTA. Positive notifications are only performed [RFC-ESMTP-DSN] when specifically requested.
传递状态通知（DSN）当邮件未成功传递到下一个跃点或最终邮件存储，或成功传递到外部MTA、本地传递代理或不支持DSN的MTA时，MTA会生成传递状态通知[RFC-DSN]。只有在明确要求时，才会执行[RFC-ESMTP-DSN]的肯定通知。
Non-Delivery Notification (NDN) A non-delivery notification is a special form of DSN indicating unsuccessful delivery.
未送达通知（NDN）未送达通知是DSN的一种特殊形式，表示未成功送达。
Message Disposition Notification (MDN) A Message Disposition Notification is used to report the disposition of a message after it has been successfully delivered to a recipient.
邮件处置通知（MDN）邮件处置通知用于在邮件成功传递给收件人后报告邮件的处置情况。
Tracking User Agent (TUA) A tracking user agent wants to find information on a message on the behalf of a user. It is the requestor or initiator of such a request. (The MUA and TUA could be combined into the same program.)
跟踪用户代理（TUA）跟踪用户代理希望代表用户查找消息中的信息。它是此类请求的请求者或发起者。（MUA和TUA可以合并到同一个项目中。）
Tracking Server A tracking server provides tracking information to a tracking client. It is the repository of the information about a message for the traversal through a particular MTA. (The tracking server and MTA may run on the same system.)
跟踪服务器跟踪服务器向跟踪客户端提供跟踪信息。它是有关消息的信息存储库，用于遍历特定MTA。（跟踪服务器和MTA可以在同一系统上运行。）
The entities involved in message tracking are: message user agents, message submission agents, message transfer agents, tracking user agents and tracking servers.
邮件跟踪涉及的实体有：邮件用户代理、邮件提交代理、邮件传输代理、跟踪用户代理和跟踪服务器。
These are requirements that any message tracking solution must be able to satisfy:
任何邮件跟踪解决方案都必须满足以下要求：
The message tracking solution:
邮件跟踪解决方案：
** MUST scale to the internet.
**必须扩展到互联网。
** MUST be easy to deploy.
**必须易于部署。
** SHOULD maximize the reuse of existing, already deployed technology and infrastructure.
**应最大限度地重用现有的、已部署的技术和基础设施。
** If possible, SHOULD extend existing protocols and not invent new ones.
**如果可能的话，我们应该扩展现有的协议，而不是发明新的协议。
** SHOULD have a low implementation cost. (This makes it easy to incorporate into existing products.)
**应具有较低的实施成本。（这使其易于并入现有产品。）
** MUST restrict tracking of a message to the originator of the message (or a delegate).
**必须将邮件跟踪限制为邮件的原始发件人（或代表）。
** MUST be able to do authentication.
**必须能够进行身份验证。
** MAY allow an originator to delegate this responsibility to a third party.
**可允许发起人将此责任委托给第三方。
** SHOULD have the property that they would allow per-message delegation of the tracking responsibility.
**应具有允许每封邮件委派跟踪责任的属性。
** MUST require a tracking user agent to prove that they are permitted to request the tracking information.
**必须要求跟踪用户代理证明他们被允许请求跟踪信息。
** MUST be able to uniquely identify messages.
**必须能够唯一标识消息。
** MUST require every message to have unique identification.
**必须要求每条消息具有唯一标识。
There are several models by which tracking of messages can be enabled, by which messages can be tracked, and by which information can be requested and gathered.
有几种模型可用于启用消息跟踪、跟踪消息以及请求和收集信息。
Either the envelope or message header must contain enough information to track a message and securely retrieve information about the message. Any message that does not have enough information to track it is by definition not trackable.
信封或消息头必须包含足够的信息来跟踪消息并安全地检索有关消息的信息。根据定义，没有足够信息跟踪的任何消息都是不可跟踪的。
If there is not enough information available in current standard envelopes or message headers, then the current standards will need to be extended. Either the MUA or MSA must determine the additional information and enable the tracking by adding the additional information to either the envelope or header.
如果当前标准信封或邮件标题中没有足够的可用信息，则需要扩展当前标准。MUA或MSA必须确定附加信息，并通过将附加信息添加到信封或标头来启用跟踪。
This leads to two tracking enabling models: passive enabling and active enabling.
这导致了两种跟踪启用模型：被动启用和主动启用。
The "passive enabling" model assumes that there is sufficient information available. No UA or MSA interaction occurs to turn tracking on; it is on by default.
“被动启用”模型假设有足够的可用信息。未发生UA或MSA交互以打开跟踪；默认情况下，它处于启用状态。
The "active enabling" model requires that the MUA and MSA exchange information when the message is submitted. This exchange indicates that logging of the message's traversal should be performed, as well as providing enough additional information to allow the message to be tracked. This information will need to be passed on to subsequent MTAs as needed.
“主动启用”模型要求MUA和MSA在提交消息时交换信息。此交换指示应执行消息遍历的日志记录，并提供足够的附加信息以允许跟踪消息。此信息需要根据需要传递给后续MTA。
There are several models by which tracking information may be requested.
有几种模型可用于请求跟踪信息。
The "passive request" model requires active enabling to indicate that some form of tracking is to be performed. The tracking information can be sent back immediately (as a form of telemetry) or sent to a 3rd party for later retrieval.
“被动请求”模型需要主动启用，以指示要执行某种形式的跟踪。跟踪信息可以立即发回（作为遥测的一种形式）或发送给第三方以供以后检索。
Forms of passive tracking information that could potentially be requested are as follows. Note that mechanisms already exist for requesting the information marked with a (+). The references for such mechanisms are listed at the end of each such entry.
可能被请求的被动跟踪信息的形式如下。请注意，已存在用于请求标记为（+）的信息的机制。这些机制的参考资料列在每个条目的末尾。
** send a DSN of a message arriving at an intermediate MTA
**发送到达中间MTA的邮件的DSN
** (+) send a DSN of a message being rejected while at an intermediate MTA [RFC-DSN]
**（+）在中间MTA中发送被拒绝邮件的DSN[RFC-DSN]
** (+) send a DSN of a message leaving an intermediate MTA and going to another MTA [RFC-DELIVER-BY]
**（+）发送从中间MTA发送到另一MTA的邮件的DSN[RFC-DELIVER-BY]
** send a DSN of a message arriving at a final MTA
**发送到达最终MTA的邮件的DSN
** (+) send a DSN of a message being rejected while at a final MTA [RFC-DSN]
**（+）在最终MTA时发送被拒绝邮件的DSN[RFC-DSN]
** (+) send a DSN of a message being delivered to a user's message store [RFC-DSN]
**（+）发送发送到用户消息存储区的消息的DSN[RFC-DSN]
** (+) send a DSN of a message being delivered to a foreign MTA [RFC-DSN]
**（+）向外部MTA发送正在传递的邮件的DSN[RFC-DSN]
** (+) send an MDN of a message being read by an end user [RFC-MDN]
** (+) send an MDN of a message being read by an end user [RFC-MDN]
The "active request" model requires an active query by a user's user agent to the MSA, intermediate MTAs and final MTA, or to a third party, to find the message's status as known by that MTA. Active request will work with either passive enabling or active enabling.
“主动请求”模型要求用户的用户代理向MSA、中间MTA和最终MTA或第三方进行主动查询，以查找该MTA已知的邮件状态。主动请求将与被动启用或主动启用一起工作。
When a tracking server has been asked for tracking information, and the message has been passed on to another MTA of which this tracking server has no tracking knowledge, there are two modelling choices:
当跟踪服务器被要求提供跟踪信息，并且消息已传递给该跟踪服务器不了解跟踪信息的另一个MTA时，有两种建模选择：
** the first tracking server will contact the next tracking server to query for status and pass back the combined status (server chaining), or
**第一个跟踪服务器将联系下一个跟踪服务器以查询状态并传回组合状态（服务器链接），或
** the first tracking server will return the address of the next MTA and the tracking client has the responsibility of contacting the next tracking server (server referrals).
**第一个跟踪服务器将返回下一个MTA的地址，跟踪客户端负责联系下一个跟踪服务器（服务器推荐）。
Forms of active tracking information that could potentially be requested are as follows. (Note that no mechanisms currently exist for requesting such information.)
可能被请求的活动跟踪信息的形式如下。（请注意，目前不存在请求此类信息的机制。）
** the message has been queued for later delivery
**邮件已排队等待稍后传递
** the message was delivered locally
**消息是在本地传递的
** the message was delivered to another MTA,
**邮件已传递到另一个MTA，
** the message was delivered to a foreign MTA
**该邮件已传递到外部MTA
** ask a different tracking server,
**询问其他跟踪服务器，
** I know but can't tell you,
**我知道但不能告诉你，
** I don't know.
**我不知道。
5.4. Combining DSN and MDN Information with Message Tracking Information
5.4. 将DSN和MDN信息与消息跟踪信息相结合
The information that would be retrieved by message tracking and the information that is returned for DSN and MDN requests all attempt to answer the question of "what happened to message XX"? The information provided by each is complimentary in nature, but similar. A tracking user agent could use all three possible information sources to present a total view of the status of a message.
消息跟踪将检索到的信息以及为DSN和MDN请求返回的信息都试图回答“消息XX发生了什么”的问题？每个人提供的信息本质上是互补的，但相似。跟踪用户代理可以使用所有三个可能的信息源来显示消息状态的总体视图。
Both DSN and MDN notifications utilize the formats defined by RFC 3462 [RFC-REPORT]. This suggests that the information returned by message tracking solutions should also be similar.
DSN和MDN通知都使用RFC 3462[RFC-REPORT]定义的格式。这表明消息跟踪解决方案返回的信息也应该类似。
Security vulnerabilities are detailed in [RFC-MTRK-ESMTP], [RFC-MTRK-TSN] and [RFC-MTRK-MTQP]. These considerations include:
[RFC-MTRK-ESMTP]、[RFC-MTRK-TSN]和[RFC-MTRK-MTQP]中详细介绍了安全漏洞。这些考虑包括：
** vulnerability to snooping or replay attacks when using unencrypted sessions
**使用未加密会话时易受窥探或重播攻击
** a dependency on the randomness of the per-message secret
**依赖于每条消息机密的随机性
** reliance on TLS
**依赖TLS
** man-in-the-middle attacks
**中间人攻击
** reliance on the server maintaining the security level when it performs chaining
**依赖服务器在执行链接时维护安全级别
** denial of service
**拒绝服务
** confidentiality concerns
**保密问题
** forgery by malicious servers
**恶意服务器伪造
This is a security model for message identification and authentication that could be deployed. (There may be others.)
这是可以部署的消息标识和身份验证的安全模型。（可能还有其他人。）
A Tracking User Agent must prove that they are permitted to request tracking information about a message. Every [RFC-822]-compliant message is supposed to contain a Message-Id header. One possible mechanism is for the originator to calculate a one-way hash A from the message ID + time stamp + a per-user secret. The user then calculates another one-way hash B to be the hash of A. The user includes B in the submitted message, and retains A. Later, when the user makes a message tracking request to the messaging system or tracking entity, it submits A in the tracking request. The entity receiving the tracking request then uses A to calculate B, since it was already provided B, verifying that the requestor is authentic. In summary,
跟踪用户代理必须证明他们被允许请求有关消息的跟踪信息。每个符合[RFC-822]的消息都应该包含一个消息Id头。一种可能的机制是发起者根据消息ID+时间戳+每个用户的秘密计算单向散列a。然后，用户计算另一个单向散列B作为A的散列。用户在提交的消息中包含B，并保留A。稍后，当用户向消息传递系统或跟踪实体发出消息跟踪请求时，它在跟踪请求中提交A。然后，接收跟踪请求的实体使用A来计算B，因为已经提供了B，从而验证请求者是真实的。总之，
A = H(message ID + time stamp + secret)
A = H(message ID + time stamp + secret)
B = H(A)
B=H（A）
Another possible mechanism for A is to ignore the message ID and time stamp and just use a one-way hash from a large (>128 bits) random number. B would be calculated as before. In summary,
另一种可能的机制是忽略消息ID和时间戳，只使用大（>128位）随机数的单向散列。B将按以前的方式计算。总之，
A = H(large-random-number)
A=H（大随机数）
B = H(A)
B=H（A）
This is similar in technique to the methods used for One-Time Passwords [RFC-OTP]. The success of these techniques is dependent on the randomness of the per-user secret or the large random number, which can be incredibly difficult in some environments.
这在技术上类似于一次性密码[RFC-OTP]使用的方法。这些技术的成功取决于每个用户秘密的随机性或大的随机数，这在某些环境中可能非常困难。
If the originator of a message were to delegate his or her tracking request to a third party by sending it A, this would be vulnerable to snooping over unencrypted sessions. The user can decide on a message-by-message basis if this risk is acceptable.
如果消息的发起者通过发送消息将其跟踪请求委托给第三方，则很容易在未加密的会话上进行窥探。如果该风险是可接受的，用户可以逐个消息来决定。
[RFC-822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-DELIVER-BY] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC-DELIVER-BY]Newman，D.，“通过SMTP服务扩展交付”，RFC 2852000年6月。
[RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC-DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC-ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC-ESMTP-DSN]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.
[RFC-MDN]Hansen，T.和G.Vaudreuil，编辑，“消息处置通知”，RFC 3798，2004年5月。
[RFC-OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[RFC-OTP]Haller，N.，Metz，C.，Nesser，P.和M.Straw，“一次性密码系统”，STD 61，RFC 2289，1998年2月。
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[RFC-REPORT]Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[RFC-MTRK-ESMTP] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[RFC-MTRK-ESMTP]Allman，E.和T.Hansen，“用于邮件跟踪的SMTP服务扩展”，RFC 38852004年9月。
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME Extension", RFC 3886, September 2004.
[RFC-MTRK-TSN]Allman，E.“消息/跟踪状态MIME扩展”，RFC 38862004年9月。
[RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC 3887, September 2004.
[RFC-MTRK-MTQP]Hansen，T，“消息跟踪查询协议”，RFC 3887，2004年9月。
This document is the product of input from many people and many sources, including all of the members of the Message Tracking Working Group: Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, and Gregory Neil Shapiro. It owes much to earlier work by Gordon Jones, Bruce Ernst, and Greg Vaudreuil. In particular, I'd like to also thank Ken Lin for his considerable contributions to the early versions of the document.
本文档是来自许多人和许多来源的输入的产物，包括邮件跟踪工作组的所有成员：Philip Hazel、Alexey Melnikov、Lyndon Nerenberg、Chris Newman和Gregory Neil Shapiro。这在很大程度上要归功于戈登·琼斯、布鲁斯·恩斯特和格雷格·沃德鲁伊早期的工作。特别是，我还要感谢Ken Lin对文档早期版本的贡献。
Tony Hansen AT&T Laboratories Middletown, NJ 07748 USA
美国新泽西州米德尔顿市托尼·汉森AT&T实验室07748
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。