RFC3326 日本語訳

Network Working Group                                     H. Schulzrinne
Request for Comments: 3326                           Columbia University
Category: Standards Track                                        D. Oran
                                                                   Cisco
                                                            G. Camarillo
                                                                Ericsson
                                                           December 2002

Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3326年のコロンビア大学カテゴリ: 標準化過程D.オランシスコG.キャマリロエリクソン2002年12月

   The Reason Header Field for the Session Initiation Protocol (SIP)

セッション開始プロトコルのための理由ヘッダーフィールド(一口)

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   For creating services, it is often useful to know why a Session
   Initiation Protocol (SIP) request was issued.  This document defines
   a header field, Reason, that provides this information.  The Reason
   header field is also intended to be used to encapsulate a final
   status code in a provisional response.  This functionality is needed
   to resolve the "Heterogeneous Error Response Forking Problem", or
   HERFP.

サービスを作成するのに、(SIP)が要求するSession Initiationプロトコルがなぜ発行されたかを知るのはしばしば役に立ちます。 このドキュメントはヘッダーフィールド、この情報を提供するReasonを定義します。 また、最終的な状態が暫定的な応答でコードであるとカプセル化するのにReasonヘッダーフィールドが使用されることを意図します。 この機能性が、「異種の誤り応答分岐問題」、またはHERFPを決議するのに必要です。

Schulzrinne, et. al.        Standards Track                     [Page 1]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[1ページ]。

Table of Contents

目次

   1.   Introduction ...............................................  2
   1.1. Terminology ................................................  3
   2.   The Reason Request Header Field ............................  3
   3.   Examples ...................................................  4
   3.1. Call Completed Elsewhere ...................................  4
   3.2. Refusing an Offer that Comes in a Response .................  4
   3.3. Third Party Call Control ...................................  5
   3.4. ISUP interworking ..........................................  5
   4.   IANA Considerations ........................................  6
   5.   Security Considerations ....................................  6
   6.   Acknowledgments ............................................  7
   7.   Authors' Addresses .........................................  7
   8.   Normative References .......................................  7
   9.   Full Copyright Statement ...................................  8

1. 序論… 2 1.1. 用語… 3 2. 理由要求ヘッダーフィールド… 3 3. 例… 4 3.1. ほかの場所で完成していた状態で、電話をしてください… 4 3.2. ResponseでそのComesをOfferに拒否します… 4 3.3. 第三者呼び出しコントロール… 5 3.4. ISUPの織り込むこと… 5 4. IANA問題… 6 5. セキュリティ問題… 6 6. 承認… 7 7. 作者のアドレス… 7 8. 標準の参照… 7 9. 完全な著作権宣言文… 8

1. Introduction

1. 序論

   The same SIP [1] request can be issued for a variety of reasons.  For
   example, a SIP CANCEL request can be issued if the call has completed
   on another branch or was abandoned before answer.  While the protocol
   and system behavior is the same in both cases, namely, alerting will
   cease, the user interface may well differ.  In the second case, the
   call may be logged as a missed call, while this would not be
   appropriate if the call was picked up elsewhere.

さまざまな理由で同じSIP[1]要求を出すことができます。 例えば、呼び出しが別のものでブランチを完成したか、または答えの前に捨てられたなら、SIP CANCEL要求を出すことができます。 プロトコルとシステムの振舞いがどちらの場合も同じである間、すなわち、警告はやんで、ユーザーインタフェースはたぶん異なるでしょう。 2番目の場合では、呼び出しは逃された呼び出しとして登録されるかもしれません、呼び出しがほかの場所で再開されるなら、これが適切でないでしょうにが。

   Third party call controllers sometimes generate a SIP request upon
   reception of a SIP response from another dialog.  Gateways generate
   SIP requests after receiving messages from a different protocol than
   SIP.  In both cases the client may be interested in knowing what
   triggered the SIP request.

