この文書はRFC 3204の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group E. Zimmerer
Request for Comments: 3204 Rankom, Inc.
Category: Standards Track J. Peterson
Neustar, Inc.
A. Vemuri
Qwest Communications
L. Ong
Ciena Networks
F. Audet
M. Watson
M. Zonoun
Nortel Networks
December 2001
MIME media types for ISUP and QSIG Objects
ＩＳＵＰとＱＳＩＧオブジェクトのＭＩＭＥメディア種別
Status of this 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.
この文書はインターネット共同体のためのインターネット標準化中のプロト
コルを指定し、そして改良のために議論と提案を求めます。このプロトコル
と標準化状態と状況は「インターネット公式プロトコル標準」（ＳＴＤ１）
の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
要約
This document describes MIME types for application/ISUP and
application/QSIG objects for use in SIP applications, according to
the rules defined in RFC 2048. These types can be used to identify
ISUP and QSIG objects within a SIP message such as INVITE or INFO, as
might be implemented when using SIP in an environment where part of
the call involves interworking to the PSTN.
この文書は、ＲＦＣ２０４８で定義される規則に従い、ＳＩＰアプリケーショ
ンで使うためのapplication/ISUPとapplication/QSIGのオブジェクトのMIME
種別を記述します。この種別はＩＮＶＩＴＥやＩＮＦＯ等のＳＩＰメッセー
ジ内のＩＳＵＰとＱＳＩＧオブジェクトを識別するために使うことが出来ま
す、呼の一部がＰＳＴＮと相互接続する環境でＳＩＰを使うときに実装され
るかもしれません。
1. Introduction
1. はじめに
ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is
a signaling protocol used between telephony switches. There are
configurations in which ISUP-encoded signaling information needs to
be transported between SIP entities as part of the payload of SIP
messages, where the preservation of ISUP data is necessary for the
proper operation of PSTN features.
ＩＴＵ−Ｔ勧告Ｑ．７６１〜４で定義されるＩＳＵＰ（ＩＳＤＮユーザ部）
は、電話交換機間で使われる信号プロトコルです。ＳＩＰメッセージのペイ
ロードの一部としてＳＩＰエンティティー間でＩＳＵＰでコード化された信
号情報が送られる必要がある設定があります、そしてそこでＩＳＵＰデータ
の保存はＰＳＴＮ機能の適切な運用に必要です。
QSIG is the analogous signaling protocol used between private branch
exchanges to support calls within private telephony networks. There
is a similar need to transport QSIG-encoded signaling information
between SIP entities in some environments.
ＱＳＩＧは私的電話網の呼をサポートするために使われる構内交換間で使
われるアナログ信号プロトコルです。 ある環境でＳＩＰエンティティ間
でＱＳＩＧでコードされた信号情報を送る必要があります。
This document is specific to this usage and would not apply to the
transportation of ISUP or QSIG messages in other applications. These
media types are intended for ISUP or QSIG application information
that is used within the context of a SIP session, and not as general
purpose transport of SCN signaling.
この文書はこの使用方法に固有で、他のアプリケーションでＩＳＵＰやＱ
ＳＩＧメッセージを運ぶことには当てはまらないでしょう。これらのメディ
ア種別はＳＩＰセッションの状況でＩＳＵＰやＱＳＩＧアプリケーション
情報を使うことを意図し、ＳＣＮ信号の多目的転送を意図しません。
The definition of media types for ISUP and QSIG application
information does not address fully how the non-SIP and SIP entities
exchanging messages determine or negotiate compatibility. It is
assumed that this is addressed by alternative means such as the
configuration of the interworking functions.
ＩＳＵＰとＱＳＩＧアプリケーション情報のメディア種別の定義は、非Ｓ
ＩＰやＳＩＰエンティティでどのように交換メッセージを決定あるいは互
換性を交渉するか、を完全には扱いません。これがインターワーク機能の
設定のような代わりの手段によって扱われると想定されます。
This is intended to be an IETF approved MIME type, and to be defined
through an RFC. NOTE: usage of Q.SIG within SIP is neither endorsed
nor recommended as a result of this MIME registration.
これはＩＥＴＦによって承認されたＭＩＭＥ種別で、ＲＦＣを通して定義
されるように意図されます。メモ：このＭＩＭＥの登録結果として、ＳＩ
ＰでのＱ．ＳＩＧの使用が推奨されたりも勧められたりはしません。
3. Proposed new media types
3. 新しいメディア種別の提案
ISUP and QSIG messages are composed of arbitrary binary data that is
transparent to SIP processing. The best way to encode these is to use
binary encoding. This is in conformance with the restrictions imposed
on the use of binary data for MIME (RFC 2045 [3]). It should be noted
that the rules mentioned in the RFC 2045 apply to Internet mail
messages and not to SIP messages. Binary has been preferred over
Base64 encoding because the latter would only result in adding bulk
to the encoded messages and possibly be more costly in terms of
processing power.
ＩＳＵＰとＱＳＩＧメッセージは任意のバイナリデータで構成されＳＩＰ
処理で透過です。これらをコード化する最も良い方法はバイナリエンコー
ディングを使うことです。これはＭＩＭＥ（ＲＦＣ２０４５[3]）のバイナ
リデータの使用に課された制約に従います。ＲＦＣ２０４５で述べた規則
がインターネットメッセージに適用され、ＳＩＰメッセージに適用されな
いことを指摘します。後者がコード化メッセージを増加させる結果をもた
らし、そして処理能力に関してより高価であろうから、バイナリがＢＡＳ
Ｅ６４エンコーディングより好まれました。
3.1 ISUP Media Type
3.1 ＩＳＵＰメディア種別
This media type is defined by the following information:
このメディア種別は次の情報で定義されます：
Media type name: application
メディア種別名：application
Media subtype name: ISUP
メディア副種別名：ISUP
Required parameters: version
必須パラメータ：version
Optional parameters: base
任意パラメータ：base
Encoding scheme: binary
エンコーディング計画：バイナリ
Security considerations: See section 5.
セキュリティの考慮：５章を見てください。
The ISUP message is encapsulated beginning with the Message Type Code
(i.e., omitting Routing Label and Circuit ID Code).
ＩＳＵＰメッセージはメッセージタイプコードで始まり（すなわち、ルー
ティングラベルと回線識別子コードを省略する）カプセルかされます。
The use of the 'version' parameter allows network administrators to
identify specific versions of ISUP that will be exchanged on a
bilateral basis. This enables a particular client such as a
SoftSwitch/Media Gateway Controller to recognize and parse the
message correctly, or (possibly) to reject the message if the
specified ISUP version is not supported. This specification places no
constraints on the values that may be used in 'version'; these are
left to the discretion of the network administrator.
ＩＳＵＰの特定のバージョンを識別することを許します。これはソフト
スイッチやメディアゲートウェイコントローラのような特定のクライアン
トが正確にメッセージを認識して解析することか、あるいは（もしかする
と）もし指定されたＩＳＵＰバージョンがサポートされないならメッセー
ジを拒絶することができるようにします。この仕様書は'version'で使わ
れるかもしれない値に制約を置きません；これらはネットワーク管理者の
裁量を邪魔しません。
This 'version' could, for example, be used to identify a network-
specific implementation of ISUP, e.g., X-NetxProprietaryISUPv3, or to
identify a well-known standard version of ISUP, e.g., itu-t or ansi.
'version'パラメータの使用は双方のネットワーク管理者間で交換される
この'version'は、例えば、ＩＳＵＰのネットワーク固有の実装、例えば
X-NetxProprietaryISUPv3を識別することや、あるいはＩＳＵＰのよく知
られている標準的なバージョン、例えば、itu-tやansiを識別するために
使うことができます。
A 'base' parameter can optionally be included in some cases (e.g., if
the receiver may not recognize the 'version' string) to specify that
the encapsulated ISUP can also be processed using the identified
'base' specification. Table 1 provides a list of 'base' values
supported by the 'application/ISUP' media type, including whether or
not the forward compatibility mechanism defined in ITU-T 1992 ISUP is
supported.
'base'パラメータはある場合に（例えば、もし受信者が'version'文字列を
認識しないかもしれないなら）カプセル化さられたＩＳＵＰが識別された
'base'仕様を使って処理できることを明示するために、任意で含めること
ができます。表１は'application/ISUP'メディア種別でサポートされた
'base'値のリストと、１９９２年のITU-T ISUPでサポートされた順方向互換
性メカニズムがサポートされるかどうかを示します。
Table 1: ISUP 'base' values
表１：ＩＳＵＰ'base'値
base protocol compatibility
base プロトコル 互換性
itu-t88 ITU-T Q.761-4 (1988) no
itu-t92+ ITU-T Q.761-4 (1992) yes
ansi88 ANSI T1.113-1988 no
ansi00 ANSI T1.113-2000 yes
etsi121 ETS 300 121 no
etsi356 ES 300 356 yes
gr317 BELLCORE GR-317 no
ttc87 JT-Q761-4(1987-1992) no
ttc93+ JT-Q761-4(1993-) yes
The Content-Disposition header [5] may be included to describe how
the encapsulated ISUP is to be processed, and in particular what the
handling should be if the received Content-Type is not recognized.
The default disposition-type for an ISUP message body is "signal".
This type indicates that the body part contains signaling information
associated with the session, but does not describe the session.
カプセルに入れられたＩＳＵＰをどう処理するか、特に受信したContent-Type
が認識できない場合にどう扱うかを記述するためにContent-Dispositionヘッ
ダ[5]が含まれるかもしれません。ＩＳＵＰメッセージ本体のdisposition-type
のデフォルトは"signal"です。この種別はセッションと結びつく信号情報を
含む本体部を示しますが、セッションを記述しません。
Supplementing the description of the Content-Disposition header in
[5], as well as any characterization of the Content-Disposition
header in the SIP standard, is the following BNF describing
disposition-types and disposition-params that may be used in the
header of ISUP and QSIG MIME bodies.
[5]のContent-Dispositionヘッダの記述を補うのは、ＳＩＰ標準の
Content-Dispositionヘッダ全ての特徴と同様に、disposition-types
とdisposition-paramsを記述する次のＢＮＦです、これはＩＳＵＰとＱＳＩＧ
本体のヘッダで使われるかもしれません。
Content-Disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-param )
disposition-type = "signal" | disp-extension-token
disposition-param = "handling" "="
( "optional" | "required" | other-handling )
| generic-param
other-handling = token
disp-extension-token = token
A full definition of the use of the "handling" parameter is given in
the IANA Considerations section below. The following is how a
typical header would look ('base' may be omitted):
"handling"パラメータの使用方法の完全な定義が下記のＩＡＮＡの考慮の
章でされます。以下は典型的なヘッダです（'base'が省略されるかもしれ
ません）：
Content-Type: application/ISUP; version=nxv3; base=etsi121
Content-Disposition: signal; handling=optional
3.2 QSIG Media Type
3.2 QSIG のメディア種別
The application/QSIG media type is defined by the following
information:
application/QSIGメディア種別は次の情報によって定義されます：
Media type name: application
メディア種別名：application
Media subtype name: QSIG
メディア副種別名：QSIG
Required parameters: none
必須パラメータ：なし
Optional parameters: version
任意パラメータ：version
Encoding scheme: binary
エンコーディング計画：バイナリ
Security considerations: See section 5.
セキュリティの考慮：５章を見てください。
The use of the 'version' parameter allows identification of different
QSIG variants. This enables the terminating Connection Server to
recognize and parse the message correctly, or (possibly) to reject
the message if the particular QSIG variant is not supported.
'version'パラメータの使用で異なるQSIG方言の識別が可能です。これは終
端接続サーバが正確にメッセージを認識し解析し、あるいは（もしかすると）、
もし特定のQSIG方言がサポートされないなら、メッセージを拒絶することが
できるようにします。
Table 2 is a list of protocol versions supported by the
'application/QSIG' media type.
表２は 'application/QSIG'メディア種別によってサポートされるプロトコ
ルバージョンのリストです。
Table 2: QSIG versions
表２：ＱＳＩＧ版数
version protocol
版数 プロトコル
------- --------
iso ISO/IEC 11572 (Basic Call) and
ISO/IEC 11582 (Generic Functional Protocol)
The following is how a typical header would look (Content-Disposition
not included in this instance):
次のは典型的なヘッダです（この場合Content-Dispositionはありません）：
Content-Type: application/QSIG; version=iso
The default Content-Disposition disposition-type is "signal" as in an
ISUP body part. The "handling" parameter described above can also be
used for QSIG bodies.
デフォルトContent-Disposition性質種別はＩＳＵＰ本体同様に"signal"で
す。上記の"handling"パラメータは同じくQSIG本体のために使われることが
できます。
4. Illustrative examples
4. 例示
4.1 ISUP
4.1 ＩＳＵＰ
SIP message format requires a Request line followed by Header lines
followed by a CRLF separator followed by the message body. To
illustrate the use of the 'application/ISUP' media type, below is an
INVITE message which has the originating SDP information and an
encapsulated ISUP IAM.
ＳＩＰメッセージフォーマットがリクエスト行、それに続くヘッダ行、Ｃ
ＲＬＦ分離記号に続くメッセージ本体を要求します。下の'application/ISUP'
メディアタイプの使用の例示は、出発点のＳＤＰ情報とカプセルに入れら
れたＩＳＵＰ ＩＡＭを持つＩＮＶＩＴＥメッセージとです。
Note that the two payloads are demarcated by the boundary parameter
(specified in RFC 2046 [4]) which in the example has the value
"unique-boundary-1". This is part of the specification of MIME
multipart and is not related to the
２つのペイロードは、例では"unique-boundary-1"である、境界線パラメー
タ（ＲＦＣ２０４６[4]で指定）によって区切られることに注意してくださ
い。これはＭＩＭＥマルチパート仕様の一部で、○○○と関係がありません
INVITE sip:13039263142@Den1.level3.com SIP/2.0
Via: SIP/2.0/UDP den3.level3.com
From: sip:13034513355@den3.level3.com
To: sip:13039263142@Den1.level3.com
Call-ID: DEN1231999021712095500999@Den1.level3.com
CSeq: 8348 INVITE
Contact: <sip:jpeterson@level3.com>
Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
v=0
o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP seminar
c=IN IP4 MG122.level3.com
t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-Type: application/ISUP; version=nxv3;
base=etsi121
Content-Disposition: signal; handling=optional
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique-boundary-1--
Note: Since binary encoding is used for the ISUP payload, each byte
is encoded as a byte, and not as a two-character hex representation.
Hex digits were used in the document because a literal encoding of
those bytes would have been confusing and unreadable.
注釈：バイナリコーディングがＩＳＵＰペイロードのために使われますか
ら、それぞれのバイトが２文字の１６進表示ではなく、１バイトでコード
化されます。それらのバイトの文字通りのコーディングが紛らわしくて、
読めないであろうから、１６進数字が文書で使われました。
4.2 QSIG
4.2 ＱＳＩＧ
To illustrate the use of the 'application/QSIG' media type, below is
an INVITE message which has the originating SDP information and an
encapsulated QSIG SETUP message.
下の'application/QSIG'メディアタイプの使用の例示は、出発点のＳＤＰ
情報とカプセルに入れられるＱＳＩＧ ＳＥＴＵＰメッセージを持つＩＮＶ
ＩＴＥメッセージです。
Note that the two payloads are demarcated by the boundary parameter
(specified in RFC 2046 [4]) which in the example has the value
"unique- boundary-1". This is part of the specification of MIME
multipart and is not related to the 'application/QSIG' media type.
２つのペイロードが、例で"unique- boundary-1"である、境界線パラメー
タ（ＲＦＣ２０４６[4]で指定）によって区切られることに注意してくだ
さい。これはＭＩＭＥマルチパート仕様の一部であり、'application/QSIG'
メディアタイプと関係がありません。
INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0
Via: SIP/2.0/UDP sc10.nortelnetworks.com
From: sip:14085655675@sc10.nortelnetworks.com
To: sip:14084955072@sc1.nortelnetworks.com
Call-ID: 1231999021712095500999@sc12.nortelnetworks.com
CSeq: 1234 INVITE
Contact: <sip:14085655675@sc10.nortelnetworks.com>
Content-Length: 358
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
v=0
o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4
s=SDP seminar
c=IN IP4 MG141.nortelnetworks.com
t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-type:application/QSIG; version=iso
08 02 55 55 05 04 02 90 90 18 03 a1 83 01
70 0a 89 31 34 30 38 34 39 35 35 30 37 32
--unique-boundary-1--
5. Security considerations
5. セキュリティの考察
Information contained in ISUP and QSIG bodies may include sensitive
customer information, potentially requiring use of encryption.
ＩＳＵＰとＱＳＩＧ本体に含まれる情報が機密性が高い顧客情報を含むか
もしれず、暗号の使用を必要とする可能性があります。
Security mechanisms are provided in RFC 2543 (SIP - Session
Initiation Protocol) and should be used as appropriate for both the
SIP message and the encapsulated ISUP or QSIG body.
セキュリティメカニズムがＲＦＣ２５４３（ＳＩＰ−セッション開始プロ
トコル）で提供されて、そしてＳＩＰメッセージとカプセルに入れられた
ＩＳＵＰあるいはＱＳＩＧ本体の両方で同じく適切に使われるべきです。
6. IANA considerations
6. ＩＡＮＡの考慮
This document registers the "application/ISUP" and "application/QSIG"
MIME media types.
この文書は"application/ISUP"と"application/QSIG"のＭＩＭＥメディア種別
を登録します。
Registrations for the 'version' symbols used within the ISUP and QSIG
MIME types must specify a definitive specification reference,
identifying a particular issue of the specification, to which the new
symbol shall refer. Identifying a definite specification reference
requires a review process; the authors recommend that a subject
matter expert be designated as described in RFC 2434 [6] under Expert
Review.
ISUPとQSIG MIME種別で使う'version'記号は、新しい記号の登録が示すべき
仕様の特定の問題を識別する最終的な仕様の文献を指定しなくてはなりませ
ん。明確な仕様の文献を識別することは調査手順を必要とします；著者は、
ＲＦＣで２４３４[6]で記述されるように専門家調査で、主題専門家が指名
されることを勧めます。
Note that where a specification is fully peer-to-peer backwards
compatible with a previous issue (i.e., the compatibility mechanism
is supported by both), then there is no need for separate symbols to
be registered. The symbol for the original specification should be
used to identify backwards-compatible upgrades of that specification
as well.
仕様が問題に対し完全なピア対ピアの後方互換性があるなら（すなわち、互
換性メカニズムが両者でサポートされるなら）、別個の記号が登録される必
要がないことに注意してください。元の仕様のための記号は同様にその仕様
の後方互換性がある改版を識別するために使われるべきです。
Symbols beginning with the characters 'X-' are reserved for non-
standard usage (e.g., cases in which a token other than a string
representing an issue of an ISUP specification is appropriate for
characterizing ISUP within an administrative domain). Such non-
standard version can only be transmitted between administrative
domains in accordance with a bilateral agreement. These symbols
should be administered under the Private Use policy described in RFC
2434.
'X-'で始まる記号は非標準の使用のために予約されます（例えば、管理ド
メイン内でＩＳＵＰを述べる、ＩＳＵＰ仕様の問題を表している文字列以
外のトークンが適切である場合）。このような非標準の版はただ二者間の
規定で管理ドメイン間で伝達できるだけです。これらの記号はＲＦＣ２４
３４で記述したプライベートの使用ポリシ下で与えられるべきです。
This document registers a new disposition-type for the Content-
Disposition header, 'signal', to be used when a MIME body contains
supplemental signaling information (ISUP and QSIG as MIME bodies
being examples of this).
この文書は、ＭＩＭＥ本体が補足の信号情報を含んでいるとき使われる、
内容性質ヘッダの新しい性質種別'signal'を登録します（ＩＳＵＰとＱＳ
ＩＧのＭＩＭＥ本体がこの例です）。
This document also defines a Content Disposition parameter,
"handling". The handling parameter, handling-parm, describes how the
UAS should react if it receives a message body whose content type or
disposition type it does not understand. If the parameter has the
value "optional", the UAS MUST ignore the message body; if it has the
value "required", the UAS MUST return 415 (Unsupported Media Type).
If the handling parameter is missing, the value "required" is to be
assumed.
この文書は同じく内容性質パラメータ"handling"を定義します。取り扱い
パラメータ、handling-parm、はもしＵＡＳがその内容種別あるいは性質種
別を理解しないメッセージ本体を受け入れるなら、ＵＡＳがどのように反
応するべきであるか記述します。もしパラメータ値が"optional"であるな
ら、ＵＡＳはメッセージ本体を無視しなくてはなりません(MUST)；もし値
が"required"なら、ＵＡＳは４１５（サポートされていないメディア種別）
を返さなくてはなりません。もし取り扱いパラメータが欠けているなら
"required"値と仮定されるはずです。
7. Authors Addresses
7. 著者のアドレス
Eric Zimmerer
Rankom Inc.
19500 Pruneridge Ave Suite #4303
Cupertino, CA 95014, USA
EMail: eric_zimmerer@yahoo.com
Aparna Vemuri
Qwest Communications
6000 Parkwood Pl
Dublin, OH 43016, USA
EMail: Aparna.Vemuri@Qwest.com
Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520, USA
EMail: jon.peterson@neustar.com
Lyndon Ong
Ciena
Cupertino, CA, USA
EMail: lyndon_ong@yahoo.com
Francois Audet
Nortel Networks
4301 Great America Parkway
Santa Clara, CA 95054, USA
EMail: mzonoun@nortelnetworks.com
Mo Zonoun
Nortel Networks
4301 Great America Parkway
Santa Clara, CA 95054, USA
EMail: audet@nortelnetworks.com
M. Watson
Nortel Networks
Maidenhead, UK
EMail: mwatson@nortelnetworks.com
8. References
8. 参考文献
[1] Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail
Extensions (MIME) Part Four: Registration Procedures", BCP 13,
RFC 2048, November 1996.
[2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"Session Initiation Protocol (SIP)", RFC 2543, March 1999.
[3] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045,
November 1996.
[4] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Full Copyright Statement
完全著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（Ｃ）インターネット社会（２００１）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット社会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット社会によって
供給されます。