[要約] 要約： RFC 3298は、公衆交換電話網/インテリジェントネットワーク（PSTN/IN）でのインターネットサービスの要求（SPIRITS）プロトコルの要件について説明しています。目的： このRFCの目的は、PSTN/IN環境でのインターネットサービスの要求に関するプロトコル要件を定義し、相互運用性とサービス品質の向上を促進することです。
Network Working Group I. Faynberg, Editor
Request for Comments: 3298 Lucent Technologies
Category: Informational J. Gato
Vodaphone
H. Lu
Lucent Technologies
L. Slutsman
AT&T
August 2002
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
公開された電話ネットワーク/インテリジェントネットワーク（PSTN/IN）のサービスインターネットサービス（Spirits）プロトコル要件の要求
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
このドキュメントでは、RFC 3136で提示されたアーキテクチャに基づいたSpiritsプロトコルの要件について説明します。ネットワーク（PSTN）とPSTNとインターネットの間の相互作用が必要です。同様に、そのようなサービスはSpirits Servicesと呼ばれます。（インターネットコールウェイティング、インターネット発信者-ID配信、およびインターネットコール転送はスピリットサービスの例ですが、プロトコルは他の多くのサービスを構築できるビルディングブロックを定義することです。）PSTN側では、Spirits Servicesが開始されます。インテリジェントネットワーク（in）エンティティから。PSTN/Internet Interworking（PINT）での以前のIETF作業により、サービスをサポートするプロトコル（RFC 2848）が、インターネットからPSTNまでの逆の方法を開始しました。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
この目的のために、このドキュメントには、スピリッツプロトコルの一般的な要件と、IN、ワイヤレスIN、およびパイントビルディングブロックに関連するものがリストされています。このドキュメントは、スピリッツシグナリングプロトコルの選択に関するスピリットWGコンセンサスも示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119に記載されているとおりに解釈されます。
Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN).
特に適格でない限り、ここでは、現在のパイントサービスやプロトコルを参照するためではなく、ジェネリックパイント（スピリッツ）サービス特性の範囲を参照するために使用されます。PSTN）。
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
このドキュメントでは、RFC 3136で提示されたアーキテクチャに基づいたSpiritsプロトコルの要件について説明します。ネットワーク（PSTN）とPSTNとインターネットの間の相互作用が必要です。このようなサービスは、Spirits Servicesと呼ばれます。（インターネットコールウェイティング、インターネット発信者-ID配信、およびインターネットコール転送はスピリットサービスの例ですが、プロトコルは他の多くのサービスを構築できるビルディングブロックを定義することです。）PSTN側では、Spirits Servicesが開始されます。インテリジェントネットワーク（in）エンティティから。PSTN/Internet Interworking（PINT）での以前のIETF作業により、サービスをサポートするプロトコル（RFC 2848）が、インターネットからPSTNまでの逆の方法を開始しました。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.
この目的のために、このドキュメントには、スピリッツプロトコルの一般的な要件と、IN、ワイヤレスIN、およびパイントビルディングブロックに関連するものがリストされています。このドキュメントは、スピリッツシグナリングプロトコルの選択に関するスピリットWGコンセンサスも示しています。共同パイント/スピリッツアーキテクチャ（[1]で説明）を図1に示します。
It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].)
Spiritsクライアントは、PSTN/Inに代わって行動するように、SpiritsクライアントはInサービス制御機能（SCF）と共同で通信するか（PSTN固有のインターフェイスDを介して）そのような方法で通信していると想定されています。（この仮定は、[2]で報告されているように、現在の実装によって確認されます。）
The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
Spiritsサービスは、Spiritsクライアントからのメッセージ（in Service Control Point [SCP]またはService Node [SN]）にあるSpirits Gatewayに到着すると、スピリッツサービスが呼び出されます（その後、Spiritsプロトコルが開始されます）。Spirits Gatewayはメッセージを処理し、インターフェイスBを介してSpiritsサーバーに渡します。最も実際に重要なケースでは、Spiritsクライアントからのリクエストは、最終的にはSCPまたはSNに送信された中央オフィス（つまり、電話スイッチ）からのリクエストによって引き起こされますが、これらの要素によるインターネットベースのサービスイニシエーションは、中央オフィスによってトリガーされたことは理論的に可能です。（間違いなく、Spiritsベンチマークサービスのいずれもそのような方法で開始されないため、Spiritsプロトコル開発の目的のために、サービスの呼び出しはサービススイッチング機能による以前のアクションの直接的な結果であると仮定する必要があります。）
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . | Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . * E
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
* *
* *
Subscriber's * C *
Telephone * *
* *
(---) * *
* * *
* * * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
Figure 1. Joint PINT/SPIRITS Architecture
図1.共同パイント/スピリッツアーキテクチャ
With PINT (and that also applies to the PINT architecture and protocol as described in [3]), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E.
[3]で説明されているパイントアーキテクチャとプロトコルにも適用されます）を使用すると、PINTサーバーへのサービス要求は常にインターフェイスA上のPINTクライアントによって開始されます。INサービスコントロールまたは同様のエンティティ（[3]による「エグゼクティブシステム」と呼ばれる）またはPSTN固有のインターフェイスE.を介して通信します。
As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements.
図1に示すように、PINTクライアントとSpiritsサーバーは、サブスクライバーのIPホストに共同住宅されています。実際、両方とも1つのプロセスとして実行するように実装できます。PINTクライアントとSpiritsサーバーの間の相互作用については、規定は行われていません。同様に、パイントサーバー/パイントゲートウェイとスピリッツゲートウェイも共同開催されていると想定されています。この仮定は便利ですが、必須ではありません。PINTサーバーは、Spiritsクライアントと共同で開催することもできます。どちらの場合でも、全体的なパイント関連要件をリストする以外に、Pint ServerとSpirits GatewayまたはPint ServerクライアントとSpint Serverクライアントのいずれかの間のインターワーキングを定義するための特定の規定は作成されていません。
Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network).
現在展開されているワールドワイドワイヤレスネットワークは回路の切り替えに基づいているため、スピリットの目的でPSTNネットワークと見なされます。Spiritsタイプのサービスをワイヤレスネットワークに追加すると、新しいサービスを開発できます（たとえば、Geolocation InformationはIPネットワークで処理できます）。
Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture.
それにもかかわらず、ワイヤレスネットワークの特定の特性があり、プロトコルの要件とSpiritsアーキテクチャで考慮されることを強制します。
A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would.
ここで検討されている標準開発の特定のワイヤレスは、第3世代パートナーシップグループ（3GPP）によって標準化されたCamelフェーズ3です。関連するサービスとアーキテクチャの考慮事項とプロトコルの要件は、このドキュメントの後半で説明されています。アーキテクチャに関する限り、特定のワイヤレスイベントは、モバイルスイッチングセンター（MSC）（SSPに相当するワイヤレス相当）の一部である場合がありますが、ホームロケーションレジスタ（HLR）によって生成されます。これらのイベントは、サービス制御のために伝えられます。その時点で、同じメカニズムを使用して、スピリッツサービスを呼び出すために使用します。
The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
このドキュメントの残りの部分は、要件、要件の特定のワイヤレス、パイント要件、プロトコル開発方法、およびセキュリティの問題について、一般的な要件、その順序で対処しています。
Based on the success of extending SIP for PINT ([3]) and, especially, the results of pre-SPIRITS implementations reported in [2], the Session Initiation Protocol (SIP) [7] has been chosen as the signaling base protocol for SPIRITS.
PINT（[3]）のSIPを拡張することの成功（[3]）、特に[2]で報告されたスピリット前の実装の結果に基づいて、セッション開始プロトコル（SIP）[7]は、シグナリングベースプロトコルとして選択されています。霊。
Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms.
したがって、特定のスピリット関連のパラメーターを、SIPプラクティスと一致する方法で実行されることが要件です。特に、セッション説明プロトコル（SDP）[8]または多目的インターネットメールエクステンションMIME [5-6]がこの目的に使用される場合があります。提案された新しい購読/通知メカニズム[4]、および既にパイントで定義されている拡張機能を除き、新しいSIP拡張機能は予見されません。代わりに、Spiritsプロトコルは上記の拡張メカニズムに依存することです。
It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.
スピリットの実装がパイントサービスを自動的にサポートすることは決して要件ではありません。Spiritsプロトコルは、最小限として、パイントサービスに依存せず、またはPSTNとの永続的な相互作用に依存せずに基本的な通知メカニズムのみをサポートできる方法で定義する必要があります。それにもかかわらず、パイントビルディングブロックとスピリットの構成要素を組み合わせることは、豊かで強化されたPSTN/インターネットサービスを構築するのに有益であることが実証されているため、Spiritsプロトコルはこのドキュメントのセクション7にリストされているパイント関連の要件を満たす必要があります。
One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
このドキュメントでさらに詳しく説明されている後者の要件の適用を示す特定の例の1つは、次のとおりです。Subscribe/Notifyの実装は、最小スピリッツプロトコルに関する限り必須ではありません。したがって、最初のPSTN（検出ポイント）通知は、常にSIP Inviteメソッドを介して届きます。ただし、PSTNとの永続的な相互作用を実装するには、購読方法を使用してPSTNイベントのさらなる通知を取得できます。その後、これらのイベントは、Notifyメソッドによって報告されます。
The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Gateway (interface C). A typical message (which starts a SPIRITS service) looks like this:
インターフェイスは、SpiritsクライアントとSpirits Gateway（Interface C）の間ですぐに関連しています。典型的なメッセージ（スピリッツサービスを開始する）は次のようになります。
C -> G: <Event Notification>, <Parameter-List (DP)>
The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The <Parameter-List> is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply: 1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those which relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.
関連するイベントは、基本コール状態モデル（BCSM）の検出ポイント（DPS）に対応しています。<parameter-list>は、特定のDPの関数です。それに関連するパラメーターが含まれています。次の要件が適用されます。1）カバーされるDPSのリストには、IN能力セット3 BCSMで定義されているものと、ITU-TのIMT 2000プロジェクトで指定された（WIN）のワイヤレスに関連するものが含まれます。
2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition.
2) このようなDPに関連付けられたすべてのパラメーターがSpiritsベンチマークサービスに必要であるわけではなく、スピリッツではすべてのパラメーターが必要ではありません。関連するパラメーターの選択は、Spiritsプロトコル定義の一部です。
3) It is desirable to avoid semantic overload of protocol messages. (One way to achieve that is to match each type of an event with a message that corresponds to it.) As the SPIRITS protocol is designed as a set of extensions to another (existing) protocol with the defined message set, the syntax and semantics of the extensions should be defined with this requirement in mind.
3) プロトコルメッセージの意味的過負荷を回避することが望ましいです。（それを達成する1つの方法は、各タイプのイベントをそれに対応するメッセージと一致させることです。）Spiritsプロトコルは、定義されたメッセージセット、構文、およびセマンティクスを使用して、別の（既存の）プロトコルへの拡張セットとして設計されているため拡張機能の要件を念頭に置いて定義する必要があります。
4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) to specify the semantics of the IN Application Protocol (INAP) parameters, which are expected to be binary-encoded. Neither the use of the ASN.1, nor the requirement for binary encoding are the typical requirements for the IETF application protocols. Recognizing that, provisions must be made for careful specification of the conversion of the INAP parameters to text, which must preserve their original semantics. The actual conversion of the parameters is the function of the SPIRITS Client.
4) ITU-Tの推奨事項は、抽象的構文表記（ASN.1）を使用して、バイナリエンコードされると予想されるアプリケーションプロトコル（INAP）パラメーターのセマンティクスを指定します。ASN.1の使用もバイナリエンコードの要件も、IETFアプリケーションプロトコルの典型的な要件ではありません。それを認識して、INAPパラメーターのテキストへの変換を注意深く指定するために規定を作成する必要があります。これは、元のセマンティクスを保持する必要があります。パラメーターの実際の変換は、スピリッツクライアントの関数です。
In order to issue an initial query (or a notification) to service control, a switch must have such a DP set. This can be done statically via service management (this particular action should be left to implementation and thus is considered outside of the scope of SPIRITS Protocol) or dynamically--but only for the purpose of a particular call--from the service control. In the latter case, it is part of the SPIRITS (or PINT) protocol to request the event notification from the service control. The SIP specific event notification scheme [4] should be specifically considered. This function can be performed by either the Spirits Client or PINT Server, the distinction being further discussed in the next section. Assuming that it is performed by the SPIRITS Client, the relevant message should look like:
サービスコントロールに初期クエリ（または通知）を発行するには、スイッチにはそのようなDPセットが必要です。これは、サービス管理を介して静的に行うことができます（この特定のアクションは実装に任される必要があるため、Spiritsプロトコルの範囲外であると見なされる必要があります）または動的に - 特定の呼び出しの目的でのみ、サービスコントロールからです。後者の場合、サービスコントロールからイベント通知を要求するのは、スピリッツ（またはパイント）プロトコルの一部です。SIP固有のイベント通知スキーム[4]を具体的に考慮する必要があります。この関数は、SpiritsクライアントまたはPintサーバーのいずれかで実行できます。これは、次のセクションでさらに説明します。Spiritsクライアントによって実行されていると仮定すると、関連するメッセージは次のようになります。
G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,
g-> c：購読<Event> <mode> <DP固有のパラメーター>、
where <Event> refers to a particular DP; <Mode> determines whether the Event Detection Point (EDP) is to be armed as EDP Request (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not foreseen because it would not provide any additional capability for SPIRITS); and the <DP-specific parameters> is the list of the values of the parameters associated with the EDP (for example, if the DP in question is O_No_Answer, then the value of the appropriate timer should be included in the list). Note that such a subscription may also originate at a) PINT Client or b) SPIRITS Gateway, either of which may (but does not have to) have a locally significant definition of the <Event>. In either case, it is the function of the SPIRITS Client to translate the definition of the Event into a particular DP (or set of DPs) when passing the message to Service Control. To summarize, for the case when PINT and SPIRITS events are defined in a way where they do not refer to the BCSM DPs, it is the function of the SPIRITS Client to define a mapping:
ここで、<Event>は特定のDPを指します。<mode>イベント検出ポイント（EDP）がEDPリクエスト（EDP-R）、EDP通知（EDP-N）、またはTDP-R（TDP-Nの必要性が予見されないかどうかが予見されないかどうかを決定します。スピリッツに追加の能力を提供しない）;<DP固有のパラメーター>は、EDPに関連付けられたパラメーターの値のリストです（たとえば、問題のDPがO_NO_Answerの場合、適切なタイマーの値をリストに含める必要があります）。このようなサブスクリプションは、a）パイントクライアントまたはb）スピリッツゲートウェイでも発生する可能性があります。どちらの場合でも、メッセージをサービスコントロールに渡す際に、イベントの定義を特定のDP（またはDPSのセット）に変換するのは、スピリッツクライアントの機能です。要約すると、パイントとスピリットのイベントがBCSM DPSを参照しない方法で定義されている場合、マッピングを定義するのはスピリッツクライアントの機能です。
Event -> DP List,
イベント - > DPリスト、
for each event for which the PSTN notification is needed.
PSTN通知が必要な各イベントについて。
The list of CS-3 DPs envisioned in SPIRITS is:
スピリットで想定されるCS-3 DPSのリストは次のとおりです。
- origination_attempt_authorized (the SPIRITS service can control call attempts, (for example, to limit calls during specific time periods)
- origination_attempt_authorized（スピリッツサービスはコールの試行を制御できます（たとえば、特定の期間中に電話を制限するため）
- collected_information and analyzed_information (for SPIRITS outgoing call screening)
- collected_information and analyzed_information（スピリットの発信コールスクリーニングの場合）
- o_answer, o_term_seized, and t_answer (to release SPIRITS resources after the call is complete and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_answer、o_term_seized、およびt_answer（コールが完了した後にスピリットリソースをリリースし、地上電話、携帯電話、SMS、ページングなどのさまざまな手段を介してパーティーに到達する試みの記録を作成するなど、関連するOA＆Mアクションを実行する）。
- o_no_answer, route_select_failure, and t_no_answer (to re-route a call)
- o_no_answer、route_select_failure、およびt_no_answer（電話を再ルーティングするため）
- o_called_party_busy (to re-route a call and for Internet Call Waiting)
- o_called_party_busy（電話を再ルーティングし、インターネットコールを待機するために）
- o_mid_call and t_mid_call (to assist a midcall action)
- o_mid_callとt_mid_call（ミッドコールアクションを支援するため）
- o_abandon, o_disconnect, t_abandon, and t_disconnect (to terminate a SPIRITS service and release the resources and perform relevant OA&M actions such as creating a record of attempts to reach a party via various means like land-line phone, cell phone, SMS, or paging.)
- o_abandon、o_disconnect、t_abandon、およびt_disconnect（スピリッツサービスを終了し、リソースをリリースし、関連するOA＆Mアクションを実行するために、地上線の電話、携帯電話、SMS、またはページングなどのさまざまな手段を介してパーティーに到達しようとする試みの記録を作成するなど、関連するOA＆Mアクションを実行する。）
In addition, the following DPs are relevant to the present SPIRITS milestone services:
さらに、次のDPは現在のスピリットマイルストーンサービスに関連しています。
- termination_attempt_authorized
- Termination_attempt_authorized
- facility_selected_and_available (could be used in SPIRITS Internet Caller-ID)
- 施設_selected_and_available（SpiritsインターネットCaller-idで使用できます）
- t_busy (for Internet Call Waiting and Call Forwarding).
- T_Busy（インターネットコール待機と電話の転送用）。
Wireless IN covers several types of "calls," which are neither circuit switched nor have an effect on circuit switched calls. For this reason, those are not considered in SPIRITS requirements. To further clarify this point, the types of "calls" not considered are:
ワイヤレスのワイヤレスは、いくつかのタイプの「コール」をカバーします。これは、回路が切り替えられておらず、回路の切り替えコールに影響を与えません。このため、それらはスピリッツの要件では考慮されていません。この点をさらに明確にするために、考慮されていない「呼び出し」のタイプは次のとおりです。
- USSD (Unstructured Supplementary Service Data)
- USSD（非構造化された補足サービスデータ）
- GPRS (General Packet Radio System)
- GPRS（一般的なパケット無線システム）
- SMS (Short Message System)
- SMS（ショートメッセージシステム）
The types of calls relevant to SPIRITS are as follows:
スピリットに関連する呼び出しの種類は次のとおりです。
a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is "Not Reachable" (when it is detected that the mobile user is out of coverage or has switched off), which is mapped as a special cause in the Busy DP. Since the Busy DP parameters would be received (if a SPIRITS service has subscribed to Busy), it would be possible to distinguish a "busy" from a "not reachable" situation.
a) 音声通話。この場合、ラクダDPがCS2に含まれているため、新しいDPは必要ありません。唯一の特別なケースは、「到達できない」（モバイルユーザーがカバレッジが外れているか、オフになっていることが検出された場合）です。これは、忙しいDPの特別な原因としてマッピングされます。忙しいDPパラメーターが受信されるため（スピリッツサービスが忙しい場合にサブスクライブした場合）、「忙しくない」状況と「忙しい」と区別することが可能です。
This translates into the requirement that one of the parameters in the Event Notification message (from SPIRITS Client to SPIRITS Gateway, over the interface C) denotes the "cause" for the Busy Detection Point.
これは、イベント通知メッセージのパラメーターの1つ（スピリッツクライアントからスピリッツゲートウェイまで、インターフェイスc）がビジー検出ポイントの「原因」を示すという要件に変換されます。
Another aspect of difference, when compared to PSTN, is setting of static DPs. In CAMEL networks, this is done in the Home Location Register (HLR) (and copied to the VLR during location update). It is important to note this difference, even though it has no effect on SPIRITS protocol.
PSTNと比較した場合、違いのもう1つの側面は、静的DPSの設定です。キャメルネットワークでは、これはホームロケーションレジスタ（HLR）で行われます（ロケーションの更新中にVLRにコピーされます）。Spiritsプロトコルには影響しない場合でも、この違いに注意することが重要です。
b) Mobility Management events. This allows a SPIRITS server to be notified of changes of location of a mobile user. The events would only be applicable to mobile users reachable through a Circuit-Switched network. To provide for this function, the subscription marks must be set in the subscriber's HLR. This is equivalent to setting TDPs in the SSP. In this case, the marks in the HLR (which are copied to the Visitor Location Register [VLR] on location update) are not mapped into Trigger Detection Points.
b) モビリティ管理イベント。これにより、Spiritsサーバーにモバイルユーザーの場所の変更を通知できます。イベントは、サーキットが切り替えられたネットワークを介して到達可能なモバイルユーザーにのみ適用できます。この関数を提供するには、サブスクリプションマークをサブスクライバーのHLRに設定する必要があります。これは、SSPにTDPを設定することと同等です。この場合、HLRのマーク（ロケーションアップデートでVisitor Location Register [VLR]にコピーされます）は、トリガー検出ポイントにマッピングされません。
As with TDP setting, this is outside of the scope of SPIRITS protocol.
TDP設定と同様に、これはスピリッツプロトコルの範囲外です。
In order to support this function in SPIRITS, the SPIRITS protocol should be able to map the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface. (This is just an extension of the DP notification mechanism from the SPIRITS client to the SPIRITS gateway).
Spiritsでこの機能をサポートするために、Spirits Protocolは、Camel固有の操作をSpiritsクライアントにイベント通知にマッピングできるはずです。SCPはモビリティ状態に関する情報を受信するため、これにはCインターフェイスが含まれます。（これは、SpiritsクライアントからSpirits GatewayまでのDP通知メカニズムの単なる拡張機能です）。
The events (which are not DP-related) which need notifications are:
通知が必要なイベント（DP関連ではありません）は次のとおりです。
- Location Update in the same VLR service area
- 同じVLRサービスエリアでの場所の更新
- Location Update in another VLR service area
- 別のVLRサービスエリアでの場所の更新
- IMSI attach
- IMSIアタッチ
- MS initiated IMSI detach
- MSはIMSIデタッチを開始しました
- Network initiated IMSI detach.
- ネットワークはIMSIデタッチを開始しました。
With this mechanism, the SPIRITS services can use the user-profile-based location information. For example, the Internet Call Waiting service can re-direct the call to a mobile phone.
このメカニズムを使用すると、Spirits Servicesはユーザープロファイルベースの位置情報を使用できます。たとえば、インターネットコール待機サービスは、携帯電話への通話を再ダイレクトできます。
c) Supplementary Services Notification.
c) 補足サービス通知。
This mechanism makes a SPIRITS server aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber, or Multi-Party.
このメカニズムにより、Spiritsサーバーは、次の補足サービスのいずれかを呼び出したサブスクライバーを認識させます。明示的な呼び出し転送、コールデフレクション、ビジーサブスクライバーの呼び出し完了、またはマルチパーティ。
Before a SPIRITS service can be invoked, the relevant IP Host must be registered. Thus, Registration is an essential service, which is initiated from the IP side. The registration information is ultimately used by the PSTN to authenticate the subscriber.
Spiritsサービスを呼び出す前に、関連するIPホストを登録する必要があります。したがって、登録は重要なサービスであり、IP側から開始されます。登録情報は、最終的にPSTNによってサブスクライバーを認証するために使用されます。
Depending on the model, this can be done in two ways with the present architecture:
モデルに応じて、これは現在のアーキテクチャで2つの方法で実行できます。
1) The PINT Client issues the appropriate Register message over the interface A, which is then passed by the PINT server to the SPIRITS Gateway and SPIRITS Client:
1) PINTクライアントは、インターフェイスAに適切なレジスタメッセージを発行します。これは、PINTサーバーによってSpirits GatewayとSpiritsクライアントに渡されます。
PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS C.]. In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication.
パイントC。： - 登録 - >パイントS. [ - > Spirits Gateway-> Spirits C.]。この場合、Spiritsクライアント（サービスコントロールと共同住宅）は、記録保持と認証を担当します。
2) The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic".
2) PINTクライアントは、PINTサーバーに適切なレジスタメッセージを発行し、この情報を「魔法による」PSTNサービスコントロールに渡します。
The second model is much easier to handle, because it involves only one relevant interface ("A"); however it assumes no interworking between PINT and SPIRITS except that the SPIRITS Client finds "by magic" that a friendly and expecting IP Host is alive and well.
2番目のモデルは、関連するインターフェイス（ "a"）のみを含むため、処理がはるかに簡単です。しかし、スピリッツのクライアントが、フレンドリーで期待しているIPホストが生きていることを「魔法で」見つけることを除いて、それはパイントとスピリットの間に交流を想定していません。
Finally, in the event PINT is not implemented, the SIP SUBSCRIBE mechanism can be used.
最後に、パイントが実装されていない場合、SIPサブスクライブメカニズムを使用できます。
As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks [3] must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in [4]; it provides the necessary mechanism for specifying relevant events.) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP).
前のセクションで述べたように、既存の購読/通知パイントビルディングブロック[3]は、DPSの設定/DPイベント通知の取得目的で、スピリッツで使用するために拡張する必要があります。（同じパイントに導入されたブロックのより一般的なSIPメカニズムは、[4]で説明されています。関連するイベントを指定するために必要なメカニズムを提供します。）逆に、機能能力の同じビルディングブロックは、パイントとスピリットの両方のプロトコルで使用できます。。ただし、Spiritsでは、PSTN通知は、イベントの特定のサブスクリプションなしで（静的に設定されたDPの場合）到着する可能性があることに注意してください。
The requirements of this section are neither PINT-specific, nor IN-specific; their role is to outline the remaining element necessary for the delivery of the SPIRITS service, which is the reaction to the notification received.
このセクションの要件は、パイント固有のものでも、固有でもありません。彼らの役割は、受け取った通知に対する反応であるスピリッツサービスの提供に必要な残りの要素の概要を説明することです。
In a particular scenario where:
特定のシナリオで：
a) The IP subscriber registers a SPIRITS service;
a) IPサブスクライバーはスピリッツサービスを登録します。
b) A call triggering the SPIRITS service is received (and notification is sent); and
b) スピリッツサービスをトリガーするコールが受信されます（通知が送信されます）。そして
c) The call disposition is performed by the end user, the signalling flow is demonstrated in Figure 2.
c) コールの処分はエンドユーザーによって実行され、シグナリングフローを図2に示します。
|----> Registration ----->|
SPIRITS |<-- Event Notification <-- | SPIRITS
Gateway |---> Call Disposition ---->| Client
| |
|
|
|
V
Service Control
|
|
V
SSP
Figure 2: Sequence of SPIRITS actions
図2：スピリットアクションのシーケンス
One of the following actions is required by benchmark services:
ベンチマークサービスでは、次のアクションのいずれかが必要です。
a) Accept the incoming call
a) 着信を受け入れます
b) Reject the incoming call
b) 着信を拒否します
c) Redirect the incoming call
c) 着信コールをリダイレクトします
d) Accept the call via VoIP (this particular item is outside of the scope of SPIRITS WG).
d) VoIP経由でコールを受け入れます（この特定のアイテムは、スピリッツWGの範囲外です）。
Accordingly, the SPIRITS protocol should define the following message types:
したがって、Spiritsプロトコルは次のメッセージタイプを定義する必要があります。
a) S->G: <Accept Call>
b) S->G: <[Reject Call],[Cause]>
c) S->G: <[Redirect Call],[Redirection Destination]>
To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set of messages), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-3 BSCM has the richest set of DPs, although not all switching exchanges have implemented it.
最小スピリットプロトコル語彙（つまり、メッセージのセット）を決定するには、基本的なコール状態モデルの各検出ポイントに関連付けられたPSTNイベントを調べる必要があります。現在までに、CS-3 BSCMはDPSの最も豊富なセットを持っていますが、すべての切り替え交換がそれを実装しているわけではありません。
To determine the MINIMUM information available to the SPIRITS client (this information is to be carried by the SPIRITS protocol from SPIRITS client to SPIRITS server), each DP-specific information elements needs to be examined.
Spiritsクライアントが利用できる最小情報（この情報は、SpiritsクライアントからSpiritsサーバーへのSpiritsプロトコルによって運ばれる）を決定するために、各DP固有の情報要素を調べる必要があります。
Parameters should be event-specific, the following generic types of parameters are expected to be mandatory:
パラメーターはイベント固有である必要があり、次の汎用タイプのパラメーターが必須であると予想されます。
- timer (for no answer)
- タイマー（答えなし）
- midcall control info (for mid_call)
- MidCallコントロール情報（MID_CALL用）
- number of digits (for collected_information)
- 数字数（collected_information用）
Overall, the basic aspects of security apply to SPIRITS protocol:
全体として、セキュリティの基本的な側面は、スピリッツプロトコルに適用されます。
- Authentication: In the communications between the SPIRITS Client and SPIRITS Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is required that the information be sent between known and trusted partners.
- 認証：SpiritsクライアントとSpirits Gateway、Spirits Gateway and Spiritsサーバーの間の通信では、情報を既知のパートナーと信頼できるパートナーの間で送信する必要があります。
- Integrity: It is a requirement that no exchanged data be modified in transit.
- 整合性：交換されたデータが輸送中に変更されないことが要件です。
- Confidentiality: It is a requirement that any private user information or confidential network data be protected by the protocol (typically through encryption, for which the protocol should allow a choice in the algorithm selection.
- 機密性：プライベートユーザー情報または機密ネットワークデータをプロトコルによって保護することが要件です（通常、暗号化を介して、プロトコルがアルゴリズムの選択の選択を許可する必要があります。
- Availability: It is a requirement that the communicating endpoints remain in service for authorized use only.
- 可用性：通信エンドポイントが認可された使用のみのために使用され続けることが要件です。
In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber.
さらに、プロトコルは、PSTNサブスクライバーの充電に関連するこれらの制御メッセージの非repudiationをサポートする必要があります。
As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet and is thus most vulnerable to security attacks resulting in theft or denial of service. The C interface, on the other hand is likely to be implemented across a service providers intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks.
図1に示すように、2つの異なる通信インターフェイス、BとCがあります。BとCは、一般に、パブリックインターネット全体にあるため、セキュリティ攻撃に対して最も脆弱であり、盗難またはサービスの拒否をもたらします。一方、Cインターフェイスは、サービスプロバイダーの裁量でセキュリティ対策を適用する必要があるサービスプロバイダーイントラネット全体で実装される可能性があります。それでも、少なくとも1つのIPホスト（パイントゲートウェイ）がインターネットに接続されているため、特別な測定（例えば、ファイアウォールのインストール、この特定のメジャーだけでは不十分な場合があります）は、インターフェイスCと残りを保護するために取得する必要があります。セキュリティ攻撃からのネットワークの。
The assumption that the PINT Client and SPIRITS server are co-located, dictates that the security considerations for the A and B interfaces are exactly same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 [3].
PINTクライアントとSpiritsサーバーが共同で配置されているという仮定は、AおよびBインターフェイスのセキュリティに関する考慮事項がまったく同じであると規定しています。インターフェイスA（およびその結果、b）の詳細なセキュリティ要件とソリューションは、RFC 2848 [3]に記載されています。
Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber. For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of integrity of a valid registration) may force a network operator to provide to an authorized party a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients (who may further defraud the unsuspecting calling party). In this case, the calling party is using only the PSTN and thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber.
セキュリティ攻撃の可能性は、盗難とサービスの拒否の両方をもたらす可能性があります。さらに、このような攻撃は、PSTNサブスクライバーのプライバシーに違反する可能性があります。たとえば、インターネットが待機すると、不正な登録（または有効な登録の整合性の操作）により、ネットワークオペレーターは、承認された当事者に電話の試みの完全なログ（発信者の識別を伴う）を提供するように強制する場合があります。さらに、コールは間違った受信者に転用される場合があります（疑いを持たない呼び出し当事者をさらに詐欺する可能性があります）。この場合、発信者はPSTNのみを使用しているため、PSTNの典型的な通信のセキュリティを期待しています。PSTNサービスプロバイダーは、間違った接続を確立する結果について責任を負う可能性があります。さらに、PSTNサービスプロバイダーは、サブスクライバーの個人情報を不注意に漏らすことに責任を負う可能性があります。
The service and network providers need to review the possibilities of the security attacks and prepare the means of protection from them. Some of this may be achieved by using the means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them. As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body.
サービスおよびネットワークプロバイダーは、セキュリティ攻撃の可能性を確認し、それらからの保護手段を準備する必要があります。これのいくつかは、プロトコル自体によって提供される手段以外の平均を使用することで達成される場合があります。たとえば、管理情報（Pint MIBやSpirits MIBによって収集された統計など）は、違反を決定し、それらを妨害するのに役立ちます。プロトコルに関する限り、セッションと同様にサブスクライバーを認証する手段を提供する必要があります。また、暗号化された情報を体内に運ぶ機能も提供する必要があります。
The authors are grateful to all participants in the SPIRITS group for the discussion that has been shaping this work. Many thanks go to Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and John Voelker for their incisive comments. Special thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose careful, detailed reviews of several versions of this document have been particularly helpful in improving its quality.
著者は、この作品を形作ってきた議論について、Spiritsグループのすべての参加者に感謝しています。Jorgen Bjorkner、Alec Brusilovsky、Jim Buller、Lawrence Conroy、Soren Nyckelgard、およびJohn Voelkerに鋭いコメントをしてくれたことに感謝します。Vijay Gurbani、Dave Hewins、およびKumar Vemuriに感謝します。このドキュメントのいくつかのバージョンの慎重で詳細なレビューは、その品質を改善するのに特に役立ちました。
[1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits Architecture", RFC 3136, June 2001.
[1] Slutsman、L.、Faynberg、I.、Lu、H。およびM. Weissman、「The Spirits Architecture」、RFC 3136、2001年6月。
[2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS Implementations of PSTN-Initiated Services", RFC 2995, November 2000.
[2] Lu、H。（編集者）、Faynberg、I.、Voelker、J.、Weissman、M.、Zhang、W.、Rhim、S.、Hwang、J.、Ago、S.、Moeenuddin、S.、Hadvani、S.、Nyckelgard、S.、Yoakum、J。、およびL. Robart、「PSTN開始サービスの事前スピリット実装」、RFC 2995、2000年11月。
[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[3] Petrack、S。and L. Conroy、「The Pint Service Protocol：SIPおよびSDPへの拡張電話への電話サービスへのアクセスのためのSDP」、RFC 2848、2000年6月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7] Handley、M.、Schooler、E.、Schulzrinne、H。、およびJ. Rosenberg、「SIP：セッション開始プロトコル」、RFC 2543、1999年3月。
[8] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley、M。and V. Jacobsen、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748
Lev Slutsman AT＆T Laboratories 200 Laurel Ave.ミドルタウン、ニュージャージー、07748
Phone: (732) 420-3752 EMail: lslutsman@att.com
電話：（732）420-3752メール：lslutsman@att.com
Igor Faynberg Bell Labs/Lucent Technologies Room 4D-601A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
Igor Faynberg Bell Labs/Lucent Technologies Room 4D-601A、101 Crawfords Corner Road Holmdel、ニュージャージー、07733
Phone: (732) 949-0137 EMail: faynberg@lucent.com
電話：（732）949-0137メール：faynberg@lucent.com
Jorge Gato Vodaphone Avda de Europa, 1. 28108 Alcobendas (Madrid). Spain
Jorge Gato Vodafone Avda de Europa、1。28108Alcobendas（Madrid）。スペイン
Phone: +34 607 13 31 10
Fax: +34 607 13 30 57
EMail: jgato@airtel.es
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A、101 Crawfords Corner Road Holmdel、ニュージャージー、07733
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
電話：（732）949-0321メール：huilanlu@lucent.com
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エディター機能の資金は現在、インターネット協会によって提供されています。