第三者呼び出しコントローラは別の対話からSIP応答のレセプションに関するSIP要求を時々生成します。 異なったプロトコルからメッセージを受け取った後に、ゲートウェイはSIPよりSIPに要求を生成します。 どちらの場合も、クライアントは、何がSIP要求の引き金となったかを知りたがっているかもしれません。

   SIP responses already offer a means of informing the user of why a
   request failed.  The simple mechanism in this document accomplishes
   something roughly similar for requests.

SIP応答は既に要求が失敗した理由についてユーザに知らせる手段を提供します。 簡単なメカニズムは本書では要求には、およそ何か同様のものを達成します。

   An INVITE can sometimes be rejected not because the session
   initiation was declined, but because some aspect of the request was
   not acceptable.  If the INVITE forked and resulted in a rejection,
   the error response may never be forwarded to the client unless all
   the other branches also reject the request.  This problem is known as
   the "Heterogeneous Error Response Forking Problem", or HERFP.  It is
   foreseen that a solution to this problem may involve encapsulating
   the final error response in a provisional response. The Reason header
   field is a candidate to be used for such encapsulation.

セッション開始が断たれたので拒絶されるのではなく、要求の何らかの局面が許容できなかったので、時々INVITEを拒絶できます。 INVITEが拒絶を分岐して、もたらして、また、他のすべてのブランチが要求を拒絶しないなら、誤り応答をクライアントに決して送らないかもしれません。 この問題は「異種の誤り応答分岐問題」、またはHERFPとして知られています。 この問題への解決が、暫定的な応答における最終的な誤り応答をカプセル化することを伴うかもしれないのが見通されます。 Reasonヘッダーフィールドはそのようなカプセル化に使用されるべき候補です。

Schulzrinne, et. al.        Standards Track                     [Page 2]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[2ページ]。

   Initially, the Reason header field defined here appears to be most
   useful for BYE and CANCEL requests, but it can appear in any request
   within a dialog, in any CANCEL request and in any response whose
   status code explicitly allows the presence of this header field.

初めは、ここで定義されたReasonヘッダーフィールドはBYEとキャンセル要求の最も役に立つように見えますが、それは対話の中のどんな要求、どんなキャンセル要求、およびステータスコードが明らかにこのヘッダーフィールドの存在を許容するどんな応答にも現れることができます。

   Note that the Reason header field is usually not needed in responses
   because the status code and the reason phrase already provide
   sufficient information.

ステータスコードと理由句が既に十分な情報を提供するので、通常、Reasonヘッダーフィールドは応答で必要でないことに注意してください。

   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

クライアントとサーバは無料でこのヘッダーフィールドを無視できます。 それは影響力を全くプロトコル処理に持っていません。

1.1 Terminology

1.1 用語

   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 BCP 14, RFC 2119
   [2] and indicate requirement levels for compliant SIP
   implementations.

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[2]ということであり、対応する一口実装のために要件レベルを示すべきであるかをさせましょう。

2. The Reason Header Field

2. 理由ヘッダーフィールド

   The Reason header field MAY appear in any request within a dialog, in
   any CANCEL request and in any response whose status code explicitly
   allows the presence of this header field.  The syntax of the header
   field follows the standard SIP parameter syntax.

Reasonヘッダーフィールドは対話の中のどんな要求、どんなキャンセル要求、およびステータスコードが明らかにこのヘッダーフィールドの存在を許容するどんな応答にも現れるかもしれません。 ヘッダーフィールドの構文は標準のSIPパラメタ構文に従います。

 Reason            =  "Reason" HCOLON reason-value *(COMMA reason-value)
 reason-value      =  protocol *(SEMI reason-params)
 protocol          =  "SIP" / "Q.850" / token
 reason-params     =  protocol-cause / reason-text
                      / reason-extension
 protocol-cause    =  "cause" EQUAL cause
 cause             =  1*DIGIT
 reason-text       =  "text" EQUAL quoted-string
 reason-extension  =  generic-param

