Network Working Group O. Levin
Request for Comments: 4488 Microsoft Corporation
Category: Standards Track May 2006
Network Working Group O. Levin
Request for Comments: 4488 Microsoft Corporation
Category: Standards Track May 2006
Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
会话启动协议（SIP）引用方法隐式订阅的抑制
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request.
RFC 3515中定义的会话发起协议（SIP）REFER扩展自动建立典型的短命事件订阅，用于向发送REFER请求的一方通知接收方在执行REFER请求的事务时的状态。并非所有情况下都需要这些通知。本规范提供了一种方法，以防止使用REFER请求中可能包含的新SIP扩展头字段自动建立事件订阅和后续通知。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Preventing Forking of REFER Requests . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Preventing Forking of REFER Requests . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
The REFER specification [3] specifies that every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient.
REFER规范[3]规定，每个REFER都会在REFER颁发者和REFER接收者之间创建一个隐式订阅。
This document defines a new SIP header field: "Refer-Sub" meaningful within a REFER transaction only. This header field, when set to "false", specifies that a REFER-Issuer requests that the REFER-Recipient doesn't establish an implicit subscription and the resultant dialog.
本文档定义了一个新的SIP头字段：“referesub”仅在refere事务中有意义。当设置为“false”时，此标题字段指定引用颁发者请求引用接收者不建立隐式订阅和结果对话框。
This document defines a new option tag: "norefersub". This tag, when included in the Supported header field, indicates that a User Agent (UA) is capable of accepting a REFER request without creating an implicit subscription when acting as a REFER-Recipient.
本文档定义了一个新的选项标记：“norefersub”。当此标记包含在Supported header字段中时，表示用户代理（UA）能够在充当REFER收件人时接受REFER请求，而无需创建隐式订阅。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
To simplify discussions of the REFER method and its extensions, the three terms below are being used throughout the document:
为了简化对REFER方法及其扩展的讨论，本文件中使用了以下三个术语：
o REFER-Issuer: the UA issuing the REFER request
o 转介发卡机构：发出转介请求的UA
o REFER-Recipient: the UA receiving the REFER request
o 转介接收人：接收转介请求的UA
o REFER-Target: the UA designated in the Refer-To Uniform Resource Identifier (URI)
o 引用目标：引用统一资源标识符（URI）中指定的UA
The REFER specification mandates that every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient. This subscription results in at least one NOTIFY being sent from the REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose to cancel the implicit subscription with this NOTIFY. The REFER-Issuer may choose to cancel this implicit subscription with an explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY.
REFER规范要求每个REFER在REFER颁发者和REFER接收者之间创建一个隐式订阅。此订阅会导致从推荐收件人向推荐发行人发送至少一个通知。推荐收件人可以选择使用此通知取消隐式订阅。在收到初始通知后，推荐发行人可以选择使用显式订阅（到期日：0）取消此隐式订阅。
One purpose of requiring the implicit subscription and initial NOTIFY is to allow for the situation where the REFER request gets forked and the REFER-Issuer needs a way to see the multiple dialogs that may be established as a result of the forked REFER. This is the same approach used to handle forking of SUBSCRIBE [4] requests. Where the
要求隐式订阅和初始通知的一个目的是考虑到REFER请求被分叉的情况，REFER发行人需要一种方式来查看可能由于分叉REFER而建立的多个对话框。这与处理SUBSCRIBE[4]请求的分叉相同。在哪里
REFER-Issuer explicitly specifies that forking not occur, the requirement that an implicit subscription be established is unnecessary.
REFER Issuer明确指定不发生分叉，不需要建立隐式订阅的要求。
Another purpose of the NOTIFY is to inform the REFER-Issuer of the progress of the SIP transaction that results from the REFER at the REFER-Recipient. In the case where the REFER-Issuer is already aware of the progress of the requested operation, such as when the REFER-Issuer has an explicit subscription to the dialog event package at the REFER-Recipient, the implicit subscription and resultant NOTIFY traffic related to the REFER can create an unnecessary network overhead.
通知的另一个目的是通知转介发行人转介接收方的SIP交易的进展情况。在REFER颁发者已经知道所请求操作的进度的情况下，例如当REFER颁发者在REFER接收者处对对话框事件包有显式订阅时，隐式订阅和与REFER相关的结果NOTIFY通信量可能会产生不必要的网络开销。
This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER-Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used).
本文档定义了一个新的SIP头字段：“referesub”。此标头字段有意义，只能与REFER请求和相应的2XX响应一起使用。此标题字段设置为“false”指定引用颁发者请求引用收件人不建立隐式订阅和结果对话框。请注意，在使用此扩展时，refere仍然是一个目标刷新请求（在默认情况下——不使用扩展时）。
This document adds the following entry to Table 2 of [2]. The additions to this table are also provided for extension methods at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way:
本文件将以下条目添加到[2]的表2中。在本文件发布时，本表还提供了扩展方法的补充内容。这是出于对读者的礼貌，在任何方面都不规范：
Header field where proxy ACK BYE CAN INV OPT REG MSG
代理确认BYE可以INV OPT REG MSG的标头字段
Refer-Sub R, 2xx - - - - - - -
Refer-Sub R, 2xx - - - - - - -
Header field where SUB NOT REF INF UPD PRA PUB
标题字段，其中SUB NOT REF INF UPD PRA PUB
Refer-Sub R, 2xx - - o - - - -
Refer-Sub R, 2xx - - o - - - -
The Refer-Sub header field MAY be encrypted as part of end-to-end encryption.
引用子报头字段可以作为端到端加密的一部分进行加密。
The syntax of the header field follows the BNF defined below:
标题字段的语法遵循下面定义的BNF：
Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)
refer-sub-value = "true" / "false"
exten = generic-param
Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)
refer-sub-value = "true" / "false"
exten = generic-param
where the syntax of generic-param is defined in [2].
其中[2]中定义了泛型参数的语法。
The "Refer-Sub" header field set to "false" MAY be used by the REFER-Issuer only when the REFER-Issuer can be certain that the REFER request will not be forked.
“refere Sub”标题字段设置为“false”，只有当refere发卡机构能够确定refere请求不会被分叉时，refere发卡机构才可以使用该字段。
If the REFER-Recipient supports the extension and is willing to process the REFER transaction without establishing an implicit subscription, it MUST insert the "Refer-Sub" header field set to "false" in the 2xx response to the REFER-Issuer. In this case, no implicit subscription is created. Consequently, no new dialog is created if this REFER was issued outside any existing dialog.
如果转介接收人支持扩展，并且愿意在不建立隐含订阅的情况下处理转介交易，则必须在对转介发行人的2xx响应中插入设置为“false”的“转介子”标题字段。在这种情况下，不会创建隐式订阅。因此，如果此引用是在任何现有对话框之外发出的，则不会创建新对话框。
If the REFER-Issuer inserts the "Refer-Sub" header field set to "false", but the REFER-Recipient doesn't grant the suggestion (i.e., either does not include the "Refer-Sub" header field or includes the "Refer-Sub" header field set to "true" in the 2xx response), an implicit subscription is created as in the default case.
如果REFER发卡机构插入设置为“false”的“REFER Sub”标题字段，但REFER收件人不同意该建议（即，在2xx响应中不包含“REFER Sub”标题字段或包含设置为“true”的“REFER Sub”标题字段），则会像默认情况一样创建隐式订阅。
This document also defines a new option tag, "norefersub". This tag, when included in the Supported header field, specifies that a User Agent (UA) is capable of accepting a REFER request without creating an implicit subscription when acting as a REFER-Recipient.
本文档还定义了一个新的选项标记“norefersub”。当此标记包含在Supported header字段中时，它指定用户代理（UA）能够在充当REFER收件人时接受REFER请求，而无需创建隐式订阅。
The REFER-Issuer can know the capabilities of the REFER-Recipient from the presence of the option tags in the Supported header field of the dialog initiating request or response. Another way of learning the capabilities would be by using presence, such as defined in [6]. However, if the capabilities of the REFER-Recipient are not known, using the "norefersub" tag with the Require header field is NOT RECOMMENDED. This is due to the fact that in the event the REFER-Recipient doesn't support the extension, in order to fall back to the normal REFER, the REFER-Issuer will need to issue a new REFER transaction thus resulting in additional round-trips.
REFER发卡机构可以通过发起请求或响应的对话框的Supported header字段中的选项标记来了解REFER接收方的能力。学习这些能力的另一种方法是使用状态，如[6]中定义的。但是，如果不知道refererecipient的功能，则不建议在Require header字段中使用“norefersub”标记。这是因为，如果转介接收人不支持延期，为了回到正常转介，转介发行人将需要发行新的转介交易，从而导致额外的往返。
As described in Section 8.2.2.3 in [2], a REFER-Recipient will reject a REFER request containing a Require: norefersub header field with a 420 (Bad Extension) response unless it supports this extension. Note that Require: norefersub can be present with a Refer-Sub: false header field.
如[2]第8.2.2.3节所述，参考接收人将拒绝包含Require:norefersub标头字段和420（错误扩展）响应的参考请求，除非其支持此扩展。请注意，Require:norefersub可以与referesub:false标题字段一起出现。
The REFER specification allows for the possibility of forking a REFER request that is sent outside of an existing dialog. In addition, a proxy may fork an unknown method type. Should forking occur, the sender of the REFER with "Refer-Sub" will not be aware as only a single 2xx response will be forwarded by the forking proxy. As a result, the responsibility is on the issuer of the REFER with "Refer-Sub" to ensure that no forking will result.
REFER规范允许分叉在现有对话框外部发送的REFER请求。此外，代理可能会派生未知的方法类型。如果发生分叉，带有“referesub”的refere的发送方将不知道，因为分叉代理只转发一个2xx响应。因此，使用“参考子项”进行参考的发行人有责任确保不会产生分叉。
If a REFER request to a given Request-URI might fork, the REFER-Issuer SHOULD NOT include the "Refer-Sub" header field. The REFER-Issuer SHOULD use standardized mechanisms for ensuring the REFER request does not fork. In absence of any other mechanism, the Request-URI of the REFER request SHOULD have Globally Routable User Agent URI (GRUU) properties according to the definitions of [5] as those properties ensure the request will not fork.
如果对给定请求URI的REFER请求可能会分叉，则REFER颁发者不应包括“REFER Sub”头字段。转介发行人应使用标准化机制确保转介请求不会分叉。在没有任何其他机制的情况下，根据[5]的定义，REFER请求的请求URI应该具有全局可路由用户代理URI（GRUU）属性，因为这些属性确保请求不会分叉。
An example of REFER that suppresses the implicit subscription is shown below. Note that the conventions used in the SIP Torture Test Messages [7] document are reused, specifically the <allOneLine> tag.
下面显示了抑制隐式订阅的引用示例。请注意，SIP测试消息[7]文档中使用的约定被重用，特别是<allOneLine>标记。
REFER sip:pc-b@example.com SIP/2.0
Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1
From: <sip:a@example.com>;tag=1a
<allOneLine>
To: sip:b@example.com;opaque=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a
</allOneLine>
Call-ID: 1@issuer.example.com
CSeq: 234234 REFER
Max-Forwards: 70
Refer-To: <sip:c@example.com;method=INVITE>
Refer-Sub: false
Supported: norefersub
Contact: sip:a@issuer.example.com
Content-Length: 0
REFER sip:pc-b@example.com SIP/2.0
Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1
From: <sip:a@example.com>;tag=1a
<allOneLine>
To: sip:b@example.com;opaque=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a
</allOneLine>
Call-ID: 1@issuer.example.com
CSeq: 234234 REFER
Max-Forwards: 70
Refer-To: <sip:c@example.com;method=INVITE>
Refer-Sub: false
Supported: norefersub
Contact: sip:a@issuer.example.com
Content-Length: 0
This document registers a new SIP header field "Refer-Sub". This header field is only meaningful for the REFER request defined in RFC 3515 [3] and the corresponding response. The following information has been added to the SIP Header field sub-registry in the SIP Parameters Registry:
本文档注册了一个新的SIP头字段“Refer Sub”。此标头字段仅对RFC 3515[3]中定义的REFER请求和相应的响应有意义。以下信息已添加到SIP参数注册表中的SIP头字段子注册表中：
o Header Name: Refer-Sub
o 标题名称：参考子标题
o Compact Form: None
o 紧凑型：无
o Reference: RFC 4488
o 参考：RFC4488
This document also registers a new SIP option tag, "norefersub", adding it to the SIP Option Tags sub-registry in the SIP Parameters Registry. The required information for this registration, as specified in RFC 3261 [2], is:
本文档还注册了一个新的SIP选项标记“norefersub”，将其添加到SIP参数注册表中的SIP选项标记子注册表中。RFC 3261[2]中规定的本次注册所需信息为：
o Name: norefersub
o 姓名：norefersub
o Description: This option tag specifies a User Agent ability of accepting a REFER request without establishing an implicit subscription (compared to the default case defined in RFC 3515 [3]).
o 描述：此选项标记指定用户代理在不建立隐式订阅的情况下接受REFER请求的能力（与RFC 3515[3]中定义的默认情况相比）。
The purpose of this SIP extension is to modify the expected behavior of the REFER-Recipient. The change in behavior is for the REFER-Recipient not to establish a dialog and not to send NOTIFY messages back to the REFER-Issuer. As such, a malicious inclusion of a "Refer-Sub" header field set to "false" reduces the processing and state requirements on the recipient. As a result, its use in a denial-of-service attack seems limited.
此SIP扩展的目的是修改引用收件人的预期行为。行为上的改变是指REFER收件人不建立对话框，也不将NOTIFY消息发送回REFER颁发者。因此，恶意包含设置为“false”的“referesub”头字段会降低对收件人的处理和状态要求。因此，它在拒绝服务攻击中的使用似乎是有限的。
On the other hand, by inserting a "Refer-Sub" header field set to "false", a man-in-the-middle (MitM) can potentially exploit the mechanism for easier (than an interception) suppression of the notifications from the REFER-Receiver without the REFER-Issuer noticing it. Also, by removing a "Refer-Sub" header field set to "false", a MitM can cause the REFER-Receiver to generate notifications over the implicit dialog that otherwise had been suppressed by the REFER-Issuer.
另一方面，通过插入设置为“false”的“referesub”报头字段，中间人（MitM）可以潜在地利用该机制来更容易地（而不是截取）抑制来自refere接收方的通知，而不会引起refere发行人的注意。此外，通过删除设置为“false”的“referesub”头字段，MitM可以使refere接收方通过隐式对话框生成通知，否则该对话框已被refere颁发者抑制。
To protect against these kinds of MitM attacks, integrity protection should be used. For example, the REFER-Issuer could use S/MIME as discussed in RFC 3261 [2] to protect against these kinds of attacks.
为了防止此类MitM攻击，应使用完整性保护。例如，如RFC 3261[2]中所述，引用颁发者可以使用S/MIME来防止此类攻击。
The SIP community would like to thank Sriram Parameswar for his ideas, originally presented in "Suppressing Refer Implicit Subscription" (October 2002), which served as the basis for this specification.
SIP社区要感谢Sriram Parameswar的想法，这些想法最初是在“订阅”（2002年10月）中提出的，作为本规范的基础。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[5] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2005年10月。
[6] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
[6] Lonnfors，M.和K.Kiss，“会话启动协议（SIP）用户代理能力扩展到状态信息数据格式（PIDF）”，正在进行的工作，2006年1月。
[7] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[7] Sparks，R.，Ed.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
Author's Address
作者地址
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
奥利特·莱文微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: 425-722-2225 EMail: oritl@microsoft.com
电话：425-722-2225电子邮件：oritl@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。