RFC3050 日本語訳
3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J.Rosenberg. January 2001. (Format: TXT=76652 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lennox
Request for Comments: 3050 H. Schulzrinne
Category: Informational Columbia U.
J. Rosenberg
dynamicsoft
January 2001
コメントを求めるワーキンググループJ.レノックス要求をネットワークでつないでください: 3050時間Schulzrinneカテゴリ: 情報のコロンビアU.J.ローゼンバーグdynamicsoft2001年1月
Common Gateway Interface for SIP
一口のための共通ゲートウェイインターフェイス
Status of this Memo
この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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI is a good candidate for service creation in a SIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.
インターネット電話に、新種業務が急速に作成されて、配布される手段があるに違いありません。 WWWでは、共通ゲートウェイインターフェイス(CGI)はポピュラーな手段としてプログラミングウェブサービスに向かって機能しました。 Session Initiationプロトコル(SIP)とHyper Text Transferプロトコル(HTTP)の間の類似性のために、CGIはSIP環境におけるサービス作成の良い候補です。 このドキュメントは、SIPサーバでサービスをSIPに供給するためにSIP CGIインタフェースを定義します。
IESG Note
IESG注意
The IESG notes that the mechanism specified here depends on the Common Gateway Interface. Should this interface change or be enhanced changes in this specification may also be necessary or appropriate. According to the W3C, the CGI is presently maintained by the NCSA Software Development Group. See
IESGは、ここで指定されたメカニズムが共通ゲートウェイインターフェイスによることに注意します。 これが連結するなら、変化しなさいか、また、この仕様に基づく高められた変化も必要であるか、または適切であるかもしれないということになってください。 W3Cによると、CGIは現在、NCSA Software Development Groupによって維持されます。 見てください。
http://www.w3c.org/cgi
http://www.w3c.org/cgi
for additional information on the current state of the CGI interface.
CGIの現状の追加情報に関しては、連結してください。
Lennox, et al. Informational [Page 1] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[1ページ]のRFC3050CGI
Table of Contents
目次
1 Introduction ....................................... 3 2 Motivations ........................................ 4 3 Differences from HTTP CGI .......................... 5 3.1 Basic Model ........................................ 6 3.2 Persistence Model .................................. 8 3.3 SIP CGI Triggers ................................... 9 3.4 Naming ............................................. 9 3.5 Environment Variables .............................. 9 3.6 Timers ............................................. 10 4 Overview of SIP CGI ................................ 10 5 SIP CGI Specification .............................. 12 5.1 Introduction ....................................... 12 5.1.1 Relationship with HTTP CGI ......................... 12 5.1.2 Conventions of This Document ....................... 12 5.1.3 Specifications ..................................... 12 5.1.4 Terminology ........................................ 13 5.2 Notational Conventions and Generic Grammar ......... 13 5.3 Invoking the Script ................................ 14 5.4 The SIP CGI Script Command Line .................... 14 5.5 Data Input to the SIP CGI Script ................... 14 5.5.1 Message Metadata (Metavariables) ................... 14 5.5.1.1 AUTH_TYPE .......................................... 16 5.5.1.2 CONTENT_LENGTH ..................................... 16 5.5.1.3 CONTENT_TYPE ....................................... 17 5.5.1.4 GATEWAY_INTERFACE .................................. 17 5.5.1.5 Protocol-Specific Metavariables .................... 18 5.5.1.6 REGISTRATIONS ...................................... 18 5.5.1.7 REMOTE_ADDR ........................................ 19 5.5.1.8 REMOTE_HOST ........................................ 19 5.5.1.9 REMOTE_IDENT ....................................... 19 5.5.1.10 REMOTE_USER ........................................ 20 5.5.1.11 REQUEST_METHOD ..................................... 20 5.5.1.12 REQUEST_TOKEN ...................................... 21 5.5.1.13 REQUEST_URI ........................................ 21 5.5.1.14 RESPONSE_STATUS .................................... 21 5.5.1.15 RESPONSE_REASON .................................... 21 5.5.1.16 RESPONSE_TOKEN ..................................... 21 5.5.1.17 SCRIPT_COOKIE ...................................... 22 5.5.1.18 SERVER_NAME ........................................ 22 5.5.1.19 SERVER_PORT ........................................ 22 5.5.1.20 SERVER_PROTOCOL .................................... 22 5.5.1.21 SERVER_SOFTWARE .................................... 23 5.5.2 Message Bodies ..................................... 23 5.6 Data Output from the SIP CGI Script ................ 23 5.6.1 CGI Action Lines ................................... 25 5.6.1.1 Status ............................................. 25
1つの序論… 3 2の動機… HTTP CGIからの4 3の違い… 5 3.1基本型… 6 3.2固執モデル… 8 3.3 CGI引き金をちびちび飲んでください… 9 3.4 命名します。 9 3.5の環境変数… 9 3.6個のタイマ… 10 一口CGIの4概要… 10 5 CGI仕様をちびちび飲んでください… 12 5.1序論… 12 5.1 HTTP CGIとの.1関係… 12 5.1 このドキュメントの.2のコンベンション… 12 5.1 .3の仕様… 12 5.1 .4用語… 13 5.2 記号法のコンベンションとジェネリック文法… 13 5.3 スクリプトを呼び出します… 14 5.4 一口CGIスクリプトコマンドライン… 14 一口CGIスクリプトへの5.5データの入力… 14 5.5 .1 メッセージメタデータ(Metavariables)… 14 5.5 .1 .1 AUTH_タイプ… 16 5.5 .1 .2 満足している_の長さ… 16 5.5 .1 .3 内容_はタイプします… 17 5.5 .1 .4 ゲートウェイ_は連結します… 17 5.5 .1 .5 プロトコル特有のMetavariables… 18 5.5 .1 .6の登録証明書… 18 5.5 .1 .7 リモート_ADDR… 19 5.5 .1 .8のリモート_ホスト… 19 5.5 .1 .9 リモート_IDENT… 19 5.5 .1 .10のリモート_ユーザ… 20 5.5 .1 .11 _メソッドを要求してください… 20 5.5 .1 .12 _トークンを要求してください… 21 5.5 .1 .13 _ユリを要求してください… 21 5.5 .1 .14 応答_状態… 21 5.5 .1 .15 応答_は推論します… 21 5.5 .1 .16応答_トークン… 21 5.5 .1 .17スクリプト_クッキー… 22 5.5 .1 .18サーバ_名… 22 5.5 .1 .19 サーバ_ポート… 22 5.5 .1 .20サーバ_は議定書を作ります… 22 5.5 .1 .21 サーバ_ソフトウェア… 23 5.5 .2 メッセージ本体… 23 5.6 一口CGIスクリプトからのデータ出力… 23 5.6 .1 CGI動作は立ち並んでいます… 25 5.6 .1 .1状態… 25
Lennox, et al. Informational [Page 2] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[2ページ]のRFC3050CGI
5.6.1.2 Proxy Request ...................................... 25 5.6.1.3 Forward Response ................................... 26 5.6.1.4 Script Cookie ...................................... 26 5.6.1.5 CGI Again .......................................... 27 5.6.1.6 Default Action ..................................... 27 5.6.2 CGI Header Fields .................................. 28 5.6.2.1 Request-Token ...................................... 28 5.6.2.2 Remove ............................................. 28 5.7 Local Expiration Handling .......................... 28 5.8 Locally-Generated Responses ........................ 29 5.9 SIP CGI and REGISTER ............................... 29 5.10 SIP CGI and CANCEL ................................. 29 5.11 SIP CGI and ACK .................................... 30 5.11.1 Receiving ACK's .................................... 30 5.11.2 Sending ACK's ...................................... 30 6 System Specifications .............................. 30 6.1 Unix ............................................... 30 6.2 Microsoft Windows .................................. 31 7 Security Considerations ............................ 31 7.1 Request Initiation ................................. 31 7.2 Authenticated and Encrypted Messages ............... 31 7.3 SIP Header Fields Containing Sensitive Information.. 32 7.4 Script Interference with the Server ................ 32 7.5 Data Length and Buffering Considerations ........... 32 8 Acknowledgements ................................... 33 9 Authors' Addresses ................................. 33 10 Bibliography ....................................... 34 11 Full Copyright Statement ........................... 35
5.6.1.2 プロキシ要求… 25 5.6 .1 .3 応答を進めてください… 26 5.6 .1 .4スクリプトクッキー… 26 5.6 .1.5CGI、再び… 27 5.6 .1 .6 デフォルト動作… 27 5.6 .2 CGIヘッダーフィールド… 28 5.6 .2 .1要求トークン… 28 5.6 .2 .2 取り外してください… 28 5.7 地方の満了取り扱い… 28 5.8 局所的に、応答を生成します… 29 5.9 CGIをちびちび飲んでください、そして、登録してください… 29 5.10 CGIをちびちび飲んでください、そして、取り消してください… 29 5.11 CGIとACKをちびちび飲んでください… 30 5.11.1 ACKを受けます… 30 5.11.2 送付ACKのもの… 30 6 システム仕様… 30 6.1unix… 30 6.2 マイクロソフトWindows… 31 7 セキュリティ問題… 31 7.1 開始を要求してください… 31 7.2 メッセージを認証して、暗号化します… 31 7.3は機密情報を含むヘッダーフィールドをちびちび飲みます。 32 7.4 サーバのスクリプト干渉… 32 7.5のデータの長さとバッファリング問題… 32 8つの承認… 33 9人の作者のアドレス… 33 10図書目録… 34 11の完全な著作権宣言文… 35
1 Introduction
1つの序論
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In traditional telephony networks, this was accomplished through IN service creation environments, which provided an interface for creating new services, often using GUI- based tools.
インターネット電話に、新種業務が急速に作成されて、配布される手段があるに違いありません。 伝統的な電話ネットワークでは、これはINサービス生成環境を通して達成されました、しばしばGUIのベースのツールを使用して。サービス生成環境は新種業務を作成するのにインタフェースを提供しました。
The WWW has evolved with its own set of tools for service creation. Originally, web servers simply translated URLs into filenames stored on a local system, and returned the file content. Over time, servers evolved to provide dynamic content, and forms provided a means for soliciting user input. In essence, what evolved was a means for service creation in a web environment. There are now many means for creation of dynamic web content, including server side JavaScript, servlets, and the common gateway interface (CGI) [1].
それ自身のサービス作成のためのツールのセットに従って、WWWは発展しました。 元々、ウェブサーバーは、単にローカルシステムに保存されたファイル名にURLを翻訳して、ファイル内容を返しました。 時間がたつにつれて、サーバはダイナミックな内容を提供するために発展しました、そして、フォームはユーザ入力に請求するための手段を提供しました。 本質では、発展したことはウェブ環境におけるサービス作成のための手段でした。 現在、ダイナミックなウェブ内容の作成のための多くの手段があります、サーバサイドJavaScript、サーブレット、およびコモンゲートウェイインターフェース(CGI)[1]を含んでいて。
Lennox, et al. Informational [Page 3] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[3ページ]のRFC3050CGI
Multimedia communications, including Internet telephony, will also require a mechanism for creating services. This mechanism is strongly tied to the features provided by the signaling protocols. The Session Initiation Protocol (SIP) [2] has been developed for initiation and termination of multimedia sessions. SIP borrows heavily from HTTP, inheriting its client-server interaction and much of its syntax and semantics. For this reason, the web service creation environments, and CGI in particular, seem attractive as starting points for developing SIP based service creation environments.
また、インターネット電話を含むマルチメディア通信は、サービスを作成するためにメカニズムを必要とするでしょう。 このメカニズムは強くシグナリングプロトコルによって提供された特徴に結ばれます。 Session Initiationプロトコル(SIP)[2]はマルチメディアセッションの開始と終了のために開発されました。 その構文と意味論のクライアント/サーバ相互作用と多くを引き継いで、SIPはHTTPから大いに借ります。 この理由に関しては、展開しているSIPのための出発点がサービス生成環境を基礎づけたので、ウェブサービス作成環境、および特にCGIは魅力的に見えます。
2 Motivations
2動機
CGI has a number of strengths which make it attractive as an environment for creating SIP services:
CGIには、それをSIPサービスを作成するための環境として魅力的にする多くの強さがあります:
Language independence: CGI works with perl, C, VisualBasic, tcl,
and many other languages, as long as they support access to
environment variables.
言語独立: 環境変数へのアクセスをサポートする限り、CGIはパール、C、ビジュアルベーシック、tcl、および他の多くの言語で働いています。
Exposes all headers: CGI exposes the content of all the headers
in an HTTP request to the CGI application. An application
can make use of these as it sees fit, and ignore those it
doesn't care about. This allows all aspects of an HTTP
request to be considered for creation of content. In a SIP
environment, headers have greater importance than in HTTP.
They carry critical information about the transaction,
including caller and callee, subject, contact addresses,
organizations, extension names, registration parameters and
expirations, call status, and call routes, to name a few.
It is therefore critical for SIP services to have as much
access to these headers as possible. For this reason, CGI
is very attractive.
露出、すべてのヘッダー: CGIはHTTP要求におけるすべてのヘッダーの内容をCGIアプリケーションに暴露します。 アプリケーションは、適していると決めるようにこれらを利用して、それが心配しないものを無視できます。 これは内容の作成のために考えられるというHTTP要求の全面を許容します。 SIP環境で、ヘッダーはHTTPよりすばらしい重要性を持っています。 彼らはトランザクションに関する重要情報を運びます、訪問者と訪問される人を含んでいて、受けることがあります、とアドレスが連絡して、組織(拡大名、登録パラメタ、および満期)は、いくつかを命名するために状態と呼んで、ルートと呼びます。 したがって、SIPサービスができるだけ多くのアクセスをこれらのヘッダーに持っているのは、重要です。 この理由で、CGIは非常に魅力的です。
Creation of responses: CGI is advantageous in that it can create
all parts of a response, including headers, status codes
and reason phrases, in addition to message bodies. This is
not the case for other mechanisms, such as Java servlets,
which are focused primarily on the body. In a SIP
environment, it is critical to be able to generate all
aspects of a response (and, all aspects of new or proxied
requests), since the body is usually not of central
importance in SIP service creation.
応答の作成: 応答のすべての部品を作成できるので、CGIは有利です、ヘッダー、ステータスコード、および理由句を含んでいて、メッセージ本体に加えて。 これはJavaサーブレットなどの他のメカニズムのためのそうではありません。(Javaサーブレットは主としてボディーに焦点を合わせられます)。 そして、SIP環境で、応答の全面を生成することができるのが重要である、(新しいかproxiedされた要求の全面)、通常、ボディーがSIPで中央に少しも重要でないので、作成を修理してください。
Lennox, et al. Informational [Page 4] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[4ページ]のRFC3050CGI
Component reuse: Many of the CGI utilities allow for easy
reading of environment variables, parsing of form data, and
often parsing and generation of header fields. Since SIP
reuses the basic RFC822 [3] syntax of HTTP, many of these
tools are applicable to SIP CGI.
コンポーネント再利用: CGIユーティリティの多くが環境変数(フォームデータ、しばしば構文解析、および世代のヘッダーフィールドの構文解析)の簡単な読書を考慮します。 SIPがHTTPの基本的なRFC822[3]構文を再利用するので、これらのツールの多くがSIP CGIに適切です。
Familiar environment: Many web programmers are familiar with
CGI.
身近な環境: 多くのウェブプログラマがCGIに詳しいです。
Ease of extensibility: Since CGI is an interface and not a
language, it becomes easy to extend and reapply to other
protocols, such as SIP.
伸展性の容易さ: CGIが言語ではなく、インタフェースであるので、他のプロトコルに広げて、再び使うのが簡単になります、SIPなどのように。
The generality, extensibility, and detailed control and access to information provided by CGI, coupled with the range of tools that exist for it, which can be immediately applied to SIP, make it a good mechanism for SIP service creation.
すぐにSIPに適用できるそれのために存在するツールの範囲に結びつけられたCGIによって提供された一般性、伸展性、詳細なコントロール、および情報入手はSIPサービス作成のためにそれを良いメカニズムにします。
3 Differences from HTTP CGI
HTTP CGIからの3つの違い
While SIP and HTTP share a basic syntax and a request-response model, there are important differences. Proxies play a critical role in services for SIP, while they are less important for HTTP. SIP servers can fork requests (proxying multiple requests when a single request is received), an important capability absent from HTTP. SIP supports additional features, such as registrations, which are absent from HTTP. These differences are reflected in the differences between SIP CGI and HTTP CGI. SIP CGI runs primarily on proxy, redirect, and registrar servers, rather than user agent servers (which are the equivalent of origin servers in HTTP). SIP CGI allows the script to perform specific messaging functions not supported in HTTP CGI (such as proxying requests), and SIP CGI introduces a persistence model that allow a script to maintain control through multiple message exchanges. HTTP CGI has no persistence for scripts.
SIPとHTTPは基本的な構文と要求応答モデルを共有しますが、重要な違いがあります。 プロキシはSIPのためにサービスにおける重要な役割を果たしますが、HTTPには、それらはそれほど重要ではありません。 SIPサーバは要求(ただ一つの要求が受信されているとき、複数の要求をproxyingして)、HTTPから欠けている重要な能力を分岐させることができます。 SIPは登録証明書などの付加的な機能をサポートします。(登録証明書はHTTPから欠けています)。 これらの違いはSIP CGIとHTTP CGIの違いに反映されます。 SIP CGIはプロキシ、主としてユーザエージェントサーバ(HTTPにおける発生源サーバの同等物である)よりむしろ再直接と記録係サーバで動きます。 SIP CGIはスクリプトにHTTP CGI(要求をproxyingなどなどの)でサポートされなかった特定のメッセージング機能を実行させます、そして、SIP CGIは複数の交換処理でスクリプトにコントロールを維持させる固執モデルを紹介します。 HTTP CGIには、スクリプトのための固執が全くありません。
Lennox, et al. Informational [Page 5] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[5ページ]のRFC3050CGI
3.1 Basic Model
3.1 基本型
The basic model for HTTP CGI is depicted in figure 1.
HTTP CGIのための基本型は図1に表現されます。
----- ------------
~~~~~~~~ |req | | -------- |
| |----------| | http | |
| client | |resp | | | server | |
| |----------| | | |w
~~~~~~~~ | | | -------- |e
----- | s| /\s |b
net | t| |t |
|e d| C |d |s
|n i| G |o |e
|v n| I |u |r
| | |t |v
| \/ | |e
| ------- |r
| | | |
| | CGI | |
| | prog. | |
| | | |
| ------- |
------------
----- ------------ ~~~~~~~~ |req| | -------- | | |----------| | http| | | クライアント| |resp| | | サーバ| | | |----------| | | |w~~~~~~~~ | | | -------- |e----- | s| /\s|bネット| t| |t| |e d| C|d|s|n i| G|o |e|nに対して| I|u|r| | |t|v| \/ | |e| ------- |r| | | | | | CGI| | | | prog。 | | | | | | | ------- | ------------
Figure 1: HTTP CGI Model
図1: HTTP CGIモデル
A client issues an HTTP request, which is passed either directly to the origin server (as shown), or is forwarded through a proxy server. The origin server executes a CGI script, and the CGI script returns a response, which is passed back to the client. The main job of the script is to generate the body for the response. Only origin servers execute CGI scripts, not proxy servers.
クライアントはHTTP要求を出します。(それは、直接発生源サーバ(示されるように)に合格されるか、またはプロキシサーバを通して転送されます)。発生源サーバはCGIスクリプトを実行します、そして、CGIスクリプトは応答を返します。(それは、クライアントに戻されます)。 スクリプトの主な仕事は応答のためにボディーを生成することです。 発生源サーバだけがプロキシサーバではなく、CGIスクリプトを実行します。
Lennox, et al. Informational [Page 6] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[6ページ]のRFC3050CGI
In a SIP server, the model is different, and is depicted in Figure 2.
SIPサーバで、モデルは、異なって、図2に表現されます。
~~~~~~~~ req ------- req ------- req ~~~~~~~~
| |------| |-------| |---------| |
| client | resp | server| resp | server| resp | client |
| |------| |-------| |---------| |
~~~~~~~~ ------- ------- --------
| | CGI
| |
-------
| |
| CGI |
| prog. |
| |
-------
~~~~~~~~ req------- req------- req~~~~~~~~ | |------| |-------| |---------| | | クライアント| resp| サーバ| resp| サーバ| resp| クライアント| | |------| |-------| |---------| | ~~~~~~~~ ------- ------- -------- | | CGI| | ------- | | | CGI| | prog。 | | | -------
Figure 2: SIP CGI Model
図2: 一口CGIモデル
The client generates a request, which is forwarded to a server. The server may generate a response (such as an error or redirect response). Or, if the server is a proxy server, the request is proxied to another server, and eventually to a user agent, and the response is passed back upstream, through the server, and back towards the client. A SIP proxy server may additionally fork requests, generating multiple requests in response to a received request. Generally, a proxy server will not generate the content in responses. These contain session descriptions created by user agents. Services, such as call forward and mobility services, are based on the decisions the server makes about (1) when, to where, and how many requests to proxy downstream, and (2) when to send a response back upstream. Creation of services such as ad-hoc bridging (where the server acts as a media mixer in a multiparty call, without being asked to do so by the end users) will require the server to generate new requests of its own, and for it to modify and generate the body in responses.
クライアントは要求を生成します。(要求はサーバに転送されます)。サーバは応答(誤りか再直接の応答などの)を生成するかもしれません。 または、要求はサーバがプロキシサーバであるなら、別のサーバにproxiedされます、そして、結局、ユーザエージェント、および応答には、上流とサーバを通したクライアントに向かった通っている後部があります。 受信された要求に対応して複数の要求を生成して、SIPプロキシサーバは要求をさらに、分岐させるかもしれません。 一般に、プロキシサーバは応答における内容を生成しないでしょう。 これらはユーザエージェントによって作成されたセッション記述を含んでいます。 呼び出しフォワードや移動性サービスなどのサービスは川下でサーバが(1) いつ頃にプロキシへのどこでいくつの要求にする決定に基づいていて、(2) いつ上流へ応答を返送するかをそうされます。 臨時のブリッジすることなど(尋ねられないで、サーバがメディアミキサーとして「マルチ-パーティー」呼び出しで機能するところでは、エンドユーザでそうする)のサービスの作成は、応答でボディーをそれ自身の新しい要求を生成して、変更して、生成するためにサーバを必要とするでしょう。
An HTTP server is mainly concerned about generation of responses. A SIP server is generally concerned about performing four basic operations:
HTTPサーバは応答のおよそ世代の間、主に関係があります。 SIPサーバは四則計算を実行することに関して一般に心配しています:
Proxying of Requests: Receiving a request, adding or modifying
any of the headers, deciding on a set of servers to forward
the request to, and forwarding it to them.
要求のProxying: サーバのセットでそれらに要求を転送して、それを送ると決めて、要求を受け取るか、加えるか、またはヘッダーのいずれも変更します。
Returning Responses: Receiving a response, adding or modifying
any of the headers, and passing the response towards the
client.
戻っている応答: 応答を受けて、ヘッダーのどれかを加えるか、または変更して、クライアントに向かって応答を渡します。
Lennox, et al. Informational [Page 7] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[7ページ]のRFC3050CGI
Generating Requests: Creating a new request, originating at the
server, placing headers and a body into the message, and
sending it to a server.
生成するのは以下を要求します。 新しい要求を作成して、サーバで起因して、ヘッダーとボディーをメッセージに置いて、それをサーバに送ります。
Generation of Responses: Receiving a request, generating a
response to it, and sending it back to the client.
応答の世代: 要求を受け取って、それへの応答を生成して、それをクライアントに送り返します。
When a request is received, one or more of the above operations may occur at once. For example, a SIP server may generate a provisional response, generate a new request, and proxy the original request to two servers. This implies that SIP CGI must encompass a greater set of functions than HTTP CGI. These functions are a super-set of the simple end-server request/response model.
要求がすぐに受信されているとき、上の操作の1つ以上は起こるかもしれません。 例えば、SIPサーバは暫定的な応答を生成するかもしれなくて、2つのサーバへのオリジナルの要求を新しい要求、およびプロキシに生成してください。 これは、SIP CGIがHTTP CGIより大きい関数群を取り囲まなければならないのを含意します。 これらの機能は簡単なエンドサーバ要求/応答モデルのスーパーセットです。
3.2 Persistence Model
3.2 固執モデル
In HTTP CGI, a script is executed once for each request. It generates the response, and then terminates. There is no state maintained across requests from the same user, as a general rule (although this can be done -- and is -- for more complex services such as database accesses, which essentially encapsulate state in client-side cookies or dynamically-generated URLs). A transaction is just a single request, and a response.
HTTP CGIでは、スクリプトは各要求のために一度作成されます。 それは、応答を生成して、次に、終わります。 同じユーザからの要求の向こう側に維持された状態が全くありません、概して(これは、クライアントサイドクッキーかダイナミックに発生しているURLで本質的には状態をカプセル化するデータベースアクセスなどの、より複雑なサービスのためのすることができて、ものですが)。 トランザクションは、ただただ一つの要求と、応答です。
In SIP CGI, since a request can generate many new and proxied requests, these themselves will generate responses. A service will often require these responses to be processed, and additional requests or responses to be generated. As a result, whereas an HTTP CGI script executes once per transaction, a SIP CGI script must maintain control somehow over numerous events.
SIP CGIでは、要求が多くの新しくてproxiedされた要求を生成することができるので、これら自体は応答を生成するでしょう。 サービスは、しばしば追加要求か応答が生成されるのをこれらの応答が処理されるのが必要であり、必要とするでしょう。 ところが、aとして、なってください。SIP CGIスクリプトがトランザクションに従って多数のイベントに関していったんどうにかコントロールを維持しなければならないと、HTTP CGIスクリプトは実行します。
In order to enable this, and to stay with the original CGI model, we mandate that a SIP CGI script executes when a message arrives, and after generating output (in the form of additional messages), terminate. State is maintained by allowing the CGI to return an opaque token to the server. When the CGI script is called again for the same transaction, this token is passed back to the CGI script. When called for a new transaction, no token is passed.
これを可能にして、オリジナルで滞在するために、CGIはモデル化されて、私たちはメッセージが到着するときSIP CGIスクリプトが実行する命令です、そして、出力(追加メッセージの形の)を生成した後に、終わってください。 CGIが不透明なトークンをサーバに返すのを許容することによって、状態は維持されます。CGIスクリプトが同じトランザクションのために再び呼ばれるとき、このトークンはCGIスクリプトに戻されます。 新しいトランザクションのために呼ばれる場合、トークンは全く通過されません。
For example, consider a request which arrives at a SIP server. The server calls a CGI script, which generates a provisional response and a proxied request. It also returns a token to the server, and then terminates. The response is returned upstream towards the client, and the request is proxied. When the response to the proxied request arrives, the script is executed again. The environment variables are set based on the content of the new response. The script is also passed back the token. Using the token as its state, the script decides to proxy the request to a different location. It therefore
例えば、SIPサーバに到着する要求を考えてください。サーバはCGIスクリプトを呼びます。(それは、暫定的な応答とproxied要求を生成します)。 それは、また、トークンをサーバに返して、次に、終わります。 上流へクライアントに向かって応答を返します、そして、要求をproxiedします。 proxied要求への応答が到着するとき、スクリプトは再び作成されます。 環境変数は新しい応答の内容に基づいて設定されます。 スクリプトはそうです、また、通過されて、トークンを支持してください。 状態としてトークンを使用して、スクリプトは別の場所への要求についてプロキシに決めます。 したがってそれ。
Lennox, et al. Informational [Page 8] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[8ページ]のRFC3050CGI
returns a proxied request, and another token. The server forwards this new request, and when the response comes, calls the CGI script once more, and passes back the token. This time, the script generates a final response, and passes this back to the server. The server sends the response to the client, destroys the token, and the transaction is complete.
proxied要求、および別のトークンを返します。 サーバはこの新しい要求、いつ応答が来て、呼び出しがもう一度のCGIスクリプトであるか、そして、およびパス後部にトークンを送ります。 今回、スクリプトは、最終的な応答を生成して、サーバへのこの後部を通過します。サーバは、応答をクライアントに送って、トークンを破壊します、そして、トランザクションは完全です。
3.3 SIP CGI Triggers
3.3 一口CGI引き金
In many cases, calling the CGI script on the reception of every message is inefficient. CGI scripts come at the cost of significant overhead since they generally require creation of a new process. Therefore, it is important in SIP CGI for a script to indicate, after it is called the first time, under what conditions it will be called for the remainder of the transaction. If the script is not called, the server will take the "default" action, as specified in this document. This allows an application designer to trade off flexibility for computational resources. Making an analogy to the Intelligent Network (IN) - a script is able to define the triggers for its future execution.
多くの場合、あらゆるメッセージのレセプションにCGIスクリプトを呼ぶのは効率が悪いです。 彼らが一般にニュープロセスの作成を必要とするので、CGIスクリプトは重要なオーバーヘッドの費用で来ます。 したがって、示すスクリプトに、それはSIP CGIで重要です、それが1回目と呼ばれた後に、それがトランザクションの残りのためにどんな状態に呼ばれるかの下で。 スクリプトが呼ばれないと、サーバは本書では指定されるとしての「デフォルト」行動を取るでしょう。 これで、アプリケーション設計者はコンピュータのリソースのために柔軟性を交換できます。 類推をIntelligent Network(IN)にします--スクリプトは今後の実行のための引き金を定義できます。
So, in summary, whereas an HTTP CGI script executes once during a transaction, a single SIP CGI script may execute many times during a transaction, and may specify at which points it would like to have control for the remainder of the transaction.
ところが、概要のそう、ただ一つのSIP CGIスクリプトが、トランザクションの間、いったんトランザクションの間の何回も実行して、それがどのポイントでトランザクションの残りのためのコントロールが欲しいかを指定するかもしれないと、HTTP CGIスクリプトは実行します。
3.4 Naming
3.4 命名
In HTTP CGI, the CGI script itself is generally the resource named in the request URI of the HTTP request. This is not so in SIP. In general, the request URI names a user to be called. The mapping to a script to be executed may depend on other SIP headers, including To and From fields, the SIP method, status codes, and reason phrases. As such, the mapping of a message to a CGI script is purely a matter of local policy administration at a server. A server may have a single script which always executes, or it may have multiple scripts, and the target is selected by some parts of the header.
HTTP CGIでは、一般に、CGIスクリプト自体はHTTP要求の要求URIで指定されたリソースです。 SIPでこれはそうではありません。 一般に、要求URIは、呼ばれるためにユーザを命名します。 実行されるべきスクリプトへのマッピングを他のSIPヘッダーに頼るかもしれません、To、From分野、SIPメソッド、ステータスコード、および理由句を含んでいて。 そういうものとして、CGIスクリプトへのメッセージに関するマッピングは純粋にサーバにおける地方の方針管理の問題です。シングルがいつもサーバでどれに原稿を書くかもしれないか、実行、それには、複数のスクリプトがあるかもしれなくて、目標はヘッダーの数個の一部によって選択されます。
3.5 Environment Variables
3.5 環境変数
In HTTP CGI, environment variables are set with the values of the paths and other aspects of the request. As there is no notion of a path in SIP, some of these environment variables do not make sense.
HTTP CGIでは、環境変数は要求の経路と他の局面の値で設定されます。 経路の概念が全くSIPにないとき、これらの環境変数のいくつかが理解できません。
Lennox, et al. Informational [Page 9] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[9ページ]のRFC3050CGI
3.6 Timers
3.6 タイマ
In SIP, certain services require that the script gets called not only when a message arrives, but when some timer expires. The classic example of this is "call forward no answer." To be implemented with SIP CGI, the first time the script is executed, it must generate a proxied request, and also indicate a time at which to be called again if no response comes. This kind of feature is not present in HTTP CGI, and some rudimentary support for it is needed in SIP CGI.
SIPでは、あるサービスは、あるタイマが期限が切れるとき、スクリプトが単にメッセージが到着するとき、呼ばれるのではなく、呼ばれるのを必要とします。 この典型例は「答えを全く前に呼ばない」ことです。 1回目に、SIP CGIと共に実装されるために、スクリプトが作成されて、応答が全く来ないなら、それは、proxied要求を生成して、また、再び呼ばれる時を示さなければなりません。 この種類の特徴はHTTP CGIに存在していません、そして、それの何らかの初歩的なサポートがSIP CGIで必要です。
4 Overview of SIP CGI
一口CGIの4概要
When a request arrives at a SIP server, initiating a new transaction, the server will set a number of environment variables, and call a CGI script. The script is passed the body of the request through stdin.
新しいトランザクションを開始して、要求がSIPサーバに到着するとき、サーバは、多くの環境変数を設定して、CGIスクリプトを呼ぶでしょう。 要求のボディーはstdinでスクリプトに通過されます。
The script returns, on stdout, a set of SIP action lines, each of which may be modified by CGI and/or SIP headers. This set is delimited through the use of two carriage returns. The action lines allow the script to specify any of the four operations defined above, in addition to the default operation. Generating a response is done by copying the the status line of the response into an action line of the CGI output. For example, the following will create a 200 OK to the original request:
スクリプトはstdoutで1セットのSIP要処置限界値を返します。それはCGI、そして/または、SIPヘッダーによってそれぞれ変更されるかもしれません。 このセットは2つの復帰の使用で区切られます。 スクリプトは要処置限界値で上で定義された四則のどれかを指定できます、デフォルト操作に加えて。 応答は、CGI出力の要処置限界値に応答の状況表示行をコピーすることによって、生成されます。 例えば、以下は200OKをオリジナルの要求に作成するでしょう:
SIP/2.0 200 OK
一口/2.0 200OK
The operation of proxying a request is supported by the CGI-PROXY- REQUEST CGI action, which takes the URL to proxy to as an argument. For example, to proxy a request to dante@inferno.com:
要求をproxyingする操作がCGI-PROXY- REQUEST CGI動作でサポートされる、議論として。(動作はプロキシにURLを取ります)。 例えば dante@inferno.com へのプロキシa要求に:
CGI-PROXY-REQUEST sip:dante@inferno.com SIP/2.0 Contact: sip:server1@company.com
CGI-PROXY-REQUEST一口: dante@inferno.com SIP/2.0Contact: 一口: server1@company.com
In this example, the server will take the original request, and modify any header fields normally changed during the proxy operation (such as decrementing Max-Forwards, and adding a Via field). This message is then "merged" with the output of the CGI script - SIP headers specified below the action line in the CGI output will be added to the outbound request. In the above example, the Contact header will be added. Note that the action line looks like the request line of a SIP request message. This is done in order to simplify parsing.
この例では、サーバは、オリジナルの要求を取って、通常、プロキシ操作(前方へマックスを減少させて、Via分野を加えなどなどの)の間に変えられたどんなヘッダーフィールドも変更するでしょう。 次に、このメッセージはCGIスクリプトの出力に「合併されます」--要処置限界値の下でCGI出力で指定されたSIPヘッダーは外国行きの要求に追加されるでしょう。 上記の例では、Contactヘッダーは加えられるでしょう。 要処置限界値がSIP要求メッセージの要求系列に似ていることに注意してください。 構文解析を簡素化するためにこれをします。
To delete headers from the outgoing request, the merge process also supports the CGI header CGI-Remove. Like SIP headers, CGI headers are written underneath the action line. They are extracted by the SIP server, and used to provide the server with additional guidance.
また、送信する要求、マージからヘッダーを削除するには、CGIヘッダーがCGIで取り除くサポートを処理してください。 SIPヘッダーのように、CGIヘッダーは要処置限界値の下に書かれています。 それらは、SIPサーバによって抽出されて、追加指導をサーバに提供するのに使用されます。
Lennox, et al. Informational [Page 10] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[10ページ]のRFC3050CGI
CGI headers always begin with CGI to differentiate them from SIP headers. In this case, the supported values for the CGI-Remove header are the names of headers in the original message.
CGIヘッダーはCGIでSIPヘッダーと彼らをいつも区別し始めます。 この場合、CGIで取り外しているヘッダーのためのサポートしている値はオリジナルのメッセージのヘッダーの名前です。
Returning of responses is more complex. A server may receive multiple responses as the result of forking a request. The script should be able to ask the server to return any of the responses it had received previously. To support this, the server will pass an opaque token to the script through environment variables, unique for each response received. To return a response, a CGI script needs to indicate which response is to be returned. For example, to return a response named with the token abcdefghij, the following output is generated:
応答の復帰は、より複雑です。 サーバは要求を分岐させるという結果として複数の応答を受けるかもしれません。 スクリプトは、それが以前に受けた応答のどれかを返すようにサーバに頼むことができるべきです。 これをサポートするために、サーバは環境変数にスクリプトへの不透明なトークンを通すでしょう、受けられた各応答において、ユニークです。 応答を返すために、CGIスクリプトは、返すために応答がどれであるかを示す必要があります。 例えば、トークンabcdefghijで指定された応答を返すために、以下の出力は発生しています:
CGI-FORWARD-RESPONSE abcdefghij SIP/2.0
CGI-FORWARD-RESPONSE abcdefghij SIP/2.0
Finally, if the script does not output any of the above actions, the server does what it would normally do upon receiving the message that triggered the script.
最終的に、スクリプトが上の動作のいずれも出力しないなら、サーバはスクリプトの引き金となったメッセージを受け取るとき通常、それがすることをします。
A SIP CGI script is normally only executed when the original request arrives. If the script also wants to be called for subsequent messages in a transaction -- due to responses to proxied requests, or (in certain circumstances) ACK and CANCEL requests, it can perform the CGI-AGAIN action:
オリジナルの要求が到着するときだけ、通常、SIP CGIスクリプトは実行されます。 スクリプトのproxied要求への応答のためトランザクションにおけるその後のメッセージのために呼ばれるべき必需品も、または(ある特定の状況では)ACKであるなら、キャンセル要求であり、CGI-AGAIN動作を実行できます:
CGI-AGAIN yes SIP/2.0
CGI-AGAINはいのSIP/2.0
This action applies only to the next invocation of the script; it means to invoke the script one more time. Outputting "no" is identical to outputting "yes" on this invocation of the script and outputting nothing the next time the script is called.
この動作はスクリプトの次の実施だけに適用されます。 それは、より多くの1回の間、スクリプトを呼び出すことを意味します。 「いいえ」を出力するのはスクリプトのこの実施で「はい」を出力して、スクリプトが呼ばれる次の時に何も出力しないのと同じです。
When the script is re-executed, it may need access to some state in order to continue processing. A script can generate one piece of state, called a cookie, for any new request or proxied request. It is passed to the server through the CGI-SET-COOKIE action. The action contains a token, which is the cookie itself. The server does not examine or parse the cookie. It is simply stored. When the script is re-executed, the cookie is passed back to the script through an environment variable.
スクリプトが実行し直されるとき、それは、処理し続けるために何らかの状態へのアクセスを必要とするかもしれません。 スクリプトはどんな新しい要求やproxied要求のためにもクッキーと呼ばれる1つの状態を生成することができます。 それはCGI-SET-COOKIE動作でサーバに通過されます。 動作はトークンを含んでいます。(それは、クッキー自体です)。 サーバは、クッキーを調べもしませんし、分析もしません。 それは単に保存されます。 スクリプトが実行し直されるとき、クッキーは環境変数を通してスクリプトに戻されます。
CGI-SET-COOKIE khsihppii8asdl SIP/2.0
CGI-SET-COOKIE khsihppii8asdl SIP/2.0
Finally, when the script causes the server to proxy a request, responses to these requests will arrive. To ease matching of responses to requests, the script can place a request token in the CGI CGI-Request-Token header. This header is removed by the server
最終的に、スクリプトがプロキシへの要求をサーバに引き起こすと、これらの要求への応答は到着するでしょう。 要求への応答のマッチングを緩和するために、スクリプトはCGI CGI要求トークンヘッダーに要求トークンを置くことができます。 サーバはこのヘッダーを取り除きます。
Lennox, et al. Informational [Page 11] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[11ページ]のRFC3050CGI
when the request is proxied. Any responses received to this request will have the token passed in an environment variable.
要求がproxiedされると。 この要求に受けられたどんな応答でも、環境変数でトークンを通過するでしょう。
5 SIP CGI Specification
5 一口CGI仕様
5.1 Introduction
5.1 序論
5.1.1 Relationship with HTTP CGI
5.1.1 HTTP CGIとの関係
This SIP CGI specification is based on work-in-progress revision 1.1 of the HTTP CGI specification [1]. That document is a product of the CGI-WG mailing list, which is not an official IETF working group. CGI-WG's homepage is located at the URL http://Web.Golux.Com/coar/cgi/, and the most recent versions of the CGI specification are available there. This specification incorporates a great deal of text from the work-in-progress version of that document as of February 23, 2000. A future version of this specification may be changed to cite parts of that document by reference instead.
このSIP CGI仕様はHTTP CGI仕様[1]の処理中の作業改正1.1に基づいています。 そのドキュメントはCGI-WGメーリングリストの製品です。(それは、公式のIETFワーキンググループではありません)。 CGI-WGのホームページはURL http://Web.Golux.Com/coar/cgi/ に位置しています、そして、CGI仕様の最新のバージョンはそこで入手できます。 この仕様は2000年2月23日現在、そのドキュメントの処理中の作業バージョンからの多くのテキストを取り入れます。 代わりに参照でそのドキュメントの部分を引用するためにこの仕様の将来のバージョンを変えるかもしれません。
5.1.2 Conventions of This Document
5.1.2 このドキュメントのコンベンション
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant SIP CGI implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[4]について説明して、対応する一口CGI実装のために要件レベルを示すとき解釈されることであるべきですか?
Some paragraphs are indented, like this; they give
motivations of design choices, or questions for future
discussion in the development of SIP CGI. They are not
normative to the specification of the protocol.
数個のパラグラフがこのように字下がりにされます。 彼らはSIP CGIの開発における今後の議論のためにデザイン選択、または質問の動機を与えます。 それらはプロトコルの仕様に規範的ではありません。
5.1.3 Specifications
5.1.3 仕様
Not all of the functions and features of SIP CGI are defined in the main part of this specification. The following phrases are used to describe the features which are not specified:
機能のすべてとSIP CGIのどんな特徴もこの仕様の主部で定義されません。 以下の句は指定されない特徴について説明するのに使用されます:
System-defined: The feature may differ between systems, but
must be the same for different implementations using the
same system. A system will usually identify a class of
operating systems. Some systems are defined in section 6
of this document. New systems may be defined by new
specifications without revision of this document.
システムで定義される: 特徴は、システムの間で異なるかもしれませんが、異なった実装に、同じシステムを使用するのにおいて同じであるに違いありません。 通常、システムはオペレーティングシステムのクラスを特定するでしょう。いくつかのシステムがこのドキュメントのセクション6で定義されます。 新しいシステムはこのドキュメントの改正なしで新しい仕様で定義されるかもしれません。
Implementation-defined: The behavior of the feature may vary
from implementation to implementation, but a particular
implementation should be consistent in its behavior.
実装で定義される: 実装によって特徴の振舞いは異なるかもしれませんが、特定の実装は振舞いで一貫しているべきです。
Lennox, et al. Informational [Page 12] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[12ページ]のRFC3050CGI
5.1.4 Terminology
5.1.4 用語
This specification uses many terms defined in the SIP/2.0 specification [2]; however, the following terms are used here in a sense which may not accord with their definitions in that document, or with their common meaning.
この仕様はSIP/2.0仕様[2]に基づき定義された多くの用語を使用します。 しかしながら、そのドキュメント、またはそれらの一般的な意味がある彼らの定義と一致しないかもしれない次の用語がある意味でここで使用されます。
metavariable: A named parameter that carries information from
the server to the script. It is not necessarily a
variable in the operating system's environment, although
that is the most common implementation.
metavariable: サーバからスクリプトまで情報を運ぶ命名されたパラメタ。 それは最も一般的な実装ですが、それは必ずオペレーティングシステムの環境で変数であるというわけではありません。
script: The software which is invoked by the server via this
interface. It need not be a standalone program, but
could be a dynamically-loaded or shared library, or even
a subroutine in the server. It may be a set of
statements interpreted at run-time, as the term `script'
is frequently understood, but that is not a requirement
and within the context of this specification the term has
the broader definition stated.
スクリプト: このインタフェースを通してサーバによって呼び出されるソフトウェア。 それは、スタンドアロンプログラムである必要はありませんが、サーバのダイナミックに満載の、または、共有ライブラリの、または、同等のaサブルーチンであるかもしれません。'スクリプト'という用語が頻繁に理解されていますが、それが要件でなく、用語がこの仕様の文脈の中に述べられたより広い定義を持っているのでランタイムのときに解釈された1セットの声明であるかもしれません。
server: The application program which invokes the script in
order to service messages.
サーバ: メッセージを修理するためにスクリプトを呼び出すアプリケーション・プログラム。
message: A SIP request or response, typically either the one
that triggered the invocation of the CGI script, or one
that the CGI script caused to be sent.
メッセージ: SIP要求か応答(通常CGIスクリプトの実施の引き金となったものかCGIスクリプトで送ったもののどちらか)。
5.2 Notational Conventions and Generic Grammar
5.2 記号法のコンベンションとジェネリック文法
In this specification we use the Augmented Backus-Naur Form notation as described in appendix C of the SIP/2.0 specification, RFC 2543 [2].
この仕様では、私たちはSIP/2.0仕様(RFC2543[2])の付録Cで説明されるようにAugmentedバッカス記法記法を使用します。
The following grammatical constructs are taken from other documents; this table lists the appropriate sources.
以下の文法的な構造物は他のドキュメントから抜粋されます。 このテーブルは適切なソースを記載します。
OCTET SIP/2.0 [2] Appendix C.1
CHAR SIP/2.0 [2] Appendix C.1
digit SIP/2.0 [2] Appendix C.1
alphanum SIP/2.0 [2] Appendix C.1
token SIP/2.0 [2] Appendix C.1
hostname SIP/2.0 [2] Section 2
SIP-URL SIP/2.0 [2] Section 2
SIP-Version SIP/2.0 [2] Section 4.3.1
Status-Code SIP/2.0 [2] Section 5.1.1
Reason-Phrase SIP/2.0 [2] Section 5.1.1
media-type HTTP/1.1 [5] Section 3.7
OCTET SIP/2.0[2]付録C.1 CHAR SIP/2.0[2]付録C.1ケタSIP/2.0[2]付録C.1 alphanum SIP/2.0[2]付録C.1トークンSIP/2.0[2]付録C.1ホスト名SIP/2.0[2]部分2のSIP-URL SIP/2.0[2]部分2のSIP-バージョンSIP/2.0[2]部分4.3.1Status-コードSIP/2.0[2]部5.1の.1Reason-句のSIP/2.0[2]部5.1の.1メディアタイプHTTP/1.1[5]部3.7
Lennox, et al. Informational [Page 13] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[13ページ]のRFC3050CGI
(via SIP/2.0 [2] Section 6.16)
field-name SIP/2.0 [2] Section 6.6
(SIP/2.0[2]セクション6.16を通した) フィールド名SIP/2.0[2]部6.6
Other grammatical constructs taken from outside sources are noted in the text.
外部のソースから取られた他の文法的な構造物はテキストに述べられます。
5.3 Invoking the Script
5.3 スクリプトを呼び出すこと。
The script is invoked in a system-defined manner. Unless specified otherwise, the file containing the script will be invoked as an executable program.
スクリプトはシステムで定義された方法で呼び出されます。 別の方法で指定されないと、スクリプトを含むファイルは実行可能プログラムとして呼び出されるでしょう。
Only one CGI script at a time may be outstanding for a SIP transaction. If subsequently arriving responses would cause a CGI script to be invoked, handling of them is deferred, except for ACK, until CGI scripts for previous messages in the transaction terminate. Messages are processed in the order they are received.
SIPトランザクションにおいて、一度に1つのCGIスクリプトだけが傑出しているかもしれません。 次に到着している応答でCGIスクリプトを呼び出すなら、それらの取り扱いは延期されます、ACKを除いて、トランザクションにおける前のメッセージのためのCGIスクリプトが終わるまで。 メッセージはオーダーで処理されて、それらが受け取られているということです。
5.4 The SIP CGI Script Command Line
5.4 一口CGIスクリプトコマンドライン
The server SHOULD NOT provide any command line arguments to the script.
サーバSHOULD NOTはどんなコマンドライン議論もスクリプトに提供します。
Command line arguments are used for indexed queries in HTTP
CGI; HTTP indexed queries do not have an equivalent in SIP.
コマンドライン議論はHTTP CGIでの索引をつけられた質問に使用されます。 HTTPの索引をつけられた質問はSIPに同等物を持っていません。
5.5 Data Input to the SIP CGI Script
5.5 一口CGIスクリプトへのデータの入力
Information about a message comes from two different sources: the message header, and any associated content-body. Servers MUST make portions of this information available to scripts.
メッセージに関する情報は2人のさまざまな原因から来ます: メッセージヘッダー、およびどんな関連満足しているボディー。 サーバで、この情報の部分はスクリプトに利用可能にならなければなりません。
5.5.1 Message Metadata (Metavariables)
5.5.1 メッセージメタデータ(Metavariables)
Each SIP CGI server implementation MUST define a mechanism to pass data about the message from the server to the script. The metavariables containing these data are accessed by the script in a system-defined manner. The representation of the characters in the metavariables is system-defined.
それぞれのSIP CGIサーバ実装は、サーバからスクリプトまでメッセージに関するデータを通過するためにメカニズムを定義しなければなりません。 スクリプトでシステムで定義された方法でこれらのデータを含むmetavariablesにアクセスします。 metavariablesのキャラクタの表現はシステムによって定義されています。
The representation of metavariables MUST distinguish between undefined values (which are not present) and null values (which are present, but have zero length). Null values are only allowed for those metavariables whose grammar permits this.
metavariablesの表現は未定義値(存在していない)とヌル値(存在していますが、ゼロ・レングスを持っている)を見分けなければなりません。 ヌル値は文法がこれを可能にするそれらのmetavariablesのために許容されているだけです。
Lennox, et al. Informational [Page 14] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[14ページ]のRFC3050CGI
For historical reasons, HTTP CGI does not distinguish
between null values and undefined values. This
specification eliminates this misfeature; null values and
undefined values are semantically different.
歴史的な理由で、HTTP CGIはヌル値と未定義値を見分けません。 この仕様はこのmisfeatureを排除します。 ヌル値と未定義値は意味的に異なっています。
Case is not significant in the metavariable names, in that there
cannot be two different variables whose names differ in case only.
Here they are shown using a canonical representation of capitals plus
underscore ("_"). The actual representation of the names is system
defined; for a particular system the representation MAY be defined
differently than this.
ケースはmetavariable名で重要ではありません、名前が場合だけにおいて異なる2つの異なった変数があるはずがないので。 ここで、彼らは、首都の正準な表現を使用するのが示されて、("_")の下線を引きます。 名前の実際の表現は定義されたシステムです。 特定のシステムにおいて、表現はこれと異なって定義されるかもしれません。
Metavariable values MUST be considered case-sensitive except as noted otherwise.
別の方法で注意されるのを除いて、大文字と小文字を区別しているとMetavariable値を考えなければなりません。
The canonical metavariables defined by this specification are:
この仕様で定義された正準なmetavariablesは以下の通りです。
AUTH_TYPE
CONTENT_LENGTH
CONTENT_TYPE
GATEWAY_INTERFACE
REMOTE_ADDR
REMOTE_HOST
REMOTE_IDENT
REMOTE_USER
REGISTRATIONS
REQUEST_METHOD
REQUEST_TOKEN
REQUEST_URI
RESPONSE_STATUS
RESPONSE_REASON
RESPONSE_TOKEN
SCRIPT_COOKIE
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
リモートリモートリモートAUTHの_IDENTリモート_ユーザ_タイプ内容_長さの内容_タイプゲートウェイ_インタフェース_ADDR_ホスト登録証明書は_メソッド要求_トークン要求_URI応答_状態応答_理由応答_トークンスクリプト_クッキーサーバ_ネームサーバ_ポートサーバ_プロトコルサーバ_ソフトウェアを要求します。
Metavariables with names beginning with the protocol name (e.g., "SIP_ACCEPT") are also canonical in their description of message header fields. The number and meaning of these fields may change independently of this specification. (See also section 5.5.1.5.)
また、名前がプロトコル名(例えば、「一口_は受け入れる」)で始まっているMetavariablesも彼らのメッセージヘッダーフィールドの記述で正準です。 これらの分野の数と意味はこの仕様の如何にかかわらず変化するかもしれません。 (また、.5にセクション5.5.1を見ます)
A server MAY also specify additional non-canonical metavariables.
また、サーバは追加正典外のmetavariablesを指定するかもしれません。
Lennox, et al. Informational [Page 15] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[15ページ]のRFC3050CGI
5.5.1.1 AUTH_TYPE
5.5.1.1 AUTH_タイプ
If the target of the message required access authentication for external access, then the server MUST set the value of this variable from the auth-scheme token in the message's Authorization header field. Otherwise it is not defined.
メッセージの目標が外部のアクセスのためのアクセス認証を必要としたなら、サーバはメッセージのAuthorizationヘッダーフィールドにおけるauth-体系トークンからこの変数の値を設定しなければなりません。 さもなければ、それは定義されません。
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | "PGP" | token
AUTH_タイプが等しい、「」| auth-体系auth-体系=「基本的です」。| 「読みこなしてください」| "PGP"| トークン
SIP access authentication schemes are described in sections 14 and 15 of the SIP/2.0 specification [2]. The auth-scheme is not case- sensitive.
SIPアクセス認証体系はSIP/2.0仕様[2]のセクション14と15で説明されます。 auth-体系はケース敏感ではありません。
Servers MUST provide this metavariable to scripts if the message header included an Authorization field that was authenticated.
メッセージヘッダーが認証されたAuthorization分野を入れたなら、サーバはこのmetavariableをスクリプトに提供しなければなりません。
For the complex authentication schemes, the server SHOULD perform the authentication checking itself. If the authentication failed, this metavariable SHOULD NOT be set.
複雑な認証体系のために、サーバSHOULDは自制する認証を実行します。 認証は失敗して、これはmetavariable SHOULDです。設定されません。
If several authentication credentials, with multiple schemes, are present in the message, this variable SHOULD be set to correspond to the authenticated credentials with the strongest scheme the server supports. If credentials are present for several domains, the server SHOULD NOT perform any action on credentials from domains external to it.
いくつかの認証資格証明書が最も強い体系で認証された資格証明書に相当するセットがサーバサポートであったなら複数の体系と共にメッセージ、この可変SHOULDに存在していた状態であるなら。 資格証明書がいくつかのドメインに存在しているなら、サーバSHOULD NOTはそれへの外部のドメインから資格証明書へのどんな動作も実行します。
If both Authorization and Proxy-Authorization headers are present, the server SHOULD perform the authorizations based on the appropriate header for the context in which it is running. For example, a server which is a proxy server and a registrar would use Authorization headers for REGISTER messages aimed at its local domains, and Proxy- Authorization headers for all other messages.
AuthorizationとProxy-承認ヘッダーの両方が出席しているなら、サーバSHOULDはそれが稼働する予定である文脈のために適切なヘッダーに基づく承認を実行します。 例えば、プロキシサーバと記録係であるサーバは、局所領域が向けられたREGISTERメッセージにAuthorizationヘッダーを使用して、他のすべてのメッセージにProxy承認ヘッダーを使用するでしょう。
5.5.1.2 CONTENT_LENGTH
5.5.1.2 内容_長さ
This metavariable is set to the size of the message-body entity attached to the message, if any, in decimal number of octets. If no data are attached, then this metavariable is not defined. The syntax is the same as for the SIP Content-Length header field (section 6.15, SIP/2.0 specification [2]).
このmetavariableはメッセージに付けられたメッセージ本体実体のサイズに用意ができています、もしあれば、八重奏の10進数で。 どんなデータも添付していないなら、このmetavariableは定義されません。 構文はSIP Content-長さのヘッダーフィールドのように同じです。(セクション6.15、SIP/2.0仕様[2])。
CONTENT_LENGTH = "" | 1*digit
内容_長さが等しい、「」| 1*ケタ
Servers MUST provide this metavariable to scripts if the message was a accompanied by a content-body entity, even if the message did not include a Content-Length header field.
サーバはメッセージが満足しているボディー実体によって伴われたaであったならこのmetavariableをスクリプトに提供しなければなりません、メッセージがContent-長さのヘッダーフィールドを含まなかったとしても。
Lennox, et al. Informational [Page 16] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[16ページ]のRFC3050CGI
5.5.1.3 CONTENT_TYPE
5.5.1.3 内容_はタイプします。
If the message includes a message-body, CONTENT_TYPE is set to the Internet Media Type [6] of the attached entity if the type was provided via a Content-type field in the message header, or if the server can determine it in the absence of a supplied Content-type field. The syntax is the same as for the SIP Content-Type header field.
メッセージがメッセージ本体を含んでいるなら、メッセージヘッダーの文書内容分野を通してタイプを提供したか、またはサーバが供給された文書内容分野がないときそれを決定できるなら、CONTENT_TYPEは付属実体のインターネットメディアType[6]に用意ができています。 構文はSIPコンテントタイプヘッダーフィールドのように同じです。
CONTENT_TYPE = "" | media-type
内容_が=をタイプする、「」| メディアタイプ
The type, subtype, and parameter attribute names are not case- sensitive. Parameter values MAY be case sensitive. Media types and their use in SIP are described in section 6.16 of the SIP/2.0 specification [2], and by reference in section 3.7 of the HTTP/1.1 specification [5].
タイプ、「副-タイプ」、およびパラメタ属性名はケース敏感ではありません。 パラメタ値は大文字と小文字を区別しているかもしれません。 メディアタイプとSIPにおける彼らの使用はSIP/2.0仕様[2]のセクション6.16、およびHTTP/1.1仕様[5]のセクション3.7での参照で説明されます。
Since in SIP the Content-Type header MUST be specified if a body is present, servers MUST provide this metavariable to scripts if a body was present in the original message, unless the "body" is actually an encrypted payload.
ボディーが存在しているならSIPでコンテントタイプヘッダーを指定しなければならないので、ボディーがオリジナルのメッセージに存在していたなら、サーバはこのmetavariableをスクリプトに提供しなければなりません、「ボディー」が実際に暗号化されたペイロードでないなら。
5.5.1.4 GATEWAY_INTERFACE
5.5.1.4 ゲートウェイ_は連結します。
This metavariable is set to the dialect of SIP CGI being used by the server to communicate with the script. Syntax:
このmetavariableはサーバによって使用される、スクリプトで交信するSIP CGIの方言に用意ができています。 構文:
GATEWAY_INTERFACE = "SIP-CGI" "/" major "." minor
major = 1*digit
minor = 1*digit
「ゲートウェイ_INTERFACE=「一口CGI」」/、」 少佐、」 . 」 1*ケタ小さい方の主要な=未成年者=1*ケタ
Note that the major and minor numbers are treated as separate integers and hence each may be more than a single digit. Thus SIP- CGI/2.4 is a lower version than SIP-CGI/2.13 which in turn is lower than SIP-CGI/12.3. Leading zeros in either the major or the minor number MUST be ignored by scripts and SHOULD NOT be generated by servers.
主要で小さい方の数が別々の整数として扱われて、したがって、一桁よりそれぞれ多いかもしれないことに注意してください。 したがって、SIP CGI/2.4は順番に低いSIP-CGI/2.13より低いSIP-CGI/12.3よりバージョンです。 スクリプトとSHOULD NOTは主要な数か小さい方の数における先行ゼロを無視しなければなりません。サーバで、生成されます。
This document defines the 1.1 version of the SIP CGI interface
("SIP-CGI/1.1").
このドキュメントがSIP CGIインタフェースの1.1バージョンを定義する、(「一口CGI/1.1インチ)」
Servers MUST provide this metavariable to scripts.
サーバはこのmetavariableをスクリプトに提供しなければなりません。
For maximal compatibility with existing HTTP CGI libraries,
we want to keep this as similar as possible to the syntax
of CGI 1.1. However, we do want it to be clear that this is
indeed SIP CGI. Making HTTP CGI's version identifier a
substring of the SIP CGI identifier seemed like a
既存のHTTP CGIライブラリとの最大限度の互換性のために、できるだけCGI1.1の構文と同様にこれを保ちたいと思います。 しかしながら、私たちは、本当に、これがSIP CGIであることが明確になるようにそれが欲しいと思います。 HTTP CGIのバージョン識別子をSIP CGI識別子に関するサブストリングにするように同様のaに思えました。
Lennox, et al. Informational [Page 17] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[17ページ]のRFC3050CGI
reasonable compromise. (The existing CGI libraries we
checked do not seem to check the version.)
妥当な感染。 (私たちがチェックした既存のCGIライブラリはバージョンをチェックするように思えません。)
5.5.1.5 Protocol-Specific Metavariables
5.5.1.5 プロトコル特有のMetavariables
These metavariables are specific to the protocol via which the method is sent. Interpretation of these variables depends on the value of the SERVER_PROTOCOL metavariable (see section 5.5.1.20).
これらのmetavariablesはを通したメソッドを送るプロトコルに特定です。 セクション5.5を見てください。これらの変数の解釈をSERVER_プロトコルmetavariableの値に依存する、(.1 .20)。
Metavariables with names beginning with "SIP_" contain values from the message header, if the protocol used was SIP. Each SIP header field name is converted to upper case, has all occurrences of "-" replaced with "_", and has "SIP_" prepended to form the metavariable name. Similar transformations are applied for other protocols. The header data MAY be presented as sent by the client, or MAY be rewritten in ways which do not change its semantics. If multiple header fields with the same field-name are received then the server MUST rewrite them as though they had been received as a single header field having the same semantics before being represented in a metavariable. Similarly, a header field that is received on more than one line MUST be merged into a single line. The server MUST, if necessary, change the representation of the data (for example, the character set) to be appropriate for a CGI metavariable.
名前が「一口_」で始まっているMetavariablesは使用されるプロトコルが一口であったならメッセージヘッダーからの値を含んでいます。 それぞれのSIPヘッダーフィールド名で、大文字に変換されて、「-」のすべての発生を"_"に取り替えさせて、metavariable名を形成するために「一口_」をprependedします。 相似変換は他のプロトコルのために適用されます。 ヘッダー・データ5月は、クライアントによって送られるように提示されるか、または意味論を変えない方法で書き直されるかもしれません。 同じフィールド名がある複数のヘッダーフィールドが受け取られているなら、サーバはまるでmetavariableに表される前に同じ意味論を持っているただ一つのヘッダーフィールドとしてそれらを受け取ったかのようにそれらを書き直さなければなりません。 同様に、1つ以上の系列に受け取られるヘッダーフィールドを単線に合併しなければなりません。 必要なら、サーバは、CGI metavariableに適切になるようにデータ(例えば、文字集合)の表現を変えなければなりません。
Note: these metavariables' names were changed from HTTP_*
to SIP_* since the first draft of this specification. The
intention had been to make it easier to use existing CGI
libraries unmodified, but this convenience was felt to be
outweighed by the confusion this introduced.
以下に注意してください。 この仕様の最初の草稿以来これらのmetavariablesの名前はHTTP_*からSIP_*に変わりました。 意志が変更されていなく既存のCGIライブラリを使用するのをより簡単にすることでしたが、この便利はこれが導入した混乱より軽いと感じられました。
Servers are not required to create metavariables for all the message header fields they receive. However, because of the relatively high importance of headers in SIP for messages' semantic content, the server SHOULD provide all headers which do not contain potentially sensitive authorization information, such as Authorization. Servers SHOULD provide protocol-specific metavariables even for information which is available through other SIP CGI metavariables, such as CONTENT_LENGTH and CONTENT_TYPE.
サーバは、彼らが受けるすべてのメッセージヘッダーフィールドのためにmetavariablesを作成するのに必要ではありません。 しかしながら、メッセージの意味内容のためのSIPのヘッダーの比較的高い重要性のために、サーバSHOULDは潜在的に機密の承認情報を含まないすべてのヘッダーを提供します、Authorizationなどのように。 サーバSHOULDは他のSIP CGI metavariablesを通して利用可能な情報にさえプロトコル特有のmetavariablesを提供します、CONTENT_LENGTHやCONTENT_TYPEのように。
This allows a SIP CGI script to determine, if necessary,
whether the information in the other metavariables was in
the original message, or was synthesized by the server.
必要なら、これで、SIP CGIスクリプトは、他のmetavariablesの情報がオリジナルのメッセージにあったか、またはサーバによって統合されたかを決定できます。
5.5.1.6 REGISTRATIONS
5.5.1.6 登録証明書
This metavariable contains a list the current locations the server has registered for the user in the Request-URI of the initial request of a transaction. It is syntactically identical to the protocol
このmetavariableはリストを含んでいます。サーバにはある現在の位置はトランザクションの初期の要求のRequest-URIでユーザに登録しました。 それはシンタクス上プロトコルと同じです。
Lennox, et al. Informational [Page 18] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[18ページ]のRFC3050CGI
metavariable SIP_CONTACT, and thus is defined by section 5.5.1.5 of this document and by section 6.13 of the SIP/2.0 specification [2]. It contains all the uris, uri parameters, display names, and contact parameters for the addresses registered with the server.
定義されて、5.5を区分してください。metavariable SIP_CONTACT、その結果、存在、.1 この.5通のドキュメントとセクションのそばの6.13のSIP/2.0仕様[2]。 それはサーバに登録されたアドレスのためのすべてのuris、uriパラメタ、ディスプレイ名、および連絡パラメタを含んでいます。
The syntax of REGISTRATIONS is identical to how SIP_CONTACT
would appear in a 302 response from a redirection server.
This allows parsing code to be re-used.
REGISTRATIONSの構文はSIP_CONTACTがリダイレクションサーバから302応答にどう現れるだろうかと同じです。これは、構文解析コードが再使用されるのを許容します。
If a user's registrations change in the course of a transaction, the server SHOULD update this metavariable accordingly for subsequent script invocations for the transaction.
トランザクションの間のユーザー登録変化であるなら、サーバSHOULDはトランザクションのためのその後のスクリプト実施のためにそれに従って、このmetavariableをアップデートします。
5.5.1.7 REMOTE_ADDR
5.5.1.7 リモート_ADDR
The IP address of the client that sent the message to the server. This is not necessarily that of the originating user agent client or server.
必ず起因しているユーザエージェントのクライアントかサーバのものではなく、メッセージをサーバに送ったクライアントのIPアドレス。
REMOTE_ADDR = hostnumber
hostnumber = IPv4address | IPv6address
REMOTE_ADDR=hostnumber hostnumberはIPv4addressと等しいです。| IPv6address
The definitions of IPv4address and Ipv6address are provided in Appendix B of RFC 2373 [7].
RFC2373[7]のAppendix BにIPv4addressとIpv6addressの定義を提供します。
For locally-generated responses (see section 5.8), this SHOULD be the loopback address (i.e., 127.0.0.1 for IPv4 or ::1 for IPv6).
局所的に発生している応答(セクション5.8を見る)、このSHOULD、ループバックアドレスになってください、(すなわち、127.0、.0、: : IPv4のための.1かIPv6のための1、)
Servers MUST supply this value to scripts.
サーバはこの値をスクリプトに供給しなければなりません。
5.5.1.8 REMOTE_HOST
5.5.1.8 リモート_ホスト
This is the fully qualified domain name of the host sending the message to this server, if available, otherwise not defined. (See section 5.5.1.7). Domain names are not case sensitive.
これはこのサーバにメッセージを送るホストの完全修飾ドメイン名です、利用可能であるなら、別の方法で定義されないで。 セクション5.5を見てください。(.1 .7)。 ドメイン名は大文字と小文字を区別していません。
REMOTE_HOST = hostname
REMOTE_HOSTはホスト名と等しいです。
Servers SHOULD provide this information to scripts.
サーバSHOULDはこの情報をスクリプトに提供します。
5.5.1.9 REMOTE_IDENT
5.5.1.9 リモート_IDENT
The identity information supported about the connection by a RFC 1413 [8] request, if available.
RFC1413[8]要求で接続に関してサポートしていて、利用可能なアイデンティティ情報。
REMOTE_IDENT = *CHAR
リモート_IDENT=*炭
Lennox, et al. Informational [Page 19] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[19ページ]のRFC3050CGI
The server MAY choose not to support this feature, and it is anticipated that not many implementations will, as the information is not particularly useful in the presence of complex proxy paths.
サーバは、この特徴をサポートしないのを選ぶかもしれません、そして、それほど多くない実装がそうすると予期されます、情報が複雑なプロキシ道があるとき特に役に立たないので。
5.5.1.10 REMOTE_USER
5.5.1.10 リモート_ユーザ
If the message requested authentication (i.e., the AUTH_TYPE metavariable is set), then the value of the REMOTE_USER metavariable is set to the user-ID supplied for the authentication. For Basic authentication this is the content of the (decoded) "userid" grammar element; for Digest it is content of "username-value." For PGP authentication, it is the URI specified in the "signed-by" parameter of the Authorization header, if present, otherwise the URI part of the From header.
メッセージが認証を要求したなら(すなわち、AUTH_TYPE metavariableは用意ができています)、REMOTE_USER metavariableの値は認証に供給されたユーザIDに設定されます。 Basic認証のために、これは(解読されます)「ユーザID」文法要素の内容です。 Digestに関しては、それは「ユーザ名値」の内容です。 そうでなければ、PGP認証のために、それは「署名されて」Authorizationヘッダーのパラメタで指定されて、現在のURI、FromヘッダーのURI一部です。
If some other authentication scheme was requested, this metavariable SHOULD be set to an appropriate component of the authorization information identifying the user or entity associated with the credentials. If authentication was not requested, this metavariable is not defined.
体系はある他の認証であるなら要求されました、このmetavariable SHOULD。承認情報の適切な成分に資格証明書に関連しているユーザか実体を特定するように設定されてください。 認証が要求されなかったなら、このmetavariableは定義されません。
REMOTE_USER = *OCTET
リモート_ユーザ=*八重奏
Servers SHOULD provide this metavariable to scripts.
サーバSHOULDはこのmetavariableをスクリプトに提供します。
5.5.1.11 REQUEST_METHOD
5.5.1.11 _メソッドを要求してください。
If the message triggering the script was a request, the REQUEST_METHOD metavariable is set to the method with which the request was made, as described in section 4.2 of the SIP/2.0 specification [2]; otherwise not defined.
スクリプトの引き金となったメッセージが要求であったなら、REQUEST_METHOD metavariableは要求がされたメソッドに用意ができています、SIP/2.0仕様[2]のセクション4.2で説明されるように。 別の方法で定義されていません。
REQUEST_METHOD = sip-method
sip-method = "INVITE" | "BYE" | "OPTIONS" | "CANCEL"
| "REGISTER" | "ACK"
| extension-method
extension-method = token
一口メソッド一口REQUEST_METHOD=メソッドは「招待」と等しいです。| 「さようなら」| 「オプション」| 「取り消してください」| 「登録してください」| "ACK"| 拡大メソッド拡大メソッドはトークンと等しいです。
Note that ACK is usually not appropriate for the SIP CGI 1.1 environment; however, see section 5.11. The implications of REGISTER in the CGI context are discussed in section 5.9, and CANCEL is discussed in section 5.10. A SIP CGI 1.1 server MAY choose to process some methods directly rather than passing them to scripts.
SIP CGI1.1環境には、通常、ACKが適切でないことに注意してください。 しかしながら、セクション5.11を見てください。 セクション5.9でCGI文脈のREGISTERの含意について議論します、そして、セクション5.10でキャンセルについて議論します。 SIP CGI1.1サーバは、それらをスクリプトに通過するより直接むしろいくつかのメソッドを処理するのを選ぶかもしれません。
Servers MUST provide this metavariable to scripts if the triggering message was a request.
サーバは引き金となるメッセージが要求であったならこのmetavariableをスクリプトに提供しなければなりません。
Lennox, et al. Informational [Page 20] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[20ページ]のRFC3050CGI
5.5.1.12 REQUEST_TOKEN
5.5.1.12 _トークンを要求してください。
REQUEST_TOKEN = token
REQUEST_TOKENはトークンと等しいです。
If the script specified a request token in a proxied request, this token is returned to the server in responses to that request. Note that this token is chosen by the script, not by the server. Each response to a proxied request contains the same value for this token.
スクリプトがproxied要求における要求トークンを指定したなら、その要求への応答におけるサーバにこのトークンを返します。 このトークンがサーバではなく、スクリプトによって選ばれていることに注意してください。proxied要求への各応答はこのトークンのための同じ値を含んでいます。
5.5.1.13 REQUEST_URI
5.5.1.13 _ユリを要求してください。
This metavariable is specific to requests made with SIP.
このmetavariableはSIPと共にされた要求に特定です。
REQUEST_URI = absoluteURI ; defined in RFC 2396 [9]
_URI=absoluteURIを要求してください。 RFC2396では、定義されます。[9]
If the message triggering the script was a request, this variable indicates the URI specified with the request method. This metavariable is only defined if REQUEST_METHOD is defined; in that case, servers MUST provide it to scripts.
スクリプトの引き金となったメッセージが要求であったなら、この変数は、URIが要求メソッドで指定したのを示します。 REQUEST_METHODが定義される場合にだけ、このmetavariableは定義されます。 その場合、サーバはそれをスクリプトに提供しなければなりません。
This metavariable fills the roles of HTTP CGI's
SCRIPT_NAME, PATH_INFO, and QUERY_STRING.
このmetavariableはHTTP CGIのSCRIPT_NAME、PATH_INFO、およびQUERY_STRINGの役割をいっぱいにしています。
5.5.1.14 RESPONSE_STATUS
5.5.1.14 応答_状態
RESPONSE_STATUS = Status-Code
応答_状態はステータスコードと等しいです。
If the message triggering the script was a response, this variable indicates the numeric code specified in the response; otherwise it is not defined. In the former case, servers MUST provide this metavariable to scripts.
スクリプトの引き金となったメッセージが応答であったなら、この変数は、数字コードが応答で指定したのを示します。 さもなければ、それは定義されません。 前の場合では、サーバはこのmetavariableをスクリプトに提供しなければなりません。
5.5.1.15 RESPONSE_REASON
5.5.1.15 応答_理由
RESPONSE_REASON = Reason-Phrase
応答_理由=理由句
If the message triggering the script was a response, this variable indicates the textual string specified in the response.
スクリプトの引き金となったメッセージが応答であったなら、この変数は、原文のストリングが応答で指定したのを示します。
5.5.1.16 RESPONSE_TOKEN
5.5.1.16 応答_トークン
RESPONSE_TOKEN = token
RESPONSE_TOKENはトークンと等しいです。
If the message triggering the script was a response, the server MUST specify a token which subsequent invocations of the CGI script can use to identify this response. This string is chosen by the server and is opaque to the CGI script. See the discussion of CGI-FORWARD- RESPONSE in section 5.6.1 below.
スクリプトの引き金となったメッセージが応答であったなら、サーバはCGIスクリプトのその後の実施がこの応答を特定するのに使用できるトークンを指定しなければなりません。 このストリングは、サーバによって選ばれていて、CGIスクリプトに不透明です。 セクション5.6.1未満における、CGI-FORWARD- RESPONSEの議論を見てください。
Lennox, et al. Informational [Page 21] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[21ページ]のRFC3050CGI
5.5.1.17 SCRIPT_COOKIE
5.5.1.17 スクリプト_クッキー
SCRIPT_COOKIE = token
SCRIPT_COOKIEはトークンと等しいです。
This is the value an earlier invocation of this script for this transaction passed to the server in CGI action line CGI-SET-COOKIE. See the description of that action in section 5.6.1.4 below.
これはこのトランザクションのためのこのスクリプトの以前の実施がCGI要処置限界値CGI-SET-COOKIEのサーバに通過した値です。 以下でのその動作コネセクション5.6.1.4の記述を見てください。
5.5.1.18 SERVER_NAME
5.5.1.18 サーバ_名前
The SERVER_NAME metavariable is set to the name of the server.
SERVER_NAME metavariableはサーバの名前に用意ができています。
SERVER_NAME = hostname | hostnumber
SERVER_NAMEはホスト名と等しいです。| hostnumber
Servers MUST provide this metavariable to scripts.
サーバはこのmetavariableをスクリプトに提供しなければなりません。
5.5.1.19 SERVER_PORT
5.5.1.19 サーバ_ポート
The SERVER_PORT metavariable is set to the port on which the message was received.
SERVER_PORT metavariableはメッセージが受け取られたポートに用意ができています。
SERVER_PORT = 1*digit
サーバ_ポートは1*ケタと等しいです。
Servers MUST provide this metavariable to scripts.
サーバはこのmetavariableをスクリプトに提供しなければなりません。
5.5.1.20 SERVER_PROTOCOL
5.5.1.20 サーバ_プロトコル
The SERVER_PROTOCOL metavariable is set to the name and revision of the protocol with which the message arrived. This will usually be "SIP/2.0". This is not necessarily the same as the protocol version used by the server in its response to the client.
SERVER_プロトコルmetavariableはメッセージが到着したプロトコルの名前と改正に用意ができています。 通常、これは「一口/2インチ」でしょう。 これは必ずサーバによってクライアントへの応答に使用されるプロトコルバージョンと同じであるというわけではありません。
SERVER_PROTOCOL = SIP-Version | extension-version
| extension-token
extension-version = protocol "/" 1*digit "." 1*digit
protocol = 1*( alphanum | "+" | "-" | "." )
extension-token = token
サーバ_プロトコル=一口バージョン| 拡大バージョン| 「拡大トークン拡大バージョン=は」 /について議定書の中で述べる」という1*ケタ、」、」 「1*ケタプロトコル=1*、(alphanum| 「+」 | 「-」|、」、」、)、拡大トークン=トークン
Servers MUST provide this metavariable to scripts.
サーバはこのmetavariableをスクリプトに提供しなければなりません。
Lennox, et al. Informational [Page 22] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[22ページ]のRFC3050CGI
5.5.1.21 SERVER_SOFTWARE
5.5.1.21 サーバ_ソフトウェア
The SERVER_SOFTWARE metavariable is set to the name and version of the information server software handling the message (and running the gateway).
SERVER_SOFTWARE metavariableはメッセージを扱う名前へのセットと情報サーバソフトウェアのバージョン(ゲートウェイを動かして)です。
SERVER_SOFTWARE = 1*product
product = token [ "/" product-version ]
product-version = token
SERVER_SOFTWAREは1*製品製品=トークン[「/」製品バージョン]製品バージョン=トークンと等しいです。
Servers MUST provide this metavariable to scripts.
サーバはこのmetavariableをスクリプトに提供しなければなりません。
5.5.2 Message Bodies
5.5.2 メッセージ本体
As there may be a data entity attached to the message, there MUST be a system-defined method for the script to read these data. Unless defined otherwise, this will be via the `standard input' file descriptor.
メッセージに付けられたデータ実体があるかもしれないので、スクリプトがこれらのデータを読むシステムで定義されたメソッドがあるに違いありません。 別の方法で定義されないと、これは'標準の入力'ファイルディスクリプタであるでしょう。
If the metavariable CONTENT_LENGTH (see section 5.5.1.2) is defined, the server MUST supply at least that many bytes to scripts on the standard input stream. Scripts are not obliged to read the data. Servers MAY signal an EOF condition after CONTENT_LENGTH bytes have been read, but are not obligated to do so. Therefore, scripts MUST NOT attempt to read more than CONTENT_LENGTH bytes, even if more data are available.
セクション5.5を見てください。metavariable CONTENT_LENGTHである、(.1 .2は)定義されて、サーバは標準の入力ストリームに関するスクリプトを少なくともそんなに多くのバイト供給しなければなりません。 スクリプトがデータを読むのが強いられません。 サーバは、CONTENT_LENGTHバイトを読んである後にEOF状態に合図するかもしれませんが、そうするのが義務付けられません。 したがって、より多くのデータが利用可能であっても、スクリプトは、CONTENT_LENGTHバイトよりもう少し読むのを試みてはいけません。
5.6 Data Output from the SIP CGI Script
5.6 一口CGIスクリプトからのデータ出力
There MUST be a system-defined method for the script to send data back to the server or client. Unless defined otherwise, this will be via the `standard output' file descriptor.
スクリプトがサーバかクライアントにデータを送り返すシステムで定義されたメソッドがあるに違いありません。 別の方法で定義されないと、これは'標準の出力'ファイルディスクリプタであるでしょう。
Servers MAY implement a timeout period within which data must be received from scripts, a maximum number of requests or responses that a particular CGI script can initiate, a maximum total number of requests or responses that can be sent by scripts over the lifetime of a transaction, or any other resource limitations it desires. If a script exceeds one of these limitations, the server MAY terminate the script process and SHOULD abort the transaction with either a `504 Gateway Timed Out' or a `500 Internal Server Error' response.
サーバはスクリプトでトランザクションの生涯、またはそれが望んでいるいかなる他のリソース制限の上にも送ることができる最大の総数のスクリプト、最大数の要求、特定のCGIスクリプトが開始できる応答、要求または応答からデータを受け取らなければならないタイムアウト時間を実装するかもしれません。 スクリプトがこれらの制限の1つを超えているなら、サーバはスクリプトプロセスを終えるかもしれません、そして、SHOULDは'504ゲートウェイTimed Out'か'500Internal Server Error'のどちらか応答でトランザクションを中止します。
Lennox, et al. Informational [Page 23] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[23ページ]のRFC3050CGI
A SIP CGI script's output consists of any number of messages, each corresponding to actions which the script is requesting that the server perform. Messages consist of an action line, whose syntax is specific to the type of action, followed by CGI header fields and SIP header fields. Action lines determine the nature of the action performed, and are described in section 5.6.1. CGI header fields pass additional instructions or information to the server, and are described in section 5.6.2.
SIP CGIスクリプトの出力はサーバが働くというそれぞれスクリプトが要求している動作に対応するメッセージのどんな数からも成ります。 メッセージはCGIヘッダーフィールドとSIPヘッダーフィールドがあとに続いた動作のタイプに、構文が特定である要処置限界値から成ります。 要処置限界値は、動作の本質が働いたことを決定して、セクション5.6.1で説明されます。 CGIヘッダーフィールドは、追加指示か情報にサーバに合格して、セクション5.6.2で説明されます。
A message MUST contain exactly one action line, MAY also contain any number of CGI header fields and SIP header fields, and MAY contain a SIP body.
メッセージは、まさに1個の要処置限界値を含まなければならなくて、また、いろいろなCGIヘッダーフィールドとSIPヘッダーフィールドを含んでいて、SIPボディーを含むかもしれません。
All header fields (both SIP and CGI) occurring in an output message MUST be specified one per line; SIP CGI 1.1 makes no provision for continuation lines.
1系列あたり出力メッセージに起こるすべてのヘッダーフィールド(SIPとCGIの両方)が指定されたものであるに違いありません。 SIP CGI1.1は継続行に備えません。
The generic syntax of CGI header fields is specified in section 5.6.2.
CGIヘッダーフィールドのジェネリック構文はセクション5.6.2で指定されます。
A server MAY choose to honor only some of the requests or responses; in particular, it SHOULD NOT accept any responses following a Status message which sends a definitive non-success response.
サーバは、要求か応答のいくつかだけを光栄に思うのを選ぶかもしれません。 特にそれ、決定的な非成功応答を送るStatusメッセージに従って、SHOULD NOTはどんな応答も受け入れます。
The messages sent by a script are delimited as follows:
スクリプトで送られたメッセージは以下の通り区切られます:
1. A message begins with an action line.
1. メッセージは要処置限界値で始まります。
2. If the message does not contain a Content-Type header
field, or if it contains the header field "Content-Length:
0", then it is terminated by a blank line.
2. メッセージがコンテントタイプヘッダーフィールドを含んでいないか、またはヘッダーフィールドを含んでいる、「コンテンツの長さ:」 そして、何0インチも、それは空白行によって終えられます。
3. If the message contains both Content-Type and Content-
Length header fields, the message has a body consisting of
the Content-Length octets following the blank line below
the set. The next message begins after the body (and
optionally some number of blank lines). If the script
closes its output prematurely, the server SHOULD report a
500-class server error.
3. メッセージがコンテントタイプとContent長さのヘッダーフィールドの両方を含んでいるなら、メッセージで、セットの下の空白行に続いて、ボディーはContent-長さの八重奏から成ります。 次のメッセージはボディーの後に始まります(任意に、何らかの数の空白が立ち並んでいます)。 スクリプトが早まって出力を終えるなら、サーバSHOULDは500クラスのサーバ誤りを報告します。
4. If the message contains Content-Type but not Content-
Length, the message's body similarly begins with the blank
line following the set; this body extends until the script
closes its output. In this case, this is necessarily the
last message the script can send. The server SHOULD insert
a Content-Length header containing the amount of data read
before the script closed its output.
4. メッセージがContentの長さではなく、コンテントタイプを含んでいるなら、空白行がセットに続いていて、メッセージのボディーは同様に始まります。 スクリプトが出力を終えるまで、このボディーは広がります。 この場合、これは必ずスクリプトが送ることができる最後のメッセージです。 サーバSHOULDはスクリプトが出力を終える前に読まれたデータ量を含むContent-長さのヘッダーを挿入します。
Lennox, et al. Informational [Page 24] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[24ページ]のRFC3050CGI
5. If a message contains a non-zero Content-Length but does
not contain a Content-Type, it is an error. The server
SHOULD report a 500-class server error.
5. メッセージが非ゼロのContent-長さを含んでいますが、コンテントタイプは含んでいないなら、それが誤りです。 サーバSHOULDは500クラスのサーバ誤りを報告します。
The output of a SIP CGI script is intended to be
syntactically identical to that of a UDP packet in which
multiple requests or responses are sent, so that the same
message parser may be used.
SIP CGIスクリプトの出力がシンタクス上複数の要求か応答が送られるUDPパケットのものと同じであることを意図します、同じメッセージパーサを使用できるように。
5.6.1 CGI Action Lines
5.6.1 CGI要処置限界値
5.6.1.1 Status
5.6.1.1 状態
Status = SIP-Version 3*digit SP reason-phrase NL
状態はSIP-バージョン3*ケタSP理由句のNLと等しいです。
This action line causes the server to generate a SIP response and relay it upstream towards the client. The server MUST copy the To, From, Call-ID, and CSeq headers from the original request into the response if these headers are not specified in the script output. The server SHOULD copy any other headers from the request which would normally be copied in the response if these are not specified in the script output.
この要処置限界値は、サーバがSIPが応答であると生成して、上流へクライアントに向かってそれをリレーすることを引き起こします。 これらのヘッダーがスクリプト出力で指定されないなら、サーバはTo、From、Call-ID、およびCSeqヘッダーをオリジナルの要求を応答に回避しなければなりません。 サーバSHOULDはいかなる他のヘッダーもこれらがスクリプト出力で指定されないなら通常、応答でコピーされる要求を回避します。
For compatibility with HTTP CGI, a server MAY interpret a message containing a Content-Type header field and no action line as though it contained "SIP/2.0 200 OK". This usage is deprecated.
HTTP CGIとの互換性のために、サーバはコンテントタイプヘッダーフィールドを含んでいますが、まるで「一口/2.0 200OK」を含んでいるかのようにどんな要処置限界値も含まないメッセージを解釈するかもしれません。 この用法は推奨しないです。
5.6.1.2 Proxy Request
5.6.1.2 プロキシ要求
Proxy-Request = "CGI-PROXY-REQUEST" SIP-URL SIP-Version
プロキシ要求=「CGIプロキシ要求」一口URL一口バージョン
This action line causes the server to forward a request to the specified SIP URI. It may be sent either by a script triggered by a request, in which case the triggering request is forwarded; or by a script triggered by a response on a server which is running statefully, in which case the initial request of the transaction is sent.
この要処置限界値で、サーバは指定されたSIP URIに要求を転送します。 要求で引き起こされたスクリプトでそれを送るかもしれません、その場合、引き金となる要求を転送します。 または、実行しているstatefullyであるサーバで応答で引き起こされたスクリプトで、その場合、トランザクションの初期の要求を送ります。
Any SIP header field MAY be specified below the action line. Specified SIP headers replace all those in the original message in their entirety; if a script wants to preserve header elements from the original message as well as adding new ones, it can concatenate them by the usual rules of header concatenation, and place the result in the script output. New header fields are added to the message after any Via headers but before any other headers.
どんなSIPヘッダーフィールドも要処置限界値の下で指定されるかもしれません。 指定されたSIPヘッダーはオリジナルのメッセージのすべてのそれらを全体として取り替えます。 スクリプトが新しいものを加えることと同様にオリジナルのメッセージからヘッダー要素を保存したいなら、それは、ヘッダー連結の普通の規則でそれらを連結して、スクリプト出力に結果を置くことができます。 新しいヘッダーフィールドはヘッダーにもかかわらず、いかなる他のヘッダーの前のどんなViaの後のメッセージにも追加されます。
Lennox, et al. Informational [Page 25] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[25ページ]のRFC3050CGI
Any headers from the original request which are not generated by the CGI script are copied into the proxied request, after modifications normally performed by a proxy server. In particular, the server MUST append a Via field and decrement Max-Forwards. A server MAY perform additional modifications as it sees fit, such as adding a Record- Route header. A server SHOULD NOT append these headers if they are specified in the script output.
CGIスクリプトによって生成されないオリジナルの要求からのどんなヘッダーもproxied要求にコピーされます、通常、変更がプロキシサーバで働いた後に。サーバは、特に、Via野原を追加して、前方へマックスを減少させなければなりません。 サーバはRecordルートヘッダーを加えるのなどように適していると決めるように追加変更を実行するかもしれません。 彼らがスクリプト出力で指定されるなら、サーバSHOULD NOTはこれらのヘッダーを追加します。
A script MAY specify that a SIP header is to be deleted from the message by using the CGI-Remove CGI header; see section 5.6.2.
スクリプトは、SIPヘッダーがメッセージからCGIで取り外しているCGIヘッダーを使用することによって削除されることになっていると指定するかもしれません。 セクション5.6.2を見てください。
If the message does not specify a body, the body from the initial request is used. A message with "Content-Length: 0" is specifying an empty body; this causes the body to be deleted from the message.
メッセージがボディーを指定しないなら、初期の要求からのボディーは使用されています。 Aが通信する、「コンテンツの長さ:」 0インチは空のボディーを指定しています。 これで、メッセージからボディーを削除します。
If the original request was authenticated by any means other than `basic,' the script SHOULD NOT add, change, or remove any end-to-end headers, as this would break the authentication.
スクリプトSHOULD NOTは、'基本的'を除いて、オリジナルの要求がなんとか認証されたなら、変化するか、または終わりから終わりへのあらゆるヘッダーを取り除くように言い足します、これが認証を壊すだろうというとき。
5.6.1.3 Forward Response
5.6.1.3 前進の応答
Forward-Response = "CGI-FORWARD-RESPONSE" Response-Name
SIP-Version
Response-Name = response-token | "this"
「CGIの前進の応答」応答名の一口バージョン応答前進の応答=名は応答トークンと等しいです。| 「これ」
This action line causes the server to forward a response on to its appropriate final destination. The same rules apply for accompanying SIP headers and message bodies as for CGI-PROXY-REQUEST.
この要処置限界値で、サーバは適切な最終的な目的地に応答を送ります。 同じ規則はCGI-PROXY-REQUESTのように付随のSIPヘッダーとメッセージ本体に申し込みます。
The specified response name may either be a response token the server previously submitted in a RESPONSE_TOKEN metavariable, or the string "this." The string "this" may only be sent if the message which triggered this CGI script was a response; it indicates that this triggering response should be forwarded.
指定された応答名は、サーバが以前にRESPONSE_TOKEN metavariableで提出した応答トークン、またはストリング「これ」のどちらかであるかもしれません。 このCGIスクリプトの引き金となったメッセージが応答であった場合にだけストリング「これ」を送るかもしれません。 それは、この引き金となる応答が進められるべきであるのを示します。
5.6.1.4 Script Cookie
5.6.1.4 スクリプトクッキー
Script-Cookie = "CGI-SET-COOKIE" token SIP-Version
スクリプトクッキー=「CGIセットクッキー」トークン一口バージョン
This action line causes the server to store a script cookie, passed as a token in the action line. Subsequent script invocations for messages within the same transaction carry the token in a meta- header. The script can alter the value of the cookie by subsequent script cookie actions. This alteration will take affect for all subsequent script invocations.
この要処置限界値で、サーバはトークンとして要処置限界値で取られるスクリプトクッキーを保存します。 同じトランザクションの中のメッセージのためのその後のスクリプト実施はメタヘッダーでトークンを運びます。 スクリプトはその後のスクリプトクッキー動作でクッキーの値を変更できます。 変更が取るこれはすべてのその後のスクリプトのために実施に影響します。
Lennox, et al. Informational [Page 26] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[26ページ]のRFC3050CGI
5.6.1.5 CGI Again
5.6.1.5 CGI、再び。
CGI-Again = "CGI-AGAIN" ("yes" | "no") SIP-Version
再びCGI=「再びCGI」(「はい」| 「いいえ」)一口バージョン
This action line determines whether the script will be invoked for subsequent requests and responses for this transaction. If the parameter "yes" is given to this action, the script will be executed again when the next message arrives. If the parameter is "no," or this action is not specified, the script will not be executed again, and the server will perform its default action for all subsequent messages.
この要処置限界値は、スクリプトがこのトランザクションのためのその後の要求と応答のために呼び出されるかどうか決定します。 次のメッセージが到着するとき、「はい」というパラメタをこの動作に与えると、再びスクリプトを作成するでしょう。 パラメタが「いいえ」であるかこの動作が指定されないと、スクリプトは再び作成されないでしょう、そして、サーバはすべてのその後のメッセージのためのデフォルト動作を実行するでしょう。
5.6.1.6 Default Action
5.6.1.6 デフォルト動作
If none of the actions CGI-PROXY-REQUEST, CGI-FORWARD-RESPONSE, or a new response are performed -- that is to say, the script outputs only CGI-AGAIN, CGI-SET-COOKIE, or nothing -- the script performs its default action. The default action to take depends on the event which triggered the script:
動作CGI-PROXY-REQUEST、CGI-FORWARD-RESPONSE、または新しい応答のいずれもすなわち、実行されないなら、スクリプトはCGI-AGAIN、CGI-SET-COOKIE、または何だけも出力しません--スクリプトはデフォルト動作を実行します。 取るデフォルト行動はスクリプトの引き金となったイベントによります:
Request received: When the request is first received, the
default action of the server is to check whether the
domain of the server matches the domain of the Request-
URI. If it does not, the request is proxied to the
request in the Request-URI. Otherwise, the server checks
its registration database against the request, and either
proxies or redirects the request based on the action
specified by the user agent in the registration.
要求は受信されました: 最初に要求を受け取るとき、サーバのデフォルト動作はサーバのドメインがRequest URIのドメインに合っているかどうかチェックすることです。 そうしないなら、要求はRequest-URIにおける要求にproxiedされます。 さもなければ、サーバは、要求、およびどちらのプロキシに対しても登録データベースをチェックするか、または登録でユーザエージェントによって指定された動作に基づく要求を向け直します。
Proxied response received: If a response is received to a
proxied request, the server forwards the response towards
the caller if the response was a 200 or 600 class
response, and sends a CANCEL on all pending branches. If
the response was 100 class, the state machinery for that
branch is updated, and the response is proxied upstream
towards the caller unless the it was a 100 response, not
some other 1xx. For 300, 400, and 500 class responses,
an ACK is sent, and the response is forwarded upstream
towards the caller if all other branches have terminated,
and the response is the best received so far. If not all
branches have terminated, the server does nothing. If
all branches have terminated, but this response is not
the best, the best is forwarded upstream. This is the
basic algorithm outlined in the SIP specification.
Proxied応答は受信されました: proxied要求に応答を受けるなら、サーバは、応答が200か600クラス応答であったなら訪問者に向かって応答を送って、すべての未定のブランチでキャンセルを送ります。 応答が100のクラスであったなら、そのブランチのための州の機械をアップデートして、上流へ訪問者に向かって応答をproxiedする、それはある他の1xxではなく、100応答でした。 300、400、および500のクラス応答において、ACKを送ります、そして、他のすべてのブランチが終わったなら、上流へ訪問者に向かって応答を送ります、そして、応答は今までのところ受け取られているベストです。 そうでなければ、すべてのブランチが終わって、サーバは何もしません。 すべてのブランチが終わりましたが、この応答が最も良くないなら、上流へベストを進めます。 これはSIP仕様に概説された基本的なアルゴリズムです。
Lennox, et al. Informational [Page 27] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[27ページ]のRFC3050CGI
5.6.2 CGI Header Fields
5.6.2 CGIヘッダーフィールド
CGI header fields syntactically resemble SIP header fields, but their names all begin with the string "CGI-". The SIP server MUST strip all CGI header fields from any message before sending it, including those it does not recognize.
CGIヘッダーフィールドはシンタクス上SIPヘッダーフィールドに類似していますが、それらの名前はストリング「CGI」ですべて始まります。 それを送る前にSIPサーバはどんなメッセージからもすべてのCGIヘッダーフィールドを剥取らなければなりません、それが認識しないものを含んでいて。
CGI header fields have the generic syntax specified in section 6.6 of the SIP/2.0 specification [2]. The field-name is not case sensitive; the field value MUST conform to the grammar of that specific field in the specification where it is defined.
CGIヘッダーフィールドで、SIP/2.0仕様[2]のセクション6.6でジェネリック構文を指定します。 フィールド名は大文字と小文字を区別していません。 分野値はそれが定義される仕様でその特定の分野の文法に従わなければなりません。
5.6.2.1 Request-Token
5.6.2.1 要求トークン
Request-Token = "CGI-Request-Token" ":" token
「要求トークン=「CGI要求トークン」」:、」 トークン
To assist in matching responses to proxied requests, the script can place a CGI-Request-Token CGI header in a CGI-PROXY-REQUEST or new request. This header contains a token, opaque to the server. When a response to this request arrives, the token is passed back to the script as a meta-header.
proxied要求への応答に合っているのを助けるために、スクリプトはCGI要求トークンCGIヘッダーをCGI-PROXY-REQUESTか新しい要求に置くことができます。 このヘッダーはトークンを含んでいます、サーバに、不透明です。この要求への応答が到着するとき、トークンはメタヘッダーとしてスクリプトに戻されます。
This allows scripts to "fork" a proxy request, and
correlate which response corresponds to which branch of the
request.
これは、スクリプトがプロキシ要求、およびそれの応答が要求のどのブランチに対応する相関物を「分岐させること」を許容します。
5.6.2.2 Remove
5.6.2.2 取り外してください。
Remove = "CGI-Remove" ":" 1#field-name
「「CGIで取り外した」状態で=を取り除いてください」:、」 1#フィールド名
The CGI-Remove header allows the script to remove SIP headers from the outgoing request or response. The value of this header is a comma-separated list of SIP headers which should be removed before sending out the message.
CGIで取り外しているヘッダーはスクリプトに送信する要求か応答からSIPヘッダーを取り除かせます。 このヘッダーの値はメッセージを出す前に取り除かれるべきであるSIPヘッダーのコンマで切り離されたリストです。
A script MAY specify headers which are not in the request; the server SHOULD silently ignore these. A script SHOULD NOT both specify a SIP header in its output and also list that header in a CGI-Remove header; the result of doing this is undefined.
スクリプトは要求にないヘッダーを指定するかもしれません。 サーバSHOULDは静かにこれらを無視します。 スクリプトSHOULD NOTは出力でSIPヘッダーを指定して、また、CGIで取り外しているヘッダーにそのヘッダーを記載します。 これをするという結果は未定義です。
5.7 Local Expiration Handling
5.7 地方の満了取り扱い
If a CGI script specifies an Expires header field along with CGI- PROXY-REQUEST, the SIP server SHOULD track the expiration timeout locally as well as sending the message to the remote server. When the timeout expires, the server SHOULD generate a "408 Request
CGIスクリプトがCGI PROXY-REQUESTに伴うExpiresヘッダーフィールドを指定するなら、リモートサーバにメッセージを送ることと同様にSIPサーバSHOULDは局所的に満了タイムアウトを追跡します。タイムアウトが期限が切れると、サーバSHOULDは「408要求」を生成します。
Lennox, et al. Informational [Page 28] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[28ページ]のRFC3050CGI
Timeout" response. The timeout response SHOULD be handled as specified in section 5.8. At the time the request is timed out, the server SHOULD also transmit CANCEL messages for the request.
「タイムアウト」応答。 タイムアウト応答SHOULD、セクション5.8で指定されるように、扱われてください。 当時、要求は外で調節されています、また、サーバSHOULDが要求へのキャンセルメッセージを送ります。
This allows a SIP CGI script in a proxy server to implement
services like "Call Forward No Answer" to trigger after a
user-determined time, even if the remote user-agent server
is not responding or does not properly handle the Expires
header field.
これで、プロキシサーバにおけるSIP CGIスクリプトはユーザが決定している時の後に引き金となる「呼び出しの前進のいいえ答え」のようなサービスを実装することができます、リモートユーザエージェントサーバが応じていない、または適切にExpiresヘッダーフィールドを扱わないでも。
5.8 Locally-Generated Responses
5.8 局所的に発生している応答
In a proxy environment, locally-generated responses such as "408 Request Timeout" SHOULD be sent to the CGI script in the same manner as received messages are. However, messages which merely report a problem with a message, such as "400 Bad Request", SHOULD NOT be.
「408はタイムアウトを要求する」SHOULDなどのプロキシ環境の、そして、局所的に発生している応答では、受信されたメッセージが送るので、CGIスクリプトに同じ方法で送ってください。 しかしながら、単にaに関する問題を報告するメッセージが「400の悪い要求」などのようにSHOULD NOTを通信させます。いてください。
This is the other half of the requirements for the
implementation of the "Call Forward No Answer" service,
along with the local handling of the Expires header.
これは「呼び出しの前進のいいえ答え」サービスの実装のための要件のもう片方の半分です、Expiresヘッダーの地方の取り扱いと共に。
5.9 SIP CGI and REGISTER
5.9 一口CGIとレジスタ
The specific semantics of a SIP CGI script which is triggered by a REGISTER request are somewhat different than that of those triggered by call-related requests; however, allowing user control of registration may in some cases be useful. The two specific actions for REGISTER that need to be discussed are the response "200" and the default action. In the former case, the server SHOULD assume that the CGI script is handling the registration internally, and SHOULD NOT add the registration to its internal registration database; in the latter case, the server SHOULD add the registration to its own database. The server also SHOULD NOT add the registration if a 3xx, 4xx, 5xx, or 6xx status was returned, or if the registration request was proxied to another location.
REGISTER要求で引き起こされるSIP CGIスクリプトの特定の意味論は呼び出し関連の要求で引き起こされたもののものといくらか異なっています。 しかしながら、いくつかの場合、登録のコントロールをユーザに許すのは役に立つかもしれません。 議論する必要があるREGISTERのための2つの特定の動作は、応答「200」とデフォルト動作です。 前の場合では、サーバSHOULDは、CGIスクリプトが内部的に登録を扱っていると仮定します、そして、SHOULD NOTは内部の登録データベースに登録を追加します。 後者の場合では、サーバSHOULDはそれ自身のデータベースに登録を追加します。 サーバ、また、3xx、4xx、5xx、または6xx状態を返したか、またはもう1つの位置に登録要求をproxiedしたなら、SHOULD NOTは登録を加えます。
5.10 SIP CGI and CANCEL
5.10は、CGIをちびちび飲んで、取り消されます。
SIP CGI servers SHOULD execute scripts when a CANCEL message is received. The script SHOULD clean up any state it has for the transaction as quickly as possible.
キャンセルメッセージが受信されているとき、SIP CGIサーバSHOULDはスクリプトを作成します。 スクリプトSHOULDはそれがトランザクションのためにできるだけはやく持っているどんな状態もきれいにします。
Lennox, et al. Informational [Page 29] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[29ページ]のRFC3050CGI
When a CANCEL is received at a server for an existing transaction, the server SHOULD send a 200 OK response to the cancel and cancel all currently outstanding branches. The transmission of the script on a CANCEL message is purely advisory, and the script SHOULD NOT perform any actions in response to it.
既存のトランザクションのためにサーバでキャンセルを受けるとき、サーバSHOULDは200OK応答をキャンセルに送って、すべての現在傑出しているブランチを取り消します。 キャンセルメッセージにおけるスクリプトの送信は純粋に顧問です、そして、スクリプトSHOULD NOTはそれに対応してどんな動作も実行します。
5.11 SIP CGI and ACK
5.11 一口CGIとACK
5.11.1 Receiving ACK's
5.11.1 ACKを受けること。
Under normal circumstances, if the server receives an ACK, the script is not re-executed. If the ACK is destined for the proxy (acknowledging a 300, 400, 500, or 600 response), the ACK causes response retransmissions to cease. If the ACK is for a 200 response forwarded from a downstream server, the ACK is proxied downstream.
通常の状況下で、サーバがACKを受けるなら、スクリプトは実行し直されません。 ACKがプロキシのために運命づけられているなら(300、400、500、または600応答を承諾して)、ACKは応答「再-トランスミッション」をやませます。 ACKが川下のサーバから進められた200応答のためのものであるなら、ACKは川下でproxiedされます。
However, if the script generated its own 200 response to an INVITE request, the script SHOULD be re-executed with the ACK message. This is necessary in cases where the script is causing the proxy to act as a UAS. ACK messages can contain bodies, and would therefore be useful to the script.
しかしながら、スクリプトが、それ自身のものがINVITE要求への200応答、スクリプトSHOULDであると生成したなら、ACKメッセージで、実行し直されてください。 これがスクリプトがプロキシがUASとして務めることを引き起こすことである場合で必要です。 ACKメッセージは、ボディーを含むことができて、したがって、スクリプトの役に立つでしょう。
5.11.2 Sending ACK's
5.11.2 送付ACKのもの
When the server receives a non-200 final response to an INVITE request, it SHOULD generate an ACK on its own, and not depend on the script to do so. There is no way in SIP CGI 1.1 to override this behavior. However, since the server will not generate an ACK for 200 responses to INVITE, a script causing the server to act as a UAC MUST generate ACK's for them.
サーバはINVITE要求への非200の最終的な応答を受けます、それ。いつ、SHOULDは、それ自身のところでACKを生成して、そうするためにスクリプトによらないか。 この振舞いをくつがえすために、道は全くSIP CGI1.1にありません。 しかしながら、サーバが200の応答のためにACKを生成しないので、INVITE、サーバがUAC MUSTとして機能するスクリプトにそれらのためにACKのものを生成してください。
6 System Specifications
6 システム仕様
6.1 Unix
6.1 unix
The implementation of SIP CGI on a Unix operating system platform SHOULD use environment variables as the mechanism of providing request metadata to CGI scripts.
UnixオペレーティングシステムSHOULDプラットホームのSIP CGIの実装は提供している要求メタデータのメカニズムとしてCGIスクリプトに環境変数を使用します。
For Unix compatible operating systems, the following are defined:
Unixコンパチブルオペレーティングシステムにおいて、以下は定義されます:
Environment variables: These are accessed by the C library
routine getenv.
環境変数: これらはCライブラリ・ルーチンgetenvによってアクセスされます。
Lennox, et al. Informational [Page 30] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[30ページ]のRFC3050CGI
The current working directory: The current working directory for
the script SHOULD be set to the directory containing the
script.
現在の働くディレクトリ: ディレクトリ含有へのセットがスクリプトであったならスクリプトSHOULDのためにディレクトリを扱う電流。
Character set: The US-ASCII character set is used for the
definition of environment variable names and header field
names; the newline (NL) sequence is LF; servers SHOULD also
accept CR LF as a newline.
文字集合: 米国-ASCII文字の組は環境変数名とヘッダーフィールド名の定義に使用されます。 ニューライン(NL)系列はLFです。 また、サーバSHOULDはニューラインとしてCR LFを認めます。
6.2 Microsoft Windows
6.2 マイクロソフトWindows
The implementation of SIP CGI on 32-bit Microsoft Windows system platforms (Windows 95, 98, NT, and 2000) SHOULD use environment variables as the mechanism of providing request metadata to CGI scripts.
32ビットのマイクロソフトWindowsシステムの上のSIP CGIの実装はSHOULDが要求メタデータをCGIスクリプトに提供しながらメカニズムとしての環境変数を使用する(Windows95、98、NT、および2000)を載せます。
For Microsoft Windows, the following are defined:
マイクロソフトWindowsにおいて、以下は定義されます:
Environment variables: These are accessed by the C library
routine getenv.
環境変数: これらはCライブラリ・ルーチンgetenvによってアクセスされます。
The current working directory: The current working directory for
the script SHOULD be set to the directory containing the
script.
現在の働くディレクトリ: ディレクトリ含有へのセットがスクリプトであったならスクリプトSHOULDのためにディレクトリを扱う電流。
Character set: The US-ASCII character set is used for the
definition of environment variable names and header field
names; the newline (NL) sequence is CR LF; servers SHOULD
also accept LF as a newline.
文字集合: 米国-ASCII文字の組は環境変数名とヘッダーフィールド名の定義に使用されます。 ニューライン(NL)系列はCR LFです。 また、サーバSHOULDはニューラインとしてLFを認めます。
7 Security Considerations
7 セキュリティ問題
7.1 Request Initiation
7.1 要求開始
CGI scripts are able to initiate arbitrary SIP transactions, or to produce spoofed responses of any sort. This protocol does not attempt to restrict the actions CGI scripts can take. Server administrators MUST consider CGI scripts to be as security-sensitive as their SIP server itself, and perform equivalent levels of security review before installing them.
CGIスクリプトが任意のSIPトランザクションを開始できますか、または生産するのはどんな種類の応答も偽造しました。 このプロトコルは、CGIスクリプトが取ることができる行動を制限するのを試みません。 サーバアドミニストレータは、CGIスクリプトがセキュリティそれらのSIPサーバ自体と同じくらい敏感であると考えて、それらをインストールする前に、同等なレベルの安全レビューを実行しなければなりません。
7.2 Authenticated and Encrypted Messages
7.2 認証されて暗号化されたメッセージ
CGI scripts must be careful not to interfere with authentication. In particular, adding or removing header fields that are below the Authorization header will cause the message to fail authentication at the user agent.
CGIスクリプトは、認証を妨げないように慎重でなければなりません。 Authorizationヘッダーの下にあるヘッダーフィールドを加えるか、または取り除くと、特に、ユーザエージェントで認証に失敗するメッセージは引き起こされるでしょう。
Lennox, et al. Informational [Page 31] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[31ページ]のRFC3050CGI
When a SIP request is encrypted, the headers which are in the clear are passed to the server according to this specification. The encrypted portion of the request is passed to the script as a body. Any SIP headers output by the script will be added to the message. However, scripts should be aware that these may be discarded if they also exist within the encrypted portion.
SIP要求が暗号化されているとき、明確にあるヘッダーはこの仕様通りにサーバに渡されます。 要求の暗号化された部分はボディーとしてスクリプトに通過されます。 スクリプトで出力されたどんなSIPヘッダーもメッセージに追加されるでしょう。 しかしながら、スクリプトはまた、暗号化された部分の中に存在しているならこれらが捨てられるかもしれないのを意識しているべきです。
7.3 SIP Header Fields Containing Sensitive Information
7.3 機密情報を含む一口ヘッダーフィールド
Some SIP header fields may carry sensitive information which the server SHOULD NOT pass on to the script unless explicitly configured to do so. For example, if the server protects the script using the Basic authentication scheme, then the client will send an Authorization header field containing a username and password. If the server, rather than the script, validates this information then the password SHOULD NOT be passed on to the script via the HTTP_AUTHORIZATION metavariable.
いくつかのSIPヘッダーフィールドがそうするために明らかに構成されない場合サーバSHOULD NOTがスクリプトに通過する機密情報を運ぶかもしれません。 例えば、サーバがBasic認証体系を使用することでスクリプトを保護すると、クライアントはユーザ名とパスワードを含むAuthorizationヘッダーフィールドを送るでしょう。 サーバがその時スクリプトよりむしろこの情報を有効にする、パスワードSHOULD NOT、_HTTP AUTHORIZATION metavariableを通してスクリプトに通過されてください。
7.4 Script Interference with the Server
7.4 サーバのスクリプト干渉
The most common implementation of CGI invokes the script as a child process using the same user and group as the server process. It SHOULD therefore be ensured that the script cannot interfere with the server process, its configuration, or documents.
サーバとしての同じユーザを使用する子プロセスとグループが処理されるとき、CGIの最も一般的な実装はスクリプトを呼び出します。 それ、SHOULD、したがって、それが確実にされる場合スクリプトがサーバプロセス、構成、または書類に干渉できないということになってください。
If the script is executed by calling a function linked in to the server software (either at compile-time or run-time) then precautions SHOULD be taken to protect the core memory of the server, or to ensure that untrusted code cannot be executed.
次に、サーバソフトウェア(コンパイル時かランタイムの)注意SHOULDにリンクされた機能を回収することによってスクリプトを作成するなら、取って、サーバのコアメモリを保護してください。さもないと、その信頼されていないコードを確実にするのを実行できません。
7.5 Data Length and Buffering Considerations
7.5 データの長さと問題をバッファリングすること。
This specification places no limits on the length of entity bodies presented to the script. Scripts SHOULD NOT assume that statically allocated buffers of any size are sufficient to contain the entire submission at one time. Use of a fixed length buffer without careful overflow checking may result in an attacker exploiting `stack- smashing' or `stack-overflow' vulnerabilities of the operating system. Scripts may spool large submissions to disk or other buffering media, but a rapid succession of large submissions may result in denial of service conditions. If the CONTENT_LENGTH of an entity-body is larger than resource considerations allow, scripts SHOULD respond with `413 Request Entity Too Large.'
この仕様はスクリプトに提示された実体本体の長さに限界を全く置きません。 静的にどんなサイズに関するバッファも割り当てたSHOULD NOTが仮定するスクリプトは、ひところ全体の服従を含むように十分です。 慎重なオーバーフローの照合のない固定長バッファの使用はオペレーティングシステムの'スタック粉砕'か'スタックオーバーフロー'脆弱性を利用している攻撃者をもたらすかもしれません。 スクリプトはメディアをバッファリングしながら、何らかのディスクに大きい差出をスプールするかもしれませんが、大きい差出の急速な連続は運転条件の否定をもたらすかもしれません。 実体本体のCONTENT_LENGTHがリソース問題が許容するより大きいなら、SHOULDが'413Request Entity Too Large'と共に反応させるスクリプトです。
Lennox, et al. Informational [Page 32] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[32ページ]のRFC3050CGI
8 Acknowledgements
8つの承認
This work draws extremely heavily upon the HTTP CGI specification [1]; approximately half the text of the specification section is taken from that document.
この仕事は非常に大いにHTTP CGI仕様[1]を利用します。 仕様部のテキストのおよそ半分がそのドキュメントから抜粋されます。
9 Authors' Addresses
9人の作者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスColumbia University1214アムステルダムアベニューのジョナサンレノックス部、ニューヨーク、ニューヨーク10027の米国のM.C.0401
EMail: lennox@cs.columbia.edu
メール: lennox@cs.columbia.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock Ave。 ニュージャージー 最初に、床の東ハノーバー王家、07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスColumbia University1214アムステルダムアベニューのヘニングSchulzrinne部、ニューヨーク、ニューヨーク10027の米国のM.C.0401
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Lennox, et al. Informational [Page 33] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[33ページ]のRFC3050CGI
10 Bibliography
10 図書目録
[1] http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
[1] http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
[2] Handley, M, Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] ハンドレー、M、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[3] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 10, RFC 822, August 1982.
[3] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD10、RFC822、1982年8月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[7]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[8] St. Johns, M., "Identification Protocol", RFC 1413, January
1993.
[8] 聖ジョーンズ、M.、「識別プロトコル」、RFC1413、1993年1月。
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
Lennox, et al. Informational [Page 34] RFC 3050 CGI for SIP January 2001
レノックス、他 一口2001年1月のための情報[34ページ]のRFC3050CGI
11 Full Copyright Statement
11 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lennox, et al. Informational [Page 35]
レノックス、他 情報[35ページ]
一覧
スポンサーリンク
