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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書は、これらのタイプは、INVITEまたはINFOなどのSIPメッセージ内ISUPとQSIGオブジェクトを識別するために使用することができるRFC 2048で定義された規則に従って、SIPアプリケーションで使用するためのアプリケーション/ ISUPとアプリケーション/ QSIGオブジェクトのMIMEタイプを記述する呼び出しの一部は、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ユーザ部）Q.761-4テレフォニースイッチの間で使用されるシグナリングプロトコルであるITU-T勧告で定義されました。 ISUP符号化されたシグナリング情報は、ISUPデータの保存は、PSTN機能の適切な動作に必要なSIPメッセージのペイロードの一部としてSIPエンティティ間で転送する必要のある構成が存在します。
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セッションのコンテキスト内ではなく、SCNシグナリングの汎用トランスポートとして使用されるISUPまたはQSIGアプリケーション情報のために意図されています。
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メッセージしないことに留意すべきです。後者のみが符号化されたメッセージにバルクを追加もたらし、おそらく処理能力の点でより高価になるので、バイナリは、Base64エンコードよりも好まれています。
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の特定のバージョンを識別することを可能にします。これは、指定された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.
この「バージョン」は、例えば、ISUPのネットワーク固有の実装、例えば、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 1992 ISUPがサポートされているか否かがITU-Tで定義された上位互換性機構を備えた「アプリケーション/ 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
ITU-T88 ITU-T Q.761-4（1988）なしのITU-T92 + ITU-T Q.761-4（1992）はいansi88 ANSI T1.113-1988ないansi00 ANSI T1.113-2000はいetsi121 ETS 300 121無etsi356 ES 300 356イエスのgr317 BELLCORE GR-317無ttc87 JT-Q761-4（1987年から1992年）なしttc93 + JT-Q761-4（1993-）はい
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-Dispositionヘッダー[5]は、カプセル化ISUPが処理される方法を説明するために含まれてもよいし、受信したコンテンツタイプが認識されない場合、特に取り扱いがどうあるべきか。 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]のContent-Dispositionヘッダーの説明、ならびにSIP標準のContent-Dispositionヘッダーの任意の特徴付けを補う、配置・タイプのヘッダで使用することができる配置-paramsはを説明する以下のBNFでありますISUPとQSIG MIMEボディ。
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
コンテンツ配置は=の "Content-処分" "：" 気質タイプ*（ ";" 処分-PARAM）処分型= "信号" | "（ "その他のハンドリング" | | "" 必要なオプション）=" = "を取り扱う" DISP-拡張トークン処分-PARAM |トークン=ジェネリック-PARAM他のハンドリング=トークンDISP-拡張トークン
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
コンテンツタイプ：アプリケーション/ ISUP。バージョン= nxv3。基地= etsi121コンテンツの廃棄：信号。取り扱い=オプション
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
コンテンツタイプ：アプリケーション/ QSIG。バージョン=イソ
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-処分処分型は、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分離に続いてヘッダ行に続く要求線を必要とします。 「アプリケーション/ ISUP」メディアタイプの使用を例示するために、以下の発信SDP情報とカプセル化ISUP IAMを有するINVITEメッセージです。
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つのペイロードを例に値「一意境界-1」を有する（RFC 2046で指定された[4]）境界パラメータによって画定されていることに留意されたいです。これは、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
--unique境界-1のContent-Type：アプリケーション/ SDP;文字セット= 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
V = 0 0 = jpeterson 2890844526 2890842807 IN IP4 126.16.64.4 S = SDPセミナーC = IN IP4 MG122.level3.com T = 2873397496 2873404696メートル=オーディオ9092 RTP / AVP 0 3 4 --unique境界-1のContent-Type ：アプリケーション/ ISUP。バージョン= nxv3。基地= etsi121コンテンツの廃棄：信号。取り扱い=オプション
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--
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境界-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.
「アプリケーション/ QSIG」メディアタイプの使用を例示するために、以下の発信SDP情報とカプセル化されたQSIG SETUPメッセージを有するINVITEメッセージです。
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つのペイロードを例に値「unique-境界-1」を有する（RFC 2046で指定された[4]）境界パラメータによって画定されていることに留意されたいです。これは、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
--unique境界-1のContent-Type：アプリケーション/ SDP;文字セット= 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
IP4 134.177.64.4のSDPセミナーでは、Y = 0、Aは= 2890844526 2890842807 5あえて= C = IN IP4 MG141.nortelnetworks.com T = 2873397496 2873404696メートル=オーディオ9092 RTP / AVP 0 3 4
--unique-boundary-1 Content-type:application/QSIG; version=iso
--unique境界-1コンテンツタイプ：アプリケーション/ QSIG。バージョン=イソ
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 0A 89 31 34 30 38 34 39 35 35 30 37 32 --unique境界-1--
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.
セキュリティメカニズムは、（SIP - セッション開始プロトコル）RFC 2543で提供され、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タイプの登録は新しいシンボルが指す先の明細書の特定の問題を識別する、決定的な仕様基準を指定する必要があります。明確な仕様の参照を識別することはレビュープロセスを必要とします。著者は、[6]専門家レビューの下で、RFC 2434で説明したように主題の専門家を指定することをお勧めします。
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.
この文書はまた、コンテンツ配置パラメータ、「処理」を定義します。 -PARMを扱う処理パラメータは、それがそのコンテンツタイプや気質タイプ、それは理解していないメッセージ本文を受信した場合、UASは反応すべき方法を説明します。パラメータは「オプション」値を有する場合、UASは、メッセージ本体を無視しなければなりません。それが「必要」値を持つ場合、UASは415（サポートされていないメディアタイプ）を返さなければなりません。取り扱いパラメータが欠落している場合は、「必要」値が想定されます。
Eric Zimmerer Rankom Inc. 19500 Pruneridge Ave Suite #4303 Cupertino, CA 95014, USA EMail: eric_zimmerer@yahoo.com
エリックZimmerer Rankom株式会社19500 Pruneridgeアベニュースイート＃4303クパチーノ、CA 95014、USA Eメール：eric_zimmerer@yahoo.com
Aparna Vemuri Qwest Communications 6000 Parkwood Pl Dublin, OH 43016, USA EMail: Aparna.Vemuri@Qwest.com
Aparna Vemuriクエスト・コミュニケーションズ6000パークウッドP1のダブリン、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
ジョンピーターソンNeuStar株式会社1800サターストリート、スイート570コンコード、CA 94520、USA Eメール：jon.peterson@neustar.com
Lyndon Ong Ciena Cupertino, CA, USA EMail: lyndon_ong@yahoo.com
リンドンオングシエナクパチーノ、CA、USA電子メール：lyndon_ong@yahoo.com
Francois Audet Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: mzonoun@nortelnetworks.com
フランソワAudet Nortel Networksの4301グレートアメリカパークウェイサンタクララ、CA 95054、USA Eメール：mzonoun@nortelnetworks.com
Mo Zonoun Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: audet@nortelnetworks.com
MoのZonoun Nortel Networksの4301グレートアメリカパークウェイサンタクララ、CA 95054、USA Eメール：audet@nortelnetworks.com
M. Watson Nortel Networks Maidenhead, UK EMail: mwatson@nortelnetworks.com
M.ワトソンノーテルネットワークメイデンヘッド、イギリスのEメール：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]フリード、N.、Klensin、J.およびJ.ポステル、 "マルチパートインターネットメール拡張（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]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "セッション開始プロトコル（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]フリード、N.とN. Borenstein、 "マルチパートインターネットメール拡張（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[4] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4]解放され、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.、ドルナー、S.とK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、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.
著作権（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機能のための基金は現在、インターネット協会によって提供されます。