Network Working Group C. Jennings
Request for Comments: 3325 Cisco Systems
Category: Informational J. Peterson
NeuStar, Inc.
M. Watson
Nortel Networks
November 2002
Network Working Group C. Jennings
Request for Comments: 3325 Cisco Systems
Category: Informational J. Peterson
NeuStar, Inc.
M. Watson
Nortel Networks
November 2002
Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
会话启动协议（SIP）的专用扩展，用于在可信网络中声明身份
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.
本文档描述了会话启动协议（SIP）的专用扩展，该扩展使可信SIP服务器网络能够断言经过身份验证的用户的身份，以及现有隐私机制在身份问题上的应用。这些扩展的使用仅适用于具有先前商定的生成、传输和使用此类信息的策略的管理域内。本文档不提供适用于不同信任域之间使用的一般隐私或身份模型，也不提供适用于Internet的一般隐私或身份模型。
Table of Contents
目录
1. Applicability Statement . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8
9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8
9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
1. Applicability Statement . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8
9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8
9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of new SIP header fields . . . . . . . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of new SIP header fields . . . . . . . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
This document describes private extensions to SIP [1] that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions is only applicable inside a 'Trust Domain' as defined in Short term requirements for Network Asserted Identity [5]. Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to publicly assert the identity of each party, and to be responsible for withholding that identity outside of the Trust Domain when privacy is requested. The means by which the network determines the identity to assert is outside the scope of this document (though it commonly entails some form of authentication).
本文档描述了SIP[1]的私有扩展，该扩展使可信SIP服务器网络能够断言最终用户或最终系统的身份，并传达最终用户请求的隐私指示。这些扩展的使用仅适用于网络断言标识短期要求[5]中定义的“信任域”内。此类信任域中的节点由其用户和终端系统明确信任，以公开声明各方的身份，并在请求隐私时负责在信任域之外保留该身份。网络确定要断言的身份的方法不在本文档的范围内（尽管它通常需要某种形式的身份验证）。
A key requirement of [5] is that the behavior of all nodes within a given Trust Domain 'T' is known to comply to a certain set of specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for the following:
[5]的一个关键要求是，已知给定信任域“T”内所有节点的行为都符合称为“Spec（T）”的特定规范集。规范（T）必须指定以下行为：
1. The manner in which users are authenticated
1. 对用户进行身份验证的方式
2. The mechanisms used to secure the communication among nodes within the Trust Domain
2. 用于保护信任域内节点之间通信的机制
3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain
3. 用于保护UAs和信任域内节点之间通信的机制
4. The manner used to determine which hosts are part of the Trust Domain
4. 用于确定哪些主机是信任域的一部分的方式
5. The default privacy handling when no Privacy header field is present
5. 不存在隐私标头字段时的默认隐私处理
6. That nodes in the Trust Domain are compliant to SIP [1]
6. 信任域中的节点符合SIP[1]
7. That nodes in the Trust Domain are compliant to this document
7. 信任域中的节点符合此文档
8. Privacy handling for identity as described in Section 7.
8. 第7节中描述的身份隐私处理。
An example of a suitable Spec(T) is shown in Section 11.
第11节给出了合适规范（T）的示例。
This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their identity by use of the extensions defined here. Furthermore, since the asserted identities are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of [5].
本文件不提供适用于域间使用或在互联网上广泛使用的一般隐私或身份模型。它关于用户和网络之间信任关系的假设可能不适用于许多应用程序。例如，这些扩展不适应最终用户可以通过使用此处定义的扩展独立声明其身份的模型。此外，由于断言的身份未经加密认证，因此在任何不符合[5]要求的体系结构中，它们都可能被伪造、重放和伪造。
The asserted identities also lack an indication of who specifically is asserting the identity, and so it must be assumed that the Trust Domain is asserting the identity. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
断言的标识也没有明确表示谁在断言标识，因此必须假设信任域正在断言标识。因此，只有从已知为信任域成员的节点安全地接收信息时，信息才有意义。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network which emulates a traditional circuit switched telephone network.
尽管存在这些限制，但仍有足够有用的专门部署满足上述假设，并且可以接受由此产生的限制，以保证该机制的信息发布。一个示例部署是模拟传统电路交换电话网络的封闭网络。
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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。
Throughout this document requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a Trust Domain (ex: B2BUAs).
在本文档中，对代理服务器或代理行为的要求或引用同样适用于信任域内的其他中介机构（例如：B2BUAs）。
The terms Identity, Network Asserted Identity and Trust Domain in this document have meanings as defined in [5].
本文件中的术语“身份”、“网络声明身份”和“信任域”具有[5]中定义的含义。
Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate.
通过IP网络提供电话服务的各种提供商已经选择SIP作为呼叫建立协议。它们的环境要求服务提供商（例如SIP代理服务器）操作的可信网络元件能够将订户的身份传递给这样的服务，但也需要在必要时向不可信的实体保留该信息。这类网络通常假定提供商及其操作的设备之间存在某种程度的可传递信任。
These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call. While baseline SIP can support each of these services independently, certain combinations cannot be supported without the extensions described in this document. For example, a caller that wants to maintain privacy and consequently provides limited information in the SIP From header field will not be identifiable by recipients of the call unless they rely on some other means to discover the identity of the caller. Masking identity information at the originating user agent will prevent certain services, e.g., call trace, from working in the Public Switched Telephone Network (PSTN) or being performed at intermediaries not privy to the authenticated identity of the user.
这些网络需要支持某些传统电话服务，并满足基本的监管和公共安全要求。这些功能包括呼叫标识传递服务、呼叫标识传递阻塞以及跟踪呼叫发起人的功能。虽然基线SIP可以独立地支持这些服务中的每一项，但如果没有本文档中描述的扩展，则无法支持某些组合。例如，想要维护隐私并因此在SIP From header字段中提供有限信息的呼叫者将不会被呼叫的接收者识别，除非他们依靠一些其他方法来发现呼叫者的身份。在发起用户代理处屏蔽身份信息将阻止某些服务（例如呼叫跟踪）在公共交换电话网（PSTN）中工作或在与用户的认证身份无关的中介处执行。
This document attempts to provide a network asserted identity service using a very limited, simple mechanism, based on requirements in [5]. This work is derived from a previous attempt, [6], to solve several problems related to privacy and identity in Trust Domains. A more comprehensive mechanism, [7] which uses cryptography to address this problem is the subject of current study by the SIP working group.
本文档试图根据[5]中的要求，使用非常有限、简单的机制提供网络断言的身份服务。这项工作源于以前的一次尝试[6]，旨在解决与信任域中的隐私和身份相关的几个问题。SIP工作组目前正在研究一种更全面的机制[7]，它使用密码技术来解决这个问题。
Providing privacy in a SIP network is more complicated than in the PSTN. In SIP networks, the participants in a session are typically able to exchange IP traffic directly without involving any SIP service provider. The IP addresses used for these sessions may themselves reveal private information. A general purpose mechanism for providing privacy in a SIP environment is discussed in [2]. This document applies that privacy mechanism to the problem of network asserted identity.
在SIP网络中提供隐私比在PSTN中更复杂。在SIP网络中，会话中的参与者通常能够直接交换IP流量，而不涉及任何SIP服务提供商。用于这些会话的IP地址本身可能会泄露私人信息。[2]中讨论了在SIP环境中提供隐私的通用机制。本文件将隐私机制应用于网络身份问题。
The mechanism proposed in this document relies on a new header field called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI) and an optional display-name, for example:
本文档中提出的机制依赖于名为“P-Asserted-Identity”的新标题字段，该字段包含URI（通常为SIP URI）和可选显示名称，例如：
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
A proxy server which handles a message can, after authenticating the originating user in some way (for example: Digest authentication), insert such a P-Asserted-Identity header field into the message and forward it to other trusted proxies. A proxy that is about to forward a message to a proxy server or UA that it does not trust MUST remove all the P-Asserted-Identity header field values if the user requested that this information be kept private. Users can request this type of privacy as described in Section 7.
处理消息的代理服务器可以在以某种方式对原始用户进行身份验证（例如：摘要身份验证）后，将这样一个P-Asserted-Identity头字段插入到消息中，并将其转发给其他受信任的代理。如果用户请求将消息转发给其不信任的代理服务器或UA，则该代理必须删除所有P-Asserted-Identity头字段值。如第7节所述，用户可以请求此类隐私。
The formal syntax for the P-Asserted-Identity header is presented in Section 9.
第9节介绍了P-Asserted-Identity头的正式语法。
A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it wishes to add a P-Asserted-Identity header field, the proxy MUST authenticate the originator of the message, and use the identity which results from this authentication to insert a P-Asserted-Identity header field into the message.
信任域中的代理可以从其信任的节点或不信任的节点接收消息。当代理从其不信任的节点接收消息并希望添加P-Asserted-Identity标头字段时，代理必须验证消息的原始发件人，并使用此验证产生的标识将P-Asserted-Identity标头字段插入消息中。
If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself.
如果代理从其信任的节点接收到消息（请求或响应），它可以使用P-Asserted-Identity头字段中的信息（如果有），就像它已经验证了用户本身一样。
If there is no P-Asserted-Identity header field present, a proxy MAY add one containing at most one SIP or SIPS URI, and at most one tel URL. If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field. Similarly, if the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a tel URI, the proxy MUST replace that tel URI with a single tel URI or remove the header field.
如果不存在P-Asserted-Identity报头字段，则代理可以添加一个包含最多一个SIP或SIPS URI以及最多一个tel URL的报头字段。如果代理从其不信任的元素接收到消息，并且存在包含SIP或SIPS URI的P-Asserted-Identity标头，则代理必须使用单个SIP或SIPS URI替换该SIP或SIPS URI，或删除此标头字段。类似地，如果代理从其不信任的元素接收到消息，并且存在包含tel URI的P-Asserted-Identity报头，则代理必须用单个tel URI替换该tel URI或删除报头字段。
When a proxy forwards a message to another node, it must first determine if it trusts that node or not. If it trusts the node, the proxy does not remove any P-Asserted-Identity header fields that it
当代理将消息转发到另一个节点时，它必须首先确定是否信任该节点。如果它信任该节点，则代理不会删除它所信任的任何P-Asserted-Identity头字段
generated itself, or that it received from a trusted source. If it does not trust the element, then the proxy MUST examine the Privacy header field (if present) to determine if the user requested that asserted identity information be kept private.
自身生成的，或从可信来源接收的。如果它不信任该元素，那么代理必须检查隐私头字段（如果存在），以确定用户是否请求将断言的身份信息保持为私有。
If a P-Preferred-Identity header field is present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy can add a P-Asserted-Identity header of its own construction, or it can reject the request (for example, with a 403 Forbidden). The proxy MUST remove the user-provided P-Preferred-Identity header from any message it forwards.
如果代理从其不信任的实体接收的消息中存在P-Preferred-Identity报头字段，则代理可以使用此信息作为提示，建议应断言认证用户的多个有效标识中的哪一个。如果此类提示不对应于该用户的代理已知的任何有效标识，则代理可以添加其自身构造的P-Asserted-identity头，或者可以拒绝请求（例如，使用403禁止）。代理必须从其转发的任何消息中删除用户提供的P-Preferred-Identity标头。
A user agent only sends a P-Preferred-Identity header field to proxy servers in a Trust Domain; user agents MUST NOT populate the P-Preferred-Identity header field in a message that is not sent directly to a proxy that is trusted by the user agent. Were a user agent to send a message containing a P-Preferred-Identity header field to a node outside a Trust Domain, then the hinted identity might not be managed appropriately by the network, which could have negative ramifications for privacy.
用户代理仅向信任域中的代理服务器发送P-Preferred-Identity头字段；用户代理不得在未直接发送到用户代理信任的代理的消息中填充P-Preferred-Identity标头字段。如果用户代理向信任域外的节点发送包含P-Preferred-Identity标头字段的消息，则暗示的身份可能无法由网络进行适当管理，这可能会对隐私产生负面影响。
Parties who wish to request the removal of P-Asserted-Identity header fields before they are transmitted to an element that is not trusted may add the "id" privacy token defined in this document to the Privacy header field. The Privacy header field is defined in [6]. If this token is present, proxies MUST remove all the P-Asserted-Identity header fields before forwarding messages to elements that are not trusted. If the Privacy header field value is set to "none" then the proxy MUST NOT remove the P-Asserted-Identity header fields.
希望在将P-Asserted-Identity头字段传输到不受信任的元素之前请求删除这些字段的各方可以将本文档中定义的“id”隐私令牌添加到隐私头字段。隐私标头字段在[6]中定义。如果存在此令牌，代理必须在将消息转发到不受信任的元素之前删除所有P-Asserted-Identity头字段。如果隐私标头字段值设置为“无”，则代理不得删除P-Asserted-Identity标头字段。
When a proxy is forwarding the request to an element that is not trusted and there is no Privacy header field, the proxy MAY include the P-Asserted-Identity header field or it MAY remove it. This decision is a policy matter of the Trust Domain and MUST be specified in Spec(T). It is RECOMMENDED that the P-Asserted-Identity header fields SHOULD NOT be removed unless local privacy policies prevent it, because removal may cause services based on Asserted Identity to fail.
当代理将请求转发到不受信任的元素并且没有隐私头字段时，代理可以包括P-Asserted-Identity头字段，也可以将其删除。此决定是信任域的策略问题，必须在规范（T）中指定。建议不要删除P-Asserted-Identity头字段，除非本地隐私策略阻止删除，因为删除可能会导致基于断言标识的服务失败。
However, it should be noted that unless all users of the Trust Domain have access to appropriate privacy services, forwarding of the P-Asserted-Identity may result in disclosure of information which the user has not requested and cannot prevent. It is therefore STRONGLY RECOMMENDED that all users have access to privacy services as described in this document.
然而，应当注意的是，除非信任域的所有用户都可以访问适当的隐私服务，否则转发P-Asserted-Identity可能会导致用户未请求且无法阻止的信息泄露。因此，强烈建议所有用户都可以访问本文档中描述的隐私服务。
Formal specification of the "id" Privacy header priv-value is described in Section 9.3. Some general guidelines for when users require privacy are given in [2].
第9.3节描述了“id”隐私头priv值的正式规范。[2]中给出了用户何时需要隐私的一些一般准则。
If multiple P-Asserted-Identity header field values are present in a message, and privacy of the P-Asserted-Identity header field is requested, then all instances of the header field values MUST be removed before forwarding the request to an entity that is not trusted.
如果消息中存在多个P-Asserted-Identity标头字段值，并且请求P-Asserted-Identity标头字段的隐私，则在将请求转发给不受信任的实体之前，必须删除标头字段值的所有实例。
Typically, a user agent renders the value of a P-Asserted-Identity header field that it receives to its user. It may consider the identity provided by a Trust Domain to be privileged, or intrinsically more trustworthy than the From header field of a request. However, any specific behavior is specific to implementations or services. This document also does not mandate any user agent handling for multiple P-Asserted-Identity header field values that happen to appear in a message (such as a SIP URI alongside a tel URL).
通常，用户代理向其用户呈现其接收的P-Asserted-Identity头字段的值。它可以认为信任域提供的身份是特权的，或者本质上比请求的头字段更可信。但是，任何特定的行为都是特定于实现或服务的。本文档也不要求任何用户代理处理消息中出现的多个P-Asserted-Identity头字段值（如tel URL旁边的SIP URI）。
However, if a User Agent Server receives a message from a previous element that it does not trust, it MUST NOT use the P-Asserted-Identity header field in any way.
但是，如果用户代理服务器接收到来自其不信任的前一个元素的消息，则不得以任何方式使用P-Asserted-Identity头字段。
If a UA is part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can use the value freely but it MUST ensure that it does not forward the information to any element that is not part of the Trust Domain, if the user has requested that asserted identity information be kept private.
如果UA是信任域的一部分，从该信任域接收到包含P-Asserted-Identity标头字段的消息，则UA可以自由使用该值，但如果用户请求将断言的身份信息保持为私有，则UA必须确保其不会将信息转发到不属于信任域的任何元素。
If a UA is not part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can assume this information does not need to be kept private.
如果UA不是从中接收到包含P-Asserted-Identity标头字段的消息的信任域的一部分，则可以假定该信息不需要保持私有。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [4].
以下语法规范使用RFC-2234[4]中所述的增广巴科斯诺尔形式（BNF）。
The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.
P-Asserted-Identity报头字段在受信任的SIP实体（通常是中介）之间使用，以携带通过身份验证发送SIP消息的用户的身份。
PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec
PAssertedID=“P-Asserted-Identity”HCOLON PAssertedID值*（逗号PAssertedID值）PAssertedID值=名称addr/addr spec
A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field.
P-Asserted-Identity标头字段值必须仅由一个名称addr或addr-spec组成。可能有一个或两个P-Asserted-Identity值。如果有一个值，则它必须是sip、sips或tel URI。如果有两个值，一个值必须是sip或sips URI，另一个值必须是tel URI。值得注意的是，代理可以（也将）添加和删除此标题字段。
This document adds the following entry to Table 2 of [1]:
本文件在[1]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.
P-Preferred-Identity报头字段用于从用户代理到可信代理，以携带发送SIP消息的用户希望用于可信元素将插入的P-Asserted-header字段值的标识。
PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value *(COMMA PPreferredID-value) PPreferredID-value = name-addr / addr-spec
PPreferredID=“P-Preferred-Identity”HCOLON PPreferredID value*（逗号PPreferredID value）PPreferredID value=name addr/addr spec
A P-Preferred-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Preferred-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) remove this header field.
P-Preferred-Identity标头字段值必须由一个名称addr或addr-spec组成。可能有一个或两个P-Preferred-Identity值。如果有一个值，则它必须是sip、sips或tel URI。如果有两个值，一个值必须是sip或sips URI，另一个值必须是tel URI。值得注意的是，代理可以（也将）删除此标头字段。
This document adds the following entry to Table 2 of [1]:
本文件在[1]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Preferred-Identity adr - o - o o -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Preferred-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
This specification adds a new privacy type ("priv-value") to the Privacy header, defined in [2]. The presence of this privacy type in a Privacy header field indicates that the user would like the Network Asserted Identity to be kept private with respect to SIP entities outside the Trust Domain with which the user authenticated. Note that a user requesting multiple types of privacy MUST include all of the requested privacy types in its Privacy header field value.
本规范在[2]中定义的隐私标头中添加了新的隐私类型（“priv值”）。隐私头字段中存在此隐私类型表示用户希望网络断言的身份相对于用户进行身份验证的信任域之外的SIP实体保持私有。请注意，请求多种隐私类型的用户必须在其隐私标头字段值中包含所有请求的隐私类型。
priv-value = "id"
priv-value = "id"
Example:
例子：
Privacy: id
隐私：id
In this example, proxy.cisco.com creates a P-Asserted-Identity header field from an identity it discovered from SIP Digest authentication. It forwards this information to a trusted proxy which forwards it to a trusted gateway. Note that these examples consist of partial SIP messages that illustrate only those headers relevant to the authenticated identity problem.
在本例中，proxy.cisco.com根据从SIP摘要身份验证中发现的身份创建一个P-Asserted-Identity头字段。它将此信息转发给受信任的代理，该代理将其转发给受信任的网关。请注意，这些示例包括部分SIP消息，这些消息仅说明与身份验证问题相关的那些头。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1 useragent.cisco.com->proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
* F2 proxy.cisco.com -> useragent.cisco.com
* F2 proxy.cisco.com->useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.cisco.com"
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
* F3 useragent.cisco.com->proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
* F4 proxy.cisco.com -> proxy.pstn.net (trusted)
* F4 proxy.cisco.com->proxy.pstn.net（受信任）
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
* F5 proxy.pstn.net -> gw.pstn.net (trusted)
* F5 proxy.pstn.net->gw.pstn.net（受信任）
INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
In this example, the User Agent sends an INVITE that indicates it would prefer the identity sip:fluffy@cisco.com to the first proxy, which authenticates this with SIP Digest. The first proxy creates a P-Asserted-Identity header field and forwards it to a trusted proxy (outbound.cisco.com). The next proxy removes the P-Asserted-Identity header field and the request for Privacy before forwarding this request onward to the biloxi.com proxy server which it does not trust.
在此示例中，用户代理发送一个INVITE，表示它更喜欢标识sip：fluffy@cisco.com到第一个代理，该代理使用SIP摘要对此进行身份验证。第一个代理创建一个P-Asserted-Identity头字段，并将其转发给受信任的代理（outbound.cisco.com）。下一个代理将删除P-Asserted-Identity标头字段和隐私请求，然后再将此请求转发到它不信任的biloxi.com代理服务器。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1 useragent.cisco.com->proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
* F2 proxy.cisco.com -> useragent.cisco.com SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 To: <sip:bob@biloxi.com>;tag=123456 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="cisco.com"
* F2 proxy.cisco.com->useragent.cisco.com SIP/2.0 407代理授权通过：SIP/2.0/TCP useragent.cisco.com；分支=z9hG4bK-a111至：<sip:bob@biloxi.com>;tag=123456 From:“匿名”<sip:anonymous@anonymous.invalid>;tag=9802748调用ID:245780247857024504 CSeq:1邀请代理验证：。。。。realm=“cisco.com”
* F3 useragent.cisco.com -> proxy.cisco.com
* F3 useragent.cisco.com->proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4 proxy.cisco.com -> outbound.cisco.com (trusted)
* F4 proxy.cisco.com->outbound.cisco.com（受信任）
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: id
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: id
* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted)
* F5 outbound.cisco.com->proxy.biloxi.com（不受信任）
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
Privacy: id
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
Privacy: id
* F6 proxy.biloxi.com -> bobster.biloxi.com
* F6 proxy.biloxi.com->bobster.biloxi.com
INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 67
Privacy: id
INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 67
Privacy: id
The integrity of the mechanism described in this document relies on one node knowing (through configuration) that all of the nodes in a Trust Domain will behave in a predetermined way. This requires the predetermined behavior to be clearly defined and for all nodes in the Trust Domain to be compliant. The specification set that all nodes in a Trust Domain T must comply with is termed 'Spec(T)'.
本文档中描述的机制的完整性依赖于一个节点知道（通过配置）信任域中的所有节点将以预定方式运行。这需要明确定义预定的行为，并且信任域中的所有节点都要兼容。信任域T中的所有节点必须遵守的规范集称为“规范（T）”。
The remainder of this section presents an example Spec(T), which is not normative in any way.
本节剩余部分给出了一个示例规范（T），该规范在任何方面都不规范。
1. Protocol requirements
1. 协议要求
The following specifications MUST be supported:
必须支持以下规范：
1. RFC 3261
1. RFC3261
2. RFC 3325
2. RFC3325
2. Authentication requirements
2. 认证要求
Users MUST be authenticated using SIP Digest Authentication.
必须使用SIP摘要身份验证对用户进行身份验证。
3. Security requirements
3. 安全要求
Connections between nodes within the Trust Domain and between UAs and nodes in the Trust Domain MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed and confidentiality MUST be negotiated.
信任域内的节点之间以及UAs和信任域中的节点之间的连接必须使用TLS，该TLS使用RSA_和_AES_128_CBC_SHA1的密码套件。必须在信任域中的节点之间执行相互身份验证，并且必须协商机密性。
4. Scope of Trust Domain
4. 信任域的范围
The Trust Domain specified in this agreement consists of hosts which posses a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends with one of the following domain names: trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltName in the certificate.
本协议中指定的信任域由拥有由examplerootca.org签署的有效证书的主机组成；b） 其subjectAltName以以下域名之一结尾：trusted.div1.carrier-a.net、trusted.div2.carrier-a.net、sip.carrier-b.com；和c）其域名对应于证书中subjectAltName中的主机名。
5. Implicit handling when no Privacy header is present
5. 不存在隐私标头时的隐式处理
The elements in the trust domain must support the 'id' privacy service therefore absence of a Privacy header can be assumed to indicate that the user is not requesting any privacy. If no Privacy header field is present in a request, elements in this Trust Domain MUST act as if no privacy is requested.
信任域中的元素必须支持“id”隐私服务，因此，可以假设没有隐私头表示用户没有请求任何隐私。如果请求中不存在隐私标头字段，则此信任域中的元素必须起到不请求隐私的作用。
The mechanism provided in this document is a partial consideration of the problem of identity and privacy in SIP. For example, these mechanisms provide no means by which end users can securely share identity information end-to-end without a trusted service provider. Identity information that the user designates as 'private' can be inspected by any intermediaries participating in the Trust Domain. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.
本文件中提供的机制部分考虑了SIP中的身份和隐私问题。例如，这些机制无法提供终端用户在没有可信服务提供商的情况下安全地端到端共享身份信息的方法。用户指定为“私有”的身份信息可由参与信任域的任何中介机构进行检查。此信息由传递信任保护，传递信任仅与信任链中最薄弱的环节一样可靠。
When a trusted entity sends a message to any destination with that party's identity in a P-Asserted-Identity header field, the entity MUST take precautions to protect the identity information from eavesdropping and interception to protect the confidentiality and integrity of that identity information. The use of transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement.
当受信任实体在P-Asserted-identity标头字段中使用该方的身份向任何目的地发送消息时，该实体必须采取预防措施保护身份信息不被窃听和截获，以保护该身份信息的机密性和完整性。使用传输层或网络层逐跳安全机制（如TLS或带有适当密码套件的IPSec）可以满足这一要求。
This document defines two new private SIP header fields, "P-Asserted-Identity" and "P-Preferred-Identity". As recommended by the policy of the Transport Area, these headers have been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.
本文档定义了两个新的私有SIP头字段，“P-Asserted-Identity”和“P-Preferred-Identity”。根据运输区政策的建议，IANA已使用本文件的RFC号作为参考，在SIP报头注册表中注册了这些报头。
Name of Header: P-Asserted-Identity
标题名称：P-Asserted-Identity
Short form: none
简表：无
Registrant: Cullen Jennings fluffy@cisco.com
注册人：Cullen Jenningsfluffy@cisco.com
Normative description: Section 9.1 of this document
规范性说明：本文件第9.1节
Name of Header: P-Preferred-Identity
标题名称：P-Preferred-Identity
Short form: none
简表：无
Registrant: Cullen Jennings fluffy@cisco.com
注册人：Cullen Jenningsfluffy@cisco.com
Normative description: Section 9.2 of this document
规范性说明：本文件第9.2节
Name of privacy type: id
隐私类型的名称：id
Short Description: Privacy requested for Third-Party Asserted Identity
简短描述：为第三方声明的身份请求隐私
Registrant: Cullen Jennings fluffy@cisco.com
注册人：Cullen Jenningsfluffy@cisco.com
Normative description: Section 9.3 of this document
规范性说明：本文件第9.3节
Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5], and Jon Peterson [7] for authoring drafts which represent the bulk of the text making up this document. Thanks to many people for useful comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
感谢Bill Marshall和Flemming Andreason[6]、Mark Watson[5]和Jon Peterson[7]撰写了代表本文件大部分文本的草稿。感谢包括乔纳森·罗森博格、罗汉·马伊和保罗·基齐瓦特在内的许多人的有益评论。
Normative References
规范性引用文件
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
Informational References
参考资料
[5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[5] 沃森，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress.
[6] Andreasen，F.，“可信网络中网络断言呼叫方身份和隐私的SIP扩展”，正在进行中。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[7] Peterson，J.，“会话启动协议（SIP）中身份验证管理的增强”，正在进行中。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems 170西塔斯曼大道MS:SJC-21/3美国加利福尼亚州圣何塞95134
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: Jon.Peterson@NeuStar.biz
Phone: +1 925/363-8720
EMail: Jon.Peterson@NeuStar.biz
Mark Watson Nortel Networks Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire England
马克·沃森北电网络梅登黑德办公室公园（布雷之家）韦斯塔科特路梅登黑德，英国伯克希尔郡
Phone: +44 (0)1628-434456
EMail: mwatson@nortelnetworks.com
Phone: +44 (0)1628-434456
EMail: mwatson@nortelnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。