[要約] RFC 3325は、信頼されたネットワーク内でのアサートされたアイデンティティを実現するためのSIPのプライベート拡張に関するものです。このRFCの目的は、SIPセッションにおけるアイデンティティの信頼性を向上させることです。
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.
Copyright（c）The Internet Society（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サーバーのネットワークが認証されたユーザーのIDを主張できるようにするセッション開始プロトコル（SIP）へのプライベート拡張機能と、IDの問題への既存のプライバシーメカニズムの適用について説明します。これらの拡張機能の使用は、そのような情報の生成、輸送、および使用に関する以前に合意されたポリシーを伴う管理ドメイン内でのみ適用されます。このドキュメントでは、さまざまな信頼ドメイン間での使用やインターネット全体での使用に適した一般的なプライバシーまたはIDモデルを提供していません。
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
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サーバーのネットワークがエンドユーザーまたはエンドシステムのアイデンティティを主張し、エンドユーザー要求されたプライバシーの兆候を伝えるSIP [1]へのプライベートエクステンションについて説明しています。これらの拡張機能の使用は、ネットワーク主張されたアイデンティティの短期的要件で定義されている「信頼ドメイン」内でのみ適用されます[5]。このような信頼ドメインのノードは、ユーザーと最終システムによって明示的に信頼され、各当事者のIDを公に主張し、プライバシーが要求されたときにそのアイデンティティを信頼ドメイン以外で差し控える責任があります。ネットワークが主張するアイデンティティを決定する手段は、このドキュメントの範囲外であると判断します（ただし、一般的には何らかの形の認証が必要です）。
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.
適切な仕様（T）の例をセクション11に示します。
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].
このドキュメントは、インターネット全体でのドメイン間の使用または使用に適した一般的なプライバシーまたはIDモデルを提供しません。ユーザーとネットワークの間の信頼関係に関する仮定は、多くのアプリケーションでは適用されない場合があります。たとえば、これらの拡張機能は、ここで定義されている拡張機能を使用することにより、エンドユーザーが独立してアイデンティティを主張できるモデルに対応していません。さらに、主張されたアイデンティティは暗号化された認定を受けていないため、[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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.
これらのネットワークは、特定の従来のテレフォニーサービスをサポートし、基本的な規制および公共安全の要件を満たす必要があります。これらには、ID配信サービスの呼び出し、Identity Deliveryブロッキングの呼び出し、およびコールの発信者を追跡する機能が含まれます。ベースラインSIPはこれらの各サービスを個別にサポートできますが、このドキュメントで説明されている拡張機能なしでは、特定の組み合わせをサポートすることはできません。たとえば、プライバシーを維持し、その結果、ヘッダーフィールドからのSIPで限られた情報を提供する発信者は、発信者の身元を発見するために他の手段に依存しない限り、コールの受信者が識別できません。発信元のユーザーエージェントでのID情報のマスキングは、特定のサービス、たとえばコールトレースが、公開された電話ネットワーク（PSTN）で作業したり、ユーザーの認証されたIDに違反していない仲介者で実行されたりすることを防ぎます。
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]の要件に基づいて、非常に限られた単純なメカニズムを使用して、ネットワークアサートされたIDサービスを提供しようとします。この作業は、信頼ドメインのプライバシーとアイデンティティに関連するいくつかの問題を解決するための以前の試み[6]から派生しています。より包括的なメカニズム[7]は、暗号化を使用してこの問題に対処することです。これは、SIPワーキンググループによる現在の研究の主題です。
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ネットワークでは、セッションの参加者は通常、SIPサービスプロバイダーを巻き込むことなくIPトラフィックを直接交換することができます。これらのセッションに使用されるIPアドレス自体が個人情報を明らかにする場合があります。SIP環境でプライバシーを提供するための汎用メカニズムについては、[2]で説明しています。このドキュメントは、そのプライバシーメカニズムがネットワークを主張したアイデンティティの問題に適用されます。
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:
このドキュメントで提案されているメカニズムは、URI（一般的にSIP URI）とオプションのディスプレイ名を含む「P asserted-Identity」と呼ばれる新しいヘッダーフィールドに依存しています。
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.
P-Asserted-Identityヘッダーの正式な構文は、セクション9に示されています。
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ヘッダーフィールドを追加したい場合、プロキシはメッセージのオリジネーターを認証し、この認証から生じるIDを使用してPを挿入する必要があります。 - メッセージにastered-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ヘッダーフィールドが存在しない場合、プロキシは、最大1つのSIPまたはSIPS URI、および最大1つのTel URLを追加することができます。プロキシが信頼していない要素からメッセージを受信し、SIPまたはSIPS URIを含むPアサート付きアイデンティティヘッダーの存在がある場合、プロキシはそのSIPまたはSIPS URIを1回のSIPまたはSIPS URIに置き換える必要があります。このヘッダーフィールドを削除します。同様に、プロキシが信頼していない要素からメッセージを受信し、Tel URIを含むP asserted-Identityヘッダープレゼントがある場合、プロキシはそのテル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 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.
プロキシがメッセージを別のノードに転送する場合、最初にそのノードを信頼するかどうかを判断する必要があります。ノードを信頼している場合、プロキシは、それ自体が生成した、または信頼できるソースから受け取ったP-Asserted-Identityヘッダーフィールドを削除しません。要素を信頼していない場合、プロキシはプライバシーヘッダーフィールド（存在する場合）を調べて、ユーザーが主張されたID情報をプライベートに保つよう要求するかどうかを判断する必要があります。
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.
PREFERED-IDINTITYヘッダーフィールドが、プロキシが信頼していないエンティティから受け取るメッセージに存在する場合、プロキシはこの情報を使用して、認証されたユーザーの複数の有効なアイデンティティのどれを主張する必要があるかを示唆するヒントとして使用できます。このようなヒントがそのユーザーのプロキシに既知の有効なアイデンティティに対応していない場合、プロキシは独自の構造のPアサート付きアイデンティティヘッダーを追加するか、リクエストを拒否することができます（たとえば、403が禁止されています）。プロキシは、ユーザーが提供するPREFERED-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.
ユーザーエージェントは、PREFERED-ID-IDENTITYヘッダーフィールドのみを信頼ドメインのプロキシサーバーに送信します。ユーザーエージェントは、ユーザーエージェントによって信頼されているプロキシに直接送信されないメッセージに、p-referred-Identityヘッダーフィールドを入力してはなりません。P-Referred-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.
ただし、Trustドメインのすべてのユーザーが適切なプライバシーサービスにアクセスできる場合を除き、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].
「ID」プライバシーヘッダーPRIV値の正式な仕様については、セクション9.3で説明しています。ユーザーがプライバシーを必要とする場合のいくつかの一般的なガイドラインは、[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アサート付きアイデンティティヘッダーフィールド値（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ヘッダーフィールドを含むメッセージを受信したTrustドメインの一部である場合、値を自由に使用できますが、一部の要素ではない要素に情報を転送しないようにする必要があります。トラストドメインの場合、ユーザーが断定されたID情報をプライベートに保つよう要求した場合。
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ヘッダーフィールドを含むメッセージを受信したTrustドメインの一部ではない場合、この情報をプライベートに保つ必要がないと仮定できます。
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メッセージを送信するユーザーのIDを担当します。
PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec
passertedid = "p-asserted-Identity" hcolon passertedid-value *（comma passertedid-value）passertedid-value = name-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ヘッダーフィールド値は、正確に1つのname-addrまたはaddr-specで構成する必要があります。1つまたは2つのp asserted-Identity値がある場合があります。1つの値がある場合は、SIP、SIP、またはTel URIでなければなりません。2つの値がある場合、1つはSIPまたはSIPS URIでなければならず、もう1つは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 -
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-referred-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 *（comma 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-referred-Identityヘッダーフィールド値は、正確に1つのName-AddrまたはAddR-Specで構成する必要があります。1つまたは2つまたは2つのp-referred-Identity値がある場合があります。1つの値がある場合は、SIP、SIP、またはTel URIでなければなりません。2つの値がある場合、1つはSIPまたはSIPS URIでなければならず、もう1つは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 -
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-Value」）を追加します。プライバシーヘッダーフィールドにこのプライバシータイプが存在することは、ユーザーがユーザーが認証した信頼ドメインの外側のSIPエンティティに関して、ネットワークが主張されたアイデンティティをプライベートに保つことを望んでいることを示しています。複数のタイプのプライバシーを要求するユーザーは、プライバシーヘッダーフィールド値に要求されたすべてのプライバシータイプを含める必要があることに注意してください。
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ダイジェスト認証から発見したIDから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
* 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"
* 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"
* 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
* 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
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.
この例では、ユーザーエージェントは、IDIP：fluffy@cisco.comを最初のプロキシに好むことを示す招待状を送信します。最初のプロキシは、p-asserted-Identityヘッダーフィールドを作成し、信頼できるプロキシ（outbound.cisco.com）に転送します。次のプロキシは、この要求を信頼していないBiloxi.comプロキシサーバーに転送する前に、P-Asserted-Identityヘッダーフィールドとプライバシーの要求を削除します。
* 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>
* 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; branch = z9hg4bk-a111 to：<sip：bob@biloxi.com>;タグ= 123456 from： "anonymous" <sip：anonymous@anonymous.invalid>; tag = 9802748 call-id：245780247857024504 cseq：1 proxy-authenticate：.... .... 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"
* 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
* 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
* 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
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)'.
このドキュメントで説明されているメカニズムの整合性は、信頼ドメイン内のすべてのノードが事前に動作することを（構成を介して）1つのノードに依存しています。これには、所定の動作を明確に定義し、信頼ドメイン内のすべてのノードが準拠する必要があります。信頼ドメインt内のすべてのノードが準拠する必要があるすべてのノードが「Spec（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. RFC 3261
2. RFC 3325
2. RFC 3325
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とノード間の接続は、RSA_WITH_AES_128_CBC_SHA1の暗号スイートを使用してTLSを使用する必要があります。信頼ドメイン内のノード間の相互認証を実行する必要があり、機密性を交渉する必要があります。
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.
本契約で指定されている信頼ドメインは、a）examplerootca.orgによって署名される有効な証明書を所有するホストで構成されています。b）subjectaltnameは、次のドメイン名のいずれかで終了します。信頼済み。div1.carrier-a.net、trusted.div2.carrier-a.net、sip.carrier-b.com;c）ドメイン名は、証明書のsumberaltaltnameのホスト名に対応しています。
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.
Trustドメインの要素は、「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のアイデンティティとプライバシーの問題の部分的な考慮事項です。たとえば、これらのメカニズムは、エンドユーザーが信頼できるサービスプロバイダーなしでエンドツーエンドのアイデンティティ情報を安全に共有できる手段を提供しません。ユーザーが「プライベート」として指定するID情報は、信頼ドメインに参加している仲介者によって検査できます。この情報は、信頼のチェーンで最も弱いリンクと同じくらい信頼できる推移的な信頼によって保護されています。
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.
このドキュメントでは、2つの新しいプライベートSIPヘッダーフィールド「P-Asserted-Identity」と「P-Preferred-Identity」を定義します。輸送エリアのポリシーで推奨されているように、これらのヘッダーは、このドキュメントのRFC番号を参照として使用して、SIPヘッダーレジストリのIANAによって登録されています。
Name of Header: P-Asserted-Identity
ヘッダー名：p-asserted-Identity
Short form: none
短いフォーム：なし
Registrant: Cullen Jennings fluffy@cisco.com
登録者：Cullen Jennings Fluffy@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 Jennings Fluffy@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 Jennings Fluffy@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]に感謝します。Jonathan Rosenberg、Rohan Mahy、Paul Kyzivatなどの有益なコメントをしてくれた多くの人々に感謝します。
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：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、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 3324、2002年11月。
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress.
[6] Andreasen、F。、「信頼できるネットワーク内でのネットワークasserted発信者のアイデンティティとプライバシーのSIP拡張機能」、進行中の作業。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[7] ピーターソン、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 West Tasman Drive MS：SJC-21/3 San Jose、CA 95134 USA
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
Jon Peterson Neustar、Inc。1800 Sutter Street、Suite 570 Concord、CA 94520 USA
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。