Network Working Group R. Sparks
Request for Comments: 3892 Xten
Category: Standards Track September 2004
Network Working Group R. Sparks
Request for Comments: 3892 Xten
Category: Standards Track September 2004
The Session Initiation Protocol (SIP) Referred-By Mechanism
机制引用的会话启动协议（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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
会话发起协议（SIP）引用方法提供了一种机制，其中一方（引用方）向第二方（仲裁方）提供任意URI进行引用。如果该URI是SIP URI，仲裁人将向该URI（引用目标）发送SIP请求，通常是INVITE。本文件扩展了转介方法，允许转介人使用仲裁人作为中介向转介目标提供有关转介请求的信息。此信息包括引用者的身份和引用者引用的URI。该机制利用S/MIME帮助保护此信息免受恶意中介的攻击。这种保护是可选的，但是收件人可以拒绝接受请求，除非请求存在。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 3
2.1. Referrer Behavior . . . . . . . . . . . . . . . . . . . 4
2.2. Referee Behavior . . . . . . . . . . . . . . . . . . . . 4
2.3. Refer Target Behavior . . . . . . . . . . . . . . . . . 5
3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6
4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7
4.1. Refer Target Inspection of a Referred-By Token . . . . . 8
5. The 429 Provide Referrer Identity Error Response . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Identifying the Referee in the Referred-by Token . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Basic REFER . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
7.3. Requiring Referrer Identity . . . . . . . . . . . . . . 14
7.4. Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 3
2.1. Referrer Behavior . . . . . . . . . . . . . . . . . . . 4
2.2. Referee Behavior . . . . . . . . . . . . . . . . . . . . 4
2.3. Refer Target Behavior . . . . . . . . . . . . . . . . . 5
3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6
4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7
4.1. Refer Target Inspection of a Referred-By Token . . . . . 8
5. The 429 Provide Referrer Identity Error Response . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Identifying the Referee in the Referred-by Token . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Basic REFER . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
7.3. Requiring Referrer Identity . . . . . . . . . . . . . . 14
7.4. Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
The SIP REFER method [2] provides a mechanism where one party (the referrer) provides a second party (the referee) with an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). Nothing provided in [2] distinguishes this referenced request from any other request the referee might have sent to the refer target.
SIP REFERER方法[2]提供了一种机制，其中一方（推荐人）向第二方（推荐人）提供任意URI以供参考。如果该URI是SIP URI，仲裁人将向该URI（引用目标）发送SIP请求，通常是INVITE。[2]中的任何规定都不能将此参考请求与裁判员可能发送给参考目标的任何其他请求区分开来。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
|----------------->| INVITE target |
| |------------------->|
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
|----------------->| INVITE target |
| |------------------->|
There are applications of REFER, such as call transfer [8], where it is desirable to provide the refer target with particular information about the referrer and the REFER request itself. This information may include, but is not limited to, the referrer's identity, the referred to URI, and the time of the referral. The refer target can use this information when deciding whether to admit the referenced request. This document defines one set of mechanisms to provide that information.
存在REFER的应用，例如呼叫转移[8]，其中需要向REFER目标提供关于REFER和REFER请求本身的特定信息。该信息可能包括但不限于推荐人的身份、推荐的URI和推荐时间。refer目标可以在决定是否接纳引用的请求时使用此信息。本文件定义了一套提供该信息的机制。
All of the mechanisms in this document involve placing information in the REFER request that the referee copies into the referenced request. This necessarily establishes the referee as an eavesdropper and places the referee in a position to launch man-in-the-middle attacks on that information.
本文件中的所有机制都涉及在参考请求中放置信息，裁判将这些信息复制到参考请求中。这必然会使裁判成为窃听者，并使裁判处于对该信息发起中间人攻击的位置。
At the simplest level, this document defines a mechanism for carrying the referrer's identity, expressed as a SIP URI in a new header: Referred-By. The refer target can use that information, even if it has not been protected from the referee, at the perils and with the limitations documented here. The document proceeds to define an S/MIME based mechanism for expressing the identity of the referrer and capturing other information about the REFER request, allowing the refer target to detect tampering (and other undesirable behaviors) by the referee.
在最简单的层次上，本文档定义了一种机制，用于承载推荐人的身份，在新的头中表示为SIPURI:Referredby。转介目标可以使用该信息，即使该信息未受到裁判的保护，但使用该信息的风险和限制如下所述。文档继续定义基于S/MIME的机制，用于表示推荐人的身份并捕获关于推荐请求的其他信息，从而允许推荐目标检测到推荐人的篡改（和其他不良行为）。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The following figure summarizes how Referred-By information is carried to the Refer Target. The Referrer provides a Referred-By header with its SIP address-of-record, optionally associating an S/MIME protected token reflecting the identity of the referrer and the details of the REFER request. The Referee copies this header and the token, if provided, into the triggered request (shown here as an INVITE).
下图总结了如何将被引用信息传递到引用目标。referer提供一个refered-By报头及其SIP记录地址，可选地关联一个S/MIME保护的令牌，该令牌反映了referer的身份和referer请求的详细信息。仲裁人将此标头和令牌（如果提供）复制到触发的请求中（此处显示为邀请）。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
| Referred-By: referrer;cid=X | |
| | |
| (one of the body parts is) | |
| Content-ID: X | |
| <Referred-By Token> | |
|----------------------------->| |
| | INVITE target |
| | Referred-By: referrer;cid=X |
| | |
| | (one of the body parts is) |
| | Content-ID: X |
| | <Referred-By token> |
| |---------------------------->|
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
| Referred-By: referrer;cid=X | |
| | |
| (one of the body parts is) | |
| Content-ID: X | |
| <Referred-By Token> | |
|----------------------------->| |
| | INVITE target |
| | Referred-By: referrer;cid=X |
| | |
| | (one of the body parts is) |
| | Content-ID: X |
| | <Referred-By token> |
| |---------------------------->|
A UA sending a REFER request (a referrer) MAY provide a Referred-By header field value in the request. A REFER request MUST NOT contain more than one Referred-By header field value.
发送referer请求（referer）的UA可以在请求中提供refered By header字段值。引用请求不能包含多个由标头引用的字段值。
A referrer MAY include a Referred-By token in a REFER request. A REFER request containing a Referred-By token MUST contain a Referred-By header field value with a cid parameter value equal to the Content-ID of the body part containing the token.
推荐人可以在推荐请求中包括推荐人令牌。包含refered By标记的refered请求必须包含refered By header字段值，该字段值的cid参数值等于包含该标记的主体部分的内容ID。
The referrer will receive a NOTIFY with a message/sipfrag [4] body indicating a final response of 429 "Provide Referrer Identity" to the referenced request if the refer target requires a valid Referred-By token to accept the request. This can occur when either no token is provided or a provided token is invalid.
如果转介目标需要有效的转介者令牌来接受请求，则转介者将收到一条带有消息/sipfrag[4]正文的通知，其中指示对被转介请求的最终响应为429“提供转介者身份”。当未提供令牌或提供的令牌无效时，可能会发生这种情况。
The referrer will receive a 429 "Provide Referrer Identity" response to the REFER if the referee requires a Referred-By token to be present in order to accept the REFER.
如果裁判员要求出示转介代币以接受转介，则转介人将收到429“提供转介人身份”的转介回复。
If a referrer wishes to re-attempt to refer a referee after receiving a 429 response or a NOTIFY containing a 429, it MAY submit a new REFER request containing a Referred-By token.
如果推荐人希望在收到429响应或包含429的通知后再次尝试推荐推荐人，则其可以提交包含推荐人令牌的新推荐请求。
A UA accepting a REFER request (a referee) to a SIP URI (using either the sip: or sips: scheme) MUST copy any Referred-By header field value and token into the referenced request without modification.
UA接受对SIP URI的引用请求（仲裁人）（使用SIP:或sips:方案）必须将任何引用的头字段值和令牌复制到引用的请求中，而无需修改。
A referee MAY reject a REFER request that does not contain a Referred-By token with a 429 "Provide Referrer Identity" response. A referee SHOULD NOT reject a request that contains a Referred-By token encrypted to a key it does not possess simply because it cannot decrypt the token. (One scenario where such rejection would be appropriate is when the referee is attempting to remain anonymous (see Section 6.1).) Note that per [3], the referee should still be able to verify the signature of such an encrypted token.
裁判员可以拒绝不包含带有429“提供推荐人身份”响应的推荐人令牌的推荐请求。仲裁人不应仅仅因为无法解密令牌而拒绝包含加密为其不拥有的密钥的引用令牌的请求。（此类拒绝适用的一种情况是，仲裁人试图保持匿名（见第6.1节）。）请注意，根据[3]，仲裁人仍应能够验证此类加密令牌的签名。
A referee SHOULD present the same identity to the referrer and the refer target.
裁判员应向推荐人和推荐目标出示相同的身份证明。
A UA receiving a non-REFER SIP request MAY inspect the request for a Referred-By header field and token.
接收到非参考SIP请求的UA可以检查请求中的参考者报头字段和令牌。
If a Referred-By header field value is not present, this UA cannot distinguish this request from any other the UA acting as the referee might have sent. Thus, the UA would apply exactly the admissions policies and processing described in [5] to the request.
如果引用的标头字段值不存在，则此UA无法将此请求与作为仲裁人的UA可能发送的任何其他请求区分开来。因此，UA会将[5]中所述的录取政策和处理完全应用于申请。
If a Referred-By header field value is present, the receiving UA can consider itself a refer target and MAY apply additional admission policies based on the contents of the Referred-By header field and token.
如果存在引用的头字段值，则接收UA可以认为自己是参考目标，并且可以基于所引用的头字段和令牌的内容应用附加的接纳策略。
The referee is in a position to modify the contents of the Referred-By header field value, or falsely provide one even if no REFER actually exists. If such behavior could affect admission policy (including influencing the agent's user by rendering misleading content), the refer target SHOULD require that a valid Referred-By token be present.
裁判员可以修改Referred By header字段值的内容，或者错误地提供一个字段值，即使实际上不存在Reference。如果此类行为可能影响许可策略（包括通过呈现误导性内容影响代理的用户），则引用目标应要求存在有效的引用令牌。
The refer target MAY reject a request if no Referred-By token is present or if the token is stale using the 429 "Provide Referrer Identity" error response defined in Section 5. The 428 error response from [7] is not appropriate for this purpose - it is needed for the refer target to request an authentication token from the referee.
如果使用第5节中定义的429“提供参考者标识”错误响应，不存在参考令牌，或者如果该令牌过时，则参考目标可以拒绝请求。[7]的428错误响应不适用于此目的-参考目标需要从裁判处请求身份验证令牌。
If no Referred-By token is present, the refer target MAY proceed with processing the request. If the agent provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information is suspect.
如果不存在被引用令牌，则引用目标可以继续处理请求。如果代理在处理请求时向其用户提供来自Referred By标头的任何信息，则必须通知用户该信息可疑。
The refer target MUST reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response.
refer目标必须以429错误响应拒绝格式良好的请求，该请求包含无效的REFERED By令牌（参见第4节）。
Referred-By is a request header field as defined by [5]. It can appear in any request. It carries a SIP URI representing the identity of the referrer and, optionally, the Content-ID of a body part (the Referred-By token) that provides a more secure statement of that identity.
引用的是[5]定义的请求标头字段。它可以出现在任何请求中。它携带一个SIP URI，该URI表示引用者的身份，还可以选择包含提供该身份更安全声明的主体部分（被引用令牌）的内容ID。
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri
*( SEMI (referredby-id-param / generic-param) )
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri
*( SEMI (referredby-id-param / generic-param) )
referrer-uri = ( name-addr / addr-spec )
referrer-uri = ( name-addr / addr-spec )
referredby-id-param = "cid" EQUAL sip-clean-msg-id
referedby id param=“cid”等于sip clean msg id
sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
dot-atom = atom *( "." atom )
点原子=原子*（“”原子）
atom = 1*( alphanum / "-" / "!" / "%" / "*" /
"_" / "+" / "'" / "`" / "~" )
atom = 1*( alphanum / "-" / "!" / "%" / "*" /
"_" / "+" / "'" / "`" / "~" )
Since the Content-ID appears as a SIP header parameter value which must conform to the expansion of the gen-value defined in [5], this grammar produces values in the intersection of the expansions of gen-value and msg-id from [9]. The double-quotes surrounding the sip-clean-msg-id MUST be replaced with left and right angle brackets to derive the Content-ID used in the message's MIME body. For example,
由于内容ID显示为SIP头参数值，该参数值必须符合[5]中定义的gen值的扩展，因此该语法在[9]中的gen值和msg ID的扩展的交叉处生成值。围绕sip clean msg id的双引号必须替换为左括号和右括号，以派生消息MIME正文中使用的内容id。例如
Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example"
indicates the token is in the body part containing
Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example"
indicates the token is in the body part containing
Content-ID: <2UWQFN309shb3@ref.example>
Content-ID: <2UWQFN309shb3@ref.example>
If the referrer-uri contains a comma, question mark, or semicolon, (for example, if it contains URI parameters) the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
如果referer uri包含逗号、问号或分号（例如，如果它包含uri参数），则uri必须用尖括号（<和>）括起来。任何URI参数都包含在这些括号内。如果URI未括在尖括号中，则任何分号分隔的参数都是标头参数，而不是URI参数。
The Referred-By header field MAY appear in any SIP request, but is meaningless for ACK and CANCEL. Proxies do not need to be able to read Referred-By header field values and MUST NOT remove or modify them.
referenced By header字段可能出现在任何SIP请求中，但对于ACK和CANCEL没有意义。代理不需要能够读取标头引用的字段值，并且不得删除或修改它们。
The following row should be interpreted as if it appeared in Table 3 of RFC 3261.
应将以下行解释为RFC 3261的表3中所示。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Referred-By R - o - o o o
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Referred-By R - o - o o o
The Referred-By token is an Authenticated Identity Body as defined by [3]. This body part MUST be identified with a MIME [6] Content-ID: field.
所引用的令牌是由[3]定义的经过身份验证的标识体。此正文部分必须用MIME[6]内容ID:字段标识。
The sipfrag inside a Referred-By token MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request.
Referred By令牌内的sipfrag必须包含Refer请求中的Refer-Referred-By和Date标头字段的副本。
The token SHOULD NOT contain the Call-ID header field from the REFER request as that information is not useful to the refer target and may even be an information leak. The token SHOULD NOT contain the From header field from the REFER request since the identity being claimed is represented in the Referred-By header field.
令牌不应包含REFER请求中的Call ID header字段，因为该信息对REFER目标没有用处，甚至可能是信息泄漏。令牌不应包含REFER请求的From标头字段，因为所声明的标识在REFERED By标头字段中表示。
The token MAY contain the To header field from the REFER request, but it SHOULD NOT be included unless the referrer has cryptographically identified the referee. Some ways this authentication can be achieved include inspecting the certificates used in a TLS association between the referrer and the referee or encrypting the Refer-To header in the REFER request using the S/MIME encryption techniques detailed in [5].
令牌可能包含来自referer请求的To header字段，但除非referer以加密方式标识了仲裁人，否则不应包含该字段。实现这种身份验证的一些方法包括检查推荐人和推荐人之间的TLS关联中使用的证书，或者使用[5]中详述的S/MIME加密技术对Refer请求中的Refer Refer头进行加密。
When inspecting the certificates used to establish TLS associations, the identity asserted in the token's To header field URI is compared to the subjectAltNames from the referee's certificate. The sip and sips URI schemes MUST be treated as equivalent for this comparison. If the URI is an exact match, confidence in the authentication is high and the To header field MAY be added to the token. If the certificate subjects contain only a hostname matching the hostname portion of the URI, an application level warning SHOULD be issued to the referrer agent's user seeking that user's consent before including the To header field in the token.
检查用于建立TLS关联的证书时，将令牌的to标头字段URI中声明的标识与仲裁人证书中的SubjectAltName进行比较。对于此比较，必须将sip和sips URI方案视为等效方案。如果URI是完全匹配的，则验证的可信度很高，并且可以将To头字段添加到令牌中。如果证书主题仅包含与URI的主机名部分匹配的主机名，则在将to标头字段包含在令牌中之前，应向寻求该用户同意的referrer代理的用户发出应用程序级警告。
Including the To header field in the token significantly strengthens the claim being asserted by the token, but may have privacy implications as discussed in Section 6.1.
在令牌中包含To header字段可显著增强令牌所声明的声明，但可能具有第6.1节中讨论的隐私含义。
Additional header fields and body parts MAY be included in the token.
令牌中可能包含其他标题字段和正文部分。
As described in [3], a Referred-By token MAY be encrypted as well as signed. The subjectAltName of the certificate used for these operations SHOULD exactly match the identity claimed in the referrer-uri in the Referred-By header field in the token.
如[3]中所述，被引用令牌可以被加密，也可以被签名。用于这些操作的证书的subjectAltName应与令牌中Referred By标头字段中的Referred uri中声明的标识完全匹配。
A refer target MUST treat a Referred-By token with an invalid signature as an invalid token. A target SHOULD treat a token with an aged Date header field value as invalid.
引用目标必须将具有无效签名的被引用令牌视为无效令牌。目标应将具有过期日期标头字段值的令牌视为无效。
A target SHOULD verify that the request it receives matches the reference in the Refer-To header field in the token. This verification SHOULD include at least the request method and any indicated end-to-end header field values. Note that the URI in the Refer-To header field may not match the request URI in the received request due to request re-targeting between the referee and the refer target.
目标应验证其接收的请求是否与令牌中refere-To-header字段中的引用匹配。此验证应至少包括请求方法和任何指示的端到端头字段值。请注意，由于仲裁人和参考目标之间的请求重新确定目标，参考标头字段中的URI可能与接收到的请求中的请求URI不匹配。
The target SHOULD verify that the identity in the Referred-By header field in the token exactly matches the SubjectAltName from the signing certificate, reporting discrepancies to its user as described in [3].
目标应验证令牌中Referred By header字段中的标识是否与签名证书中的SubjectAltName完全匹配，并向其用户报告差异，如[3]所述。
If the token contains a To header field, the target SHOULD verify that the identity it expresses matches the referrer. One way of verifying this is to exactly match the identity in the token's To header field with the subjectAltName of the certificate used by the referee to sign the aib protecting the request itself. The 428 response defined in [7] can be used to request such an aib if one is not already present.
如果令牌包含To头字段，则目标应验证其表示的标识是否与引用者匹配。验证这一点的一种方法是将令牌的to标头字段中的标识与仲裁人用于签署保护请求本身的aib的证书的subjectAltName精确匹配。[7]中定义的428响应可用于请求此类aib（如果尚未出现）。
The 429 client error response code is used by a refer target to indicate that the referee must provide a valid Referred-By token. As discussed in the behavior section, the referee will forward this error response to the referrer in a NOTIFY as the result of the REFER. The suggested text phrase for the 429 error response is "Provide Referrer Identity".
参考目标使用429客户端错误响应代码来指示裁判必须提供有效的参考令牌。如行为部分所述，裁判员将在一份通知中将此错误响应转发给推荐人，作为推荐的结果。429错误响应的建议文本短语是“提供推荐人身份”。
The mechanism defined in this specification relies on an intermediary (the referee) to forward information from the referrer to the refer target. This necessarily establishes the referee as an eavesdropper of that information and positions him perfectly to launch man-in-the-middle attacks using the mechanism.
本规范中定义的机制依赖于中间人（裁判员）将信息从推荐人转发给推荐目标。这必然会使裁判员成为该信息的窃听者，并使他能够利用该机制完美地发起中间人攻击。
A SIP proxy is similarly positioned. Protecting SIP messaging from malicious proxy implementations is discussed in [5]. In contrast to a proxy, the referee's agent is an endpoint. Proxies will typically be managed and monitored by service providers. Malicious behavior by a proxy is more likely to be noticed and result in negative repercussions for the provider than malicious behavior by an endpoint would be. The behavior of an endpoint can be entirely under the control of a single user. Thus, it is more feasible for an endpoint acting as referee to behave maliciously than it is for a proxy being operated by a service provider.
SIP代理的位置类似。[5]中讨论了保护SIP消息免受恶意代理实现的影响。与代理不同，裁判员的代理是端点。代理通常由服务提供商管理和监控。与端点的恶意行为相比，代理的恶意行为更容易被注意到并对提供程序造成负面影响。端点的行为可以完全由单个用户控制。因此，充当仲裁人的端点比由服务提供商操作的代理更可能恶意行事。
This specification uses an S/MIME based mechanism to enable the refer target to detect manipulation of the Referred-By information by the referee. Use of this protection is optional! The community has asserted that there are systems where trust in the validity of this information is either not important or can be established through other means. Any implementation choosing not to use this optional mechanism needs to provide its own defense to the following risks:
本规范使用基于S/MIME的机制，使参考目标能够检测裁判对参考信息的操纵。使用此保护是可选的！社区声称，在某些系统中，对这些信息的有效性的信任不是很重要，就是可以通过其他方式建立。任何选择不使用此可选机制的实现都需要为以下风险提供自己的防御：
o The Referred-By information is highly likely to influence request admission policy. For instance, it may be displayed to the user of the agent with a "This call was transferred to you by X. Accept?" prompt. A malicious referee can unduly influence that policy decision by providing falsified referred-by information. This includes falsely claiming to have been referred in the first place. (The S/MIME mechanism protects the information with a signature, hampering the referee's ability to inject or modify information without knowing the key used for that signature.)
o 所引用的信息极有可能影响请求接纳策略。例如，它可能会向代理的用户显示“此呼叫已由X.Accept转接给您？”提示。恶意的仲裁人通过提供虚假的参考信息，可能不适当地影响决策。这包括一开始就谎称自己已被转介。（S/MIME机制使用签名保护信息，妨碍裁判在不知道用于该签名的密钥的情况下插入或修改信息的能力。）
o A referee is by definition an eavesdropper of the referred-by information. Parts of that information may be sensitive. (The S/MIME mechanism allows encryption.)
o 根据定义，裁判员是指信息所指内容的窃听者。部分信息可能是敏感的。（S/MIME机制允许加密。）
o The referee may store any referred-by information it sees and paste it into future unrelated requests. (The S/MIME mechanism allows detection of stale assertions by covering a timestamp with the signature and allows detection of use in unrelated requests by covering the Refer-To header field with the signature.)
o 裁判员可以存储其看到的任何参考信息，并将其粘贴到未来的无关请求中。（S/MIME机制允许通过用签名覆盖时间戳来检测陈旧断言，并允许通过用签名覆盖refere-header字段来检测在不相关请求中的使用。）
The mechanisms in this specification do NOT prevent the referee from deleting ALL referred-by information from the referenced request. A refer target can not detect such deletion. This introduces no new problems since removing all referred-by information from a referenced request transforms it into an ordinary SIP request as described in [5]. Thus the referee gains no new influence over processing logic at the refer target by removing the referred-by information.
本规范中的机制不阻止仲裁人从引用的请求中删除所有引用的信息。引用目标无法检测到此类删除。这不会带来新的问题，因为从引用的请求中删除所有被引用的信息会将其转换为普通的SIP请求，如[5]中所述。因此，裁判员通过删除所引用的信息，不会对引用目标的处理逻辑产生新的影响。
Refer targets can protect themselves from the possibility of a malicious referee removing a token (leaving an unsecured identity in the Referred-By header field) by using the 429 error response.
通过使用429错误响应，Refer目标可以保护自己免受恶意裁判删除令牌（在REFERED By header字段中留下不安全的标识）的可能性。
Applications using the mechanisms in this document may be able to take advantage of pre-existing relationships between the participants to mitigate the risks of its use. In some transfer scenarios, A has the choice of referring B to C or referring C to B. If A and B have a pre-existing trust relationship, leading A to have greater confidence that B will not behave maliciously (B is A's administrative assistant for example), referring B to C may make more sense.
使用本文档中的机制的应用程序可能能够利用参与者之间预先存在的关系来降低其使用风险。在某些转移场景中，A可以选择将B转介给C或将C转介给B。如果A和B之间存在预先存在的信任关系，导致A对B不会有恶意行为有更大的信心（例如，B是A的行政助理），将B转介给C可能更有意义。
This mechanism involves two SIP requests between three endpoints, the REFER and the referenced request. The content of those messages (including the referred-by information) is subject to the security considerations and protection mechanisms documented in [5].
该机制涉及三个端点之间的两个SIP请求，即REFERE和referenced请求。这些消息的内容（包括所引用的信息）受[5]中记录的安全注意事项和保护机制的约束。
Proxies between the participants may collect referred-by information and re-insert it in future requests or make it available to hostile endpoints. The end-to-end confidentiality capabilities discussed in [5] can help reduce the risk of exposing sensitive referred-by information to these proxies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referee and the refer target are identical to the abuse by the referee, and the considerations discussed for a malicious referee applies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referrer and the referee are similar to those discussed for the presentation of Authenticated Identity Bodies in [7].
参与者之间的代理可以收集所引用的信息，并在将来的请求中重新插入该信息，或使其可供敌对端点使用。[5]中讨论的端到端保密功能有助于降低向这些代理暴露敏感信息的风险。仲裁人和转介目标之间的代理（或他们可能泄露信息的端点）在后续请求中的滥用可能性与仲裁人的滥用相同，并且针对恶意仲裁人讨论的注意事项适用。推荐人和推荐人之间的代理（或他们可能向其泄露信息的端点）在后续请求中的滥用可能性与[7]中针对认证身份机构的呈现所讨论的类似。
To a refer target, a Referred-By token minimally asserts "The identity expressed by this Referred-By header field asked at the time indicated in this Date header field that the request indicated by this Refer-To header field be sent". This assertion makes no claims at all about who is being asked to send the request. This is sufficient to enable policies such as "Accept any requests referred by Alice", but not "Only accept requests from Bob if he can prove that Alice referred him to us". Thus, there is an opportunity for a cut-and-paste attack. If Mallory sees Alice refer Carol to us using a minimal token, he can copy that token into his own request (as long as it matches what is indicated in the embedded Refer-To header), and it will appear to us that Alice referred Mallory to us. This risk is best mitigated by protecting the REFER Alice sends to Carol from eavesdropping, using TLS or the S/MIME mechanisms detailed in [5].
对于referect目标，refered By token最低限度地断言“由该refered By header字段表示的标识在该日期报头字段中指示的时间被请求发送该refered By header字段所指示的请求”。这个断言对于被请求发送请求的人没有任何声明。这足以启用诸如“接受Alice提交的任何请求”之类的策略，而不是“仅接受Bob的请求，前提是Bob能够证明Alice将其提交给我们”。因此，存在剪切粘贴攻击的机会。如果Mallory看到Alice使用最小令牌向我们引用Carol，他可以将该令牌复制到自己的请求中（只要它与嵌入的refer-refer头中指示的内容匹配），我们就会觉得Alice向我们引用了Mallory。通过使用TLS或[5]中详述的S/MIME机制，保护Alice发送给Carol的参考文件免受窃听，可以最好地缓解此风险。
Including the To header field from the REFER request in the Referred-by token enables the "Only accept requests from Bob if he can prove that Alice referred him to us". Alice is constrained to add this header to the token only if she is sure she is sending the REFER request to Bob. We, in turn, ensure it was Bob that sent the referenced request to us, in addition to validating Alice's signature of the token. Mallory's earlier attack is not effective with this token.
将refered请求中的To header字段包含在refered by标记中，可以启用“仅接受来自Bob的请求，前提是Bob能够证明Alice将他推荐给我们”。仅当Alice确定她正在向Bob发送REFER请求时，她才必须将此头添加到令牌中。反过来，除了验证Alice对令牌的签名之外，我们还要确保是Bob向我们发送了引用的请求。Mallory的早期攻击在使用此令牌时无效。
Including the To header field in the Referred-By token has privacy implications, however. Carol, above, might wish to contact us anonymously. That wish would be defeated if Carol's identity appeared in the token Alice created. If Alice encrypted the token to us, Carol will not even be aware of the information leak. To protect herself when she wishes anonymity, Carol will have to reject any REFER requests containing a Referred-By token she can not inspect.
但是，在referenced By令牌中包含To header字段会影响隐私。上面的Carol可能希望匿名联系我们。如果卡罗尔的身份出现在爱丽丝创造的代币上，这一愿望就会破灭。如果Alice将令牌加密给我们，Carol甚至不会意识到信息泄漏。为了在希望匿名时保护自己，Carol必须拒绝任何包含她无法检查的转介令牌的转介请求。
This example shows the secured Referred-By mechanism applied to a REFER to an SIP INVITE URI.
此示例显示了应用于引用SIP INVITE URI的安全引用机制。
Details are shown only for those messages involved in exercising the mechanism defined in this document.
仅显示与执行本文档中定义的机制有关的消息的详细信息。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: sip:referee@referee.example
From: sip:referrer@referrer.example;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: sip:referee@referee.example
From: sip:referrer@referrer.example;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（此处有适当的签名）
--dragons39-- --unique-boundary-1--
--龙39--unique-boundary-1--
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（此处有适当的签名）
--dragons39-- --my-boundary-9--
--龙39--my-boundary-9--
The flow for this example is the same as that of Section 7.1. Here, the referrer has opted to not include a Referred-By token, and the refer target is willing to accept the referenced request without one.
本示例的流程与第7.1节的流程相同。这里，推荐人选择不包括被推荐人令牌，并且推荐目标人愿意接受没有被推荐人令牌的被推荐请求。
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
Content-Length: 0
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
Content-Length: 0
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
Content-Type: application/sdp
Content-Length: (appropriate value)
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
In contrast to the example in Section 7.2, the refer target requires a Referred-By token to accept the referenced request. The referrer chooses to provide an encrypted token (note that the block surrounded by asterisks represents encrypted content). F1 and F2 are identical to the messages detailed in Section 7.2.
与第7.2节中的示例不同，referer目标需要refered By令牌来接受引用的请求。推荐人选择提供加密令牌（请注意，由星号包围的块表示加密内容）。F1和F2与第7.2节中详述的信息相同。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| F3 429 Provide Referrer Identity
| |<---------------------------|
| | ACK |
| F4 NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| F5 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F6 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| F3 429 Provide Referrer Identity
| |<---------------------------|
| | ACK |
| F4 NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| F5 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F6 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F3 SIP/2.0 429 Provide Referrer Identity
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>;tag=392093422302334
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Content-Length: 0
F3 SIP/2.0 429 Provide Referrer Identity
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>;tag=392093422302334
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Content-Length: 0
F4 NOTIFY sip:referrer@referrer.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390
To: <sip:referrer@referrer.example>;tag=39092342
From: <sip:referee@referee.example>;tag=199949923
Call-ID: 2203900ef0299349d9209f023a
CSeq: 3920390 NOTIFY
Event: refer;id=1239930
Subscription-State: terminated
Content-Type: message/sipfrag
Content-Length: (appropriate value)
F4 NOTIFY sip:referrer@referrer.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390
To: <sip:referrer@referrer.example>;tag=39092342
From: <sip:referee@referee.example>;tag=199949923
Call-ID: 2203900ef0299349d9209f023a
CSeq: 3920390 NOTIFY
Event: refer;id=1239930
Subscription-State: terminated
Content-Type: message/sipfrag
Content-Length: (appropriate value)
SIP/2.0 429 Provide Referrer Identity
SIP/2.0 429提供推荐人身份
F5 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239931 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
F5 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239931 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature)
（适当签名）
--boundary42--
--边界42--
F6 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=1342093482342
Call-ID: 23499234-9239842993@referee.example
CSeq: 19309423 INVITE
Max-Forwards: 70
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Contact: <sip:referee@referee.example>
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
F6 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=1342093482342
Call-ID: 23499234-9239842993@referee.example
CSeq: 19309423 INVITE
Max-Forwards: 70
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Contact: <sip:referee@referee.example>
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=referee 2890844526 2890844526 IN IP4 referee.example
s=Session SDP
c=IN IP4 referee.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature)
（适当签名）
--boundary42-- --my-boundary-9--
--边界42--my-boundary-9--
The Refer-To URI may be a SIP URI indicating the REFER method. Consider The following URI which A uses to refer B to send a REFER request to C which refers C to send an INVITE to D.
refere-ref-URI可以是指示refere方法的SIP-URI。考虑下面的URI，它用来引用B向C发送引用请求，其中引用C发送邀请到D。
Note that A provides a Referred-By token which gets passed through B and C to D. In particular, B does not provide its own Referred-By token to C. Also note that A is notified of the outcome of the request it triggered at B (the REFER), not at C (the INVITE).
请注意，A提供了一个通过B和C传递给D的被引用令牌。特别是，B不向C提供其自己的被引用令牌。还请注意，A将在B（引用）而不是在C（邀请）触发的请求的结果通知A。
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
This reference would result in the following flow:
此引用将导致以下流程：
A B C D
| F1 REFER | | |
|------------------>| | |
| 202 Accepted | | |
|<------------------| | |
| NOTIFY | | |
|<------------------| F2 REFER | |
| 200 OK |------------------>| |
|------------------>| 202 Accepted | |
| F3 NOTIFY |<------------------| |
|<------------------| NOTIFY | |
| 200 OK |<------------------| F4 INVITE |
|------------------>| 200 OK |------------------>|
| |------------------>| 200 OK |
| | NOTIFY |<------------------|
| |<------------------| ACK |
| | 200 OK |------------------>|
| |------------------>| |
| | | |
A B C D
| F1 REFER | | |
|------------------>| | |
| 202 Accepted | | |
|<------------------| | |
| NOTIFY | | |
|<------------------| F2 REFER | |
| 200 OK |------------------>| |
|------------------>| 202 Accepted | |
| F3 NOTIFY |<------------------| |
|<------------------| NOTIFY | |
| 200 OK |<------------------| F4 INVITE |
|------------------>| 200 OK |------------------>|
| |------------------>| 200 OK |
| | NOTIFY |<------------------|
| |<------------------| ACK |
| | 200 OK |------------------>|
| |------------------>| |
| | | |
F1 REFER sip:B SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:B.example>
From: <sip:A.example>;tag=23490234
Call-ID: 2304098023@A.example
CSeq: 2342093 REFER
Max-Forwards: 70
Contact: <sip:A.example>
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
F1 REFER sip:B SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:B.example>
From: <sip:A.example>;tag=23490234
Call-ID: 2304098023@A.example
CSeq: 2342093 REFER
Max-Forwards: 70
Contact: <sip:A.example>
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（此处有适当的签名）
--dragons39-- --unique-boundary-1--
--龙39--unique-boundary-1--
F2 REFER sip:C.example SIP/2.0
Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842
To: <sip:C.example>
From: <sip:B.example>;tag=2934u23
Call-ID: 203942834@B.example
CSeq: 8321039 REFER
Max-Forwards: 70
Contact: <sip:B.example>
Refer-To: <sip:D.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
F2 REFER sip:C.example SIP/2.0
Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842
To: <sip:C.example>
From: <sip:B.example>;tag=2934u23
Call-ID: 203942834@B.example
CSeq: 8321039 REFER
Max-Forwards: 70
Contact: <sip:B.example>
Refer-To: <sip:D.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;cid="23094202342.1012309123@A.example"
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;cid="23094202342.1012309123@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（此处有适当的签名）
--dragons39-- --unique-boundary-1--
--龙39--unique-boundary-1--
F3 NOTIFY sip:A.example SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:A.example>;tag=23490234
From: <sip:B.example>;tag=5923020
Call-ID: 2304098023@A.example
CSeq: 29420342 NOTIFY
Event: refer;id=2342093
Subscription-State: terminated
Max-Forwards: 70
Contact: <sip:B.example>
Content-Type: message/sipfrag
Content-Length: (appropriate value)
F3 NOTIFY sip:A.example SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:A.example>;tag=23490234
From: <sip:B.example>;tag=5923020
Call-ID: 2304098023@A.example
CSeq: 29420342 NOTIFY
Event: refer;id=2342093
Subscription-State: terminated
Max-Forwards: 70
Contact: <sip:B.example>
Content-Type: message/sipfrag
Content-Length: (appropriate value)
SIP/2.0 202 Accepted
接受SIP/2.0 202
F4 INVITE sip:D.example SIP/2.0
Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234
To: <sip:D.example>
From: <sip:C.example>;tag=023942334
Call-ID: 23489020352@C.example
CSeq: 1230934 INVITE
Max-Forwards: 70
Contact: <sip:C.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
F4 INVITE sip:D.example SIP/2.0
Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234
To: <sip:D.example>
From: <sip:C.example>;tag=023942334
Call-ID: 23489020352@C.example
CSeq: 1230934 INVITE
Max-Forwards: 70
Contact: <sip:C.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: application/sdp
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=C 2890844526 2890844526 IN IP4 C.example
s=Session SDP
c=IN IP4 C.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=C 2890844526 2890844526 IN IP4 C.example
s=Session SDP
c=IN IP4 C.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.1012309123@A.example"
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.1012309123@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（此处有适当的签名）
--dragons39-- --unique-boundary-1--
--龙39--unique-boundary-1--
This document defines a new SIP header field name with a compact form (Referred-By and b respectively). It also defines a new SIP client error response code (429).
本文档以紧凑的形式定义了一个新的SIP头字段名（分别由和b引用）。它还定义了一个新的SIP客户端错误响应代码（429）。
The following changes are reflected at:
以下变化反映在：
http:///www.iana.org/assignments/sip-parameters
http:///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section (replacing any existing row for Referred-By).
以下行已添加到标题字段部分（替换引用的任何现有行）。
Header Name Compact Form Reference Referred-By b [RFC3892]
b引用的标题名称压缩格式参考[RFC3892]
The following row has been added to the response code section under the Request Failure 4xx heading.
以下行已添加到请求失败4xx标题下的响应代码部分。
429 Provide Referrer Identity [RFC3892]
429提供推荐人身份[RFC3892]
Rohan Mahy distilled RFC2822's msg-id into this document's definition of sip-clean-msg-id.
Rohan Mahy将RFC2822的msg id提取到本文件的sip-clean-msg-id定义中。
[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] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[2] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[3] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[3] Peterson，J.，“会话发起协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
[5] 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.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[7] Peterson，J.，“会话启动协议（SIP）中身份验证管理的增强”，正在进行的工作，2003年3月。
[8] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003.
[8] Sparks，R.和A.Johnston，“会话启动协议呼叫控制-传输”，正在进行的工作，2003年2月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Robert J. Sparks Xten 5100 Tennyson Parkway Suite 1000 Plano, TX 75024
德克萨斯州普莱诺市坦尼生大道1000号罗伯特·J·斯帕克斯特恩5100套房，邮编75024
EMail: RjS@xten.com
EMail: RjS@xten.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编辑功能的资金目前由互联网协会提供。