= 理由価値の*(COMMA理由価値)理由価値=プロトコル*(SEMI理由-params)プロトコル=「一口」/"Q.850"/トークン理由-paramsが理由理由プロトコル原因/テキスト/拡張子プロトコル原因と等しいという「理由」HCOLONが「原因」「テキスト」等しい引用文字列理由1*ケタ理由等しい原因原因=テキスト=拡張子=ジェネリック-paramと等しい理由

   The following values for the protocol field have been defined:

プロトコル分野への以下の値は定義されました:

      SIP: The cause parameter contains a SIP status code.

一口: 原因パラメタはSIPステータスコードを含んでいます。

      Q.850: The cause parameter contains an ITU-T Q.850 cause value
           in decimal representation.

Q.850: 原因パラメタは10進表現におけるITU-T Q.850原因価値を含んでいます。

Schulzrinne, et. al.        Standards Track                     [Page 3]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[3ページ]。

   Examples are:

例は以下の通りです。

      Reason: SIP ;cause=200 ;text="Call completed elsewhere"
      Reason: Q.850 ;cause=16 ;text="Terminated"
      Reason: SIP ;cause=600 ;text="Busy Everywhere"
      Reason: SIP ;cause=580 ;text="Precondition Failure"

理由: SIP; 原因=200; テキストは「ほかの場所に終了した呼び出し」Reasonと等しいです: Q.850; 原因=16; テキストは「終えられた」理由と等しいです: 一口; 原因=600; 「いたる所で忙しい」テキスト=は推論します: 一口; =580を引き起こしてください; テキストは「前提条件失敗」と等しいです。

   Proxies generating a CANCEL request upon reception of a CANCEL from
   the previous hop that contains a Reason header field SHOULD copy it
   into the new CANCEL request.

ReasonヘッダーフィールドSHOULDを含む前のホップからキャンセルのレセプションに関するキャンセル要求を生成するプロキシが新しいキャンセル要求にそれをコピーします。

   In normal SIP operation, a SIP status code in a response provides the
   client with information about the request that triggered the
   response, the session parameters, or the user.  For example, a 405
   (Method not allowed) response indicates that the request contained an
   unsupported method.  A 488 (Not Acceptable Here) indicates that the
   session parameters are unacceptable and a 486 (Busy Here) provides
   information about the status of the user.

通常のSIP操作では、応答におけるSIPステータスコードは応答の引き金となった要求、セッションパラメタ、またはユーザの情報をクライアントに提供します。 例えば、405(許容されなかったメソッド)応答は、要求がサポートされないメソッドを含んだのを示します。 488(Acceptable Hereでない)は、セッションパラメタが容認できなくて、(忙しいHere)がユーザの状態の情報を提供する486であることを示します。

   Any SIP status code MAY appear in the Reason header field of a
   request.  However, status codes that provide information about the
   user and about session parameters are typically useful for
   implementing services whereas status codes intended to report errors
   about a request are typically useful for debugging purposes.

どんなSIPステータスコードも要求のReasonヘッダーフィールドに現れるかもしれません。 しかしながら、ユーザとセッションパラメタの情報を提供するステータスコードは通常サービスを実装することの役に立ちますが、要求に関して誤りを報告することを意図するステータスコードは通常デバッグ目的の役に立ちます。

   A SIP message MAY contain more than one Reason value (i.e., multiple
   Reason lines), but all of them MUST have different protocol values
   (e.g., one SIP and another Q.850).  An implementation is free to
   ignore Reason values that it does not understand.

SIPメッセージは1つ以上のReason値を含むかもしれませんが(すなわち、複数のReasonが立ち並んでいます)、彼ら皆、には異なったプロトコル値(例えば、1SIPと別のQ.850)がなければなりません。 実装は自由に、それが理解していないReason値を無視できます。

3. Examples

3. 例

   This section contains a number of examples that illustrate the use of
   the Reason header field.

このセクションはReasonヘッダーフィールドの使用を例証する多くの例を含みます。

3.1 Call Completed Elsewhere

