[要約] RFC 3204はISUPとQSIGオブジェクトのためのMIMEメディアタイプを定義しており、これらのオブジェクトをインターネット上でのデータ交換に適した形式で表現することを目的としています。
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
ISUPおよびQSIGオブジェクト用のMIMEメディアタイプ
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このドキュメントでは、RFC 2048で定義されているルールに従って、SIPアプリケーションで使用するアプリケーション/ISUPおよびアプリケーション/QSIGオブジェクトのMIMEタイプについて説明します。これらのタイプは、招待や情報などのSIPメッセージ内のISUPおよびQSIGオブジェクトを識別するために使用できます。通話の一部がPSTNへのインターワーキングを伴う環境でSIPを使用するときに実装される可能性があります。
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.
ISUP（ISDNユーザーパーツ）ITU-Tの推奨事項で定義されているQ.761-4は、テレフォニースイッチ間で使用されるシグナル伝達プロトコルです。SIPメッセージのペイロードの一部として、SIPエンティティ間でISUPエンコードされたシグナリング情報を輸送する必要がある構成があります。PSTN機能の適切な操作にはISUPデータの保存が必要です。
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.
QSIGは、プライベートテレフォニーネットワーク内のコールをサポートするために、プライベートブランチ交換間で使用される類似のシグナル伝達プロトコルです。一部の環境のSIPエンティティ間でQSIGエンコードされたシグナル伝達情報を輸送する同様の必要性があります。
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.
このドキュメントはこの使用法に固有であり、他のアプリケーションでのISUPまたはQSIGメッセージの輸送には適用されません。これらのメディアタイプは、SIPセッションのコンテキスト内で使用されるISUPまたはQSIGアプリケーション情報を対象としており、SCNシグナル伝達の汎用輸送としてではありません。
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.
ISUPおよびQSIGアプリケーション情報のメディアタイプの定義は、メッセージを交換する非SIPおよびSIPエンティティが互換性を決定または交渉する方法について完全には対応していません。これは、インターワーキング関数の構成などの代替手段によって対処されると想定されています。
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.
これは、IETF承認済みのMIMEタイプであり、RFCを介して定義されることを目的としています。注：SIP内でのQ.SIGの使用は、このMIME登録の結果として承認されておらず、推奨されません。
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.
ISUPおよびQSIGメッセージは、SIP処理に対して透明な任意のバイナリデータで構成されています。これらをエンコードする最良の方法は、バイナリエンコードを使用することです。これは、MIMEのバイナリデータの使用に課される制限に準拠しています（RFC 2045 [3]）。RFC 2045で言及されているルールは、メッセージをSIPするのではなく、インターネットメールメッセージに適用されることに注意する必要があります。バイナリは、ベース64エンコードよりも好まれています。後者は、エンコードされたメッセージにバルクを追加するだけで、処理能力の点でより費用がかかる可能性があるためです。
This media type is defined by the following information:
このメディアタイプは、次の情報で定義されています。
Media type name: application Media subtype name: ISUP Required parameters: version Optional parameters: base Encoding scheme: binary Security considerations: See section 5.
メディアタイプ名：アプリケーションメディアサブタイプ名：ISUP必須パラメーター：バージョンオプションパラメーター：ベースエンコーディングスキーム：バイナリセキュリティの考慮事項：セクション5を参照してください。
The ISUP message is encapsulated beginning with the Message Type Code (i.e., omitting Routing Label and Circuit ID Code).
ISUPメッセージは、メッセージタイプコード（つまり、ルーティングラベルと回路IDコードを省略）でカプセル化されています。
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.
「バージョン」パラメーターの使用により、ネットワーク管理者は、両側ベースで交換されるISUPの特定のバージョンを特定できます。これにより、SoftSwitch/Media Gatewayコントローラーなどの特定のクライアントがメッセージを正しく認識して解析するか、（場合によっては）指定されたISUPバージョンがサポートされていない場合にメッセージを拒否することができます。この仕様は、「バージョン」で使用できる値に制約を導入しません。これらは、ネットワーク管理者の裁量に任されています。
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.
この「バージョン」は、たとえばX-netxProprietaryIsupv3のネットワーク固有の実装を特定するために、またはISUPのよく知られている標準バージョン、例えば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.
「ベース」パラメーターをオプションで含めることができます（たとえば、レシーバーが「バージョン」文字列を認識できない場合）。カプセル化されたISUPを識別された「ベース」仕様を使用して処理できることを指定できます。表1は、ITU-T 1992 ISUPで定義されている順方向互換メカニズムがサポートされているかどうかなど、「アプリケーション/ISUP」メディアタイプでサポートされている「ベース」値のリストを示しています。
Table 1: ISUP 'base' values
表1：ISUP「ベース」値
base protocol compatibility
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.
カプセル化されたISUPがどのように処理されるか、特に受信したコンテンツタイプが認識されない場合は、取り扱いがどうなるかを説明するために、コンテンツ偏見ヘッダー[5]を含めることができます。ISUPメッセージ本文のデフォルトの処分タイプは「信号」です。このタイプは、本体の部分にセッションに関連付けられたシグナリング情報が含まれているが、セッションを説明していないことを示しています。
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]のコンテンツディスポジションヘッダーの説明と、SIP標準のコンテンツ配置ヘッダーの特性評価を補完することは、次のBNFです。ISUPとQSIG MIME BODIES。
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):
「処理」パラメーターの使用の完全な定義は、以下のIANA考慮事項セクションに記載されています。以下は、典型的なヘッダーがどのように見えるかです（「ベース」は省略される可能性があります）：
Content-Type: application/ISUP; version=nxv3; base=etsi121
Content-Disposition: signal; handling=optional
The application/QSIG media type is defined by the following information:
アプリケーション/QSIGメディアタイプは、次の情報で定義されています。
Media type name: application Media subtype name: QSIG Required parameters: none Optional parameters: version Encoding scheme: binary Security considerations: See section 5.
メディアタイプ名：アプリケーションメディアサブタイプ名：QSIG必須パラメーター：なしオプションパラメーター：バージョンエンコーディングスキーム：バイナリセキュリティの考慮事項：セクション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.
「バージョン」パラメーターを使用すると、さまざまなQSIGバリエーションを識別できます。これにより、終了接続サーバーはメッセージを正しく認識して解析することができ、特定のQSIGバリアントがサポートされていない場合にメッセージを拒否することができます。
Table 2 is a list of protocol versions supported by the 'application/QSIG' media type.
表2は、「アプリケーション/QSIG」メディアタイプでサポートされているプロトコルバージョンのリストです。
Table 2: QSIG versions
表2：QSIGバージョン
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-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.
デフォルトのコンテンツ拡張処分型は、ISUPボディの部分のように「信号」です。上記の「処理」パラメーターは、QSIGボディにも使用できます。
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.
SIPメッセージ形式では、リクエストラインに続いてヘッダーラインが続いてCRLFセパレーターが続いてメッセージ本文が続きます。「Application/ISUP」メディアタイプの使用を説明するために、以下は、発生するSDP情報とカプセル化されたISUP IAMを備えた招待メッセージです。
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
2つのペイロードは、境界パラメーター（RFC 2046 [4]で指定されている）によって区切られていることに注意してください。この例では、この例では「一意の結合-1」値があります。これはMIMEマルチパートの仕様の一部であり、
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--
V = 0 O = JPeterson 2890844526 2890842807 IN IP4 126.16.64.4 S = SDPセミナーC = IP4 MG122.LEVEL3.COM T = 2873397496 2873404696 M = Audio：application/isup;バージョン= nxv3;base = eTSI121コンテンツ - 分散：信号;処理=オプション01 00 49 00 00 03 02 00 07 04 10 10 00 33 63 21 43 00 00 03 06 03 80 90 A2 07 03 10 03 63 53 00 101e 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.
注：バイナリエンコーディングはISUPペイロードに使用されるため、各バイトはバイトとしてエンコードされ、2文字の六角表現としてではありません。これらのバイトの文字通りのエンコードは混乱して読めないため、ドキュメントで16進数字が使用されました。
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」メディアタイプの使用を説明するために、以下は、発生するSDP情報とカプセル化された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.
2つのペイロードは、境界パラメーター（RFC 2046 [4]で指定されている）によって区切られていることに注意してください。この例では、この例では「一意の境界1」値があります。これは、MIMEマルチパートの仕様の一部であり、「アプリケーション/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
V = 0 O = Audet 2890844526 2890842807 5 IN IP4 134.177.64.4 S = SDPセミナーc = IP4 MG141.NORTELNETWORKS.COM T = 2873397496 2873404696 M = Audio 9092 RTP/AVP 0 3 4 3 3
--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--
08 02 55 55 05 04 02 90 90 18 03 A1 83 01 70
Information contained in ISUP and QSIG bodies may include sensitive customer information, potentially requiring use of encryption.
ISUPおよびQSIGボディに含まれる情報には、暗号化の使用が必要になる可能性がある、機密性の高い顧客情報が含まれる場合があります。
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.
セキュリティメカニズムはRFC 2543（SIP-セッション開始プロトコル）で提供されており、SIPメッセージとカプセル化されたISUPまたはQSIGボディの両方に適切に使用する必要があります。
This document registers the "application/ISUP" and "application/QSIG" MIME media types.
このドキュメントは、「アプリケーション/ISUP」および「アプリケーション/QSIG」MIMEメディアタイプを登録します。
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タイプ内で使用される「バージョン」記号の登録は、新しいシンボルが参照する仕様の特定の問題を特定して、決定的な仕様リファレンスを指定する必要があります。明確な仕様参照を特定するには、レビュープロセスが必要です。著者は、RFC 2434 [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-」から始まるシンボルは、非標準の使用法のために予約されています（たとえば、ISUP仕様の問題を表す文字列以外のトークンが、管理ドメイン内のISUPを特徴付けるのに適しています）。このような標準以外のバージョンは、二国間協定に従って行政ドメイン間でのみ送信できます。これらの記号は、RFC 2434で説明されている私的使用ポリシーの下で管理する必要があります。
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).
このドキュメントは、MIMEボディに補足シグナル伝達情報を含む場合に使用されるコンテンツディスポジションヘッダー「信号」の新しい処分型を登録します（MIMEボディとしてのISUPとQSIGがこれの例です）。
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.
このドキュメントは、コンテンツ処分パラメーター「ハンドリング」も定義します。ハンドリングパラメーターであるハンドリングパーマムは、コンテンツの種類または気質タイプがわからないメッセージ本文を受信した場合、UASがどのように反応するかを説明します。パラメーターに値「オプション」がある場合、UASはメッセージ本文を無視する必要があります。「必要」値がある場合、UASは415（サポートされていないメディアタイプ）を返す必要があります。処理パラメーターが欠落している場合、値「必要」を想定します。
Eric Zimmerer Rankom Inc. 19500 Pruneridge Ave Suite #4303 Cupertino, CA 95014, USA EMail: eric_zimmerer@yahoo.com
Eric Zimmerer Rankom Inc. 19500 Pruneridge Ave Suite＃4303 Cupertino、CA 95014、USAメール：Eric_Zimmerer@yahoo.com
Aparna Vemuri Qwest Communications 6000 Parkwood Pl Dublin, OH 43016, USA EMail: Aparna.Vemuri@Qwest.com
Aparna Vemuri QWest Communications 6000 Parkwood PL Dublin、OH 43016、USAメール：aparna.vemuri@qwest.com
Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520, USA EMail: jon.peterson@neustar.com
Jon Peterson Neustar、Inc 1800 Sutter Street、Suite 570 Concord、CA 94520、USAメール：jon.peterson@neustar.com
Lyndon Ong Ciena Cupertino, CA, USA EMail: lyndon_ong@yahoo.com
Lyndon Ong Ciena Cupertino、CA、USAメールメール：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
Francois Audet Nortel Networks 4301 Great America Parkway Santa Clara、CA 95054、USAメール：mzonoun@nortelnetworks.com Mo Zonoun Nortel Networks 4301 Great America Parkway Santa Clara、CA 95054、USAメール：audet@nortelnetworks.com
M. Watson Nortel Networks Maidenhead, UK EMail: mwatson@nortelnetworks.com
M. Watson Nortel Networks Maidenhead、UKメール：mwatson@nortelnetworks.com
[1] Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[1] Freed、N.、Klensin、J。and J. Postel、「マルチパートインターネットメールエクステンション（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "Session Initiation Protocol (SIP)", RFC 2543, March 1999.
[2] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「セッション開始プロトコル（SIP）」、RFC 2543、1999年3月。
[3] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[3] Freed、N。およびN. Borenstein、「マルチパートインターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[4] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed、N。およびN. Borenstein、「マルチパートインターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[5] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[5] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。