Network Working Group G. Camarillo
Request for Comments: 4032 Ericsson
Updates: 3312 P. Kyzivat
Category: Standards Track Cisco Systems
March 2005
Network Working Group G. Camarillo
Request for Comments: 4032 Ericsson
Updates: 3312 P. Kyzivat
Category: Standards Track Cisco Systems
March 2005
Update to the Session Initiation Protocol (SIP) Preconditions Framework
会话启动协议（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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility.
本文档更新了RFC3312，它定义了SIP中的前提条件框架。我们为新的前置条件类型的作者提供指导，并描述如何在涉及会话移动性的情况下使用SIP前置条件。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Defining New Precondition Types . . . . . . . . . . . . . . . 3
3.1. Precondition Type Tag . . . . . . . . . . . . . . . . . 3
3.2. Status Type . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Precondition Strength . . . . . . . . . . . . . . . . . 3
3.4. Suspending and Resuming Session Establishment . . . . . 3
4. Issues Related to Session Mobility . . . . . . . . . . . . . . 4
4.1. Update to RFC 3312 . . . . . . . . . . . . . . . . . . . 5
4.2. Desired Status . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Defining New Precondition Types . . . . . . . . . . . . . . . 3
3.1. Precondition Type Tag . . . . . . . . . . . . . . . . . 3
3.2. Status Type . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Precondition Strength . . . . . . . . . . . . . . . . . 3
3.4. Suspending and Resuming Session Establishment . . . . . 3
4. Issues Related to Session Mobility . . . . . . . . . . . . . . 4
4.1. Update to RFC 3312 . . . . . . . . . . . . . . . . . . . 5
4.2. Desired Status . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
RFC 3312 [3] defines the framework for SIP [2] preconditions, which is a generic framework that allows SIP UAs (User Agents) to suspend the establishment of a session until a set of preconditions are met. Although only Quality of Service (QoS) preconditions have been defined so far, this framework supports different types of preconditions. (QoS preconditions are defined by RFC 3312 as well).
RFC 3312[3]定义了SIP[2]先决条件的框架，这是一个通用框架，允许SIP UAs（用户代理）暂停会话的建立，直到满足一组先决条件。尽管到目前为止只定义了服务质量（QoS）前提条件，但该框架支持不同类型的前提条件。（QoS前提条件也由RFC 3312定义）。
This document updates RFC 3312, provides guidelines for authors of new precondition types and explains which topics they need to discuss when defining them. In addition, it updates some of the procedures in RFC 3312 for using SIP preconditions in situations that involve session mobility as described below.
本文档更新了RFC 3312，为新前提条件类型的作者提供了指南，并解释了在定义它们时需要讨论的主题。此外，它还更新了RFC 3312中的一些过程，以便在涉及会话移动性的情况下使用SIP先决条件，如下所述。
RFC 3312 focuses on media sessions that do not move around. That is, media is sent between the same end-points throughout the duration of the session. Nevertheless, media sessions established by SIP are not always static.
RFC3312专注于不移动的媒体会话。也就是说，在整个会话期间，在相同的端点之间发送媒体。然而，SIP建立的媒体会话并不总是静态的。
SIP offers mechanisms to provide session mobility, namely re-INVITEs and UPDATEs [5]. While existing implementations of RFC 3312 can probably handle session mobility, there is a need to explicitly point out the issues involved and make a slight update on some of the procedures defined there in. With the updated procedures defined in this document, messages carrying precondition information become more explicit about the current status of the preconditions.
SIP提供了提供会话移动性的机制，即重新邀请和更新[5]。虽然RFC 3312的现有实现可能可以处理会话移动性，但需要明确指出所涉及的问题，并对其中定义的一些过程进行轻微更新。通过本文档中定义的更新过程，携带前提条件信息的消息对于前提条件的当前状态变得更加明确。
Specifically, we now allow answers to downgrade current status values (this was disallowed by RFC 3312). We consider moving an existing stream to a new location as equivalent to establishing a new stream. Therefore, answers moving streams to new locations set all the current status values in their answers to "No" and start a new precondition negotiation from scratch.
具体来说，我们现在允许答案降低当前状态值（RFC3312不允许这样做）。我们认为将现有的流移动到新的位置相当于建立一个新的流。因此，将流移动到新位置的应答将其应答中的所有当前状态值设置为“否”，并从头开始新的前提条件协商。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
Specifications defining new precondition types need to discuss the topics described in this section. Having clear definitions of new precondition types is essential to ensure interoperability among different implementations.
定义新前置条件类型的规范需要讨论本节中描述的主题。明确定义新的前置条件类型对于确保不同实现之间的互操作性至关重要。
New precondition types MUST have an associated precondition type tag (e.g., "qos" is the tag for QoS preconditions). Authors of new preconditions MUST register new precondition types and their tags with the IANA by following the instructions in Section 15 of RFC 3312.
新的前提条件类型必须具有关联的前提条件类型标记（例如，“qos”是qos前提条件的标记）。新前提条件的作者必须按照RFC 3312第15节中的说明向IANA注册新的前提条件类型及其标记。
RFC 3312 defines two status types: end-to-end and segmented. Specifications defining new precondition types MUST indicate which status applies to the new precondition. New preconditions can use only one status type or both. For example, the QoS preconditions defined in RFC 3312 can use both.
RFC 3312定义了两种状态类型：端到端和分段。定义新前提条件类型的规范必须指明适用于新前提条件的状态。新的先决条件只能使用一种状态类型或同时使用两种状态类型。例如，RFC 3312中定义的QoS前提条件可以同时使用两者。
RFC 3312 defines optional and mandatory preconditions. Specifications defining new precondition types MUST describe whether or not optional preconditions are applicable, and in case they are, what is the expected behavior of a UA on reception of optional preconditions.
RFC 3312定义了可选和强制性前提条件。定义新前提条件类型的规范必须说明可选前提条件是否适用，如果适用，UA在接收可选前提条件时的预期行为是什么。
Section 6 of RFC 3312 describes the behavior of UAs from the moment session establishment is suspended, due to a set of preconditions, until it is resumed when these preconditions are met. In general, the called user is not alerted until the preconditions are met.
RFC 3312的第6节描述了从会话建立由于一组先决条件而暂停到满足这些先决条件后会话恢复的UAs行为。通常，在满足前提条件之前，不会向被叫用户发出警报。
In addition to not alerting the user, each precondition type MUST define any extra actions UAs should perform or refrain from performing when session establishment is suspended. The behavior of media streams during session suspension is therefore part of the definition of a particular precondition type. Some precondition
除了不提醒用户之外，每个前提条件类型必须定义当会话建立暂停时UAs应执行或不执行的任何额外操作。因此，会话暂停期间媒体流的行为是特定前提条件类型定义的一部分。一些前提条件
types may allow media streams to send and receive packets during session suspension; others may not. Consequently, the following paragraph from RFC 3312 only applies to QoS preconditions:
类型可允许媒体流在会话暂停期间发送和接收分组；其他人可能不会。因此，RFC 3312中的以下段落仅适用于QoS前提条件：
While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP, neither RTP nor RTCP packets are sent.
会话建立挂起时，用户代理不应通过任何媒体流发送任何数据。对于RTP，既不发送RTP数据包，也不发送RTCP数据包。
To clarify the previous paragraph, the control messages used to establish connections in connection-oriented transport protocols (e.g., TCP SYNs) are not affected by the previous rule. So, user agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to decide when to establish the connection, regardless of QoS preconditions.
为了澄清上一段，用于在面向连接的传输协议（例如TCP SYN）中建立连接的控制消息不受上一条规则的影响。因此，用户代理遵循标准规则（例如，SDP“setup”属性[7]）来决定何时建立连接，而不考虑QoS先决条件。
New precondition types MUST also describe the behaviour of UAs on reception of a re-INVITE or an UPDATE with preconditions for an ongoing session.
新的前提条件类型还必须描述UAs在收到重新邀请或更新时的行为，以及正在进行的会话的前提条件。
Section 5 of RFC 3312 describes how to use SIP [2] preconditions with the offer/answer model [4]. RFC 3312 gives a set of rules that allow a user agent to communicate changes in the current status of the preconditions to the remote user agent.
RFC 3312的第5节描述了如何将SIP[2]先决条件用于提供/应答模型[4]。RFC 3312给出了一组规则，允许用户代理将前提条件当前状态的更改传达给远程用户代理。
The idea is that a given user agent knows about the current status of some part of the preconditions (e.g., send direction of the QoS precondition) through local information (e.g., an RSVP RESV is received indicating that resource reservation was successful). The UAC (User Agent Client) informs the UAS (User Agent Server) about changes in the current status by sending an offer to the UAS. The UAS, in turn, could (if needed) send an offer to the UAC informing it about the status of the part of the preconditions the UAS has local information about.
其思想是，给定的用户代理通过本地信息（例如，接收到指示资源预留成功的RSVP RESV）来知道某部分先决条件（例如，QoS先决条件的发送方向）的当前状态。UAC（用户代理客户端）通过向UAS发送报价通知UAS（用户代理服务器）当前状态的更改。反过来，UAS可以（如果需要）向UAC发送报价，告知UAS拥有本地信息的部分先决条件的状态。
Note, however, that UASs do not usually send updates about the current status to the UAC because UASs are the ones resuming session establishment when all the preconditions are met. Therefore, rather than performing an offer/answer exchange to inform the UAC that all the preconditions are met, they simply send a 180 (Ringing) response indicating that session establishment has been resumed.
但是，请注意，UAS通常不会向UAC发送有关当前状态的更新，因为UAS是在满足所有先决条件后恢复会话建立的UAS。因此，他们没有执行要约/应答交换来通知UAC所有先决条件都已满足，而是简单地发送180（振铃）响应，指示会话建立已恢复。
While RFC 3312 allows updating current status information using the methods described above, it does not allow downgrading current status values in answers, as shown in the third row of Table 3 of RFC 3312. Figure 1 shows how performing such a downgrade in an answer would sometimes be needed.
虽然RFC 3312允许使用上述方法更新当前状态信息，但不允许在回答中降级当前状态值，如RFC 3312表3第三行所示。图1显示了有时需要如何在应答中执行这样的降级。
3pcc A Controller B C
3pcc A控制器B C
| | | |
|<-dialog 1->|<-dialog 2->| |
| | | |
| *********************** | |
|* MEDIA *| |
| *********************** | |
| | | |
| | | |
|<-dialog 1->|<------dialog 3----->|
| | | |
| ******************************** |
|* MEDIA *|
| ******************************** |
| | | |
| | | |
| | | |
|<-dialog 1->|<-dialog 2->| |
| | | |
| *********************** | |
|* MEDIA *| |
| *********************** | |
| | | |
| | | |
|<-dialog 1->|<------dialog 3----->|
| | | |
| ******************************** |
|* MEDIA *|
| ******************************** |
| | | |
| | | |
Figure 1: Session mobility using 3pcc
图1：使用3pcc的会话移动性
The 3pcc (Third Party Call Control) [6] controller in Figure 1 has established a session between A and B using dialog 1 towards A and dialog 2 towards B. At that point, the controller wants A to have a session with C instead of B. To transfer A to C (configuration shown at the bottom of Figure 1), the controller sends an empty (no offer) re-INVITE to A. Since A does not know that the session will be moved, its offer in the 200 OK states that the current status of the media stream in the send direction is "Yes". After contacting C establishing dialog 3, the controller sends back an answer to A. This answer contains a new destination for the media (C) and should have downgraded the current status of the media stream to "No", since there is no reservation of resources between A and C.
图1中的3pcc（第三方呼叫控制）[6]控制器使用对话1向a和对话2向B建立了a和B之间的会话。此时，控制器希望a与C而不是B进行会话。要将a传输到C（配置如图1底部所示），控制器发送空（无报价）重新邀请A。由于A不知道会话将被移动，因此其在200 OK中的报价声明发送方向上媒体流的当前状态为“是”。在联系C建立对话3后，控制器向A发回一个应答。该应答包含媒体（C）的新目的地，并且应该将媒体流的当前状态降级为“否”，因为A和C之间没有资源保留。
Below is a set of new rules that update RFC 3312 to address the issues above.
以下是更新RFC 3312以解决上述问题的一组新规则。
The rule below applies to offerers moving a media stream to a new address:
以下规则适用于将媒体流移动到新地址的报价人：
When a stream is being moved to a new transport address, the offerer MUST set all current status values about which it does not have local information about to "No".
当流被移动到新的传输地址时，报价人必须将其没有本地信息的所有当前状态值设置为“否”。
Note that for streams using segmented status (as opposed to end-to-end status), the fact that the address for the media stream at the local segment changes may or may not affect the status of preconditions at the remote segment. However, moving an existing stream to a new location, from the preconditions point of view, is like establishing a new stream. Therefore, it is appropriate to set all the current status values to "No" and start a new precondition negotiation from scratch.
注意，对于使用分段状态（与端到端状态相反）的流，本地段的媒体流地址改变的事实可能会也可能不会影响远程段的预条件状态。然而，从先决条件的角度来看，将现有流移动到新位置就像建立一个新流。因此，将所有当前状态值设置为“否”并从头开始新的前提条件协商是合适的。
The updated table and rules below apply to an answerer that is moving a media stream. The offerer was not aware of the move when it generated the offer.
下面更新的表格和规则适用于正在移动媒体流的应答者。发盘人在发出发盘时并不知道这一举动。
Table 3 of RFC 3312 needs to be updated to allow answerers to downgrade current status values. The following table shows the result.
RFC 3312的表3需要更新，以允许应答者降低当前状态值。下表显示了结果。
Transac status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no depends on local info
no yes depends on local info
Transac status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no depends on local info
no yes depends on local info
An answerer MUST downgrade the current status values received in the offer if it has local information about them or if the media stream is being moved to a new transport address.
如果应答者有关于当前状态值的本地信息，或者媒体流正在移动到新的传输地址，则应答者必须将其降级。
Note that for streams using segmented status, the address change at the answerer may or may not affect the status of the preconditions at the offerer's segment. However, as stated above, moving an existing stream to a new location, from the preconditions point of view, is like establishing a new stream. Therefore, it is appropriate to set all the current status values to "No" and start a new precondition negotiation from scratch.
请注意，对于使用分段状态的流，应答者的地址更改可能会或可能不会影响报价人段的先决条件状态。然而，如上所述，从先决条件的角度来看，将现有流移动到新位置就像建立一个新流。因此，将所有当前状态值设置为“否”并从头开始新的前提条件协商是合适的。
The new table below applies to an offerer that receives an answer that updates or downgrades its local status tables.
下表适用于收到更新或降级其本地状态表的答复的报价人。
Offerers should update their local status tables when they receive an answer as shown in the following table.
报价人在收到下表所示的答复时，应更新其本地状态表。
Transac. status table Local status table New value Local Status
_________________________________________________________________
no no no
yes yes yes
yes no yes
no yes no
Transac. status table Local status table New value Local Status
_________________________________________________________________
no no no
yes yes yes
yes no yes
no yes no
The desired status that a UA wants for a media stream after the stream is moved to a new transport address may be different than the desired status negotiated for the stream originally. A UA, for instance, may require mandatory QoS over a low bandwidth link but be satisfied with optional QoS when the stream is moved to a high bandwidth link.
在媒体流被移动到新的传输地址之后，UA想要媒体流的期望状态可以不同于最初为流协商的期望状态。例如，UA可能需要低带宽链路上的强制QoS，但当流移动到高带宽链路时，可以满足可选QoS。
If the new desired status is higher than the previous one (e.g., optional to mandatory), the UA, following RFC 3312 procedures, may upgrade its desired status in an offer or in an answer. If the new desired status is lower that the previous one (i.e., mandatory to optional), the UA, following RFC 3312 procedures as well, may downgrade its desired status only in an offer (i.e., not in an answer.)
如果新的期望状态高于前一个状态（例如，可选至强制性），UA可按照RFC 3312程序在报价或应答中升级其期望状态。如果新的期望状态低于前一个状态（即，强制到可选），UA也可以遵循RFC 3312程序，仅在报价中（即，不在应答中）降级其期望状态
An attacker adding preconditions to a session description or modifying existing preconditions could prevent establishment of sessions. An attacker removing preconditions from a session description could force sessions to be established without meeting mandatory preconditions.
攻击者向会话描述中添加前提条件或修改现有前提条件可能会阻止会话的建立。从会话描述中删除前提条件的攻击者可能会在不满足强制前提条件的情况下强制建立会话。
Thus, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [2].
因此，强烈建议对SDP会话描述应用完整性保护。S/MIME是提供端到端完整性保护的自然选择，如RFC 3261[2]所述。
The IANA registration requirements for the preconditions framework are defined in RFC 3312. Any new preconditions are governed by the IANA Considerations there.
RFC 3312中定义了前提条件框架的IANA注册要求。任何新的先决条件都受IANA考虑因素的制约。
Dave Oran and Allison Mankin provided useful comments on this document.
Dave Oran和Allison Mankin对此文档提供了有用的评论。
[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] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[3] Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[5] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[6] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[7] Yon, D. and Camarillo, G., "TCP-Based Media Transport in the Session Description Protocol (SDP)", Work In Progress, November 2004.
[7] Yon，D.和Camarillo，G.，“会话描述协议（SDP）中基于TCP的媒体传输”，正在进行的工作，2004年11月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue, BXB500 C2-2 Boxborough, MA 01719 USA
Paul Kyzivat Cisco Systems美国马萨诸塞州伯斯堡马萨诸塞大道1414号BXB500 C2-2 01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。