3.1 ほかの場所に終了した呼び出し

   A proxy forks an INVITE request and one of the branches returns a 200
   (OK).  The forking proxy includes this status code in a Reason header
   field in the CANCEL request that it sends to the rest of the
   branches.

プロキシはINVITE要求を分岐させます、そして、ブランチの1つは200(OK)を返します。 分岐しているプロキシはブランチの残りに発信するというキャンセル要求におけるReasonヘッダーフィールドでこのステータスコードを入れます。

3.2 Refusing an Offer that Comes in a Response

3.2 ResponseでそのComesをOfferに拒否すること。

   A client sends an empty INVITE and receives an unacceptable offer in
   a 200 (OK) response.  The client sends an ACK with a correctly
   formatted answer and immediately sends a BYE to terminate the

クライアントは、200(OK)応答で空のINVITEを送って、容認できない申し出を受けます。 クライアントは、正しくフォーマットされた答えと共にACKを送って、すぐに、終わるためにBYEを送ります。

Schulzrinne, et. al.        Standards Track                     [Page 4]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[4ページ]。

   session.  The client includes a 488 (Not Acceptable Here) status code
   in a Reason header field.

セッション。 クライアントはReasonヘッダーフィールドで488(Acceptable Hereでない)ステータスコードを入れます。

3.3 Third Party Call Control

3.3 第三者呼び出しコントロール

   The third party call controller of figure 1 tries to establish a
   session between A and B.  However, user B is busy.  The controller
   sends a BYE with the status code 486 (Busy Here) in a Reason header
   field.

しかしながら、AとB.とのセッションを確立する図1トライの第三者呼び出しコントローラ、ユーザBは忙しいです。 コントローラはReasonヘッダーフィールドにおけるステータスコード486(忙しいHere)があるBYEを送ります。

      A                Controller            B
      |   INV  no SDP     |                  |
      |<------------------|                  |
      |                   |                  |
      |    200 SDP A1     |                  |
      |-----------------> |                  |
      |                   |                  |
      |   ACK  SDP held   |                  |
      |<------------------|                  |
      |                   |                  |
      |                   |   INV no SDP     |
      |                   |----------------->|
      |                   |                  |
      |                   |  486 Busy Here   |
      |                   |<-----------------|
      |                   |                  |
      |                   |       ACK        |
      |                   |----------------->|
      |     BYE (486)     |                  |
      |<------------------|                  |
      |                   |                  |
      |     200 OK        |                  |
      |-----------------> |                  |
      |                   |                  |

コントローラB| INVノーSDP| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| 200 SDP A1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| ACK SDPは成立しました。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| INVノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 486はここで忙しくします。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| さようなら(486)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|

         Figure 1: Third Party Call Control

図1: 第三者呼び出しコントロール

3.4 ISUP interworking

3.4 ISUPの織り込むこと

   The PSTN gateway of figure 2 generates an INVITE that has to be
   CANCELed when a REL (release) message is received from the ISUP side.
   The CANCEL request contains the Q.850 cause value (16 Normal Call
   Clearing) of the REL message.

2図のPSTNゲートウェイはISUP側からREL(リリース)メッセージを受け取るとき、CANCELedでなければならないINVITEを生成します。 キャンセル要求はRELメッセージのQ.850原因価値(16Normal Call Clearing)を含んでいます。

Schulzrinne, et. al.        Standards Track                     [Page 5]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[5ページ]。

      A                Gateway               B
      |       IAM         |                  |
      |-----------------> |                  |
      |                   |     INVITE       |
      |                   |----------------->|
      |                   |                  |
      |                   |   100 Trying     |
      |                   |<-----------------|
      |     REL (16)      |                  |
      |-----------------> |                  |
      |                   | CANCEL (Q.850 16)|
      |                   |----------------->|
      |                   |      200 OK      |
      |                   |<-----------------|

ゲートウェイB| IAM| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 100 トライ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| REL(16)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (Q.850 16)を取り消してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|

             Figure 2: ISUP Interworking

図2: ISUPの織り込むこと

4. IANA Considerations

