[要約] RFC 3324は、ネットワークが主張するアイデンティティの短期的な要件に関するものであり、ユーザーのアイデンティティの確立と管理に関するガイドラインを提供しています。このRFCの目的は、ネットワーク上でのアイデンティティの信頼性を向上させ、セキュリティとプライバシーを確保することです。
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.
Copyright（c）The Internet Society（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）ネットワーク仲介者によって最初に導出されたIDです。このドキュメントでは、安全に相互に接続された信頼できるノードのネットワーク内およびそのようなネットワークに安全に接続されたユーザーエージェントのネットワーク内で、ネットワークの交換のための短期要件について説明します。
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]を使用すると、ユーザーは、from：headerを使用して、さまざまな方法でアイデンティティを主張できます。ただし、これらのアイデンティティがユーザーが望むエイリアス以外のものになる必要はありません。
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ダイジェスト認証（または他の手段）を使用して、ユーザーの認証されたIDを取得できます。ただし、UASには、別の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ネットワーク仲介者によって導出されたIDです。これは、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.
このドキュメントの目的のためのアイデンティティは、SIP：、SIP：または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.
URIは、URI（SIPの場合：またはSIP：URI）で識別されたドメインに対して意味がある必要があります。そのドメイン/番号範囲の所有者に送信されたリクエストのSIPリクエスト-URIにより、リクエストは、アイデンティティに関連付けられているユーザー/行にルーティングされるか、ユーザーに代わって実行されているサービスロジックによって処理されます。
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：または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がTel：URIである場合、電話番号が存在する数値範囲の所有者のローカルポリシーに応じて、電話回線などの特定のエンティティを識別する場合があります。ただし、数値範囲の所有者を特定することは、SIPを所有するドメインを識別するよりも簡単ではないプロセスであることに注意する必要があります：またはSIP：URI。
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ネットワークエンティティによって導出されたIDです。
In the case of a sip: or sips: URI, the domain included in the URI MUST be within the Trust Domain.
SIPの場合：または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.
ノードは、ノードが特定の仕様セットであるSpec（t）に準拠していることがわかっている場合にのみ、Trust Domainのメンバーである可能性があります。これは、Trust Domain、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.
信頼ドメインは、使用/展開している機器の特性を知っている人間によって構築されます。最も簡単な場合、トラストドメインは、それらのデバイスの動作を正確に知ることができる1人の所有者/オペレーターを持つデバイスのセットです。
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、または（または 'bはa'）に「信頼されている」と言います。
1. there is a secure connection between the nodes, AND
1. ノードの間には安全な接続があり、
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は、特定のネットワーク仲介者、A（例えば、そのホームプロキシ）を信頼するUAである可能性があります。
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から来たことを確認できます。信頼ドメイン、つまり、Spec（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).
このコンテキスト内で、信頼できるノードから1つのノードで受信した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).
同様に、ノードは、信頼できるノードに渡されたシグナリング情報がSPEC（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.
これらの機能が有用であるためには、SPEC（T）がネットワークの主張されたアイデンティティの生成方法、プライバシーの保護方法、ネットワーク周辺の継続的に整合される方法に関する要件を含める必要があります。Spec（T）の読者は、Trust Domain 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.
「信頼性」という用語（特定の信頼ドメインに関して）は、絶対的な意味で特定のノードに適用できます。ノードがTrustドメインのメンバーであると言うのと同じです。ただし、ノード自体は、トラストドメイン内であっても、別の任意のノードが「信頼されている」かどうかを知りません。上記のように安全な接続がある特定のノードについて知っています。
With the definition above, statements such as 'A trusted node SHALL ...' are just shorthand for 'A node compliant to this specification 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.
「ノードが信頼できるノードから情報を受信したとき」などのステートメントは無効です。1つのノードには、信頼ドメイン内の他のすべてのノードに関する完全な知識がないためです。
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
o AはCを信頼しますが、AはBを信頼していません
o since E knows that B is inside of the trust domain, E
o eはbが信頼ドメインの内側にあることを知っているので、e
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).
信頼ドメインの定義の側面は、そのドメイン内のすべての要素が、一般にSPEC（T）と呼ばれる一連の構成と仕様に準拠していることです。Spec（t）は、書かれたドキュメントの意味での仕様ではありません。むしろ、すべての要素が認識している情報のセットに合意された情報です。主張されたアイデンティティの適切な処理には、要素が実際に主張されているもの、それがどのように決定されたか、プライバシーポリシーが何であるかを知ることが必要です。そのすべての情報は、Spec（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).
使用される認証プロセスは、信頼ドメインの特徴的な機能であり、仕様（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.
Trustドメイン内の1つのノードが、信頼できる別のノードにネットワークをアサートされたアイデンティティを安全に送信することが可能です。
It shall be possible for one node within a Trust Domain to receive a Network Asserted identity from another node that it trusts.
Trustドメイン内の1つのノードが、信頼できる別のノードからネットワークアサートされたIDを受信することが可能です。
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.
Trustドメイン内のノード、Aが信頼ドメインの外側のノードBによって信頼されている場合、ユーザーのプライバシーポリシーで許可されている場合、AがネットワークアサートされたアイデンティティをBに安全に送信することが可能になります。それが特定されており、信頼ドメイン。
This is most often used to pass a Network Asserted Identity directly to a UA.
これは、ほとんどの場合、ネットワークをアサートされたアイデンティティをUAに直接渡すために使用されます。
It shall be possible for a node outside the Trust Domain to receive a Network Asserted Identity from a node that it trusts.
Trustドメインの外側のノードが、信頼できるノードからネットワークアサートされたIDを受信することが可能です。
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.)
ネットワークは、信頼していないノードから1つのノードで受信されたID情報を主張しました。これは、情報を生成および輸送するために仕様（t）の手順に従ったことがわからないため、信頼性または完全性の保証を保証しません。そのような情報を使用してはなりません。（つまり、それはユーザーに表示され、他のノードに渡され、サービスの入力データとして使用されます。）
A Network Asserted Identity identifies the originator of the message in which it was received.
ネットワークが主張されたIDは、受信したメッセージの発信者を識別します。
For example,
例えば、
a Network Asserted Identity received in an initial INVITE (outside the context of any existing dialog) identifies the calling party.
最初の招待状（既存のダイアログのコンテキストの外側）で受け取ったネットワークが主張されたIDは、呼び出し党を識別します。
a Network Asserted Identity received in a 180 Ringing response to such an INVITE identifies the party who is ringing.
そのような招待に対する180のリンギング応答で受け取ったネットワークが主張されたアイデンティティは、鳴っている当事者を識別します。
a Network Asserted Identity received in a 200 response to such an INVITE identifies the party who has answered.
そのような招待に対する200の応答で受け取ったネットワークが主張されたアイデンティティは、答えた当事者を特定します。
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.
サポートされるアイデンティティのタイプは、SIP：、SIP：およびTEL：URISでなければなりません。これらはすべて、セクション2.1で説明されているようにユーザーを識別します。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.
ユーザーは、ネットワークが他のユーザーに渡されないと主張するネットワークが容認されることを要求していることを示すことができます。これは、上記の兆候とは異なります。これは、ネットワークが主張されたIDに関して特定のユーザーの意図を意味するからです。
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.
メカニズムは、上記の2つの適応症が同等の信頼ドメインポリシーをサポートするものとします（つまり、プライバシー要件の唯一の可能な理由はユーザーからの要求です）、およびそれらがないポリシー。
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.
この場合、ネットワークが主張されたID仕様は、セクション4.3のメカニズムを使用してはならないことを要求するものとします。ただし、セクション4.3のメカニズムを使用して、信頼できるネットワーク内のIDを転送することができます。
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.
むしろ、メカニズム（SPEC（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.
この要件は、Trustドメインの外側のノードへの安全な接続を介して、Trustドメイン内のノードからの情報の転送もサポートしています。
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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
Author's Address
著者の連絡先
Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead, BERKS SL6 3QH UK
マークワトソンノルテルネットワークメイデンヘッドオフィスパークウェスタコットウェイメイデンヘッド、バークスSL6 3QH英国
EMail: mwatson@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。