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
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.
版权所有（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.
本文档描述了根据RFC 2048中定义的规则在SIP应用程序中使用的application/ISUP和application/QSIG对象的MIME类型。这些类型可用于标识SIP消息（如INVITE或INFO）中的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.
ITU-T建议Q.761-4中定义的ISUP（ISDN用户部分）是电话交换机之间使用的信令协议。有一些配置需要在SIP实体之间传输ISUP编码的信令信息，作为SIP消息有效负载的一部分，其中ISUP数据的保存对于PSTN功能的正确操作是必要的。
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定义。注意：由于此MIME注册，在SIP中使用Q.SIG既不被认可也不被推荐。
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中提到的规则适用于Internet邮件消息，而不适用于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提供了“应用程序/ISUP”媒体类型支持的“基本”值列表，包括是否支持ITU-T 1992 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.
可以包括内容处置报头[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.
以下BNF描述了ISUP和QSIG MIME主体的头中可能使用的处置类型和处置参数，补充了[5]中内容处置头的描述以及SIP标准中内容处置头的任何特征。
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-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注意事项部分给出了“处理”参数使用的完整定义。以下是典型标题的外观（“base”可以省略）：
Content-Type: application/ISUP; version=nxv3; base=etsi121
Content-Disposition: signal; handling=optional
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)
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
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分隔符，再后跟消息正文。为了说明“应用程序/ISUP”媒体类型的使用，下面是一条INVITE消息，其中包含原始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
请注意，两个有效载荷由边界参数（在RFC 2046[4]中规定）标定，该参数在示例中的值为“unique-boundary-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
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-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
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--
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21 43 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 1e 06 26 05 0d f5 01 06 10 04 00--唯一-边界-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有效负载，因此每个字节都被编码为一个字节，而不是两个字符的十六进制表示。文档中使用了十六进制数字，因为这些字节的文字编码可能会造成混乱和不可读。
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”媒体类型的使用，下面是一条INVITE消息，其中包含原始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.
请注意，两个有效载荷由边界参数（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
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-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=IP4中的audet 2890844526 2890842807 5 134.177.64.4 s=SDP研讨会c=IP4中的MG141.nortelnetworks.com t=2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-type:application/QSIG; version=iso
--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 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 30 37 32-唯一边界-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.
RFC2543（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).
本文档为内容处置头“signal”注册了一个新的处置类型，当MIME正文包含补充信令信息时使用（例如，ISUP和QSIG作为MIME正文）。
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描述了当UAS接收到其不理解其内容类型或处置类型的消息正文时，UAS应如何作出反应。如果参数值为“可选”，则UAS必须忽略消息体；如果其值为“required”，则UAS必须返回415（不支持的媒体类型）。如果缺少处理参数，则假定值为“必需”。
Eric Zimmerer Rankom Inc. 19500 Pruneridge Ave Suite #4303 Cupertino, CA 95014, USA EMail: eric_zimmerer@yahoo.com
Eric Zimmerer Rankom Inc.美国加利福尼亚州库珀蒂诺市普吕尼里奇大道套房（4303号，邮编95014）19500电子邮件：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都柏林，俄亥俄州43016，美国电子邮件：Aparna。Vemuri@Qwest.com
Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520, USA EMail: jon.peterson@neustar.com
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar公司，邮编：94520电子邮件：Jon。peterson@neustar.com
Lyndon Ong Ciena Cupertino, CA, USA EMail: lyndon_ong@yahoo.com
Lyndon Ong Ciena Cupertino，加利福尼亚州，美国电子邮件：Lyndon_ong@yahoo.com
Francois Audet Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: mzonoun@nortelnetworks.com
Francois Audet Nortel Networks 4301大美洲大道圣克拉拉，加利福尼亚州95054，美国电子邮件：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大美洲大道圣克拉拉，加利福尼亚州95054，美国电子邮件：audet@nortelnetworks.com
M. Watson Nortel Networks Maidenhead, UK EMail: mwatson@nortelnetworks.com
M.Watson Nortel Networks Maidenhead，英国电子邮件：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.和J.Postel，“多部分Internet邮件扩展（MIME）第四部分：注册程序”，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.和J.Rosenberg，“会话启动协议（SIP）”，RFC 25431999年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，“多部分Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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，“多部分Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年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.
版权所有（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编辑功能的资金目前由互联网协会提供。