4. IANA問題

   This document defines a new SIP header field, "Reason", according to
   Section 27 of RFC 3261.

RFC3261のセクション27に従って、このドキュメントは新しいSIPヘッダーフィールド、「理由」を定義します。

   Protocol values (and their associated protocol cause) to be used with
   this header field are registered by the IANA into a new sub-registry
   under http://www.iana.org/assignments/sip-parameters, labeled "Reason
   Protocols".  Reason protocols MUST refer to either an ITU-T
   Recommendation number, an IETF protocol name or the recognized
   protocol identifier from another standardization organization.
   Protocol cause describes the source of the 'cause' field in the
   Reason header field.

このヘッダーフィールドと共に使用されるべきプロトコル値(そして、それらの関連プロトコル原因)はIANAによって「理由プロトコル」とラベルされた http://www.iana.org/assignments/sip-parameters の下の新しいサブ登録に示されます。 理由プロトコルは別の標準化組織からITU-T Recommendation番号、IETFプロトコル名または認識されたプロトコル識別子を示さなければなりません。 プロトコル'原因がソースについて説明する、'Reasonヘッダーフィールドでは、さばきます。

   The only entries in the registry for the time being are:

当分の間間の登録における唯一のエントリーは以下の通りです。

   Protocol Value   Protocol Cause            Reference
   --------------   ---------------           -----------
   SIP              Status code               RFC 3261
   Q.850            Cause value in decimal    ITU-T Q.850
                    representation

プロトコル値のプロトコル原因参照-------------- --------------- ----------- 10進ITU-T Q.850表現におけるSIP StatusコードRFC3261Q.850 Cause価値

5. Security Considerations

5. セキュリティ問題

   Spoofing or removing the Reason header field from a response in a
   HERFP scenario can make it impossible for a client to update properly
   its previous request, making therefore session establishment
   impossible. Thus, it is RECOMMENDED that this header field is
   protected by a suitable integrity mechanism.

HERFPシナリオで応答からReasonヘッダーフィールドを偽造するか、または取り除くのにクライアントが適切に前の要求をアップデートするのが不可能になる場合があります、したがって、セッション設立を不可能にします。 したがって、このヘッダーフィールドが適当な保全メカニズムによって保護されるのは、RECOMMENDEDです。

Schulzrinne, et. al.        Standards Track                     [Page 6]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[6ページ]。

   properly its previous request, making therefore session establishment
   impossible. Thus, it is RECOMMENDED that this header field is
   protected by a suitable integrity mechanism.

適切に、それは前です。したがって、セッションを設立不可能にして、要求します。 したがって、このヘッダーフィールドが適当な保全メカニズムによって保護されるのは、RECOMMENDEDです。

6. Acknowledgments

6. 承認

   Jonathan Rosenberg, Rohan Mahy and Vijay K. Gurbani provided helpful
   comments and suggestions.

ジョナサン・ローゼンバーグ、Rohanマーイ、およびビジェイK.Gurbaniは役に立つコメントと提案を提供しました。

8. Normative References

8. 引用規格

   [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
       Session Initiation Protocol", RFC 3261, June 2002.

[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [2] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels," BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

7. Authors' Addresses

7. 作者のアドレス

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA

コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部

   EMail:  schulzrinne@cs.columbia.edu

メール: schulzrinne@cs.columbia.edu

   David R. Oran
   Cisco Systems, Inc.
   Acton, MA
   USA

デヴィッドR.オランシスコシステムズInc.MAアクトン(米国)

   EMail:  oran@cisco.com

メール: oran@cisco.com

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド

   EMail:  Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

Schulzrinne, et. al.        Standards Track                     [Page 7]

RFC 3326            The Reason Header Field for SIP        December 2002

et Schulzrinne、アル。 規格は2002年12月に一口のためのRFC3326理由ヘッダーフィールドを追跡します[7ページ]。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Schulzrinne, et. al.        Standards Track                     [Page 8]

et Schulzrinne、アル。 標準化過程[8ページ]