Network Working Group J. Lennox
Request for Comments: 3050 H. Schulzrinne
Category: Informational Columbia U.
J. Rosenberg
dynamicsoft
January 2001
Common Gateway Interface for SIP
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
インターネット電話では、新しいサービスを作成し、急速に展開される手段がなければなりません。ワールド・ワイド・ウェブでは、CGI（Common Gateway Interface）は、プログラミング、Webサービスへの人気の手段を務めています。セッション開始プロトコル（SIP）およびハイパーテキスト転送プロトコル（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ソフトウェア開発グループによって維持されています。見る
http://www.w3c.org/cgi
ｈっｔｐ：／／ｗっｗ。ｗ３ｃ。おｒｇ／ｃぎ
for additional information on the current state of the CGI interface.
CGIインタフェースの現在の状態に関する追加情報について。
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
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
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.
インターネット電話では、新しいサービスを作成し、急速に展開される手段がなければなりません。従来のテレフォニーネットワークでは、これは多くの場合、GUIベースのツールを使用して、新しいサービスを作成するためのインタフェースを提供するINサービスの作成環境を通じて達成されました。
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は、サービスを作成するためのツールの独自のセットで進化してきました。もともと、Webサーバは単に、ローカルシステム上に保存されたファイル名にURLを翻訳して、ファイルの内容を返されました。時間が経つにつれて、サーバは動的なコンテンツを提供するために進化し、そしてフォームはユーザーの入力を勧誘するための手段を提供します。本質的には、どのような進化は、Web環境でのサービスを作成するための手段でした。サーバサイドJavaScript、サーブレット、および共通ゲートウェイ・インターフェース（CGI）を含む動的なウェブコンテンツを作成するための多くの手段、[1]今あります。
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.
インターネット電話などのマルチメディア通信は、また、サービスを作成するための仕組みが必要になります。このメカニズムは強くシグナリングプロトコルによって提供される機能に関連付けられています。セッション開始プロトコル（SIP）は、[2]マルチメディアセッションの開始と終了のために開発されてきました。 SIPは、そのクライアント・サーバ間の対話とその構文と意味の多くを継承し、HTTPから重く借ります。特にこのため、Webサービスの作成環境、およびCGIの場合は、SIPベースのサービス作成環境を開発するための出発点として魅力的に見えます。
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.
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は、CGIアプリケーションへのHTTP要求ですべてのヘッダの内容を公開します。アプリケーションは、それが適当と考えるように、これらを利用して、それが気にしないそれらを無視することができます。これは、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サーブレットなどの他の機構、には当てはまりません。体がSIPサービスの作成で中心的な重要性は通常ではありませんので、SIP環境では、応答のすべての側面（及び、新規またはプロキシリクエストのすべての側面）を生成できることが重要です。
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]の構文を再利用するので、これらのツールの多くは、CGIをSIPに適用可能です。
Familiar environment: Many web programmers are familiar with CGI.
使い慣れた環境：多くのWebプログラマは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は、基本的な構文と要求 - 応答モデルを共有しながら、重要な違いがあります。彼らはHTTPのためにあまり重要でないながらプロキシは、SIPのためのサービスで重要な役割を果たしています。 SIPサーバは、HTTPには存在しない重要な機能を要求する（単一の要求を受信したとき、複数の要求をプロキシ）をフォークすることができます。 SIPは、HTTPには存在しない登録、などの追加機能をサポートしています。これらの違いは、SIP CGIとHTTP CGIとの違いに反映されています。 SIP CGIはなく（HTTPでオリジンサーバと同等である）ユーザエージェントサーバよりも、主に、プロキシ、リダイレクト、およびレジストラサーバ上で動作します。 SIPのCGIスクリプトは、（例えばプロキシ要求など）は、HTTP CGIでサポートされていない特定のメッセージング機能を実行することができ、及びSIP CGIスクリプトは、複数のメッセージ交換を介して制御を維持することを可能にする永続化モデルを導入します。 HTTPのCGIスクリプトのための持続性を持っていません。
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. | |
| | | |
| ------- |
------------
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スクリプトではなく、プロキシサーバを実行します。
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. |
| |
-------
Figure 2: SIP CGI Model
図2：SIPの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.
クライアントは、サーバーに転送された要求を生成します。サーバは、応答生成（例えばエラーとしてのまたは応答をリダイレクト）することができます。またはサーバーがプロキシサーバーであれば、要求が別のサーバーにプロキシされ、そして最終的にはユーザーエージェントに、応答は、バッククライアントに対する、サーバーを介して、上流に戻されます。 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サーバは、4つの基本的な操作の実行に関する一般的懸念しています：
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.
Returning Responses: Receiving a response, adding or modifying any of the headers, and passing the response towards the client.
追加やヘッダのいずれかを変更し、クライアントへの応答を渡し、応答を受信：応答を返します。
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よりも機能の大きなセットを包含しなければならないことを意味します。これらの機能は、単純なエンドサーバーの要求/応答モデルのスーパーセットです。
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を）。トランザクションは、単に1つの要求、および応答です。
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では、要求は多くの新しいおよびプロキシされたリクエストを生成することができるので、これら自体は応答を生成します。サービスは、多くの場合、これらの応答を処理する必要があり、生成される追加の要求または応答します。 HTTPのCGIスクリプトは、トランザクションごとに一度だけ実行されるのに対し、その結果、SIPの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 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.
例えば、SIPサーバに到着した要求を検討してください。サーバは、暫定的な応答とプロキシ要求を生成するCGIスクリプトを呼び出します。また、サーバーにトークンを返し、その後、終了します。応答がクライアントに向けて上流に返され、要求がプロキシされます。プロキシ要求に対する応答が到着すると、スクリプトを再度実行します。環境変数は、新たな応答の内容に基づいて設定されています。また、このスクリプトは、トークンを戻されます。その状態としてトークンを使用して、スクリプトがプロキシに別の場所への要求を決定します。したがって、プロキシ要求、および他のトークンを返します。応答が来たときに、サーバーの転送この新しい要求は、と、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で重要です。スクリプトが呼び出されない場合、サーバーは、この文書で指定されている、「デフォルト」行動を取るだろう。これは、計算リソースのための柔軟性をトレードオフするアプリケーションの設計を可能にします。インテリジェントネットワーク（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.
HTTPのCGIスクリプトは、トランザクション中に一度実行する一方ので、要約すると、単一のSIP CGIスクリプトは、トランザクション中に何度も実行することができる、それがトランザクションの残りのために制御したいと思うポイントれる指定することができます。
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ヘッダ、SIPメソッド、ステータスコード、および理由フレーズに依存してもよいです。そのため、CGIスクリプトへのメッセージのマッピングは、純粋にサーバーのローカルポリシーの管理の問題です。サーバは、常に実行単一のスクリプトを有していてもよく、またはそれは複数のスクリプトを有していてもよく、そして対象は、ヘッダの一部によって選択されます。
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でのパスの概念がないため、これらの環境変数のいくつかは意味がありません。
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では、特定のサービスは、メッセージが到着したときにスクリプトがないだけ呼び出されることを必要としますが、いくつかのタイマーが期限切れになったとき。この典型的な例は、「何も答えを前方に呼んでいない。」でありますSIP CGI、スクリプトが実行される最初の時間で実装されるために、それはプロキシ要求を生成し、また、応答が来ない場合は、再度呼び出される時刻を示さなければなりません。このような機能は、HTTP CGIに存在せず、そのためのいくつかの基本的なサポートは、SIP CGIで必要とされます。
4 Overview of SIP CGI
SIP 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に、CGIおよび/またはSIPヘッダによって修飾することができるそれぞれがSIPアクションラインのセットを返します。このセットは、二つのキャリッジリターンを使用することによって区切られます。アクション・ラインがスクリプトはデフォルトの動作に加えて、上記で定義された4つの操作のいずれかを指定することを可能にします。応答を生成するCGI出力の作用線への応答のステータス行をコピーすることによって行われます。たとえば、次の例は、元の要求に200 OKを作成します。
SIP/2.0 200 OK
SIP / 2.0 200 OK
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:
リクエストをプロキシの動作は、引数としてのプロキシへのURLをとるCGI-PROXY-REQUESTのCGIの作用によりサポートされています。たとえば、プロキシにdante@inferno.comするための要求：
CGI-PROXY-REQUEST sip:dante@inferno.com SIP/2.0 Contact: sip:server1@company.com
CGI-PROXY-REQUESTのSIP：dante@inferno.com SIP / 2.0連絡先：SIP：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サーバによって抽出され、追加的なガイダンスを使用してサーバを提供するために使用されています。
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ヘッダは常にSIPヘッダと区別するためにCGIで始まります。この場合、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
SIP / 2.0 ABCDEFGHIJ CGI-FORWARD-RESPONSE
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スクリプトが正常にのみ実行されます。スクリプトは、トランザクションに後続のメッセージのために呼び出されることを希望する場合 - によるプロキシ要求への応答に、または（特定の状況下で）ACKとCANCELリクエストを、それが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.
このアクションは、スクリプトの次の呼び出しに適用されます。それは、スクリプトをもう一度起動することを意味します。 「no」に出力することで、スクリプトのこの呼び出しに「yes」を出力し、スクリプトが呼び出される次回は何も出力しないと同じです。
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.
スクリプトが再実行されると、それは処理を継続するために、いくつかの状態にアクセスする必要があるかもしれません。このスクリプトは、任意の新しい要求やプロキシ要求のためにクッキーと呼ばれる状態の一枚を、生成することができます。これは、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 when the request is proxied. Any responses received to this request will have the token passed in an environment variable.
最後に、スクリプトはプロキシにリクエストをサーバーが発生したときに、これらの要求に対する応答が到着します。要求に対する応答のマッチングを容易にするために、スクリプトがCGI CGI-リクエスト・トークン・ヘッダーのリクエストトークンを配置することができます。要求がプロキシされたとき、このヘッダは、サーバによって除去されます。この要求に受信したすべての応答は、環境変数に渡されたトークンを持つことになります。
5 SIP CGI Specification
5 SIP 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に基づいています。その文書は公式IETFワーキンググループではありませんCGI-WGメーリングリストの製品です。 CGI-WGのホームページはURL http://Web.Golux.Com/coar/cgi/に位置し、CGI仕様の最新バージョンが利用可能です。この仕様の将来のバージョンではなく、参照することにより、その文書の一部を引用するように変更することができる2月23日、2000年のように、この仕様は、そのドキュメントの作業中のバージョンからのテキストを大量に搭載しています。
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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[4]及び対応するSIP 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.
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.
Implementation-defined: The behavior of the feature may vary from implementation to implementation, but a particular implementation should be consistent in its behavior.
実装定義：機能の動作は、実現例ごとに異なり得るが、特定の実装は、その挙動が一貫していなければなりません。
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.
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.
スクリプト：このインタフェースを介してサーバによって呼び出されるソフトウェア。これは、スタンドアロンのプログラムである必要はありませんが、サーバーで動的にロードされるか、共有ライブラリ、あるいはサブルーチンである可能性があります。用語 `スクリプト」が頻繁に理解されるように、それは、実行時に解釈文の集合であってもよいが、これは要件ではなく、本明細書の文脈内の用語は、記載より広い定義を有します。
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スクリプトの呼び出し、または1つをトリガーいずれか。
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仕様の付録Cに記載されているように本明細書において、我々は増補バッカス - ナウアフォーム表記を使用し、RFC 2543 [2]。
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
(via SIP/2.0 [2] Section 6.16) field-name SIP/2.0 [2] Section 6.6
フィールド名SIP / 2.0 [2]のセクション6.6（SIP / 2.0 [2]のセクション6.16を介して）
Other grammatical constructs taken from outside sources are noted in the text.
外部ソースから取得した他の文法的な構築物は、本文中に記載されています。
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.
同時に複数のCGIスクリプトは、SIPトランザクションのために優れたかもしれません。その後の応答に到着すると、CGIスクリプトが呼び出される原因となる場合は、トランザクション内の前のメッセージのためのCGIスクリプトが終了するまで、それらの取り扱いは、ACKを除き、延期されています。メッセージは、それらが受信された順序で処理されています。
The server SHOULD NOT provide any command line arguments to the script.
サーバーは、スクリプトに任意のコマンドライン引数を提供すべきではありません。
Command line arguments are used for indexed queries in HTTP
CGI; HTTP indexed queries do not have an equivalent in SIP.
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つの異なるソースから来ます。サーバは、スクリプトにこの情報の一部を利用できるようにしなければなりません。
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サーバの実装は、スクリプトにサーバからのメッセージに関するデータを渡すためのメカニズムを定義しなければなりません。これらのデータを含むメタ変数はシステム定義されたようにしてスクリプトによってアクセスされます。メタ変数内の文字の表現は、システム定義です。
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.
メタ変数の表現は（存在しない）未定義の値とNULL値を区別（存在するが、ゼロの長さを有する）しなければなりません。 NULL値のみを持つ文法これを許可し、それらのメタ変数に許可されています。
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.
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.
名前のみの場合には異なる2つの異なる変数があることができないという場合は、メタ変数名には重要ではありません。ここで彼らは、大文字とアンダースコア（「_」）の正規表現を使用して示されています。名前の実際の表現は、定義されたシステムです。特定のシステムのための表現は、これよりも異なって定義されるかもしれません。
Metavariable values MUST be considered case-sensitive except as noted otherwise.
メタ変数の値は、特記される場合を除き、大文字と小文字を区別見なされなければなりません。
The canonical metavariables defined by this specification are:
この仕様で定義された標準的なメタ変数は以下のとおりです。
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
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.)
プロトコル名（例えば、「SIP_ACCEPT」）で始まる名前のメタ変数は、メッセージヘッダフィールドのその説明でカノニカルです。これらのフィールドの数と意味は、独立して、この仕様の変更する場合があります。 （また、セクション5.5.1.5を参照してください。）
A server MAY also specify additional non-canonical metavariables.
また、サーバは、追加の非標準的なメタ変数を指定するかもしれません。
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
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アクセス認証スキームは、セクション14及びSIP / 2.0仕様書[2]の15に記載されています。 auth-方式では、大文字と小文字を区別しません。
Servers MUST provide this metavariable to scripts if the message header included an Authorization field that was authenticated.
メッセージヘッダは、認証された認証フィールドが含まれている場合、サーバは、スクリプトにこのメタ変数を提供しなければなりません。
For the complex authentication schemes, the server SHOULD perform the authentication checking itself. If the authentication failed, this metavariable SHOULD NOT be set.
複雑な認証方式の場合は、サーバー自体をチェックし、認証を実行する必要があります。認証が失敗した場合は、このメタ変数を設定するべきではありません。
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.
複数方式と複数の認証資格情報が、メッセージ内に存在する場合、この変数は、サーバがサポートする最強の方式で認証資格情報に対応するように設定されるべきです。資格情報は、いくつかのドメインに存在する場合、サーバはそれに外部ドメインから資格証明書上の任意のアクションを実行しないでください。
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.
両方の認可とプロキシ認証ヘッダが存在する場合、サーバは、それが実行されている文脈に適したヘッダーに基づいて認可を実行する必要があります。例えば、プロキシサーバおよびレジストラであるサーバは、そのローカルドメインを目的としたREGISTERメッセージ、および他のすべてのメッセージのためのプロキシ認証ヘッダの認証ヘッダーを使用します。
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]).
このメタ変数は、オクテットの10進数で、もしあれば、メッセージに添付されたメッセージボディのエンティティのサイズに設定されています。何もデータが添付されていない場合は、このメタ変数が定義されていません。構文は、SIP Content-Lengthヘッダフィールドと同じである（セクション6.15、SIP / 2.0仕様書[2]）。
CONTENT_LENGTH = "" | 1*digit
CONTENT_LENGTH = "" | 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.
メッセージは、メッセージがContent-Lengthヘッダーフィールドが含まれていない場合でも、コンテンツボディ実体を伴っていた場合、サーバーがスクリプトに、このメタ変数を提供しなければなりません。
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はインターネットメディアタイプに設定されている[6]サーバが存在しない場合にそれを決定することができるならばタイプがメッセージヘッダにContent-Typeフィールドを介して提供される、または取り付けられた場合、エンティティの付属のContent-Typeフィールドの。構文は、SIPのContent-Typeヘッダフィールドと同じです。
CONTENT_TYPE = "" | media-type
CONTENT_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におけるそれらの使用は、[5] [2]、およびHTTP / 1.1仕様のセクション3.7を参照することによりSIP / 2.0仕様のセクション6.16に記載されています。
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におけるのでContent-Typeヘッダは、ボディが存在する場合、「本体」は、実際に暗号化されたペイロードである場合を除き体は、元のメッセージ中に存在していた場合、サーバがスクリプトにこのメタ変数を提供しなければなりません指定されなければなりません。
This metavariable is set to the dialect of SIP CGI being used by the server to communicate with the script. Syntax:
このメタ変数はスクリプトと通信するためにサーバによって使用されているSIPのCGIの方言に設定されています。構文：
GATEWAY_INTERFACE = "SIP-CGI" "/" major "." minor
major = 1*digit
minor = 1*digit
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 / 12.3未満であるSIP-CGI / 2.13より低いバージョンです。メジャーまたはマイナー番号のいずれかの先行ゼロはスクリプトによって無視されなければならないとサーバによって生成されるべきではありません。
This document defines the 1.1 version of the SIP CGI interface ("SIP-CGI/1.1").
この文書は、SIP CGIインターフェース（ "SIP-CGI / 1.1"）のバージョン1.1を定義します。
Servers MUST provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供しなければなりません。
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 reasonable compromise. (The existing CGI libraries we
checked do not seem to check the version.)
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).
これらのメタ変数は、メソッドが送信される介しプロトコルに固有です。これらの変数の解釈は、SERVER_PROTOCOLのメタ変数の値に依存します（セクション5.5.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.
使用されるプロトコルはSIPである場合、「SIP_」で始まる名前のメタ変数は、メッセージヘッダからの値を含みます。 「_」で置き換え、そして「SIP_は」メタ変数名を形成するために付加している「 - 」各SIPヘッダフィールド名は大文字に変換され、すべてのオカレンスを有しています。同様の変換は、他のプロトコルに適用されます。クライアントから送信された、またはその意味を変えない方法で書き換えられるようにヘッダデータが提示されてもよいです。同じフィールド名を持つ複数のヘッダフィールドが受信された場合、彼らはメタ変数で表現される前に、同じ意味を持つ単一のヘッダフィールドとして受信されたかのように、サーバはそれらを書き直す必要があります。同様に、複数のライン上で受信されたヘッダフィールドは、単一のラインに統合されなければなりません。必要であれば、サーバは、CGI用メタ変数のために適切である（例えば、文字セット）データの表現を変更しなければなりません。
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.
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.
サーバーは、それらが受信するすべてのメッセージヘッダーフィールドのためのメタ変数を作成する必要はありません。しかし、メッセージ意味内容のためのSIPにおけるヘッダの比較的高い重要性、サーバーは、認証などの機密認証情報が含まれていないすべてのヘッダを、提供する必要があります。サーバはさらに、そのようなCONTENT_LENGTHおよびCONTENT_TYPEのような他のSIP CGI用メタ変数を介して入手可能な情報のためのプロトコル固有のメタ変数を提供すべきです。
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.
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 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.
このメタ変数は、サーバーがトランザクションの最初のリクエストのRequest-URIにユーザのために登録している現在の場所のリストが含まれています。これは、プロトコルメタ変数SIP_CONTACTと構文的に同一であり、従って、この文書のセクション5.5.1.5によって、およびSIP / 2.0仕様書[2]のセクション6.13によって定義されます。これは、すべてのURI、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.
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.
ユーザーの登録はトランザクションの途中で変更すると、サーバーは、トランザクションのために、後続のスクリプトの呼び出しのためにそれに応じて、このメタ変数を更新する必要があります。
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
The definitions of IPv4address and Ipv6address are provided in Appendix B of RFC 2373 [7].
IPv4AddressをとIpv6addressの定義は、[7] RFC 2373の付録Bに設けられています。
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を参照）、これはループバックアドレスでなければならない（すなわち、IPv4の127.0.0.1またはIPv6の:: 1）。
Servers MUST supply this value to scripts.
サーバはスクリプトに、この値を供給しなければなりません。
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.
サーバはスクリプトにこの情報を提供する必要があります。
The identity information supported about the connection by a RFC 1413 [8] request, if available.
可能な場合は識別情報は、RFC 1413 [8]要求による接続についてサポート。
REMOTE_IDENT = *CHAR
REMOTE_IDENT = * CHAR
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.
サーバーは、この機能をサポートしないことを選択してもよい、との情報が複雑なプロキシパスの存在に特に有用ではないとして、それは、多くはないの実装がすることが予想されます。
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のメタ変数が設定されている）、次いでREMOTE_USERのメタ変数の値は、ユーザIDが認証に供給さに設定されています。基本認証では、これは文法要素を「USERID」（デコード）の内容です。ダイジェストのためには、の内容である「ユーザ名値。」 PGP認証の場合は、URIヘッダからの「サインインすることによって、」Authorizationヘッダのパラメータは、存在する場合、そうでない場合は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.
いくつかの他の認証スキームが要求された場合、このメタ変数は、資格情報に関連付けられたユーザまたはエンティティを識別する認証情報の適切なコンポーネントに設定する必要があります。認証が要求されなかった場合は、このメタ変数が定義されていません。
REMOTE_USER = *OCTET
REMOTE_USER = * OCTET
Servers SHOULD provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供する必要があります。
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.
スクリプトをトリガするメッセージを要求した場合はSIP / 2.0仕様書[2]のセクション4.2に記載されているように、REQUEST_METHODのメタ変数は、リクエストが行われたと方式に設定されています。他に定義されていません。
REQUEST_METHOD = sip-method
sip-method = "INVITE" | "BYE" | "OPTIONS" | "CANCEL"
| "REGISTER" | "ACK"
| extension-method
extension-method = token
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.
ACKは通常、SIP CGI 1.1の環境に適していないことに注意してください。しかし、セクション5.11を参照してください。 CGIコンテキスト内のレジスタの意味は、セクション5.9で説明し、キャンセルされているセクション5.10に記載されています。 SIP CGI 1.1サーバーではなく、スクリプトに渡すよりも、直接いくつかのメソッドを処理するために選ぶかもしれません。
Servers MUST provide this metavariable to scripts if the triggering message was a request.
トリガメッセージが要求した場合、サーバーがスクリプトに、このメタ変数を提供しなければなりません。
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.
スクリプトは、プロキシ要求でリクエストトークンを指定した場合、このトークンは、その要求に応答して、サーバーに返されます。このトークンがないサーバーで、スクリプトによって選択されていることに注意してください。プロキシ要求への各応答は、このトークンに同じ値が含まれています。
This metavariable is specific to requests made with SIP.
このメタ変数は、SIPで作られたリクエストに固有のものです。
REQUEST_URI = absoluteURI ; defined in RFC 2396 [9]
REQUEST_URI = absoluteURIで。 [9] RFC 2396で定義されています
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が定義されている場合、このメタ変数にのみ定義されます。その場合には、サーバは、スクリプトにそれを提供しなければなりません。
This metavariable fills the roles of HTTP CGI's
SCRIPT_NAME, PATH_INFO, and QUERY_STRING.
RESPONSE_STATUS = Status-Code
RESPONSE_STATUS =ステータスコード
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.
スクリプトをトリガするメッセージが応答した場合、この変数は応答して指定された数値コードを示します。それ以外の場合は定義されていません。前者の場合、サーバは、スクリプトに、このメタ変数を提供しなければなりません。
RESPONSE_REASON = Reason-Phrase
RESPONSE_REASON =理由-フレーズ
If the message triggering the script was a response, this variable indicates the textual string specified in the response.
スクリプトをトリガするメッセージが応答した場合は、この変数は、応答で指定されたテキスト文字列を示します。
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の説明を参照してください。
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でそのアクションの説明を参照してください。
The SERVER_NAME metavariable is set to the name of the server.
SERVER_NAMEのメタ変数は、サーバーの名前に設定されています。
SERVER_NAME = hostname | hostnumber
SERVER_NAME =ホスト名|書き込み可能なホスト
Servers MUST provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供しなければなりません。
The SERVER_PORT metavariable is set to the port on which the message was received.
SERVER_PORTのメタ変数は、メッセージを受信したポートに設定されています。
SERVER_PORT = 1*digit
SERVER_PORT = 1 *桁
Servers MUST provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供しなければなりません。
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_PROTOCOLのメタ変数は、メッセージが到着したとプロトコルの名前とリビジョンに設定されています。これは通常、「SIP / 2.0」になります。これは必ずしも、クライアントへの応答でサーバによって使用されるプロトコルのバージョンと同じではありません。
SERVER_PROTOCOL = SIP-Version | extension-version
| extension-token
extension-version = protocol "/" 1*digit "." 1*digit
protocol = 1*( alphanum | "+" | "-" | "." )
extension-token = token
Servers MUST provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供しなければなりません。
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のメタ変数は、メッセージを処理する（およびゲートウェイを実行する）情報サーバソフトウェアの名前およびバージョンに設定されています。
SERVER_SOFTWARE = 1*product
product = token [ "/" product-version ]
product-version = token
Servers MUST provide this metavariable to scripts.
サーバはスクリプトに、このメタ変数を提供しなければなりません。
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.
メタ変数CONTENT_LENGTHは（セクション5.5.1.2を参照）が定義されている場合、サーバは、標準入力ストリーム上のスクリプトには、少なくともそのバイト数を指定する必要があります。スクリプトは、データを読み取ることが義務付けされていません。サーバーは、CONTENT_LENGTHバイトが読み込まれた後にEOF条件を知らせることができるが、そうする義務はありません。したがって、スクリプトは、より多くのデータが利用可能であっても、CONTENT_LENGTHバイト以上のものを読むのを試みてはいけません。
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スクリプトが開始できることを要求または応答の最大数、トランザクションの寿命にわたってスクリプトで送信することができます要求または応答の最大合計数を、データがスクリプトから受信されている必要があり、その中のタイムアウト期間を実装してもよい（MAY）それは望む、またはその他のリソース制限。スクリプトは、これらの制限の1を超えた場合、サーバーはスクリプトプロセスを終了することと `504ゲートウェイがタイムアウト「または` 500内部サーバーエラー」応答のいずれかとの取引を中止すべきです。
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.
メッセージは正確に一つの作用線を含まなければならない、また、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.
出力メッセージに発生するすべてのヘッダフィールド（SIPとCGIの両方）は1行に1つずつ指定する必要があります。 SIP CGI 1.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.
サーバーは、要求または応答の一部だけを尊重することを選択するかもしれません。特に、それが決定的な非成功の応答を送信するステータスメッセージ、次のいずれかの応答を受け入れるべきではありません。
The messages sent by a script are delimited as follows:
次のようにスクリプトによって送信されたメッセージが区切られています。
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.メッセージがContent-Typeヘッダフィールドが含まれていない、またはそれはヘッダフィールド「のContent-Length：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.
前記メッセージは、Content-TypeとContent-Lengthヘッダフィールドの両方が含まれている場合、メッセージは、設定の下の空白行の次のContent-Lengthオクテットからなる本体を有します。次のメッセージは、身体後に開始（と空白行のいくつかの数を任意に）。スクリプトが途中でその出力を閉じた場合、サーバは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-Typeではなく、コンテンツの長さが含まれている場合は、メッセージのボディには、同様に設定、次の空白行で始まります。スクリプトは、その出力を閉じるまで、この体が拡張します。この場合、これは必ずしもスクリプトを送信することができ、最後のメッセージです。サーバは、スクリプトがその出力を閉鎖する前に読み取られたデータの量を含むContent-Lengthヘッダを挿入する必要があります。
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-Lengthが含まれていますが、コンテンツタイプが含まれていない場合、それは誤りです。サーバーは、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パケットと構文的に同一であることが意図されています。
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応答を生成し、クライアントに向けて上流にそれを中継するサーバーが発生します。これらのヘッダは、スクリプトの出力に指定されていない場合は、サーバーが応答に元の要求から、より、コールID、およびのCSeqヘッダをするためにコピーする必要があります。サーバーは、これらのスクリプトの出力に指定されていない場合は正常に応じてコピーされる要求から、他のヘッダをコピーする必要があります。
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.
それが「SIP / 2.0 200 OK」を含まかのようにHTTPのCGIとの互換性のために、サーバは、Content-Typeヘッダフィールドと無作用線を含むメッセージを解釈することができます。この使用法は廃止されました。
Proxy-Request = "CGI-PROXY-REQUEST" SIP-URL SIP-Version
プロキシ要求= "CGI-PROXY-REQUEST" SIP-URLのSIP-バージョン
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に要求を転送するために、サーバーが発生します。これは、トリガリング要求が転送される場合には要求によってトリガースクリプトのいずれかによって送信されてもよいです。またはトランザクションの最初のリクエストが送信された場合には、ステートフルに実行しているサーバー上の応答によってトリガースクリプトによる。
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ヘッダーは、その全体が、元のメッセージ内のすべてのものに取って代わります。スクリプトは、元のメッセージからヘッダー要素を保持するだけでなく、新しいものを追加したい場合、それはヘッダ連結の通常の規則により、それらを連結し、スクリプト出力に結果を配置することができます。新しいヘッダフィールドには、いずれかを介して、ヘッダの後にメッセージではなく、他のヘッダの前に追加されます。
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スクリプトによって生成されていない元の要求からの任意のヘッダーは通常、プロキシサーバによって実行される変更後、プロキシリクエストにコピーされます。具体的には、サーバは、Viaフィールドとデクリメントマックス・フォワードを追加しなければなりません。そのようなRecord-Routeヘッダを追加するように、フィット見ているように、サーバは、追加の変更を行うことができます。それらはスクリプトの出力に指定されている場合、サーバはこれらのヘッダを追加すべきではありません。
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.
メッセージは、ボディを指定しない場合、最初の要求から体が使用されています。メッセージ「のContent-Length：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.
元の要求は、基本的な `以外の任意の手段によって認証された場合、これは認証を破るように、」スクリプトは、追加、変更、または任意のエンド・ツー・エンドのヘッダを削除しないでください。
Forward-Response = "CGI-FORWARD-RESPONSE" Response-Name
SIP-Version
Response-Name = response-token | "this"
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のメタ変数に、提出されたサーバ、または文字列をトークンすることができる、「これを。」このCGIスクリプトをトリガしたメッセージが応答した場合、文字列は、「これは、」のみ送信することができます。それは、このトリガーレスポンスを転送する必要があることを示します。
Script-Cookie = "CGI-SET-COOKIE" token SIP-Version
スクリプト・クッキー= "CGI-SET-COOKIE" トークンSIP-バージョン
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.
このアクションラインは、アクション行のトークンとして渡されたスクリプトのクッキーを格納するサーバーが発生します。同じトランザクション内のメッセージの後続のスクリプトの呼び出しは、メタヘッダーにトークンを運びます。スクリプトは、その後のスクリプトクッキーアクションによってCookieの値を変更することができます。この変更は、後続のすべてのスクリプトの呼び出しのために影響がかかります。
CGI-Again = "CGI-AGAIN" ("yes" | "no") SIP-Version
CGI-再び= "CGI-AGAIN"（ "YES" | "NO"）SIP-バージョン
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.
このアクションラインは、スクリプトがこのトランザクションの後続の要求と応答のために呼び出されるかどうかを決定します。パラメータが「はい」このアクションに与えられている場合、次のメッセージが到着すると、スクリプトが再び実行されます。パラメータが「なし」、またはこのアクションが指定されていない場合、スクリプトは再び実行されず、サーバーは後続のすべてのメッセージのためにそのデフォルトアクションを実行します。
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、または新規応答のいずれも行われていない場合 - それは、スクリプトは、AGAIN CGIのみの出力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.
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.
プロキシ応答を受信：レスポンスがプロキシされたリクエストに受信した場合、サーバはレスポンスが200か600クラスの応答であった場合、発信者への応答を転送し、保留中のすべての枝にCANCELを送信します。応答が100クラスだった場合は、そのブランチの状態機械が更新され、それは100応答ではなく、いくつかの他の1xxでない限り応答は、発信者に向けて、上流プロキシされます。 300、400、および500クラス応答では、ACKが送信され、他のすべての枝が終了した場合、応答は、発信者に向けて上流に転送され、応答が最高のこれまでに受けています。いないすべてのブランチが終了している場合は、サーバーは何もしません。すべてのブランチが終了しているが、この応答は最善でない場合は、最高の上流に転送されます。これは、SIP仕様で概説した基本的なアルゴリズムです。
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で指定された一般的な構文を有します。フィールド名は大文字と小文字を区別しません。フィールドの値は、それが定義されている明細書において、特定のフィールドの文法に従わなければなりません。
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.
プロキシの要求に対する応答をマッチングを支援するために、スクリプトはCGI-PROXY-REQUESTまたは新しい要求にCGI-リクエスト・トークンCGIヘッダを配置することができます。このヘッダーは、サーバーへの不透明なトークンが含まれています。この要求に応答が到着すると、トークンは、メタヘッダとしてスクリプトに戻されます。
This allows scripts to "fork" a proxy request, and
correlate which response corresponds to which branch of the
request.
Remove = "CGI-Remove" ":" 1#field-name
"1＃フィールド名：= "CGI-削除を"" 削除
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.
スクリプトは、要求に含まれていないヘッダを指定することもできます。サーバは静かにこれらを無視すべきです。スクリプトは、両方の出力にSIPヘッダーを指定してもCGI-削除ヘッダにそのヘッダをリストするべきではありません。これを実行した結果は未定義です。
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サーバは、ローカル失効タイムアウトを追跡するだけでなく、リモート・サーバにメッセージを送信するべきです。タイムアウトが経過すると、サーバーは「408要求を生成する必要があります
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.
セクション5.8で指定されたタイムアウト」応答タイムアウト応答を処理する必要があります。要求がタイムアウトした時点で、サーバーは、要求のためのメッセージをキャンセル送信すべきです。
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.
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要求のタイムアウト」としてローカルに生成された応答は、同じようにCGIスクリプトに送信する必要があります。しかし、そのような「400不正な要求」として、単にメッセージの問題を報告するメッセージは、するべきではありません。
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.
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」と、デフォルトのアクションです。前者の場合、サーバーはCGIスクリプトは内部的に登録を処理していることを前提とすべきである、とその内部の登録データベースに登録を追加しないでください。後者の場合には、サーバーには、独自のデータベースへの登録を追加する必要があります。また、サーバは3xxの、の4xx、5xxの、または6xxのステータスが返された場合、登録を追加しないでください、または登録要求を別の場所にプロキシされた場合。
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.
CANCELメッセージを受信したときにSIPのCGIサーバは、スクリプトを実行する必要があります。スクリプトは、可能な限り迅速に取引のために、それが持っている任意の状態をクリーンアップする必要があります。
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.
CANCELが既存のトランザクションのためのサーバで受信された場合、サーバーはすべて、現在未解決のブランチをキャンセルし、キャンセルに200 OK応答を送信すべきです。 CANCELメッセージのスクリプトの送信は純粋に助言され、スクリプトがそれに応じて、任意のアクションを実行しないでください。
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は、下流のプロキシされます。
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応答を生成した場合しかし、スクリプトがACKメッセージで再実行する必要があります。このスクリプトは、プロキシがUASとして動作させている場合には必要です。 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最終的な応答を受信すると、それは自分自身でACKを生成し、これを行うには、スクリプトに依存すべきではありません。この動作をオーバーライドするSIP CGI 1.1での方法はありません。サーバは200個の応答が招待するためのACKを生成しないので、サーバはUACとして動作させるスクリプトは、彼らのためにACKのを発生させなければなりません。
6 System Specifications
6つのシステム仕様
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オペレーティングシステムプラットフォーム上でSIP CGIの実装は、CGIスクリプトへリクエストメタデータを提供する仕組みとして、環境変数を使用すべきです。
For Unix compatible operating systems, the following are defined:
Unix互換のオペレーティングシステムについては、以下のものが定義されています。
Environment variables: These are accessed by the C library
routine getenv.
The current working directory: The current working directory for the script SHOULD be set to the directory containing the script.
現在の作業ディレクトリ：スクリプトの現在の作業ディレクトリは、スクリプトを含むディレクトリに設定する必要があります。
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.
文字セット：US-ASCII文字セットは、環境変数名とヘッダフィールド名の定義に使用されます。改行（NL）配列がLFです。また、サーバは改行としてCR LFを受け入れる必要があります。
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ビットのMicrosoft Windowsシステムのプラットフォーム（Windowsの95、98、NT、および2000）上のSIP CGIの実装は、CGIスクリプトへリクエストメタデータを提供する仕組みとして、環境変数を使用すべきです。
For Microsoft Windows, the following are defined:
Microsoft Windowsのために、以下が定義されています。
Environment variables: These are accessed by the C library
routine getenv.
The current working directory: The current working directory for the script SHOULD be set to the directory containing the script.
現在の作業ディレクトリ：スクリプトの現在の作業ディレクトリは、スクリプトを含むディレクトリに設定する必要があります。
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.
文字セット：US-ASCII文字セットは、環境変数名とヘッダフィールド名の定義に使用されます。改行（NL）配列はCR LFです。サーバは、改行としてLFを受け入れる必要があります。
7 Security Considerations
7つのセキュリティの考慮事項
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スクリプトが実行できるアクションを制限しようとしません。サーバー管理者は、セキュリティに敏感な彼らのSIPサーバ自体のようにCGIスクリプトを検討し、それらをインストールする前に、セキュリティレビューの同等のレベルを実行しなければなりません。
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ヘッダの下にある追加または削除ヘッダフィールドは、メッセージがユーザエージェントで認証に失敗します。
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ヘッダの出力がメッセージに追加されます。ただし、スクリプトは、彼らはまた、暗号化された部分内に存在する場合には、これらを廃棄してもよいことに注意する必要があります。
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）機密情報を運ぶことができます。サーバーが基本認証方式を使用してスクリプトを保護した場合、クライアントはユーザ名とパスワードを含むAuthorizationヘッダフィールドを送信します。サーバー場合は、むしろスクリプトよりも、この情報はHTTP_AUTHORIZATIONのメタ変数を経由して、パスワードをスクリプトに渡されるべきではない検証します。
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の最も一般的な実装では、サーバ・プロセスと同じユーザとグループを使用して子プロセスとしてスクリプトを呼び出します。したがって、スクリプトはサーバプロセス、その設定、またはドキュメントに干渉しないことを保証されるべきです。
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.
スクリプトは（コンパイル時または実行時のいずれか）、サーバーソフトウェアにリンク機能を呼び出すことによって実行された場合、注意事項は、サーバのコアメモリを保護するために取られるべきである、または信頼できないコードが実行できないことを保証します。
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.'
この仕様は、スクリプトに提示エンティティボディの長さには制限を置きません。スクリプトは、任意のサイズの静的に割り当てられたバッファが一度に全体の提出を収容するのに十分であることを仮定するべきではありません。注意深いオーバーフローチェックせずに固定長バッファを使用することは `スタック粉砕 'または'オーバーフロースタックのオペレーティングシステムの脆弱性を悪用する攻撃をもたらすことができます。スクリプトは、ディスクまたは他のバッファリングメディアに大きな提出をスプールかもしれないが、大提出の矢継ぎ早は、サービス条件の拒否が発生することがあります。エンティティボディのCONTENT_LENGTHがリソースの考慮事項が許すよりも大きい場合、スクリプトは413要求エンティティが大きすぎ `で応答する必要があります。」
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.
この作品は、[1] HTTPのCGIの仕様に非常に大きく描きます。約仕様のセクションの半分のテキストは、その文書から取得されます。
9 Authors' Addresses
9本の著者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのジョナサン・レノックス部門、NY 10027 USA
EMail: lennox@cs.columbia.edu
メールアドレス：lennox@cs.columbia.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサン・ローゼンバーグdynamicsoft 72イーグルロックアベニュー。一階イーストハノーバー、NJ 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
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
10 Bibliography
10参考文献
[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.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[3] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 10, RFC 822, August 1982.
[3]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 10、RFC 822、1982年8月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナー、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、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：メディアタイプ"、RFC 2046、1996年11月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[7] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[8] St. Johns, M., "Identification Protocol", RFC 1413, January 1993.
[8]セントジョーンズ、M.、 "識別プロトコル"、RFC 1413、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、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。