Network Working Group M. Watson
Request for Comments: 3324 Nortel Networks
Category: Informational November 2002
Short Term Requirements for Network Asserted Identity
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks.
ネットワークアイデンティティは、最初に、認証プロセスの結果として、セッション開始プロトコル（SIP）ネットワーク中継によって導出同一であるアサート。この文書では、ネットワークの交換のための短期要件がしっかりと相互接続された、信頼できるノードのネットワーク内で、しっかりとこのようなネットワークに接続されたユーザエージェントにアイデンティティをアサートについて説明します。
There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias.
ユーザーの希望エイリアス以外のものであることをSIPメッセージにUAによってアサートアイデンティティのための要件はありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Network Asserted Identity . . . . . . . . . . . . . . . . . . 3
2.3 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Generation of Networks Asserted Identity . . . . . . . . . . . 7
4. Transport of Network Asserted Identity . . . . . . . . . . . . 7
4.1 Sending of Networks Asserted Identity within a Trust Domain . 7
4.2 Receiving of Network Asserted Identity within a Trust Domain . 7
4.3 Sending of Network Asserted Identity to entities outside a
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Receiving of Network Asserted Identity by a node outside the
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Parties with Network Asserted Identities . . . . . . . . . . . 8
6. Types of Network Asserted Identity . . . . . . . . . . . . . . 8
7. Privacy of Network Asserted Identity . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
SIP [1] allows users to assert their identity in a number of ways e.g., using the From: header. However, there is no requirement for these identities to be anything other than the users desired alias.
ヘッダ：SIPは、[1]からを使用して、ユーザは、例えば、いくつかの方法で自分のアイデンティティをアサートすることを可能にします。しかし、これらのIDは、ユーザーが希望別名以外であるためには必要はありません。
An authenticated identity of a user can be obtained using SIP Digest Authentication (or by other means). However, UAs do not always have the necessary key information to authenticate another UA.
ユーザの認証識別（または、他の手段によって）SIPダイジェスト認証を使用して得ることができます。しかし、UAは常に別のUAを認証するために必要な重要な情報を持っていません。
A Network Asserted Identity is an identity initially derived by a SIP network intermediary as a result of an authentication process. This may or may not be based on SIP Digest authentication. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and also to User Agents with secure connections to such networks.
ネットワークアイデンティティは、最初に、認証プロセスの結果として、SIPネットワーク仲介によって導出同一であるアサート。これは、またはSIPダイジェスト認証に基づいていてもいなくてもよいです。この文書では、ネットワークの交換のための短期要件がしっかりと相互接続された信頼できるノードのネットワーク内のアイデンティティをアサートしても、そのようなネットワークへの安全な接続を持つユーザエージェントに説明します。
Such a network is described in this document as a Trust Domain and we present a strict definition of trust and Trust Domain for the purposes of this document. These short-term requirements provide only for the exchange of Network Asserted Identity within a Trust Domain and to an entity directly connected to the trust domain.
このようなネットワークは、信頼ドメインとして、この文書に記載されており、私たちは、このドキュメントの目的のために信頼と信頼ドメインの厳密な定義を提示します。これらの短期的な要件は、ネットワークの交換が信頼ドメイン内および直接信頼ドメインに接続されているエンティティにアイデンティティをアサートのみを提供します。
General requirements for transport of Network Asserted Identities on the Internet are out of scope of this document.
ネットワークの輸送のための一般的な要件は、インターネット上のアイデンティティは、この文書の範囲外であるアサートされます。
An Identity, for the purposes of this document, is a sip:, sips: or tel: URI, and optionally a Display Name.
またはTEL：URI、および必要に応じて表示名アイデンティティは、このドキュメントの目的のために、すする:,一口です。
The URI MUST be meaningful to the domain identified in the URI (in the case of sip: or sips: URIs) or the owner of the E.164 number (in the case of tel: URIs), in the sense that when used as a SIP Request-URI in a request sent to that domain/number range owner, it would cause the request to be routed to the user/line that is associated with the identity, or to be processed by service logic running on that user's behalf.
使用されるという意味で、（：またはSIPS：URIのSIPの場合）または（URIのTELの場合）E.164番号の所有者URIは、URIで識別されたドメインに有意義でなければなりませんそのドメイン/番号範囲所有者に送信された要求におけるSIP Request-URIが、それは要求がIDに関連付けられている、またはそのユーザーの代わりに実行されているサービス・ロジックによって処理されるように、ユーザ/回線にルーティングする原因となります。
If the URI is a sip: or sips: URI, then depending on the local policy of the domain identified in the URI, the URI MAY identify some specific entity, such as a person.
URIがSIPの場合：またはすする：URIは、その後、URIで特定されたドメインのローカルポリシーに応じて、URIは、そのような人として、いくつかの特定のエンティティを識別することができます。
If the URI is a tel: URI, then depending on the local policy of the owner of the number range within which the telephone number lies, the number MAY identify some specific entity, such as a telephone line. However, it should be noted that identifying the owner of the number range is a less straightforward process than identifying the domain which owns a sip: or sips: URI.
URIは、電話である場合：URIは、電話番号があるその内部番号範囲の所有者のローカルポリシーに応じて、番号は、電話線などのいくつかの特定のエンティティを識別することができます。またはすする：URIしかし、数値範囲の所有者を識別することは、SIPを所有しているドメインを識別未満単純なプロセスであることに留意すべきです。
A Network Asserted Identity is an identity derived by a SIP network entity as a result of an authentication process, which identifies the authenticated entity in the sense defined in Section 2.1.
ネットワークアイデンティティは、セクション2.1で定義された意味で認証されたエンティティを識別し、認証プロセスの結果としてSIPネットワークエンティティによって導出同一であるアサート。
In the case of a sip: or sips: URI, the domain included in the URI MUST be within the Trust Domain.
または一口：SIPの場合にはURI、URIに含まれるドメインは、信頼ドメイン内になければなりません。
In the case of a tel: URI, the owner of the E.164 number in the URI MUST be within the Trust Domain.
TELの場合：URI、URIにE.164番号の所有者は、信頼ドメイン内になければなりません。
The authentication process used, or at least it's reliability/ strength, is a known feature of the Trust Domain using the Network Asserted Identity mechanism i.e., in the language of 2.3 below, it is defined in Spec(T).
使用、又は少なくともそれが信頼性/強度の認証プロセスは、すなわち、アイデンティティ機構をアサートネットワークを用いた信頼ドメインの既知の特徴であり、以下2.3の言語においては、仕様（T）で定義されています。
A Trust Domain for the purposes of Network Asserted Identity is a set of SIP nodes (UAC, UAS, proxies or other network intermediaries) that are trusted to exchange Network Asserted Identity information in the sense described below.
ネットワークの目的のための信頼ドメインアイデンティティがSIPノードの集合であるアサート（UACは、UASは、プロキシまたは他のネットワーク仲介）ネットワークを交換するために信頼され、以下に記載の意味でのアイデンティティ情報をアサート。
A node can be a member of a Trust Domain, T, only if the node is know to be compliant to a certain set of specifications, Spec(T), which characterize the handling of Network Asserted Identity within the Trust Domain, T.
ノードは、ノードが仕様の特定のセットに対応することを知っている場合にのみ、信頼ドメイン、Tのメンバーになることができ、ネットワークの取り扱いを特徴付ける仕様（T）は、信頼ドメイン、T.内のアイデンティティをアサート
Trust Domains are constructed by human beings who know the properties of the equipment they are using/deploying. In the simplest case, a Trust Domain is a set of devices with a single owner/operator who can accurately know the behaviour of those devices.
トラストドメインは、それらが/展開を使用している機器の性質を知っている人間によって構築されています。最も単純なケースでは、信頼ドメインは正確にそれらのデバイスの振る舞いを知ることができ、単一の所有者/オペレータとデバイスのセットです。
Such simple Trust Domains may be joined into larger Trust Domains by bi-lateral agreements between the owners/operators of the devices.
このような単純な信頼ドメインは、デバイスの所有者/オペレータとの間の双方向の横方向の合意によって、より大きな信頼ドメインに結合することができます。
We say a node is 'trusted' (with respect to a given Trust Domain) if and only if it is a member of that domain.
私たちは、ノードがあれば（与えられた信頼ドメインに関して）「信頼」と、それはそのドメインのメンバーである場合にのみされると言います。
We say that a node, A, in the domain is 'trusted by' a node, B, (or 'B trusts A') if and only if:
私たちは、ドメイン内のノード、Aは、ノード「で信頼できる」されていることを言って、B、（または「B信託のA」）の場合に限り：
2. B has configuration information indicating that A is a member of the Trust Domain.
2. Bは、Aが信頼ドメインのメンバーであることを示す設定情報を有しています。
Note that B may or may not be a member of the Trust Domain. For example, B may be a UA which trusts a given network intermediary, A (e.g., its home proxy).
Bは、またはではないかもしれない信頼ドメインのメンバーであってもよいことに留意されたいです。例えば、Bは、所与のネットワーク中継を信頼UA、A（例えば、そのホームプロキシ）であってもよいです。
A 'secure connection' in this context means that messages cannot be read by third parties, cannot be modified by third parties without detection and that B can be sure that the message really did come from A. The level of security required is a feature of the Trust Domain i.e., it is defined in Spec(T).
この文脈での「安全な接続」は、メッセージが第三者によって読み取ることができないことを意味し、検出することなく、第三者によって変更することができず、そのBは本当にA.から必要なセキュリティのレベルを来たメッセージはの機能であることを確認することができます信頼ドメインすなわち、それは、スペック（T）で定義されています。
Within this context, SIP signaling information received by one node FROM a node that it trusts is known to have been generated and passed through the network according to the procedures of the particular specification set Spec(T), and therefore can be known to be valid, or at least as valid as specified in the specifications Spec(T).
この文脈の中で、SIPシグナリング情報は、それが仕様（T）を設定し、特定の仕様の手順に従って生成され、ネットワークを介して渡されていることが知られている信頼し、したがって有効であると知ることができるノードから一つのノードによって受信されます仕様仕様（T）で指定されるように、または少なくとも有効な。
Equally, a node can be sure that signaling information passed TO a node that it trusts will be handled according to the procedures of Spec(T).
同様に、ノードは、それが信頼ノードに渡されるシグナリング情報は、仕様（T）の手順に従って処理されることを確認することができます。
For these capabilities to be useful, Spec(T) must contain requirements as to how the Network Asserted Identity is generated, how its privacy is protected and how its integrity is maintained as it is passed around the network. A reader of Spec(T) can then make an informed judgement about the authenticity and reliability of Network Asserted Information received from the Trust Domain T.
これらの機能が有用であるためには、スペック（T）は、ネットワークアイデンティティは、それがネットワークの周りに渡されるように、その整合性が維持されているか、そのプライバシーが保護されており、どのように、生成されたアサート方法としての要件を含んでいなければなりません。その後、真正性とネットワークの信頼性について知らさ判断を下すことができスペック（T）の読者は情報の信頼ドメインT.から受信したアサート
The term 'trusted' (with respect to a given Trust Domain) can be applied to a given node in an absolute sense - it is just equivalent to saying the node is a member of the Trust Domain. However, the node itself does not know whether another arbitrary node is 'trusted', even within the Trust Domain. It does know about certain nodes with which it has secure connections as described above.
（与えられた信頼ドメインに関して）「信頼された」という用語は、絶対的な意味で与えられたノードに適用することができる - それはノードが信頼ドメインのメンバーであると言っにちょうど相当します。しかし、ノード自体は、他の任意のノードでも信頼ドメイン内では、「信頼」されているかどうか分かりません。これは、前述したように、それは安全な接続を持っていると、特定のノードについて知っているん。
With the definition above, statements such as 'A trusted node SHALL ...' are just shorthand for 'A node compliant to this specification SHALL...'.
上記の定義では、のような声明「信頼ノードが...（SHALL）」「この仕様に準拠するノードSHALL ...」のためだけの速記です。
Statements such as 'When a node receives information from a trusted node...' are NOT valid, because one node does not have complete knowledge about all the other nodes in the trust domain.
一方のノードが信頼ドメイン内の他のすべてのノードについての完全な知識を持っていないためのようなステートメント「ノードが信頼ノードからの情報を受信した場合は...」、有効ではありません。
Statements such as 'When a node receives information from another node that it trusts...' ARE valid, and should be interpreted according to the criteria (1) and (2) above.
などの文有効であり、基準（1）及び（2）上記に従って解釈されるべきである「場合、ノードは、それが信頼する別のノードから情報を受信します...」。
The above relationships are illustrated in the following figure:
上記の関係を次の図に示されています。
+------+
| |
| F |
| |
+------+
x
..............................x.........
. x .
. +------+ +------+ . +------+
. | | | | . | |
. | A | | B |-----.----| E |
. | | | | . | |
. +------+ +------+ . +------+
. \\ / .
. \\ +------+ // .
. \\ | | // .
. \ | C |/ .
. | | .
. +------+ .
. | Trust Domain.
........................................
|
|
+------+
| |
| D |
| |
+------+
xxxxxx Insecure connection
------ Secure connection
...... . .All boxes within the dotted line ......are part of the same Trust Domain
......。点線内の。すべてのボックスは......同じ信頼ドメインの一部であります
o A, B and C are part of the same trust domain
O A、BおよびCは、同じ信頼ドメインの一部であります
o A trusts C, but A does not trust B
Cが、AがBを信頼していない信託O
o since E knows that B is inside of the trust domain, E
O EはE、Bは、信頼ドメインの内部にあることを知っているので、
o trusts B, but B does not trust E
O Bを信頼しますが、BはEを信頼していません
o B does not trust F, F does not trust B
O Bは、F、FがBを信頼していない信頼していません
An aspect of the definition of a trust domain is that all the elements in that domain are compliant to a set of configurations and specifications generally referred to as Spec(T). Spec(T) is not a specification in the sense of a written document; rather, its an agreed upon set of information that all elements are aware of. Proper processing of the asserted identities requires that the elements know what is actually being asserted, how it was determined, and what the privacy policies are. All of that information is characterized by Spec(T).
信頼ドメインの定義の態様は、そのドメイン内のすべての要素は、一般仕様（T）と呼ばれる構成及び仕様のセットに準拠していることです。スペック（T）は、書かれた文書の意味での仕様ではありません。むしろ、そのANは、すべての要素が認識されている情報のセットに合意しました。アサートアイデンティティの適切な処理は、それが決定されたか、要素が実際にアサートされているかを知ることが必要、とどのようなプライバシーポリシーがあります。この情報の全ては、スペック（T）によって特徴付けられます。
A Network Asserted Identity is generated by a network intermediary following an Authentication process which authenticates the entity (UA) to be identified.
ネットワークアイデンティティ（UA）が識別されるエンティティを認証する認証処理を次のネットワーク仲介によって生成されるアサート。
The Authentication process(es) used are a characteristic feature of the Trust Domain, and MUST be specified in Spec(T).
使用される認証プロセス（ES）は、信頼ドメインの特徴であり、仕様（T）で指定する必要があります。
It shall be possible for a UA to provide a preferred identity to the network intermediary, which MAY be used to inform the generation of the Network Asserted Identity according to the policies of the Trust Domain.
UAは、信頼ドメインのポリシーに従ってネットワークアサート・アイデンティティの生成を通知するために使用されるかもしれネットワーク中継に優先アイデンティティを提供することが可能でなければなりません。
It shall be possible for one node within a Trust Domain to securely send a Network Asserted Identity to another node that it trusts.
信頼ドメイン内の一つのノードがしっかりとそれが信頼別のノードにアイデンティティをアサートネットワークを送信することが可能でなければなりません。
It shall be possible for one node within a Trust Domain to receive a Network Asserted identity from another node that it trusts.
信頼ドメイン内の1つのノードはそれが信頼他のノードからネットワークアサートアイデンティティを受信することが可能でなければなりません。
4.3 Sending of Network Asserted Identity to entities outside a Trust Domain
4.3ネットワークの送信信頼ドメイン外のエンティティにアイデンティティをアサート
If a node, A, within the Trust Domain, is trusted by a node, B, outside the Trust Domain, then it shall be possible for A to securely send a Network Asserted Identity to B, if allowed by the privacy policies of the user that has been identified, and the trust domain.
ノードは、Aは、信頼ドメイン内、信頼ドメイン外のノード、B、から信頼されている場合はしっかりとユーザーのプライバシーポリシーで許可されていれば、ネットワークは、Bにアイデンティティをアサート送信するために、それができなければなりませんそれが識別され、信頼ドメインされています。
This is most often used to pass a Network Asserted Identity directly to a UA.
これは、ほとんどの場合、UAに直接アイデンティティをアサートネットワークを渡すために使用されます。
4.4 Receiving of Network Asserted Identity by a node outside the Trust Domain
ネットワークの4.4受信手段信頼ドメイン外のノードでアイデンティティをアサート
It shall be possible for a node outside the Trust Domain to receive a Network Asserted Identity from a node that it trusts.
信頼ドメイン外のノードは、それが信頼するノードからのアイデンティティをアサートネットワークを受信することが可能でなければなりません。
Network Asserted Identity received in this way may be considered valid, and used for display to the user, input data for services etc.
サービスなどのためのアサート・アイデンティティは、このように、受信したネットワークが有効とみなされ、ユーザに表示するために使用することができる、入力データ
Network Asserted Identity information received by one node from a node which it does not trust carries no guarantee of authenticity or integrity because it is not known that the procedures of Spec(T) were followed to generate and transport the information. Such information MUST NOT be used. (i.e., it shall not be displayed to the user, passed to other nodes, used as input data for services, etc.)
ネットワークは、仕様（T）の手順は、生成した情報を搬送するために続いたことが知られていないので、それは信頼が真正又は完全性の保証を保有しませんノードから一つのノードによって受信された識別情報をアサート。このような情報を使用してはいけません。 （すなわち、それが等サービスのための入力データとして使用される、他のノードに渡され、ユーザに表示されるものではありません）
A Network Asserted Identity identifies the originator of the message in which it was received.
ネットワークアイデンティティは、それが受信されたメッセージの発信元を識別するアサート。
For example,
例えば、
a Network Asserted Identity received in an initial INVITE (outside the context of any existing dialog) identifies the calling party.
ネットワークアイデンティティは、初期に受信アサート（任意の既存のダイアログのコンテキスト外）INVITE発信者を特定します。
a Network Asserted Identity received in a 180 Ringing response to such an INVITE identifies the party who is ringing.
ネットワークは、INVITEへの180リンギング応答でアイデンティティを受信アサート鳴っているパーティを特定します。
a Network Asserted Identity received in a 200 response to such an INVITE identifies the party who has answered.
ネットワークは、INVITEに対する200応答のIDが受信アサート答えたパーティーを識別します。
It shall be possible to assert multiple identities associated with a given party (in a given message), provided that these are of distinct types.
これは、（与えられたメッセージに）指定された当事者に関連付けられた複数のアイデンティティをアサートすることが可能でなければならない、これらは異なるタイプであることを条件とします。
The types of identity supported shall be sip:, sips: and tel: URIs, all of which identify the user as described in Section 2.1. It is not required to transport both a sip: and sips: URI.
そしてTEL：2.1節で説明したように、ユーザを識別すべてがURIを、サポートされている同一のタイプでは、SIP :, SIPなければなりません。 SIPの両方を輸送する必要はありません：とすする：URI。
It shall be possible for the capability to transport additional types of identity associated with a single party to be introduced in future.
機能は、将来的に導入される単一のパーティに関連付けられているアイデンティティの追加タイプを輸送することが可能でなければなりません。
The means by which any privacy requirements in respect of the Network Asserted Identity are determined are outside the scope of this document.
ネットワークの点で任意のプライバシー要件が決定されているアイデンティティをアサートする手段は、この文書の範囲外です。
It shall be possible to indicate within a message containing a Network Asserted Identity that this Network Asserted Identity is subject to a privacy requirement which prevents it being passed to other users. This indication should not carry any semantics as to the reason for this privacy requirement.
ネットワークを含むメッセージの中に示すことが可能でなければならない。このネットワークは、アイデンティティは、それが他のユーザーに渡されるのを防ぎ、プライバシーの要件の対象であることをアサートアイデンティティをアサートされます。この指示は、このプライバシー要件の理由についてどのような意味を運ぶべきではありません。
It shall be possible to indicate that the user has requested that the Network Asserted Identity be not passed to other users. This is distinct from the above indication, in that it implies specific user intent with respect to the Network Asserted Identity.
ユーザーがネットワークアイデンティティを他のユーザーに渡されないことがアサートされていることを要求したことを示すことが可能でなければなりません。それはアイデンティティをアサートネットワークに対する特定のユーザの意図を暗示するという点で、これは、上記の表示とは区別されます。
The mechanism shall support Trust Domain policies where the above two indications are equivalent (i.e., the only possible reason for a privacy requirement is a request from the user), and policies where they are not.
機構は、信頼ドメイン上記の二つの指標が同等であるポリシー（すなわち、プライバシー要件のための唯一の可能な理由は、ユーザからの要求である）、そしてそうでないポリシーをサポートしなければなりません。
In this case, the Network Asserted Identity specification shall require that the mechanism of Section 4.3 SHALL NOT be used i.e., a trusted node shall not pass the identity to a node it does not trust. However, the mechanism of Section 4.3 MAY be used to transfer the identity within the trusted network.
この場合、ネットワークは、Identity仕様はすなわち、信頼できるノードはそれが信頼していないノードにIDを渡してはならない、セクション4.3のメカニズムを使用してはならないことを要求しなければならないアサートされます。しかし、4.3節のメカニズムは、信頼できるネットワーク内のアイデンティティを転送するために使用されるかもしれません。
Note that 'anonymity' requests from users or subscribers may well require functionality in addition to the above handling of Network Asserted Identities. Such additional functionality is out of the scope of this document.
ユーザまたは加入者からの「匿名性の要求がうまくネットワークの上の取扱いアイデンティティをアサートに加えて、機能性を必要とするかもしれないことに注意してください。このような追加機能は、この文書の範囲外です。
The requirements in this document are NOT intended to result in a mechanism with general applicability between arbitrary hosts on the Internet.
この文書に記載されている要件は、インターネット上の任意のホスト間の一般的な適用とメカニズムをもたらすことが意図されていません。
Rather, the intention is to state requirements for a mechanism to be used within a community of devices which are known to obey the specification of the mechanism (Spec(T)) and between which there are secure connections. Such a community is known here as a Trust Domain.
機構は、機構（仕様（T））の仕様に従うことが知られているデバイスのコミュニティ内で使用され、それらの間の安全な接続があることするためむしろ、その意図は、状態の要件です。このようなコミュニティは、信頼ドメインとしてここに知られています。
The requirements on the mechanisms used for security and to initially derive the Network Asserted Identity must be part of the specification Spec(T).
メカニズム上の要件は、セキュリティのために使用され、最初にネットワークアイデンティティは、仕様のスペック（T）の一部でなければなりませんアサート導出します。
The requirements also support the transfer of information from a node within the Trust Domain, via a secure connection to a node outside the Trust Domain.
要件も信頼ドメイン外のノードへの安全な接続を介して、信頼ドメイン内のノードからの情報の転送をサポートします。
Use of this mechanism in any other context has serious security shortcomings, namely that there is absolutely no guarantee that the information has not been modified, or was even correct in the first place.
他の文脈でこのメカニズムを使用すると、情報が変更され、または最初の場所でも、正しいされていないという保証は絶対にありませんつまりこと、深刻なセキュリティ上の欠点があります。
This document does not have any implications for IANA.
このドキュメントは、IANAのためのどんな意味を持っていません。
Thanks are due to Jon Peterson, Cullen Jennings, Allison Mankin and Jonathan Rosenberg for comments on this document.
おかげでこの文書に関するコメントをジョン・ピーターソン、カレン・ジェニングス、アリソンマンキンとジョナサンローゼンバーグによるものです。
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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
Author's Address
著者のアドレス
Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead, BERKS SL6 3QH UK
マーク・ワトソンノーテルネットワークメイデンヘッドオフィスパークWestacottウェイメイデンヘッド、BERKS SL6 3QH英国
EMail: mwatson@nortelnetworks.com
メールアドレス：mwatson@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。