[要約] RFC 3323は、SIPにおけるプライバシー機構を提供するための仕様です。その目的は、SIPセッションのプライバシーを保護し、ユーザーの個人情報の漏洩を防ぐことです。
Network Working Group J. Peterson
Request for Comments: 3323 Neustar
Category: Standards Track November 2002
A Privacy Mechanism for the Session Initiation Protocol (SIP)
セッション開始プロトコル（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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
このドキュメントでは、プライバシーをサポートするセッション開始プロトコル（SIP）の新しいメカニズムを定義します。具体的には、個人のアイデンティティ情報を明かすことのないメッセージの作成に関するガイドラインが提供されています。仲介業者の新しい「プライバシーサービス」論理的役割は、ユーザーエージェントが自分自身を満たすことができないプライバシー要件に答えるために定義されています。最後に、ユーザーがプライバシーサービスから特定の機能を要求できる手段が提示されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . 4
3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . 5
3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . 6
3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . 7
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
4.1 Constructing Private Messages . . . . . . . . . . . . . . 8
4.1.1 URIs, Display-Names and Privacy . . . . . . . . . . . . . 8
4.1.1.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . 9
4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . 11
4.3 Routing Requests to Privacy Services . . . . . . . . . . . 12
4.4 Routing Responses to Privacy Services . . . . . . . . . . 13
5. Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
5.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . 17
5.3 Applying User-Level Privacy Functions. . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
This document provides privacy requirements and mechanisms for the Session Initiation Protocol (SIP).
このドキュメントは、セッション開始プロトコル（SIP）のプライバシー要件とメカニズムを提供します。
Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. As identity is defined in this document, withholding the identity of a user will, among other things, render the other parties in the dialog unable to send new SIP requests to the user outside of the context of the current dialog.
このドキュメントでは、コミュニケーションの交換において、1つ以上の当事者、特にSIPダイアログからの人物（および関連する個人情報）の源泉徴収として、このドキュメントでプライバシーが定義されています。これらのパーティーには、これらのメッセージを処理するメッセージおよび/または仲介者の意図された宛先が含まれる可能性があります。このドキュメントでIDが定義されているため、ユーザーの身元を差し控えると、とりわけ、ダイアログ内の他の関係者が、現在のダイアログのコンテキスト以外のユーザーに新しいSIPリクエストを送信できません。
In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name. A SIP address-of-record has a form similar to an email address with a SIP URI scheme (for example, sip:alice@atlanta.com). A display-name is a string containing a name for the identified user (for example, "Alice"). SIP identities of this form commonly appear in the To and From header fields of SIP requests and responses. A user may have many identities that they use in different contexts.
SIPでは、アイデンティティは、SIP URIとオプションのディスプレイ名の形で最も一般的に運ばれます。SIPアドレスオブレコードには、SIP URIスキームを備えたメールアドレスに似たフォームがあります（たとえば、sip：alice@atlanta.com）。ディスプレイ名は、識別されたユーザーの名前を含む文字列です（たとえば、「アリス」）。このフォームのSIPアイデンティティは、一般に、SIPリクエストと応答のヘッダーフィールドとの間に表示されます。ユーザーは、さまざまなコンテキストで使用する多くのアイデンティティを持っている場合があります。
There are numerous other places in SIP messages in which identity-related information can be revealed. For example, the Contact header field contains a SIP URI, one that is commonly as revealing as the address-of-record in the From. In some headers, the originating user agent can conceal identity information as a matter of local policy without affecting the operation of the SIP protocol. However, certain headers are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data.
SIPメッセージには、ID関連の情報を明らかにできる他の多くの場所があります。たとえば、コンタクトヘッダーフィールドには、SIP URIが含まれています。一部のヘッダーでは、発信元のユーザーエージェントは、SIPプロトコルの操作に影響を与えることなく、ローカルポリシーの問題としてID情報を隠すことができます。ただし、特定のヘッダーはダイアログ内の後続のメッセージのルーティングで使用されるため、機能データを入力する必要があります。
The privacy problem is further complicated by proxy servers (also referred to in this document as "intermediaries" or "the network") that add headers of their own, such as the Record-Route and Via headers. Information in these headers could inadvertently reveal something about the originator of a message; for example, a Via header might reveal the service provider through whom the user sends requests, which might in turn strongly hint at the user's identity to some recipients. For these reasons, the participation of intermediaries is also crucial to providing privacy in SIP.
プライバシーの問題は、レコードルートやヘッダーなどの独自のヘッダーを追加するプロキシサーバー（このドキュメントでは「仲介者」または「ネットワーク」とも呼ばれます）によってさらに複雑になります。これらのヘッダーの情報は、メッセージの創始者に関する何かを誤って明らかにする可能性があります。たとえば、Viaヘッダーは、ユーザーがリクエストを送信するサービスプロバイダーを明らかにする可能性があります。これらの理由から、仲介者の参加もSIPでプライバシーを提供するために重要です。
Two complimentary principles have guided the design of this privacy mechanism: Users are empowered to hide their identity and related personal information when they issue requests, but intermediaries and designated recipients of requests are entitled to reject requests whose originator cannot be identified.
2つの無料の原則がこのプライバシーメカニズムの設計を導きました。ユーザーは、リクエストを発行するときに自分の身元と関連する個人情報を隠す権限を与えられていますが、仲介者と指定されたリクエストの受信者は、オリジネーターを特定できないリクエストを拒否する権利があります。
The privacy properties of only those specific headers enumerated in the core SIP specification ([1]), as opposed to headers defined by any existing or planned extension, are discussed in this document - however, the privacy mechanisms described in this document can be extended to support extensions.
既存または計画された拡張機能によって定義されたヘッダーとは対照的に、コアSIP仕様（[1]）に列挙された特定のヘッダーのみのプライバシープロパティについては、このドキュメントで説明しますが、このドキュメントで説明されているプライバシーメカニズムは拡張できます。拡張機能をサポートします。
There are other aspects of the general privacy problem for SIP that are not addressed by this document. Most significantly, the mechanisms for managing the confidentiality of SIP headers and bodies, as well the security of session traffic, are not reconsidered here. These problems are sufficiently well addressed in the baseline SIP specification and related documents, and that no new mechanisms are required.
このドキュメントでは対処されていないSIPには、一般的なプライバシー問題には他の側面があります。最も重要なことは、SIPヘッダーとボディの機密性を管理するためのメカニズム、およびセッショントラフィックのセキュリティがここで再考されないことです。これらの問題は、ベースラインSIP仕様および関連ドキュメントで十分に適切に対処されており、新しいメカニズムは必要ありません。
This document begins with a section that provides a general framework and architecture for privacy in SIP (Section 3), followed by sections that detail user agent behavior (Section 4) and privacy service behavior (Section 5).
このドキュメントは、SIP（セクション3）のプライバシーの一般的なフレームワークとアーキテクチャを提供するセクションから始まり、その後、ユーザーエージェントの動作（セクション4）とプライバシーサービスの動作（セクション5）を詳述するセクションが続きます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈され、準拠したSIP実装の要件レベルを示します。
A user may possess many identities that are used in various contexts; generally, identities are addresses-of-record which are bound to particular registrars (operated by the administrators of a domain) with whom SIP user agents register. The operators of these domains may be employers, service providers, or unaffiliated users themselves.
ユーザーは、さまざまなコンテキストで使用される多くのアイデンティティを持っている場合があります。一般に、IDは、SIPユーザーエージェントが登録する特定のレジストラ（ドメインの管理者が運営する）にバインドされる記録アドレスです。これらのドメインのオペレーターは、雇用主、サービスプロバイダー、または関係のないユーザー自身である場合があります。
When a user voluntarily asserts an identity in a request, they are claiming that they can receive requests sent to that identity in that domain. Strictly speaking, privacy entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message. In particular, there are scenarios in which a party desiring anonymity may:
ユーザーがリクエストで自発的にアイデンティティを主張するとき、彼らはそのドメインでそのアイデンティティに送信されたリクエストを受け取ることができると主張しています。厳密に言えば、プライバシーは、特定の当事者またはメッセージの受信者である特定の当事者からの特定の身元および関連する個人情報の分布の制限を伴います。特に、匿名性を望む当事者が次のようにするシナリオがあります。
send a message and withhold an identity from the final destination(s) while still communicating an identity to one or more intermediaries
メッセージを送信し、1人以上の仲介者に身元を伝えながら、最終目的地から身元を差し控えます
send a message and withhold their identity from some or all intermediaries, but still communicate an identity end-to-end to the final destination(s)
メッセージを送信し、一部またはすべての仲介者からのアイデンティティを差し控えますが、それでも最終目的地にエンドツーエンドを伝えます
withhold identity from both intermediaries and final destination(s)
仲介者と最終目的地の両方からアイデンティティを差し控える
The result of withholding an identity is that the parties in question would be unable, for example, to attempt to initiate a new dialog with the anonymous party at a later time. However, the anonymous party still must be capable of receiving responses and new requests during the dialog in which it is participating.
身元を差し控えた結果、問題の当事者は、たとえば、後で匿名の当事者との新しい対話を開始しようとすることができないということです。ただし、匿名の当事者は、参加しているダイアログ中に、回答と新しいリクエストを受け取ることができる必要があります。
It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms.
要求と応答の両方に関する身元情報を制限することが望ましい場合があります。当初、応答にプライバシーの懸念があることを示唆することは珍しいかもしれません - おそらく、リクエストの発信者は誰が連絡を取ろうとしているかを知っているので、回答者の身元はほとんど秘密になりません。ただし、回答の個人情報（回答者が現在登録されている連絡先住所など）はプライバシーの懸念の対象であり、これらのメカニズムによって対処できます。
Users may wish for identity information to be withheld from a given party for any number of reasons, for example:
ユーザーは、例えば次のような理由で、特定の当事者から身元情報を差し控えることを希望する場合があります。
Users might want to contact a particular party without revealing their identity in order to impart information with which they would not like to be associated
ユーザーは、関連付けられたくない情報を伝えるために、自分の身元を明らかにすることなく特定の当事者に連絡したい場合があります
Users might fear that the exposure of their identity or personal information to some networks or destinations will make them a target for unsolicited advertising, legal censure or other undesirable consequences
ユーザーは、自分のアイデンティティまたは個人情報の一部のネットワークや目的地にさらされることで、未承諾の広告、法的非難、またはその他の望ましくない結果のターゲットになることを恐れるかもしれません。
Users might want to withhold from participants in a session the identity by which they are known to network intermediaries for the purposes of billing and accounting
ユーザーは、請求と会計の目的でネットワーク仲介者に知られているアイデンティティをセッションの参加者から差し控えたい場合があります
When a user agent decides to send a request through a proxy server, it may be difficult for the originator to anticipate the final destination of that message. For that reason, users are advised not to base their estimation of their privacy needs on where they expect a message will go. For example, if a user sends a request to telephone number, they may believe that the final destination of the request will be a station in the public switched telephone network (PSTN) that is unable to inspect, say, SIP Contact headers, and therefore assume that it is safe to leave such headers in the clear; however, such a request might very well end up being retargeted by the network to a native SIP endpoint to which Contact headers are quite legible.
ユーザーエージェントがプロキシサーバーを介してリクエストを送信することを決定した場合、オリジネーターがそのメッセージの最終目的地を予測することは困難かもしれません。そのため、ユーザーは、メッセージが進むことを期待する場所にプライバシーのニーズを推定しないことをお勧めします。たとえば、ユーザーが電話番号にリクエストを送信した場合、リクエストの最終目的地は、たとえばSIPコンタクトヘッダーを検査できないため、公開された電話ネットワーク（PSTN）のステーションであると信じるかもしれません。そのようなヘッダーを明確にしておくことが安全であると仮定します。ただし、このような要求は、ネットワークによってネットワークヘッダーが非常に読みやすいネイティブSIPエンドポイントにリターゲティングされることになる可能性があります。
This document describes three degrees of privacy - one level of user-provided privacy, and two levels of network-provided privacy (header privacy and session privacy). How much privacy does a user need for any given session? Generally, if a user is seeking privacy, they're going to need as much of it as they can get. However, if a user knows of no privacy service, they must be content with user-provided privacy alone. Similarly, if a user knows of an anonymization service that can provide session privacy, but is unable to secure session traffic to prevent the anonymizer from possibly eavesdropping on the session, they might judge the loss of session privacy to be the lesser evil. The user might also be aware of exceptional conditions about the architecture in which the user agent is deployed that may obviate one or more privacy concerns.
このドキュメントでは、3つのレベルのユーザーが提供するプライバシー、および2つのレベルのネットワークが提供するプライバシー（ヘッダープライバシーとセッションのプライバシー）の3つのプライバシーを説明しています。ユーザーは、特定のセッションにどのくらいのプライバシーが必要ですか？一般的に、ユーザーがプライバシーを求めている場合、彼らは得ることができる限りそれを必要とするでしょう。ただし、ユーザーがプライバシーサービスを知らない場合、ユーザーが提供するプライバシーのみに満足する必要があります。同様に、ユーザーがセッションのプライバシーを提供できる匿名化サービスを知っているが、セッションのトラフィックを確保することができない場合、匿名化機がセッションで盗聴することを防ぐことができない場合、セッションのプライバシーの損失がより低い悪であると判断するかもしれません。また、ユーザーは、1つ以上のプライバシーの懸念を取り除く可能性のあるユーザーエージェントが展開されるアーキテクチャに関する例外的な条件を認識している場合があります。
A user may not always be the best judge of when privacy is required even under ideal circumstances, and thus privacy may in some architectures by applied by intermediaries without the user's explicit per-message request. By sending a request through intermediaries that can provide a privacy role, the user tacitly permits privacy functions to be invoked as needed.
ユーザーは、理想的な状況下でもプライバシーが必要な場合の最良の裁判官ではない場合があり、したがって、ユーザーの明示的な1人のリクエストなしに仲介者が適用することにより、一部のアーキテクチャではプライバシーが可能になる場合があります。プライバシーの役割を提供できる仲介者を通じてリクエストを送信することにより、ユーザーは、必要に応じてプライバシー機能を暗黙のうちに呼び出すことを許可します。
It is also important that users understand that intermediaries may be unable to provide privacy functions requested by users. Requests for privacy may not be honored due to legal constraints, unimplemented or misconfigured features, or other exceptional conditions.
また、ユーザーがユーザーが要求するプライバシー機能を提供できない可能性があることをユーザーが理解することも重要です。プライバシーの要求は、法的制約、実装されていないまたは誤解された機能、またはその他の例外的な条件のために尊重されない場合があります。
Note that just as it is the prerogative of a user to conceal their identity, so it must also be the prerogative of proxy servers and other users to refuse to process requests from users whom they cannot identify. Therefore users should not just automatically withhold their identity for all requests and responses - inability to ascertain the identity of the originator of the request will frequently be grounds for rejection. Privacy should only be requested when the user has a need for it.
ユーザーが自分の身元を隠すための特権であると同時に、それはまた、識別できないユーザーからのリクエストを処理することを拒否するために、プロキシサーバーや他のユーザーの特権でなければならないことに注意してください。したがって、ユーザーはすべてのリクエストと応答に対して自分の身元を自動的に差し控えるだけではありません。リクエストの創始者の身元を確認できないことは、拒否の根拠になることがよくあります。プライバシーは、ユーザーがそれを必要としている場合にのみ要求する必要があります。
Further to this point, withholding some information in signaling might not be necessary for all user agents to ensure privacy. For example, user agents may acquire their IP addresses and hostnames dynamically, and these dynamic addresses may not reveal any information about the user whatsoever. In these cases, restricting access to hostnames (as described in Section 4.1.1.3) is unnecessary.
さらに、この点まで、すべてのユーザーエージェントがプライバシーを確保するためには、シグナル伝達におけるいくつかの情報を差し控えることは必要ないかもしれません。たとえば、ユーザーエージェントはIPアドレスとホスト名を動的に取得する場合があり、これらの動的アドレスはユーザーに関する情報をまったく明らかにしない場合があります。これらの場合、ホスト名へのアクセスの制限（セクション4.1.1.3で説明）は不要です。
There is a certain amount of privacy that a user agent can provide itself. For example, the baseline SIP specification permits a user agent to populate the From header field of a request with an anonymous value. Users can take similar steps to avoid revealing any other unnecessarily identity information in related SIP headers (this is discussed further in Section 4.1.1).
ユーザーエージェントが自分自身を提供できる一定のプライバシーがあります。たとえば、ベースラインSIP仕様により、ユーザーエージェントは、リクエストのヘッダーフィールドから匿名の値を使用することができます。ユーザーは、関連するSIPヘッダーで他の不必要にアイデンティティ情報を明らかにすることを避けるために、同様の手順を実行できます（これについては、セクション4.1.1でさらに説明します）。
A user may have different privacy needs for a message if it traverses intermediaries rather than going directly end-to-end. A user may attempt to conceal things from intermediaries which are not concealed from the final destination, and vice versa. For example, using baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to-end in order to prevent intermediaries from inspecting them. If a SIP message will not pass through intermediaries, however, this step might not be necessary (i.e., lower-layer security, without the addition of security for SIP bodies, could be sufficient).
ユーザーは、直接エンドツーエンドに進むのではなく、仲介者を通過する場合、メッセージのプライバシーニーズが異なる場合があります。ユーザーは、最終目的地から隠されていない仲介者から物事を隠そうとする場合があります。たとえば、ベースラインSIPメカニズムを使用して、ユーザーエージェントは、仲介者がそれらの検査を防ぐために、SIPボディをエンドツーエンドで暗号化できます。ただし、SIPメッセージが仲介者を通過しない場合、この手順は必要ない場合があります（つまり、SIPボディのセキュリティを追加せずに、低層セキュリティで十分です）。
Also note that if a dialog goes directly end-to-end between participants, however, it will not be possible to conceal the network addresses of the participants.
また、ダイアログが参加者間で直接エンドツーエンドになった場合、参加者のネットワークアドレスを隠すことはできないことに注意してください。
If a user is sending a request through intermediaries, a user agent can conceal its identity to only a limited extent without the intermediaries' cooperation. Also, some information can only be concealed from destination endpoints if an intermediary is entrusted to remove it.
ユーザーが仲介業者を通じてリクエストを送信している場合、ユーザーエージェントは、仲介者の協力なしに限られた範囲でその身元を隠すことができます。また、一部の情報は、仲介者がそれを削除するように委託されている場合にのみ、宛先エンドポイントから隠すことができます。
For these reasons a user must have a way to request privacy from intermediaries, a means that allows users both to signal some indications of the desired privacy services, and to ensure that their call is routed to an intermediary that is capable of providing these services. A user may be aware of a specific third-party anonymizing host, one with which they have a pre-existing relationship, or a user may request that their local administrative domain provide privacy services.
これらの理由により、ユーザーは仲介者にプライバシーを要求する方法、ユーザーの両方が望ましいプライバシーサービスの何らかの兆候を示すことができる手段を持つ必要があり、これらのサービスを提供できる仲介者に通話がルーティングされるようにする必要があります。ユーザーは、特定のサードパーティの匿名のホストを認識している場合があります。ホストは、既存の関係を持っているホストであるか、ユーザーがローカル管理ドメインがプライバシーサービスを提供するように要求する場合があります。
Intermediaries may also be empowered to apply privacy to a message without any explicit signaling from the originating user, since user agents may not always be cognizant or capable of requesting privacy when it is necessary.
また、ユーザーエージェントが必要に応じてプライバシーを要求することは常に認識されていないとは限らないため、仲介者は、元のユーザーからの明示的なシグナリングなしでメッセージにプライバシーを適用する権限を与えられる場合があります。
There are three different ways that a user agent can contribute to the privacy of a request - by populating headers with values that reflect privacy requirements, by requesting further privacy services from the network, and by using cryptographic confidentiality to secure headers and bodies. Note that the last of these is outside the scope of this document.
ユーザーエージェントがリクエストのプライバシーに貢献できる3つの異なる方法があります - ヘッダーにプライバシー要件を反映した価値をヘッダーに登録すること、ネットワークからさらなるプライバシーサービスを要求することにより、そして暗号化の機密性を使用してヘッダーとボディを保護することにより。これらの最後は、このドキュメントの範囲外であることに注意してください。
The mechanisms provided in this section assume that a user agent is sufficiently configurable that a user can select header values and provision privacy preferences (ideally on a per-call basis). If this isn't the case, it is possible that a user can route their call through a privacy service that is configured to groom signaling from this user agent in order to provide some of the function described below (see Section 5).
このセクションで提供されているメカニズムは、ユーザーエージェントがヘッダー値を選択してプライバシー設定を提供できるように十分に構成可能であると想定しています（理想的には1列ごとに）。そうでない場合、ユーザーは、以下に説明する機能の一部を提供するために、このユーザーエージェントからの手入れを構成するように構成されたプライバシーサービスを通じて通話をルーティングできる可能性があります（セクション5を参照）。
Privacy starts with the user agent. The bulk of the steps that are required to conceal private information about the sender of a message are, appropriately enough, the sender's responsibility.
プライバシーはユーザーエージェントから始まります。メッセージの送信者に関する個人情報を隠すために必要な手順の大部分は、適切に十分に、送信者の責任です。
The following SIP headers, when generated by a user agent, can directly or indirectly reveal identity information about the originator of a message: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning. Note that the use of an authentication system (such as the SIP Digest authentication method described in [1]) also usually entails revealing identity to one or more parties; for more information see Section 6.
ユーザーエージェントによって生成された場合、次のSIPヘッダーは、メッセージの発信者に関する直接的または間接的にID情報を明らかにすることができます。call-id、in-reply-to and Warning。認証システムの使用（[1]で説明されているSIPダイジェスト認証方法など）の使用には、通常、1つ以上の当事者にアイデンティティを明らかにすることも伴うことに注意してください。詳細については、セクション6を参照してください。
The first and most obvious step is that user agents SHOULD not include any optional headers that might divulge personal information; there's certainly no reason for a user seeking privacy to include a Call-Info. Secondly, the user SHOULD populate URIs throughout the message in accordance with the guidelines given in Section 4.1.1. For example, users SHOULD create an anonymous From header field for the request. Finally, users MAY also need to request certain privacy functions from the network, as described in Section 4.2.
最初で最も明白なステップは、ユーザーエージェントが個人情報を漏らす可能性のあるオプションのヘッダーを含めるべきではないということです。プライバシーを求めているユーザーがCall-INFOを含める理由は確かにありません。第二に、ユーザーは、セクション4.1.1に記載されているガイドラインに従って、メッセージ全体にURIを埋める必要があります。たとえば、ユーザーはリクエストのためにヘッダーフィールドから匿名を作成する必要があります。最後に、セクション4.2で説明されているように、ユーザーはネットワークから特定のプライバシー関数を要求する必要がある場合があります。
The Call-ID header, which is frequently constructed in a manner that reveals the IP address or hostname of the originating client, requires special mention. User agents SHOULD substitute for the IP address or hostname that is frequently appended to the Call-ID value a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused).
call-idヘッダーは、発信元クライアントのIPアドレスまたはホスト名を明らかにする方法で頻繁に構築されているため、特別な言及が必要です。ユーザーエージェントは、Call-ID値に適切に長いランダム値に頻繁に追加されるIPアドレスまたはホスト名を代用する必要があります（リクエストのヘッダーの「タグ」として使用される値は再利用される可能性があります）。
Note that if the user wants to conceal any of the above headers from intermediaries alone, without withholding them from the final destination of the message, users MAY also place legitimate values for these headers in encapsulated 'message/sip' S/MIME bodies as described in Section 23 of [1].
ユーザーがメッセージの最終目的地から源泉徴収せずに上記のヘッダーのいずれかを単独で源泉徴収せずに隠したい場合、ユーザーは、説明されているようにカプセル化された「メッセージ/SIPのs/mime体」にこれらのヘッダーの合法的な値を配置することもできます。[1]のセクション23で。
A certain amount of privacy can be afforded by choosing to populate SIP headers with URIs and display-names that do not reveal any identity information. In some of the header fields (for example, the Reply-To and From headers), URIs are not used in further signaling within the current dialog. In others, like the Contact header, an inaccurate URI will result in a failure to route subsequent requests within the dialog.
SIPヘッダーをURISとDisplayNamesに紹介することを選択することにより、一定量のプライバシーを提供できます。一部のヘッダーフィールド（たとえば、返信やヘッダーから）では、URIは現在のダイアログ内のさらなる信号に使用されません。他の人では、コンタクトヘッダーのように、不正確なURIは、ダイアログ内の後続の要求をルーティングできなくなります。
It is a relatively common practice in email and other applications to use an assumed name in the display-name component of the From header field. Outside of a business context (especially in applications such as instant messaging or Internet gaming) the use of such aliases is unlikely to provide a cause for distrust.
From Headerフィールドのディスプレイ名コンポーネントで想定された名前を使用することは、電子メールやその他のアプリケーションで比較的一般的な慣行です。ビジネスコンテキスト以外では（特にインスタントメッセージングやインターネットゲームなどのアプリケーションで）、このようなエイリアスの使用は、不信の原因を提供する可能性は低いです。
It is RECOMMENDED that user agents seeking anonymity use a display-name of "Anonymous".
匿名を求めているユーザーエージェントは、「匿名」のディスプレイ名を使用することをお勧めします。
The structure of a URI itself can reveal or conceal a considerable amount of personal information. Consider the difference between:
URI自体の構造は、かなりの量の個人情報を明らかにまたは隠すことができます。間の違いを考えてみましょう：
sip:jon.peterson@neustar.biz
SIP：jon.peterson@neustar.biz
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
sip:a0017@anonymous-sip.com
sip：a0017@anonymous-sip.com
From the former, the full name and employer of the party in question can easily be guessed. From the latter, you learn nothing other than that the party desires anonymity. In some cases, sufficient anonymity can be achieved by selecting an oblique URI. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header.
前者から、問題の当事者のフルネームと雇用主は簡単に推測できます。後者から、党が匿名性を望んでいること以外は何も学びません。場合によっては、斜めのURIを選択することにより、十分な匿名性を実現できます。今日、SIP仕様は、From Headerのユーザー部分に「匿名」のURIを推奨しています。
In some URIs, such as those that appear in Contact headers, it MAY also make sense to omit the username altogether, and provide only a hostname, like: sip:anonymous-sip.com
接触ヘッダーに表示されるものなどの一部のURIでは、ユーザー名を完全に省略し、次のようなホスト名のみを提供することも理にかなっているかもしれません。
It is assumed by this document that the user that requests privacy wishes to receive future requests and responses within this dialog, but does not wish to reveal an identity that could be used to send new requests to him outside the scope of this dialog. For that reason, different treatment must be recommended for URIs that are used in the context of routing further requests in the dialog, as opposed to routing new requests outside the context of the dialog.
このドキュメントでは、プライバシーを要求するユーザーがこのダイアログ内で将来のリクエストと応答を受け取ることを希望するが、このダイアログの範囲外に新しいリクエストを送信するために使用できるアイデンティティを明らかにしたくないと想定されています。そのため、ダイアログのコンテキスト外に新しいリクエストをルーティングするのではなく、ダイアログ内のさらなる要求をルーティングするというコンテキストで使用されるURIには、異なる治療を推奨する必要があります。
For headers indicating how the user would like to be contacted for future sessions (such as the From header), it might not immediately be obvious why changing the hostname would be necessary - if the username is 'anonymous', requests will not be routable to the anonymous user.
ユーザーが将来のセッション（From Headerなど）のためにどのように連絡したいかを示すヘッダーの場合、ホスト名を変更する必要がある理由はすぐにはわかりません - ユーザー名が「匿名」である場合、リクエストは匿名のユーザー。
Sometimes, merely changing the username will not be enough to conceal a user's identity. A user's SIP service provider might decisively reveal a user's identity (if it reflected something like a small company or a personal domain). So in this case, even though the URI in the From header would not dereference to the anonymous user, humans might easily guess the user's identity and know the proper form of their address-of-record.
時には、単にユーザー名を変更するだけでは、ユーザーの身元を隠すのに十分ではありません。ユーザーのSIPサービスプロバイダーは、ユーザーの身元を決定的に明らかにする可能性があります（小さな会社や個人のドメインのようなものを反映している場合）。したがって、この場合、From HeaderのURIが匿名のユーザーに抑制されない場合でも、人間はユーザーの身元を簡単に推測し、適切な録画の形式を知ることができます。
For these reasons, the hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs (see [3] for more information about the reserved 'invalid' DNS TLD). The full recommended form of the From header for anonymity is (note that this From header, like all others, MUST contain a valid and unique 'tag=' parameter):
これらの理由により、ホスト名値「anonymous.invalid」は匿名のurisに使用する必要があります（[3]を参照して、予約された「無効」DNS TLDの詳細については参照）。匿名性のヘッダーの完全な推奨形式は、ヘッダーからのこれは、他のすべてのものと同様に、有効で一意の「タグ=」パラメーターを含める必要があることに注意してください）：
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
For headers indicating how further requests in the current dialog should be routed (namely the Contact header, Via header, and session information in the SDP), there seems to be little that a user can do to disguise the existing URI, because users MUST provide a value that will allow them to receive further requests. In some cases, disguising or failing to provide the username, as described above, may create some level of privacy, but the hostname provides a more significant obstacle.
現在のダイアログでのさらなるリクエストをルーティングする方法を示すヘッダー（つまり、SDPのヘッダーとセッション情報を介して連絡先ヘッダー）の場合、ユーザーが提供する必要があるため、ユーザーが既存のURIを偽装するためにできることはほとんどないようです。彼らがさらなるリクエストを受信できるようにする値。場合によっては、上記のようにユーザー名を偽装または提供に失敗すると、ある程度のプライバシーが生じる可能性がありますが、ホスト名はより重要な障害を提供します。
Is there much additional privacy in using an IP address rather than a hostname? It does prevent someone who casually inspects a message from gathering information that they might see otherwise. However, reverse-resolving such addresses is generally trivial, and substituting an IP address for a hostname could introduce some complications, for example due to NAT and firewall traversal concerns. Headers used in routing may also rely on certain DNS practices to provide services that would be lost if an IP address is used in place of a hostname.
ホスト名ではなくIPアドレスを使用することには、追加のプライバシーがありますか？それは、他の方法で見るかもしれない情報を収集するメッセージを何気なく検査する人を妨げます。ただし、そのようなアドレスを逆回復することは一般に些細なことであり、たとえばNATやファイアウォールの走査の懸念により、ホスト名のIPアドレスを置き換えると合併症が導入される可能性があります。ルーティングで使用されるヘッダーは、特定のDNSプラクティスに依存して、ホスト名の代わりにIPアドレスが使用されている場合に失われるサービスを提供する場合があります。
This document thus recommends that the host portion of URIs that are used in the routing of subsequent requests, such as URIs appearing in the Contact header, SHOULD NOT be altered by the user agent due to privacy considerations. If these headers require anonymization, the user requests that service from an intermediary, namely a privacy service.
したがって、このドキュメントは、コンタクトヘッダーに表示されるURISなど、後続のリクエストのルーティングで使用されるURIのホスト部分を、プライバシーの考慮事項のためにユーザーエージェントが変更すべきではないことを推奨しています。これらのヘッダーが匿名化を必要とする場合、ユーザーは仲介者、つまりプライバシーサービスからそのサービスを要求します。
Note that many of the considerations regarding the Contact header above apply equal well to SIP headers in which a hostname, rather than a URI, is used for some routing purpose (namely the Via header).
上記のコンタクトヘッダーに関する考慮事項の多くは、URIではなくホスト名が何らかのルーティング目的（つまり、ヘッダー）に使用されるSIPヘッダーに等しく適用されることに注意してください。
There are some headers that a user agent cannot conceal itself, because they are used in routing, that could be concealed by an intermediary that subsequently takes responsibility for directing messages to and from the anonymous user. The user agent must have some way to request such privacy services from the network. For that purpose, this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses.
ユーザーエージェントは、ルーティングで使用されているため、ユーザーエージェントが自分自身を隠すことができないヘッダーがいくつかあります。これは、匿名のユーザーとの間でメッセージを指示する責任を負う仲介者によって隠される可能性があります。ユーザーエージェントは、ネットワークからそのようなプライバシーサービスを要求する何らかの方法が必要です。その目的のために、このドキュメントは、リクエストと応答のプライバシー処理を指定するために使用できる新しいSIPヘッダー、プライバシーを定義します。
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
User agents SHOULD include a Privacy header when network-provided privacy (as described in Section 3.3) is required. Note that some intermediaries may also add the Privacy header to messages, including privacy services. However, such intermediaries SHOULD only do so if they are operating at a user's behest, for example if a user has an administrative arrangement with the operator of the intermediary that it will add such a Privacy header. An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified.
ユーザーエージェントには、ネットワークが提供するプライバシー（セクション3.3で説明されている）が必要な場合は、プライバシーヘッダーを含める必要があります。一部の仲介者は、プライバシーサービスを含むメッセージにプライバシーヘッダーを追加する場合があることに注意してください。ただし、そのような仲介業者は、ユーザーが依頼して動作している場合にのみ、そうする必要があります。たとえば、ユーザーがそのようなプライバシーヘッダーを追加することを中間のオペレーターと管理契約者と持っている場合です。仲介者は、「なし」のpriv-valueがすでに指定されている場合、プライバシーヘッダーをいかなる方法でも変更してはなりません。
The values of priv-value today are restricted to the above options, although further options can be defined as appropriate (see Section 7). Each legitimate priv-value can appear zero or one times in a Privacy header. The current values are:
今日のpriv値の値は上記のオプションに制限されていますが、さらなるオプションは必要に応じて定義できます（セクション7を参照）。各正当なPRIV値は、プライバシーヘッダーでゼロまたは1回表示される可能性があります。現在の値は次のとおりです。
header: The user requests that a privacy service obscure those headers which cannot be completely expunged of identifying information without the assistance of intermediaries (such as Via and Contact). Also, no unnecessary headers should be added by the service that might reveal personal information about the originator of the request.
ヘッダー：ユーザーは、プライバシーサービスが、仲介者の支援（viaや連絡など）の支援なしに情報を識別することを完全に削除できないヘッダーを不明瞭にすることを要求します。また、リクエストの発信者に関する個人情報を明らかにする可能性のあるサービスによって、不必要なヘッダーを追加する必要はありません。
session: The user requests that a privacy service provide anonymization for the session(s) (described, for example, in a Session Description Protocol [5] body) initiated by this message. This will mask the IP address from which the session traffic would ordinarily appear to originate. When session privacy is requested, user agents MUST NOT encrypt SDP bodies in messages. Note that requesting session privacy in the absence of any end-to-end session encryption raises some serious security concerns (see Section 5.2).
セッション：ユーザーは、プライバシーサービスがこのメッセージによって開始されたセッションの匿名化（たとえば、セッション説明プロトコル[5]ボディ）で説明されることを要求します。これにより、セッショントラフィックが通常発生するように見えるIPアドレスをマスクします。セッションのプライバシーが要求された場合、ユーザーエージェントはメッセージ内のSDPボディを暗号化してはなりません。エンドツーエンドのセッション暗号化がない場合にセッションプライバシーを要求すると、いくつかの深刻なセキュリティ上の懸念が生じることに注意してください（セクション5.2を参照）。
user: This privacy level is usually set only by intermediaries, in order to communicate that user level privacy functions (as discussed in Section 5.3) must be provided by the network, presumably because the user agent is unable to provide them. User agents MAY however set this privacy level for REGISTER requests, but SHOULD NOT set 'user' level privacy for other requests.
ユーザー：このプライバシーレベルは、通常、ユーザーレベルのプライバシー関数（セクション5.3で説明されているように）がネットワークによって提供される必要があることを伝えるために、おそらくユーザーエージェントがそれらを提供できないことを伝えるために、仲介者によってのみ設定されます。ただし、ユーザーエージェントは、レジスタリクエストのためにこのプライバシーレベルを設定する場合がありますが、他のリクエストに対して「ユーザー」レベルのプライバシーを設定すべきではありません。
none: The user requests that a privacy service apply no privacy functions to this message, regardless of any pre-provisioned profile for the user or default behavior of the service. User agents can specify this option when they are forced to route a message through a privacy service which will, if no Privacy header is present, apply some privacy functions which the user does not desire for this message. Intermediaries MUST NOT remove or alter a Privacy header whose priv-value is 'none'. User agents MUST NOT populate any other priv-values (including 'critical') in a Privacy header that contains a value of 'none'.
なし：ユーザーは、プライバシーサービスが、ユーザーの事前に解決されたプロファイルやサービスのデフォルトの動作に関係なく、このメッセージにプライバシー機能を適用しないことを要求します。ユーザーエージェントは、プライバシーヘッダーが存在しない場合、ユーザーがこのメッセージを望まないプライバシー関数を適用するプライバシーサービスを通じてメッセージをルーティングすることを余儀なくされるときに、このオプションを指定できます。仲介者は、Priv-Valueが「なし」であるプライバシーヘッダーを削除または変更してはなりません。ユーザーエージェントは、「none」の値を含むプライバシーヘッダーに、他のpriv値（「クリティカル」を含む）を入力してはなりません。
critical: The user asserts that the privacy services requested for this message are critical, and that therefore, if these privacy services cannot be provided by the network, this request should be rejected. Criticality cannot be managed appropriately for responses.
重要：ユーザーは、このメッセージに対して要求されたプライバシーサービスが重要であると主張しているため、これらのプライバシーサービスをネットワークから提供できない場合、この要求は拒否されるべきです。臨界性は、回答のために適切に管理することはできません。
When a Privacy header is constructed, it MUST consist of either the value 'none', or one or more of the values 'user', 'header' and 'session' (each of which MUST appear at most once) which MAY in turn be followed by the 'critical' indicator.
プライバシーヘッダーが構築されるとき、それは値「なし」、または1つ以上の値「ユーザー」、「ヘッダー」、「セッション」（それぞれがせいぜい1回表示される必要がある）で構成する必要があります。その後、「重要な」インジケーターが続きます。
The following table specifies extensions to Table 2 in [1].
次の表は、[1]の表2の拡張機能を指定します。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o o
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
The most obvious way for a user agent to invoke the privacy function is to direct a request through an intermediary known to act as a privacy service. Doing so traditionally entails the configuration of pre-loaded Route headers that designate the privacy service.
ユーザーエージェントがプライバシー機能を呼び出すための最も明白な方法は、プライバシーサービスとして機能することが知られている仲介者を通じてリクエストを指示することです。そうすることは、従来、プライバシーサービスを指定する事前にロードされたルートヘッダーの構成を伴います。
It is RECOMMENDED that service providers couple the privacy service function with a local outbound proxy. Users can thereby send their messages that request privacy through their usual outbound route. Users should not assume, however, that the administrative domain that is the destination of the request would be willing and able to perform the privacy service function on their behalf. If the originating user wishes to keep their local administrative domain a secret, then they must use a third-party anonymization service outside of any of the principal administrative domains associated with the session.
サービスプロバイダーは、プライバシーサービス機能をローカルアウトバウンドプロキシと結合することをお勧めします。これにより、通常のアウトバウンドルートを介してプライバシーを要求するメッセージを送信できます。ただし、ユーザーは、リクエストの目的地である管理ドメインが、自分に代わってプライバシーサービス機能を喜んで実行できることを想定すべきではありません。発信元のユーザーがローカル管理領域を秘密にしたい場合、セッションに関連付けられた主要な管理ドメインのいずれか外でサードパーティの匿名化サービスを使用する必要があります。
It is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service. Ideally, users SHOULD establish a direct (i.e., single pre-loaded Route header) connection to a privacy service; this will both allow the user to inspect a certificate presented by the privacy service, and it will provide confidentiality for requests that will reduce the chances that the information that the privacy service will obscures is revealed before a message arrives at the privacy service. By establishing a direct connection to a privacy service, the user also eliminates the possibility that intermediaries could remove requests for privacy. If a direct connection is impossible, users SHOULD use a mechanism like SIPS to guarantee the use of lower-layer security all the way to the privacy service.
プライバシーサービスに連絡するときは、ユーザーエージェントがTLSなどのネットワークまたはトランスポートレイヤーセキュリティを使用することを強くお勧めします。理想的には、ユーザーはプライバシーサービスへの直接的な（つまり、単一のプリロードされたルートヘッダー）接続を確立する必要があります。これにより、ユーザーはプライバシーサービスによって提示された証明書を検査できるようになり、プライバシーサービスが曖昧にする情報がプライバシーサービスに届く前に明らかにされる可能性を減らすリクエストの機密性を提供します。プライバシーサービスへの直接的な接続を確立することにより、ユーザーはまた、仲介者がプライバシーのリクエストを削除できる可能性を排除します。直接接続が不可能な場合、ユーザーはSIPSのようなメカニズムを使用して、プライバシーサービスまでずっと低層セキュリティの使用を保証する必要があります。
If a user agent believes that it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing a new option-tag, 'privacy', especially when the 'critical' priv-value is present in the Privacy header. That way, in the unlikely event that the user agent sends a request to an intermediary that does not support the extensions described in this document, the request will fail. Note that because of special privacy service
ユーザーエージェントがリクエストをプライバシーサービスに直接送信していると考えている場合、特に「クリティカル」プライバシーに「重要な」Priv-Valueが存在する場合、新しいオプションタグ「プライバシー」を含むプロキシリクイアヘッダーを含める必要があります。ヘッダ。そうすれば、ユーザーエージェントがこのドキュメントで説明されている拡張子をサポートしていない仲介者にリクエストを送信する可能性が高い場合、リクエストは失敗します。特別なプライバシーサービスのために注意してください
behavior (described in Section 5), no subsequent intermediaries in the signaling path of the request will also need to the support the 'privacy' option-tag - once the privacy service has fulfilled all the required privacy functions, the 'privacy' option-tag is removed from the Proxy-Require header.
動作（セクション5で説明）、リクエストの信号パスにおける後続の仲介者は、「プライバシー」オプションタグをサポートするために必要ではありません - プライバシーサービスが必要なすべてのプライバシー機能、「プライバシー」オプション - タグはプロキシリクイアヘッダーから削除されます。
Making sure that responses will go through a privacy service is a little bit trickier. The path traversed by SIP responses is the same as the path over which the request traveled. Thus, the responding user agent, for example, cannot force a privacy service to be injected in the response path after it has received a request.
応答がプライバシーサービスを通過することを確認するのは少し難しいです。SIP応答によって横断されるパスは、リクエストが移動したパスと同じです。したがって、たとえば、応答するユーザーエージェントは、リクエストを受け取った後、応答パスにプライバシーサービスを強制することはできません。
What a responding user agent can do, however, is ensure that the path by which requests reach them traverses their privacy service. In some architectures, the privacy service function will be fulfilled by the same server to which requests for the local administrative domain are sent, and hence it will automatically be in the path of incoming requests. However, if this is not the case, the user will have to ensure that requests are directed through a third-party privacy service.
ただし、応答するユーザーエージェントができることは、リクエストがそれらに到達するパスがプライバシーサービスを横断することを保証することです。一部のアーキテクチャでは、プライバシーサービス機能は、ローカル管理ドメインのリクエストが送信されるのと同じサーバーによって満たされます。ただし、そうでない場合、ユーザーはリクエストがサードパーティのプライバシーサービスを通じて指示されることを確認する必要があります。
One way to accomplish this is to procure an 'anonymous callback' URI from the third-party service and to distribute this as an address-of-record. A privacy service provider might offer these anonymous callback URIs to users in the same way that an ordinary SIP service provider grants addresses-of-record. The user would then register their normal address-of-record as a contact address with the third-party service.
これを達成する1つの方法は、サードパーティサービスから「匿名のコールバック」URIを調達し、これを記録の住所として配布することです。プライバシーサービスプロバイダーは、通常のSIPサービスプロバイダーがRecordのアドレスを付与するのと同じ方法で、これらの匿名のコールバックURIをユーザーに提供する場合があります。ユーザーは、サードパーティのサービスとの連絡先アドレスとして通常の記録アドレスを登録します。
Alternatively, a user agent could send REGISTER requests through a privacy service with a request for 'user' level privacy. This will allow the privacy service to insert anonymous Contact header URIs. Requests sent to the user's conventional address-of-record would then reach the user's devices without revealing any usable contact addresses.
または、ユーザーエージェントは、「ユーザー」レベルのプライバシーを要求して、プライバシーサービスを通じてレジスタリクエストを送信できます。これにより、プライバシーサービスが匿名の連絡先ヘッダーURIを挿入できます。ユーザーの従来の住所に送信されたリクエストは、使用可能な連絡先アドレスを表示せずにユーザーのデバイスに到達します。
Finally, a user might generate a CPL ([7]) script that will direct requests to an anonymization service.
最後に、ユーザーは、匿名化サービスにリクエストを指示するCPL（[7]）スクリプトを生成する場合があります。
Users are also advised to use transport or network layer security in the response path. This may involve registering a SIPS URI and/or maintaining persistent TLS connections over which their user agent receives requests.
また、ユーザーは、応答パスでトランスポートまたはネットワークレイヤーセキュリティを使用することもお勧めします。これには、SIPS URIの登録、および/またはユーザーエージェントがリクエストを受信する永続的なTLS接続の維持が含まれる場合があります。
Privacy services MAY in turn route requests through other privacy services. This may be necessary if a privacy service does not support a particular privacy function, but it knows of a peer that does. Privacy services may also cluster themselves into networks that exchange session traffic between one another in order to further disguise the participants in a session, although no specific architecture or method for doing so is described in this document.
プライバシーサービスは、他のプライバシーサービスを介してルートリクエストを順番にリクエストする場合があります。これは、プライバシーサービスが特定のプライバシー機能をサポートしていない場合に必要になる場合がありますが、そうするピアを知っています。また、プライバシーサービスは、セッションで参加者をさらに偽装するためにセッションのトラフィックを交換するネットワークにクラスター化することもできますが、このドキュメントには特定のアーキテクチャや方法について説明しません。
This document defines a new SIP logical role called a "privacy service". The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves.
このドキュメントでは、「プライバシーサービス」と呼ばれる新しいSIP論理ロールを定義しています。プライバシーサービスの役割は、SIPプロキシサーバーとして機能することができるエンティティによって、ネットワーク仲介者によってインスタンス化されます。プライバシーサービスの機能は、ユーザーエージェント自身が提供できないSIPメッセージにプライバシー機能を提供することです。
When a message arrives at a server that can act as a privacy service, the service SHOULD evaluate the level of privacy requested in a Privacy header. Usually, only the services explicitly requested should be applied. However, privacy services MAY have some means outside SIP of ascertaining the preferences of the user (such as a pre-arranged user profile) and therefore they MAY perform such other privacy functions without an explicit Privacy header. Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support the Privacy header, or a user agent that does not allow the user to configure the values of headers that could reveal personal information. However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header.
プライバシーサービスとして機能できるサーバーにメッセージが届くと、サービスはプライバシーヘッダーで要求されたプライバシーのレベルを評価する必要があります。通常、明示的に要求されたサービスのみを適用する必要があります。ただし、プライバシーサービスは、ユーザーの好みを確認するためのSIP（事前に配置されたユーザープロファイルなど）を確認するためのいくつかの手段を持つ場合があるため、明示的なプライバシーヘッダーなしでそのような他のプライバシー関数を実行する場合があります。プライバシーサービスでユーザーレベルのプライバシー機能を実行することは、たとえば、ユーザーがプライバシーヘッダーをサポートするレガシークライアントまたはユーザーが値の構成を許可しないユーザーエージェントからメッセージを送信している場合に役立ちます。個人情報を明らかにする可能性のあるヘッダーの。ただし、「none」のプライバシーヘッダー値がメッセージで指定されている場合、プライバシーサービスはプライバシー機能を実行する必要はなく、プライバシーヘッダーを削除または変更してはなりません。
Privacy services MUST implement support for the 'none' and 'critical' privacy tokens, and MAY implement any of other privacy levels described in Section 4.2 as well as any extensions that are not detailed in this document. In some cases, the privacy service will not be capable of fulfilling the requested level of privacy. If the 'critical' privacy level is present in the Privacy header of a request, then if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then it MUST fail the request with a 500 (Server Error) response code. The reason phrase of the status line of the response SHOULD contain appropriate text indicating that there has been a privacy failure as well as an enumeration of the priv-value(s) which were not supported by the privacy service (the reason phrase SHOULD also respect any Accept-Language header in the request if possible).
プライバシーサービスは、「なし」および「重要な」プライバシートークンのサポートを実装する必要があり、セクション4.2で説明されている他のプライバシーレベルのいずれか、およびこのドキュメントで詳しく説明されていない拡張機能を実装する必要があります。場合によっては、プライバシーサービスは、要求されたレベルのプライバシーを満たすことができません。「重要な」プライバシーレベルがリクエストのプライバシーヘッダーに存在する場合、プライバシーサービスがプライバシーヘッダーで指定されたプライバシーのすべてのレベルを実行できない場合、500（サーバーエラー）でリクエストに失敗する必要があります応答コード。応答のステータス行の理由フレーズは、プライバシーの失敗とプライバシーサービスによってサポートされていないPRIV値の列挙があったことを示す適切なテキストを含める必要があります（理由フレーズはまた尊重する必要があります可能であれば、リクエストの受け入れ言語ヘッダー）。
When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable. When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from a message.
プライバシーサービスがプライバシーヘッダーにリストされているプライバシーレベルに対応する機能の1つを実行する場合、プライバシーヘッダーから対応するPRIV値を削除する必要があります。、多くの場合、それは望ましくありません。最後のPRIV値（「クリティカル」をカウントしない）がプライバシーヘッダーから削除された場合、プライバシーヘッダー全体をメッセージから削除する必要があります。
When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request.
プライバシーサービスがプライバシーヘッダー全体を削除する場合、メッセージがリクエストである場合、プライバシーサービスは、リクエストのプロキシリクイアヘッダーフィールドから「プライバシー」オプションタグを削除する必要があります。
If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help to obscure headers that might otherwise reveal information about the originator of the request. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent back-to-back user agent (B2BUA).
「ヘッダー」のプライバシーレベルが要求された場合、元のユーザーはプライバシーサービスに、リクエストの発信者に関する情報を明らかにする可能性のあるヘッダーを曖昧にするのに役立つように依頼しました。ただし、ダイアログ内のさらなるメッセージを元のユーザーエージェントにルーティングする必要がある場合、非常に不明瞭な値は回復可能でなければなりません。これらの機能を提供するために、プライバシーサービスは頻繁に透明な連続したユーザーエージェント（B2BUA）として機能する必要があります。
Firstly, a request for header privacy entails that the server SHOULD NOT add any headers to the message that reveal any identity or personal information, including the following: Call-Info, Server, and Organization. All of these provide optional information that could reveal facts about the user that has request anonymity.
第一に、ヘッダープライバシーのリクエストには、サーバーがメッセージにヘッダーを追加してはならないことを伴います。これには、Call-info、サーバー、および組織を含むIDまたは個人情報を明らかにします。これらはすべて、匿名性を要求しているユーザーに関する事実を明らかにする可能性のあるオプションの情報を提供します。
Privacy services operating on requests SHOULD remove all Via headers that have been added to the request prior to its arrival at the privacy service (a practice referred to as "Via stripping") and then SHOULD add a single Via header representing themselves. Note that the bottommost such Via header field value in a request contains an IP address or hostname that designates the originating client, and subsequent Via header field values may indicate hosts in the same administrative domain as the client. No Via stripping is required when handling responses.
リクエストに応じて動作するプライバシーサービスは、プライバシーサービスに到着する前にリクエストに追加されたヘッダーを介してすべてを削除する必要があります（「ストリッピング経由」と呼ばれるプラクティス）。その後、自分自身を表すヘッダー経由でシングルを追加する必要があります。リクエストのヘッダーフィールド値を介してBottommostには、元のクライアントを指定するIPアドレスまたはホスト名が含まれており、その後のヘッダーフィールド値を介してクライアントと同じ管理ドメインのホストを示す場合があることに注意してください。応答を処理するときは、ストリッピングを介して必要ありません。
Contact headers are added by user agents to both requests and responses. A privacy service SHOULD replace the value of the Contact header in a message with a URI that does not dereference to the originator of the message (such as the anonymous URI described in Section 4.1.1.3). The URI that replaces the existing Contact header field value MUST dereference to the privacy service.
連絡先ヘッダーは、ユーザーエージェントによってリクエストと応答の両方に追加されます。プライバシーサービスは、メッセージの接触ヘッダーの値を、メッセージの発信者に抑制しないURIに置き換える必要があります（セクション4.1.1.3で説明した匿名URIなど）。既存の連絡先ヘッダーフィールド値を置き換えるURIは、プライバシーサービスに逆に逆行する必要があります。
In a manner similar to Via stripping, a privacy service SHOULD also strip any Record-Route headers that have been added to a request before it reaches the privacy service - though note that no such headers will be present if there is only one hop between the originating user agent and the privacy service, as is recommended above. Such Record-Route headers might also divulge information about the administrative domain of the client.
ストリッピング経由と同様の方法で、プライバシーサービスは、プライバシーサービスに到達する前にリクエストに追加されたレコードルートヘッダーを削除する必要があります。上記の推奨されるように、元のユーザーエージェントとプライバシーサービス。このようなレコードルートヘッダーは、クライアントの管理ドメインに関する情報を明らかにする可能性があります。
For the purposes of this document, it is assumed that the privacy service has locally persisted the values of any of the above headers that are so removed, which requires the privacy service to keep a pretty significant amount of state on a per-dialog basis. When further requests or responses associated with the dialog reach the privacy service, it MUST restore values for the Via, Record- Route/Route or Contact headers that it has previously removed in the interests of privacy. There may be alternative ways (outside the scope of this document) to perform this function that do not require keeping state in the privacy service (usually means that involve encrypting and persisting the values in the signaling somehow).
このドキュメントの目的のために、プライバシーサービスは、そのように削除された上記のヘッダーのいずれかの値を局所的に維持していると想定されており、プライバシーサービスはかなりの量の状態を一人ごとに維持する必要があります。ダイアログに関連付けられたさらなる要求または応答がプライバシーサービスに到達する場合、プライバシーのために以前に削除したVIA、レコードルート/ルート、または連絡先ヘッダーの値を復元する必要があります。プライバシーサービスに状態を維持する必要がないこの関数を実行するための代替方法（このドキュメントの範囲外）がある場合があります（通常、何らかの形で信号の値を暗号化して持続することを意味します）。
The following procedures are RECOMMENDED for handling the Record-Route header field of requests and responses, which provides specialchallenges to a privacy service:
リクエストと応答のレコードルートヘッダーフィールドを処理するには、以下の手順を推奨します。
When a privacy service is processing (on behalf of the originator) a request that contains one or more Record-Route header field values, the privacy service must strip these values from the request and remember both the dialog identifiers and the ordered Record-Route header field values. As described above, it must also replace the Contact header field with a URI indicating itself. When a response with the same dialog identifiers arrives at the privacy service, the privacy service must reapply any Record-Route header field values to the response in the same order, and it must then add a URI representing itself to the Record-Route header field of the response. If the response contains Record-Route header field values of its own, these must also be included (in order) in the Record-Route header field after the URI representing the privacy service.
プライバシーサービスが（オリジネーターに代わって）1つ以上のレコードルートヘッダーフィールド値を含むリクエストを処理している場合、プライバシーサービスはリクエストからこれらの値を削除し、ダイアログ識別子と順序付けられたレコードルートヘッダーの両方を覚えておく必要があります。フィールド値。上記のように、コンタクトヘッダーフィールドを自分自身を示すURIに置き換える必要があります。同じダイアログ識別子を使用した応答がプライバシーサービスに到着する場合、プライバシーサービスはレコードルートヘッダーフィールド値を同じ順序で応答に再適用する必要があり、その後、レコードルートヘッダーフィールドにそれ自体を表すURIを追加する必要があります応答の。応答に独自のレコードルートヘッダーフィールド値が含まれている場合、URIがプライバシーサービスを表す後、レコードルートヘッダーフィールドに（順番に）含める必要があります。
Note that when a privacy service is handling a request and providing privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated. This document recommends no way of statefully restoring those headers if they are stripped.
プライバシーサービスがリクエストを処理し、リクエストの宛先に代わってプライバシーを提供している場合、プライバシーサービスの下流のレコードルートヘッダーのプライバシーを提供することは非常に複雑であることに注意してください。このドキュメントでは、これらのヘッダーが剥がされた場合、それらのヘッダーを状態に復元する方法がないことを推奨しています。
If a privacy level of 'session' is requested, then the user has requested that the privacy service anonymize the session traffic (e.g., for SIP telephony calls, the audio media) associated with this dialog.
「セッション」のプライバシーレベルが要求されている場合、ユーザーは、このダイアログに関連付けられているプライバシーサービス（たとえば、SIPテレフォニーコール、オーディオメディアなど）を匿名化するように要求しました。
The SIP specification dictates that intermediaries such as proxy servers cannot inspect and modify message bodies. The privacy service logical role MUST therefore act as a back-to-back user agent in order to provide media privacy, effectively terminating and re-originating the messages that initiate a session (although in support of session privacy the privacy service does not need to alter headers characterizing the originator or destination when the request is re-originated). In order to introduce an anonymizer for session traffic, the privacy service needs to control a middlebox [8] that can provide an apparent source and sink for session traffic. The details of the implementation of an anonymizer, and the modifications that must be made to the Session Description Protocol (SDP [5]) bodies in the messages that initiate a session are outside the scope of this document.
SIP仕様は、プロキシサーバーなどの仲介者がメッセージ本文を検査および変更できないことを決定します。したがって、プライバシーサービスの論理的役割は、メディアプライバシーを提供し、セッションを開始するメッセージを効果的に終了および再起動するために、連続したユーザーエージェントとして機能する必要があります（ただし、セッションプライバシーをサポートするためにプライバシーサービスは必要ありません。リクエストが再起動されたときに発信者または宛先を特徴付けるヘッダーを変更します）。セッショントラフィックのために匿名化機を導入するには、プライバシーサービスは、セッショントラフィックに見かけのソースとシンクを提供できるミドルボックス[8]を制御する必要があります。匿名の実装の詳細、およびセッションを開始するメッセージのセッション説明プロトコル（SDP [5]）ボディに行わなければならない変更は、このドキュメントの範囲外です。
The risk, of course, of using such an anonymizer is that the anonymizer itself is party to your communications. For that reason, requesting session-level privacy without resort to some sort of end-to-end security for the session traffic (with RTP [6] media, for example, SRTP [4]) is NOT RECOMMENDED.
もちろん、そのような匿名化機を使用するリスクは、匿名者自体があなたのコミュニケーションの当事者であるということです。そのため、セッショントラフィックのために何らかのエンドツーエンドのセキュリティに頼らずにセッションレベルのプライバシーを要求する（たとえば、RTP [6]メディア、SRTP [4]）は推奨されません。
If a privacy level of 'user' is requested, then the originating user has requested that privacy services perform the user-level privacy functions described in Section 4.1.
「ユーザー」のプライバシーレベルが要求されている場合、発信元のユーザーは、プライバシーサービスがセクション4.1で説明されているユーザーレベルのプライバシー関数を実行することを要求しました。
Note that the privacy service MUST remove any non-essential informational headers that have been added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To.
プライバシーサービスは、サブジェクト、Call-INFO、組織、ユーザーエージェント、返信、およびリップリーなど、ユーザーエージェントによって追加された非必須情報ヘッダーを削除する必要があることに注意してください。
Significantly, user-level privacy could entail the modification of the From header, changing it from its original value to an anonymous value. Prior to the current issue of the SIP specification, the modification of the values of the To and From headers by intermediaries was not permitted, and would result in improper dialog matching by the endpoints. Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response.
重要なことに、ユーザーレベルのプライバシーは、From Headerの変更を伴い、元の値から匿名値に変更する可能性があります。SIP仕様の現在の問題に先立ち、仲介者によるヘッダーからの値の値の変更は許可されておらず、エンドポイントによる不適切なダイアログマッチングが行われます。現在、ダイアログマッチングは、ヘッダー全体ではなく、ヘッダーからのタグのみを使用しています。したがって、新しい規則の下では、ヘッダー自体のURI値が仲介者によって変更される可能性があります。ただし、一部のレガシークライアントは、リクエストと応答の間に変更されたFROMヘッダーのURIの値がエラー条件と考える場合があります。
Also, performing user-level privacy functions MAY entail the modification of the Call-ID header, since the Call-ID commonly contains a hostname or IP address corresponding to the originating client. This field is essential to dialog matching, and it cannot be altered by intermediaries.
また、Call-IDには一般に、発信元クライアントに対応するホスト名またはIPアドレスが含まれているため、ユーザーレベルのプライバシー関数を実行するには、Call-IDヘッダーの変更が必要になる場合があります。このフィールドは一致するためには不可欠であり、仲介者が変更することはできません。
Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent.
したがって、プライバシーサービスがプライバシー上の理由でダイアログマッチングヘッダーを変更する必要がある場合は、透明な連続したユーザーエージェントとして機能する必要があり、ダイアログマッチングヘッダーの以前の値を維持する必要があります。これらの値は、元のユーザーエージェントに送信されるメッセージで復元する必要があります。
Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the very personal information that the user has asked the privacy service to obscure.
プライバシーを要求するメッセージには、機密性と整合性が必要です。整合性がなければ、要求されたプライバシー関数を格下げまたは排除し、ID情報を公開する可能性があります。機密性がなければ、ネットワーク上の盗聴者（またはユーザーとプライバシーサービスの間の仲介者）は、ユーザーがプライバシーサービスに不明瞭に求めた非常に個人情報を見ることができました。
All of the network-provided privacy functions in this document entail a good deal of trust for the privacy service. Users should only trust privacy services that are somehow accountable to them.
このドキュメントのネットワークが提供するプライバシー機能はすべて、プライバシーサービスにとって大きな信頼を伴います。ユーザーは、何らかの形で説明責任のあるプライバシーサービスのみを信頼する必要があります。
Operators of privacy services should be aware that in the eyes of downstream entities, a privacy service will be the only source to which anonymous messages can be traced.
プライバシーサービスのオペレーターは、ダウンストリームエンティティの目では、プライバシーサービスが匿名のメッセージをトレースできる唯一のソースになることに注意する必要があります。
Note that authentication mechanisms, including the Digest authentication method described in the SIP specification, are outside the scope of the privacy considerations in this document. Revealing identity through authentication is highly selective, and may not result in the compromise of any private information. Obviously, users that do not wish to reveal their identity to servers that issue authentication challenges MAY elect not to respond to such challenges.
SIP仕様に記載されているダイジェスト認証方法を含む認証メカニズムは、このドキュメントのプライバシーに関する考慮事項の範囲外であることに注意してください。認証を通じてアイデンティティを明らかにすることは非常に選択的であり、個人情報の妥協をもたらさない可能性があります。明らかに、認証の課題を発行することがそのような課題に応答しないことを選択するかもしれないサーバーに自分の身元を明らかにしたくないユーザー。
This document defines a new SIP header field called "Privacy" that allows a user agent to request a certain degree of privacy for a message. This behavior associated with this header is specified in Section 4.2. This header has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントでは、ユーザーエージェントがメッセージのある程度のプライバシーを要求できる「プライバシー」と呼ばれる新しいSIPヘッダーフィールドを定義します。このヘッダーに関連付けられたこの動作は、セクション4.2で指定されています。このヘッダーは、http：//www.iana.org/assignments/sip-parametersに基づいてヘッダーサブレジストリに追加されました。
Header name: Privacy Compact form: none defined
ヘッダー名：プライバシーコンパクトフォーム：なし定義なし
This document also creates an IANA registry for values that populate the Privacy header. This registry should be indexed by priv-value tokens and should contain a short semantic description of the new value. The current values of the "Privacy" header are as follows:
このドキュメントでは、プライバシーヘッダーを埋める価値のIANAレジストリも作成します。このレジストリは、PRIV値トークンによってインデックス付けされる必要があり、新しい値の短いセマンティックな説明を含める必要があります。「プライバシー」ヘッダーの現在の値は次のとおりです。
o user: Request that privacy services provide a user-level privacy function
o ユーザー：プライバシーサービスがユーザーレベルのプライバシー機能を提供することを要求します
o header: Request that privacy services modify headers that cannot be set arbitrarily by the user (Contact/Via).
o ヘッダー：ユーザーがarbitrarily意的に設定できないヘッダー（連絡先/via）を変更するように要求します。
o session: Request that privacy services provide privacy for session media
o セッション：プライバシーサービスがセッションメディアにプライバシーを提供することを要求します
o none: Privacy services must not perform any privacy function
o なし：プライバシーサービスはプライバシー機能を実行してはなりません
o critical: Privacy service must perform the specified services or fail the request
o クリティカル：プライバシーサービスは、指定されたサービスを実行するか、リクエストに失敗する必要があります
New values for the "Privacy" header can only be defined by IETF Consensus including RFC publication (RFC 2434). IANA registration for the "Privacy" header field values is required along with the RFC publication.
「プライバシー」ヘッダーの新しい値は、RFC Publication（RFC 2434）を含むIETFコンセンサスによってのみ定義できます。「プライバシー」ヘッダーフィールド値のIANA登録は、RFCの出版物とともに必要です。
Authors of extensions to the SIP protocol that expose personal information about the participants in sessions are advised against extending the "Privacy" header - rather, it is preferable to create new identity mechanisms whose privacy can be managed by the user agent without the agency of intermediaries.
セッションの参加者に関する個人情報を公開するSIPプロトコルへの拡張の著者は、「プライバシー」ヘッダーを拡張することに対してアドバイスされます。むしろ、中間の機関なしでユーザーエージェントがプライバシーを管理できる新しいアイデンティティメカニズムを作成することが望ましい。
This document also defines a new SIP option-tag, 'privacy', that represents support for the extension defined in this document.
このドキュメントでは、このドキュメントで定義されている拡張機能のサポートを表す新しいSIPオプションタグ「プライバシー」も定義しています。
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] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999.
[3] Eastlake、D。and A. Panitz、「予約済みのトップレベルDNS名」、RFC 2606、1999年6月。
Informative References
参考引用
[4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E., Naslund, M. and K. Normann, "The Secure Real Time Transport Protocol", Work in Progress.
[4] Baugher、M.、McGrew、D.、Oran、D.、Blom、R.、Carrara、E.、Naslund、M。、およびK. Normann、「The Secure Realtime Transport Protocol」、進行中の作業。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne、H.、Casner、S.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress
[7] Lennox、J。およびH. Schulzrinne、「CPL：インターネットテレフォニーサービスのユーザー制御のための言語」、進行中の作業
[8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[8] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
Author's Address
著者の連絡先
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Acknowledgments
謝辞
The author would like to thank Allison Mankin, Rohan Mahy, Eric Rescorla, Mark Watson, Cullen Jennings, Robert Sparks, Jonathan Rosenberg, Ben Campbell, Tom Gray and John Elwell for their comments.
著者は、アリソン・マンキン、ローハン・マヒー、エリック・レスコルラ、マーク・ワトソン、カレン・ジェニングス、ロバート・スパークス、ジョナサン・ローゼンバーグ、ベン・キャンベル、トム・グレイ、ジョン・エルウェルにコメントをしたいと思います。
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エディター機能の資金は現在、インターネット協会によって提供されています。