下载文档原格式
rfc异常处理流程RFC 异常处理流程引言在网络通信中，RFC（Request for Comments）扮演着重要的角色，它是一系列由互联网工程任务组（IETF）发布的文件，用于制定互联网标准和协议。
然而，在实际应用中，由于各种原因，可能会出现异常情况，需要进行相应的处理。
本文将针对RFC异常处理流程进行详细的介绍和分析。
一、异常情况的分类我们需要对RFC异常情况进行分类。
根据RFC文件的不同用途和内容，可以将异常情况划分为以下几类：1. 语法错误：当一个RFC文件的语法格式违反了规定，无法被正确解析时，就会发生语法错误。
这可能是由于拼写错误、缺少必要的标点符号、格式错误等原因引起的。
2. 逻辑错误：逻辑错误是指RFC文件中的描述与实际需求或规范不一致的情况。
这可能导致协议无法正常工作或产生不符合预期的结果。
3. 安全漏洞：由于互联网环境的复杂性和恶意攻击的存在，RFC文件中可能存在与安全相关的漏洞。
这些漏洞可能会被黑客利用，造成严重的安全威胁。
4. 性能问题：RFC文件中的某些规定可能会导致性能下降或资源浪费，这种情况可能需要进行调整或优化。
5. 兼容性问题：当一个RFC文件与已有的标准或协议不兼容时，就会出现兼容性问题。
这可能导致不同系统之间的通信故障或数据丢失。
二、异常处理流程针对不同的异常情况，我们需要采取不同的处理措施。
下面是一个基本的RFC异常处理流程：1. 异常检测：在应用RFC文件之前，我们需要对其进行严格的检测，以确保其符合语法规范和逻辑要求。
可以使用一些自动化的工具或脚本来进行检测，以提高效率和准确性。
2. 异常定位：一旦发现异常情况，我们需要对其进行定位，找出具体的错误或问题所在。
这可能需要仔细分析RFC文件的内容和相关的标准规范，以确定异常的原因和影响范围。
3. 异常修复：根据异常的类型和具体情况，我们需要制定相应的修复方案。
对于语法错误，可以通过修正拼写错误、添加或删除标点符号等方式进行修复；对于逻辑错误，可能需要修改相关的描述或规定，以保证与实际需求或规范的一致性。
GMP大数库静态编译什么是GMP大数库？GMP（GNU Multiple Precision Arithmetic Library）是一个用于进行精确的大数运算的开源库。
它可以处理比标准整数类型更大的整数，以及高精度的浮点数运算。
GMP库提供了一系列的函数和工具，使得开发者可以方便地进行大数计算，而无需担心溢出或精度问题。
为什么要进行静态编译？静态编译是将所有需要的库文件链接到可执行文件中，使得可执行文件在运行时不再依赖外部的动态链接库。
相比于动态链接库，静态编译的可执行文件更加独立，不容易受到环境变量等因素的影响，更加方便部署和传播。
对于使用GMP库的项目而言，静态编译可以确保在不同环境中都能够正常运行，而无需担心GMP库的版本和依赖问题。
同时，静态编译也可以提高程序的运行效率，减少动态链接库的加载和解析时间。
GMP大数库静态编译的步骤1. 下载GMP库源代码首先，我们需要从GMP官方网站（）下载GMP库的源代码。
选择适合你系统的版本，并下载压缩包。
2. 解压源代码将下载的压缩包解压到合适的目录中，例如我们将其解压到/home/user/gmp目录下。
3. 进入源代码目录使用终端进入解压后的源代码目录，例如cd /home/user/gmp。
4. 配置编译选项执行以下命令，配置编译选项：./configure --disable-shared --enable-static--disable-shared选项表示禁止生成动态链接库，--enable-static选项表示允许生成静态链接库。
5. 编译源代码执行以下命令，开始编译源代码：make这个过程可能会比较耗时，取决于你的系统性能和源代码的大小。
6. 安装GMP库执行以下命令，将编译好的GMP库安装到系统中：sudo make install这个命令需要管理员权限，因为它会将GMP库的文件复制到系统的默认库路径中。
7. 使用静态链接库在你的项目中，你可以使用静态链接库进行大数计算。
Network Working Group T. Showalter Request for Comments: 2971 Mirapoint, Inc. Category: Standards Track October 2000 IMAP4 ID extensionStatus of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved. AbstractThe ID extension to the Internet Message Access Protocol - Version4rev1 (IMAP4rev1) protocol allows the server and client to exchangeidentification information on their implementation in order to makebug reports and usage statistics more complete.1. IntroductionThe IMAP4rev1 protocol described in [IMAP4rev1] provides a method for accessing remote mail stores, but it provides no facility toadvertise what program a client or server uses to provide service.This makes it difficult for implementors to get complete bug reportsfrom users, as it is frequently difficult to know what client orserver is in use.Additionally, some sites may wish to assemble usage statistics basedon what clients are used, but in an an environment where users arepermitted to obtain and maintain their own clients this is difficultto accomplish.The ID command provides a facility to advertise information on whatprograms are being used along with contact information (should bugsever occur).Showalter Standards Track [Page 1]2. Conventions Used in this DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].The conventions used in this document are the same as specified in[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by theclient and server respectively. Line breaks have been inserted forreadability.3. SpecificationThe sole purpose of the ID extension is to enable clients and servers to exchange information on their implementations for the purposes of statistical analysis and problem determination.This information is be submitted to a server by any client wishing to provide information for statistical purposes, provided the serveradvertises its willingness to take the information with the atom "ID" included in the list of capabilities returned by the CAPABILITYcommand.Implementations MUST NOT make operational changes based on the datasent as part of the ID command or response. The ID command is forhuman consumption only, and is not to be used in improving theperformance of clients or servers.This includes, but is not limited to, the following:Servers MUST NOT attempt to work around client bugs by usinginformation from the ID command. Clients MUST NOT attempt to work around server bugs based on the ID response.Servers MUST NOT provide features to a client or otherwiseoptimize for a particular client by using information from the ID command. Clients MUST NOT provide features to a server orotherwise optimize for a particular server based on the IDresponse.Servers MUST NOT deny access to or refuse service for a clientbased on information from the ID command. Clients MUST NOT refuse to operate or limit their operation with a server based on the ID response.Showalter Standards Track [Page 2]Rationale: It is imperative that this extension not supplant IMAP’sCAPABILITY mechanism with a ad-hoc approach where implementationsguess each other’s features based on who they claim to be.Implementations MUST NOT send false information in an ID command.Implementations MAY send less information than they have available or no information at all. Such behavior may be useful to preserve user privacy. See Security Considerations, section 7.3.1. ID CommandArguments: client parameter list or NILResponses: OPTIONAL untagged response: IDResult: OK identification information acceptedBAD command unknown or arguments invalidImplementation identification information is sent by the client with the ID command.This command is valid in any state.The information sent is in the form of a list of field/value pairs.Fields are permitted to be any IMAP4 string, and values are permitted to be any IMAP4 string or NIL. A value of NIL indicates that theclient can not or will not specify this information. The client may also send NIL instead of the list, indicating that it wants to sendno information, but would still accept a server response.The available fields are defined in section 3.3.Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor""Pink Floyd Music Limited")S: * ID NILS: a023 OK ID completed3.2. ID ResponseContents: server parameter listIn response to an ID command issued by the client, the server replies with a tagged response containing information on its implementation. The format is the same as the client list.Showalter Standards Track [Page 3]Example: C: a042 ID NILS: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos""os-version" "5.5" "support-url""mailto:cyrus-bugs+@")S: a042 OK ID command completedA server MUST send a tagged ID response to an ID command. However, a server MAY send NIL in place of the list.3.3. Defined Field ValuesAny string may be sent as a field, but the following are defined todescribe certain values that might be sent. Implementations are free to send none, any, or all of these. Strings are not case-sensitive. Field strings MUST NOT be longer than 30 octets. Value strings MUST NOT be longer than 1024 octets. Implementations MUST NOT send morethan 30 field-value pairs.name Name of the programversion Version number of the programos Name of the operating systemos-version Version of the operating systemvendor Vendor of the client/serversupport-url URL to contact for supportaddress Postal address of contact/vendordate Date program was released, specified as a date-time in IMAP4rev1command Command used to start the programarguments Arguments supplied on the command line, if anyif anyenvironment Description of environment, i.e., UNIX environment variables or Windows registry settingsImplementations MUST NOT use contact information to submit automatic bug reports. Implementations may include information from an IDresponse in a report automatically prepared, but are prohibited from sending the report without user authorization.It is preferable to find the name and version of the underlyingoperating system at runtime in cases where this is possible.Information sent via an ID response may violate user privacy. SeeSecurity Considerations, section 7.Implementations MUST NOT send the same field name more than once. Showalter Standards Track [Page 4]4. Formal SyntaxThis syntax is intended to augment the grammar specified in[IMAP4rev1] in order to provide for the ID command. Thisspecification uses the augmented Backus-Naur Form (BNF) notation asused in [IMAP4rev1].command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id;; adds id command to command_any in [IMAP4rev1]id ::= "ID" SPACE id_params_listid_response ::= "ID" SPACE id_params_listid_params_list ::= "(" #(string SPACE nstring) ")" / nil;; list of field value pairsresponse_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /mailbox_data / message_data / capability_data / id_response)5. Use of the ID extension with Firewalls and Other IntermediariesThere exist proxies, firewalls, and other intermediary systems thatcan intercept an IMAP session and make changes to the data exchanged in the session. Such intermediaries are not anticipated by the IMAP4 protocol design and are not within the scope of the IMAP4 standard.However, in order for the ID command to be useful in the presence of such intermediaries, those intermediaries need to take special noteof the ID command and response. In particular, if an intermediarychanges any part of the IMAP session it must also change the IDcommand to advertise its presence.A firewall MAY act to block transmission of specific informationfields in the ID command and response that it believes revealinformation that could expose a security vulnerability. However, afirewall SHOULD NOT disable the extension, when present, entirely,and SHOULD NOT unconditionally remove either the client or serverlist.Finally, it should be noted that a firewall, when handling aCAPABILITY response, MUST NOT allow the names of extensions to bereturned to the client that the firewall has no knowledge of. Showalter Standards Track [Page 5]6. References[KEYWORDS] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", RFC 2119, March 1997.[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, October 1996.[RFC-822] Crocker, D., "Standard for the Format of ARPA InternetText Messages", STD 11, RFC 822, August 1982.7. Security ConsiderationsThis extension has the danger of violating the privacy of users ifmisused. Clients and servers should notify users that they implement and enable the ID command.It is highly desirable that implementations provide a method ofdisabling ID support, perhaps by not sending ID at all, or by sending NIL as the argument to the ID command or response.Implementors must exercise extreme care in adding fields sent as part of an ID command or response. Some fields, including a processor ID number, Ethernet address, or other unique (or mostly unique)identifier allow tracking of users in ways that violate user privacy expectations.Having implementation information of a given client or server maymake it easier for an attacker to gain unauthorized access due tosecurity holes.Since this command includes arbitrary data and does not require theuser to authenticate, server implementations are cautioned to guardagainst an attacker sending arbitrary garbage data in order to fillup the ID log. In particular, if a server naively logs each IDcommand to disk without inspecting it, an attacker can simply fire up thousands of connections and send a few kilobytes of random data.Servers have to guard against this. Methods include truncatingabnormally large responses; collating responses by storing only asingle copy, then keeping a counter of the number of times thatresponse has been seen; keeping only particularly interesting partsof responses; and only logging responses of users who actually login.Security is affected by firewalls which modify the IMAP protocolstream; see section 5, Use of the ID Extension with Firewalls andOther Intermediaries, for more information.Showalter Standards Track [Page 6]8. Author’s AddressTim ShowalterMirapoint, Inc.909 Hermosa Ct.Sunnyvale, CA 94095EMail: tjs@Showalter Standards Track [Page 7]9. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Showalter Standards Track [Page 8]。
RFC821 简单邮件传输协议（SMTP）(RFC821 SIMPLE MAIL TRANSFER PROTOCOL)目录1. 介绍 22. SMTP模型 33. SMTP过程 43.1. MAIL 43.2. 转发 53.3. 确认和扩展 63.4. 发送信件(mailing)和获得信件(sending) 7 3.5. 打开和关闭73.6. 转发 83.7. 域93.8. 改变角色94. SMTP说明94.1. SMTP命令94.1.1. 命令语法94.1.2. COMMAND语法格式134.2. SMTP响应154.3. 命令和应答序列164.4. 状态图174.5. 详细内容184.5.1. 最小实现184.5.2. 透明性194.5.3. 大小19附录 A TCP传输服务19附录 B NCP传输服务20附录 C NITS 20附录 D X.25传输服务 20附录 E 应答码构成方法20附录 F 一些例子22参考资料361. 介绍简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。
附录A，B，C和D描述了不同传送服务下SMTP的使用。
在名词表中还定义了本文档中使用的术语。
SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。
理解到传送系统（或IPCE）不是一对一的是很重要的。
进程可能直接和其它进程通过已知的IPCE通信。
邮件是一个应用程序或进程间通信。
邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。
更特别的是，邮件可以通过不同网络上的主机接力式传送。
2. SMTP模型SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。
接收SMTP可以是最终接收者也可以是中间传送者。
SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。
ietfrfc4571 格式
RFC 4571是一项Internet标准，用于定义以 Session Description Protocol(SDP) 描述会话初始化协议(SIP)会话的语法和语义。
该RFC的目的是为了确保SIP会话的顺利初始化，考虑到SDP的作用和功能。
SDP被用于在会话发起阶段传递会话和媒体信息。
在RFC 4571中，SDP的语法和规则进行了详细说明，确保了会话描述的一致性和可靠性。
RFC 4571中还包括了对SDP格式的定义和使用的示例。
这些示例涵盖了会话描述的各个方面，如会话起始、媒体流的描述、会话属性等。
此外，RFC 4571还介绍了与SDP相关的其他标准和规范，以便读者可以更好地了解和使用SDP。
值得注意的是，RFC 4571旨在提供技术指导和建议，以促进SIP 会话的交互。
它并非标准要求，而是为实施者和开发者提供一个统一的规范和参考。
因此，对于SIP会话实现者和开发者来说，理解和遵循RFC 4571对于确保会话的顺利进行非常重要。
通过遵循RFC 4571的规定，SIP会话的交互能够更加稳定和一致，提供更好的用户体验和服务质量。
在开发和实施SIP会话时，我们应该参考这一规范，并根据具体需求进行必要的自定义和扩展。
HF Cobalt CNT 使用手册电源需求：电源：电源供应： 10～30VDC功率 9.6W（400mA@24V）安装环境：操作温度－20℃～50℃存储温度－40℃～85℃湿度： 100％保护等级： IP66抗冲击等级：经过IEC68-2-27测试，EA 30克，11ms，每相3次冲击抗震等级：经过IEC68-2-6测试，FC 1.5mm，10－55Hz，每相2小时安装要点：1.本品为电磁发送接收设备，大面积金属对其正常工作影响比较大，因此必须保证天线的15厘米范围内无大面积金属物品2.本产品连接电缆应远离裸露电缆和高压电缆。
交叉电缆必须垂直通过，控制器和电缆远离电动机和变频器3.避免靠近EMI设备和高ESD发生设备4.如本产品处于一个受影响的电磁场范围内，通常表现为读写距离下降。
请移动本设备到另一个影响小的地方5.现场测试本产品时尽量保证连接最少的设备。
6.本产品设计为可承受8KV直接电压冲击和15KV的空气电压冲击，但在本产品并不适合这种经常产生冲击的输送线使用。
安装：本产品分为两个部分，一个是控制器；另一个是天线。
两个使用M5的内六角螺钉连结。
控制器下部有两个接口：左边借口为5针的标准DeviceNet接口右边为标准RS232串口DeviceNet接口针脚定义：定义1 接地GND2 电源正V+3 电源负V-4 CAN_H5 CAN_LRS232串口针脚定义定义1~5 未使用6 RX（连接计算机TX）7 TX（连接计算机RX）8 SGND（信号地）RS232连结图：配置：使用DeveceNet接口供应24V电压，读写器上电至自检完毕使用标准RS232电缆连接DNT的232口，并设置计算机的串口参数如下：设置值波特率（Baud） 9600字长（Data Bits） 8停止字符（Stop bit） 1Parity None握手（Handshaking） None使用EMS公司提供的配置软件Dashboard连接本读写器读写器模块网络状态指示灯：状态指示灯表示意义如下描述熄灭模块未在线或未上电常绿模块正常，DeviceNet网络正常绿色闪烁网络已经连接，但是需要PLC重新配置输入输出缓冲区红色闪烁可恢复性错误或网络连接超时常红不可恢复错误（通常为节点冲突）连接后界面如下本产品的默认DeveceNet配置如下=63=125K可在上图的右下角位置修改这两个选项PLC连接安装EDS文件004E00000BD60204.eds当DeviceNet模块扫描到DNT模块后，需要手动配置输入输出缓冲区。
Internet Engineering Task Force (IETF) J. Reschke Request for Comments: 5987 greenbytes Category: Standards Track August 2010 ISSN: 2070-1721Character Set and Language Encoding forHypertext Transfer Protocol (HTTP) Header Field Parameters AbstractBy default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. Thisdocument specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231.Status of This MemoThis is an Internet Standards Track document.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Further information onInternet Standards is available in Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5987.Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Reschke Standards Track [Page 1]Table of Contents1. Introduction (2)2. Notational Conventions (2)3. Comparison to RFC 2231 and Definition of the Encoding (3)3.1. Parameter Continuations (3)3.2. Parameter Value Character Set and Language Information (3)3.2.1. Definition (3)3.2.2. Examples (6)3.3. Language Specification in Encoded Words (6)4. Guidelines for Usage in HTTP Header Field Definitions (7)4.1. When to Use the Extension (7)4.2. Error Handling (7)5. Security Considerations (8)6. Acknowledgements (8)7. References (8)7.1. Normative References (8)7.2. Informative References (9)1. IntroductionBy default, message header field parameters in HTTP ([RFC2616])messages cannot carry characters outside the ISO-8859-1 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding mechanismfor use in MIME headers. This document specifies an encodingsuitable for use in HTTP header fields that is compatible with aprofile of the encoding defined in RFC 2231.Note: in the remainder of this document, RFC 2231 is onlyreferenced for the purpose of explaining the choice of featuresthat were adopted; they are therefore purely informative.Note: this encoding does not apply to message payloads transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).2. Notational ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].This specification uses the ABNF (Augmented Backus-Naur Form)notation defined in [RFC5234]. The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP(linear whitespace).Reschke Standards Track [Page 2]Note that this specification uses the term "character set" forconsistency with other IETF specifications such as RFC 2277 (see[RFC2277], Section 3). A more accurate term would be "characterencoding" (a mapping of code points to octet sequences).3. Comparison to RFC 2231 and Definition of the EncodingRFC 2231 defines several extensions to MIME. The sections belowdiscuss if and how they apply to HTTP header fields.In short:o Parameter Continuations aren’t needed (Section 3.1),o Character Set and Language Information are useful, therefore asimple subset is specified (Section 3.2), ando Language Specifications in Encoded Words aren’t needed(Section 3.3).3.1. Parameter ContinuationsSection 3 of [RFC2231] defines a mechanism that deals with the length limitations that apply to MIME headers. These limitations do notapply to HTTP ([RFC2616], Section 19.4.7).Thus, parameter continuations are not part of the encoding defined by this specification.3.2. Parameter Value Character Set and Language InformationSection 4 of [RFC2231] specifies how to embed language informationinto parameter values, and also how to encode non-ASCII characters,dealing with restrictions both in MIME and HTTP header parameters.However, RFC 2231 does not specify a mandatory-to-implement character set, making it hard for senders to decide which character set to use. Thus, recipients implementing this specification MUST support thecharacter sets "ISO-8859-1" [ISO-8859-1] and "UTF-8" [RFC3629].Furthermore, RFC 2231 allows the character set information to be left out. The encoding defined by this specification does not allow that.3.2.1. DefinitionThe syntax for parameters is defined in Section 3.6 of [RFC2616](with RFC 2616 implied LWS translated to RFC 5234 LWSP):Reschke Standards Track [Page 3]parameter = attribute LWSP "=" LWSP valueattribute = tokenvalue = token / quoted-stringquoted-string = <quoted-string, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>In order to include character set and language information, thisspecification modifies the RFC 2616 grammar to be:parameter = reg-parameter / ext-parameterreg-parameter = parmname LWSP "=" LWSP valueext-parameter = parmname "*" LWSP "=" LWSP ext-valueparmname = 1*attr-charext-value = charset "’" [ language ] "’" value-chars; like RFC 2231’s <extended-initial-value>; (see [RFC2231], Section 7)charset = "UTF-8" / "ISO-8859-1" / mime-charsetmime-charset = 1*mime-charsetcmime-charsetc = ALPHA / DIGIT/ "!" / "#" / "$" / "%" / "&"/ "+" / "-" / "^" / "_" / "‘"/ "{" / "}" / "˜"; as <mime-charset> in Section 2.3 of [RFC2978]; except that the single quote is not included; SHOULD be registered in the IANA charset registrylanguage = <Language-Tag, defined in [RFC5646], Section 2.1>value-chars = *( pct-encoded / attr-char )pct-encoded = "%" HEXDIG HEXDIG; see [RFC3986], Section 2.1attr-char = ALPHA / DIGIT/ "!" / "#" / "$" / "&" / "+" / "-" / "."/ "^" / "_" / "‘" / "|" / "˜"; token except ( "*" / "’" / "%" )Reschke Standards Track [Page 4]Thus, a parameter is either a regular parameter (reg-parameter), aspreviously defined in Section 3.6 of [RFC2616], or an extendedparameter (ext-parameter).Extended parameters are those where the left-hand side of theassignment ends with an asterisk character.The value part of an extended parameter (ext-value) is a token thatconsists of three parts: the REQUIRED character set name (charset),the OPTIONAL language information (language), and a charactersequence representing the actual value (value-chars), separated bysingle quote characters. Note that both character set names andlanguage tags are restricted to the US-ASCII character set, and arematched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section 2.1.1).Inside the value part, characters not contained in attr-char areencoded into an octet sequence using the specified character set.That octet sequence is then percent-encoded as specified in Section2.1 of [RFC3986].Producers MUST use either the "UTF-8" ([RFC3629]) or the "ISO-8859-1" ([ISO-8859-1]) character set. Extension character sets (mime-charset) are reserved for future use.Note: recipients should be prepared to handle encoding errors,such as malformed or incomplete percent escape sequences, or non- decodable octet sequences, in a robust manner. This specification does not mandate any specific behavior, for instance, thefollowing strategies are all acceptable:* ignoring the parameter,* stripping a non-decodable octet sequence,* substituting a non-decodable octet sequence by a replacementcharacter, such as the Unicode character U+FFFD (ReplacementCharacter).Note: the RFC 2616 token production ([RFC2616], Section 2.2)differs from the production used in RFC 2231 (imported fromSection 5.1 of [RFC2045]) in that curly braces ("{" and "}") areexcluded. Thus, these two characters are excluded from the attr- char production as well.Reschke Standards Track [Page 5]Note: the <mime-charset> ABNF defined here differs from the one in Section 2.3 of [RFC2978] in that it does not allow the singlequote character (see also RFC Errata ID 1912 [Err1912]). Inpractice, no character set names using that character have beenregistered at the time of this writing.3.2.2. ExamplesNon-extended notation, using "token":foo: bar; title=EconomyNon-extended notation, using "quoted-string":foo: bar; title="US-$ rates"Extended notation, using the Unicode character U+00A3 (POUND SIGN):foo: bar; title*=iso-8859-1’en’%A3%20ratesNote: the Unicode pound sign character U+00A3 was encoded into thesingle octet A3 using the ISO-8859-1 character encoding, thenpercent-encoded. Also, note that the space character was encoded as %20, as it is not contained in attr-char.Extended notation, using the Unicode characters U+00A3 (POUND SIGN)and U+20AC (EURO SIGN):foo: bar; title*=UTF-8’’%c2%a3%20and%20%e2%82%ac%20ratesNote: the Unicode pound sign character U+00A3 was encoded into theoctet sequence C2 A3 using the UTF-8 character encoding, thenpercent-encoded. Likewise, the Unicode euro sign character U+20ACwas encoded into the octet sequence E2 82 AC, then percent-encoded.Also note that HEXDIG allows both lowercase and uppercase characters, so recipients must understand both, and that the language information is optional, while the character set is not.3.3. Language Specification in Encoded WordsSection 5 of [RFC2231] extends the encoding defined in [RFC2047] toalso support language specification in encoded words. Although theHTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section2.2), it’s not clear to which header field exactly it applies, andwhether it is implemented in practice (see</wg/httpbis/trac/ticket/111> for details).Thus, this specification does not include this feature.Reschke Standards Track [Page 6]4. Guidelines for Usage in HTTP Header Field DefinitionsSpecifications of HTTP header fields that use the extensions defined in Section 3.2 ought to clearly state that. A simple way to achieve this is to normatively reference this specification, and to includethe ext-value production into the ABNF for that header field.For instance:foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-paramtitle-param = "title" LWSP "=" LWSP value/ "title*" LWSP "=" LWSP ext-valueext-value = <see RFC 5987, Section 3.2>Note: The Parameter Value Continuation feature defined in Section 3 of [RFC2231] makes it impossible to have multiple instances ofextended parameters with identical parmname components, as theprocessing of continuations would become ambiguous. Thus,specifications using this extension are advised to disallow thiscase for compatibility with RFC 2231.4.1. When to Use the ExtensionSection 4.2 of [RFC2277] requires that protocol elements containinghuman-readable text are able to carry language information. Thus,the ext-value production ought to be always used when the parametervalue is of textual nature and its language is known.Furthermore, the extension ought to also be used whenever theparameter value needs to carry characters not present in the US-ASCII ([USASCII]) character set (note that it would be unacceptable todefine a new parameter that would be restricted to a subset of theUnicode character set).4.2. Error HandlingHeader field specifications need to define whether multiple instances of parameters with identical parmname components are allowed, and how they should be processed. This specification suggests that aparameter using the extended syntax takes precedence. This wouldallow producers to use both formats without breaking recipients that do not understand the extended syntax yet.Example:foo: bar; title="EURO exchange rates";title*=utf-8’’%e2%82%ac%20exchange%20ratesReschke Standards Track [Page 7]In this case, the sender provides an ASCII version of the title forlegacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviouslyought to prefer the new syntax over the old one.Note: at the time of this writing, many implementations failed to ignore the form they do not understand, or prioritize the ASCIIform although the extended syntax was present.5. Security ConsiderationsThe format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing"scenarios, in which a displayed value appears to be something otherthan it is.Furthermore, there are known attack scenarios relating to decodingUTF-8.See Section 10 of [RFC3629] for more information on both topics.In addition, the extension specified in this document makes itpossible to transport multiple language variants for a singleparameter, and such use might allow spoofing attacks, where different language versions of the same parameter are not equivalent. Whether this attack is useful as an attack depends on the parameterspecified.6. AcknowledgementsThanks to Martin Duerst and Frank Ellermann for help figuring outABNF details, to Graham Klyne and Alexey Melnikov for general review, to Chris Newman for pointing out an RFC 2231 incompatibility, and to Benjamin Carlyle and Roar Lauritzsen for implementer’s feedback.7. References7.1. Normative References[ISO-8859-1] International Organization for Standardization,"Information technology -- 8-bit single-byte codedgraphic character sets -- Part 1: Latin alphabet No.1", ISO/IEC 8859-1:1998, 1998.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997. Reschke Standards Track [Page 8][RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.[RFC2978] Freed, N. and J. Postel, "IANA Charset RegistrationProcedures", BCP 19, RFC 2978, October 2000.[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", RFC 3629, STD 63, November 2003.[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,"Uniform Resource Identifier (URI): Generic Syntax",RFC 3986, STD 66, January 2005.[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF forSyntax Specifications: ABNF", STD 68, RFC 5234,January 2008.[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags forIdentifying Languages", BCP 47, RFC 5646,September 2009.[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for InformationInterchange", ANSI X3.4, 1986.7.2. Informative References[Err1912] RFC Errata, Errata ID 1912, RFC 2978,<>.[RFC2045] Freed, N. and N. Borenstein, "Multipurpose InternetMail Extensions (MIME) Part One: Format of InternetMessage Bodies", RFC 2045, November 1996.[RFC2047] Moore, K., "MIME (Multipurpose Internet MailExtensions) Part Three: Message Header Extensions forNon-ASCII Text", RFC 2047, November 1996.[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value andEncoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.[RFC2277] Alvestrand, H., "IETF Policy on Character Sets andLanguages", BCP 18, RFC 2277, January 1998.[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.Reschke Standards Track [Page 9]Author’s AddressJulian F. Reschkegreenbytes GmbHHafenweg 16Muenster, NW 48155GermanyEMail: julian.reschke@greenbytes.deURI: http://greenbytes.de/tech/webdav/Reschke Standards Track [Page 10]。
rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。
RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。
在本文中，我们将介绍RFC相关的设置和使用。
1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。
RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。
RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。
2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。
这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。
通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。
阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。
3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。
它们提供了协议规范、算法实现、安全性和隐私等方面的建议。
网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。
此外，RFC文档还常用于进行互联网协议的实现、编程和配置。
4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。
任何人都可以参与到RFC的制定过程中。
要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。
通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。
5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。
这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。
遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。
总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。
开源项目rfc流程开源项目RFC流程1. 什么是RFC？•RFC是”Request for Comments”的缩写，意为”征求意见”或”意见征集”。
•在开源项目中，RFC是一种协作流程，用于提出新的功能或更改现有功能的建议，并征求项目群体的意见。
2. RFC的目的与重要性•RFC流程为开源项目提供了一个包容性的环境，让所有人都有机会参与决策过程。
•通过RFC流程，项目团队可以更好地理解社区成员的需求，减少冲突和误解，并确保变更是基于共识和讨论的结果。
3. RFC流程的具体步骤•提出RFC：在项目的RFC存储库中创建一个新的RFC文件，并使用Markdown格式编写提案。
•反馈与讨论：项目群体和有兴趣的社区成员将参与讨论，提出问题、建议和其他反馈。
•修改与改进：根据收到的反馈，作者可以对RFC进行修改和改进，以更好地满足需求和解决问题。
•状态更新：在RFC的生命周期中，通过更新RFC文件的状态，作者可以向社区反馈进展情况。
•最终评审：项目核心团队将对RFC进行最终评审，并确认是否接受或拒绝提案。
•实施与跟踪：一旦RFC被接受并实施，作者需要跟踪变更的进展，并确保及时更新相关文档。
4. RFC文章的Markdown格式要求•使用Markdown格式可以更好地展示RFC的内容和结构。
•下面提供一些常用的Markdown格式要求：–标题：使用井号（#）表示不同级别的标题，以突出重点和组织结构。
–列表：使用横杠（-）或星号（*）创建无序列表，使用数字创建有序列表。
–引用：使用大于号（>）创建引用段落，用于引用他人意见或讨论。
–代码块：使用反引号（`）创建代码块，用于展示代码示例或命令。
–链接：使用方括号（[]）和圆括号（()）创建链接，以便在RFC中引用其他文件或资源。
5. 一些建议与注意事项•清晰明了地描述问题或需求，以便社区成员更好地理解和提供反馈。
•避免使用复杂的排版和格式，以保持RFC的易读性。
Network Working Group N. Freed Request for Comments: 2978 Innosoft BCP: 19 J. Postel Obsoletes: 2278 ISI Category: Best Current Practice October 2000IANA Charset Registration ProceduresStatus of this MemoThis document specifies an Internet Best Current Practices for theInternet Community, and requests discussion and suggestions forimprovements. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved. AbstractMultipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046,RFC-2047, RFC-2184) and various other Internet protocols are capable of using many different charsets. This in turn means that theability to label different charsets is essential.Note: The charset registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects.In particular, the general applicability and appropriateness of agiven registered charset to a particular application is a protocolissue, not a registration issue, and is not dealt with by thisregistration procedure.1. Definitions and NotationThe following sections define terms used in this document.1.1. Requirements NotationThis document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particularrequirements of this specification. A discussion of the meanings of these terms appears in [RFC-2119].Freed & Postel Best Current Practice [Page 1]1.2. CharacterA member of a set of elements used for the organization, control, or representation of data.1.3. CharsetThe term "charset" (referred to as a "character set" in previousversions of this document) is used here to refer to a method ofconverting a sequence of octets into a sequence of characters. This conversion may also optionally produce additional control information such as directionality indicators.Note that unconditional and unambiguous conversion in the otherdirection is not required, in that not all characters may berepresentable by a given charset and a charset may provide more than one sequence of octets to represent a particular sequence ofcharacters.This definition is intended to allow charsets to be defined in avariety of different ways, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that useISO 2022’s techniques. However, the definition associated with acharset name must fully specify the mapping to be performed. Inparticular, use of external profiling information to determine theexact mapping is not permitted.HISTORICAL NOTE: The term "character set" was originally used in MIME to describe such straightforward schemes as US-ASCII and ISO-8859-1which consist of a small set of characters and a simple one-to-onemapping from single octets to single characters. Multi-octetcharacter encoding schemes and switching techniques make thesituation much more complex. As such, the definition of this termwas revised to emphasize both the conversion aspect of the process,and the term itself has been changed to "charset" to emphasize thatit is not, after all, just a set of characters. A discussion ofthese issues as well as specification of standard terminology for use in the IETF appears in RFC 2130.1.4. Coded Character SetA Coded Character Set (CCS) is a one-to-one mapping from a set ofabstract characters to a set of integers. Examples of codedcharacter sets are ISO 10646 [ISO-10646], US-ASCII [US-ASCII], andthe ISO-8859 series [ISO-8859].Freed & Postel Best Current Practice [Page 2]1.5. Character Encoding SchemeA Character Encoding Scheme (CES) is a mapping from a Coded Character Set or several coded character sets to a set of octet sequences. Agiven CES is sometimes associated with a single CCS; for example,UTF-8 applies only to ISO 10646.2. Charset Registration RequirementsRegistered charsets are expected to conform to a number ofrequirements as described below.2.1. Required CharacteristicsRegistered charsets MUST conform to the definition of a "charset"given above. In addition, charsets intended for use in MIME content types under the "text" top-level type MUST conform to therestrictions on that type described in RFC 2045. All registeredcharsets MUST note whether or not they are suitable for use in MIMEtext.All charsets which are constructed as a composition of one or moreCCS’s and a CES MUST either include the CCS’s and CES they are based on in their registration or else cite a definition of their CCS’s and CES that appears elsewhere.All registered charsets MUST be specified in a stable, openlyavailable specification. Registration of charsets whosespecifications aren’t stable and openly available is forbidden.2.2. New CharsetsThis registration mechanism is not intended to be a vehicle for thedesign and definition of entirely new charsets. This is due to thefact that the registration process does NOT contain adequate reviewmechanisms for such undertakings.As such, only charsets defined by other processes and standardsbodies, or specific profiles or combinations of such charsets, areeligible for registration.2.3. Naming RequirementsOne or more names MUST be assigned to all registered charsets.Multiple names for the same charset are permitted, but if multiplenames are assigned a single primary name for the charset MUST be Freed & Postel Best Current Practice [Page 3]identified. All other names are considered to be aliases for theprimary name and use of the primary name is preferred over use of any of the aliases.Each assigned name MUST uniquely identify a single charset. Allcharset names MUST be suitable for use as the value of a MIME content type charset parameter and hence MUST conform to MIME parameter value syntax. This applies even if the specific charset being registeredis not suitable for use with the "text" media type.All charsets MUST be assigned a name that provides a display stringfor the associated "MIBenum" value defined below. These "MIBenum"values are defined by and used in the Printer MIB [RFC-1759]. Suchnames MUST begin with the letters "cs" and MUST contain no more than 40 characters (including the "cs" prefix) chosen from from theprintable subset of US-ASCII. Only one name beginning with "cs" may be assigned to a single charset. If no name of this form isexplicitly defined IANA will assign an alias consisting of "cs"prepended to the primary charset name.Finally, charsets being registered for use with the "text" media type MUST have a primary name that conforms to the more restrictive syntax of the charset field in MIME encoded-words [RFC-2047, RFC-2184] andMIME extended parameter values [RFC-2184]. A combined ABNFdefinition for such names is as follows:mime-charset = 1*mime-charset-charsmime-charset-chars = ALPHA / DIGIT /"!" / "#" / "$" / "%" / "&" /"’" / "+" / "-" / "^" / "_" /"‘" / "{" / "}" / "˜"ALPHA = "A".."Z" ; Case insensitive ASCII LetterDIGIT = "0".."9" ; Numeric digit2.4. Functionality RequirementCharsets MUST function as actual charsets: Registration of thingsthat are better thought of as a transfer encoding, as a media type,or as a collection of separate entities of another type, is notallowed. For example, although HTML could theoretically be thoughtof as a charset, it is really better thought of as a media type andas such it cannot be registered as a charset.2.5. Usage and Implementation RequirementsUse of a large number of charsets in a given protocol may hamperinteroperability. However, the use of a large number of undocumented and/or unlabeled charsets hampers interoperability even more.Freed & Postel Best Current Practice [Page 4]A charset should therefore be registered ONLY if it adds significant functionality that is valuable to a large community, OR if itdocuments existing practice in a large community. Note that charsets registered for the second reason should be explicitly marked as being of limited or specialized use and should only be used in Internetmessages with prior bilateral agreement.2.6. Publication RequirementsCharset registrations MAY be published in RFCs, however, RFCpublication is not required to register a new charset.The registration of a charset does not imply endorsement, approval,or recommendation by the IANA, IESG, or IETF, or even certificationthat the specification is adequate. It is expected thatapplicability statements for particular applications will bepublished from time to time that recommend implementation of, andsupport for, charsets that have proven particularly useful in thosecontexts.Charset registrations SHOULD include a specification of mapping from the charset into ISO 10646 if specification of such a mapping isfeasible.2.7. MIBenum RequirementsEach registered charset MUST also be assigned a unique enumeratedinteger value. These "MIBenum" values are defined by and used in the Printer MIB [RFC-1759].A MIBenum value for each charset will be assigned by IANA at the time of registration. MIBenum values are not assigned by the personregistering the charset.3. Charset Registration ProcedureThe following procedure has been implemented by the IANA for reviewand approval of new charsets. This is not a formal standardsprocess, but rather an administrative procedure intended to allowcommunity comment and sanity checking without excessive time delay. 3.1. Present the Charset to the CommunitySend the proposed charset registration to the "ietf-charsets@" mailing list. (Information about joining thislist is available on the IANA Website, .) Thismailing list has been established for the sole purpose of reviewing Freed & Postel Best Current Practice [Page 5]proposed charset registrations. Proposed charsets are not formallyregistered and must not be used; the "x-" prefix specified in RFC2045 can be used until registration is complete.The posting of a charset to the list initiates a two week publicreview process.The intent of the public posting is to solicit comments and feedback on the definition of the charset and the name chosen for it.3.2. Charset ReviewerWhen the two week period has passed and the registration proposer is convinced that consensus has been achieved, the registrationapplication should be submitted to IANA and the charset reviewer.The charset reviewer, who is appointed by the IETF Applications Area Director(s), either approves the request for registration or rejects it. Rejection may occur because of significant objections raised on the list or objections raised externally. If the charset reviewerconsiders the registration sufficiently important and controversial, a last call for comments may be issued to the full IETF. The charset reviewer may also recommend standards track processing (before orafter registration) when that appears appropriate and the level ofspecification of the charset is adequate.The charset reviewer must reach a decision and post it to the ietf-charsets mailing list within two weeks. Decisions made by thereviewer may be appealed to the IESG.3.3. IANA RegistrationProvided that the charset registration has either passed review orhas been successfully appealed to the IESG, the IANA will registerthe charset, assign a MIBenum value, and make its registrationavailable to the community.4. Location of Registered Charset ListCharset registrations will be posted in the anonymous FTP file"ftp:///in-notes/iana/assignments/character-sets" and all registered charsets will be listed in the periodically issued"Assigned Numbers" RFC [currently RFC-1700]. The description of the charset MAY also be published as an Informational RFC by sending itto "rfc-editor@" (please follow the instructions to RFCauthors [RFC-1543]).Freed & Postel Best Current Practice [Page 6]5. Charset Registration TemplateTo: ietf-charsets@Subject: Registration of new charset [names]Charset name:(All names must be suitable for use as the value of aMIME content-type parameter.)Charset aliases:(All aliases must also be suitable for use as the value ofa MIME content-type parameter.)Suitability for use in MIME text:Published specification(s):(A specification for the charset MUST beopenly available that accurately describes whatis being registered. If a charset is defined asa composition of one or more CCS’s and a CES then thesedefinitions MUST either be included or referenced.)ISO 10646 equivalency table:(A URI to a specification of how to translate fromthis charset to ISO 10646 and vice versa SHOULD beprovided.)Additional information:Person & email address to contact for further information:Intended usage:(One of COMMON, LIMITED USE or OBSOLETE)6. Security ConsiderationsThis registration procedure is not known to raise any sort ofsecurity considerations that are appreciably different from thosealready existing in the protocols that employ registered charsets. Freed & Postel Best Current Practice [Page 7]7. Changes made since RFC 2278Inclusion of a mapping to ISO 10646 is now recommended for allregistered charsets. The registration template has been updated toinclude this as well as a place to indicate whether or not thecharset is suitable for use in MIME text.8. References[ISO-2022]International Standard -- Information Processing --Character Code Structure and Extension Techniques,ISO/IEC 2022:1994, 4th ed.[ISO-8859]International Standard -- Information Processing -- 8-bitSingle-Byte Coded Graphic Character Sets- Part 1: Latin Alphabet No. 1, ISO 8859-1:1998, 1st ed.- Part 2: Latin Alphabet No. 2, ISO 8859-2:1999, 1st ed.- Part 3: Latin Alphabet No. 3, ISO 8859-3:1999, 1st ed.- Part 4: Latin Alphabet No. 4, ISO 8859-4:1998, 1st ed.- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1999, 2nd ed.- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1999, 1st ed.- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1999, 1st ed.- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1999, 2nd ed.International Standard -- Information Technology -- 8-bitSingle-Byte Coded Graphic Character Sets- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1998, 2nd ed. International Standard -- Information Technology -- 8-bitSingle-Byte Coded Graphic Character Sets- Part 13: Latin Alphabet No. 7, ISO/IEC 8859-10:1998, 1st ed. International Standard -- Information Technology -- 8-bitSingle-Byte Coded Graphic Character Sets- Part 14: Latin Alphabet No. 8 (Celtic), ISO/IEC8859-10:1998, 1st ed.International Standard -- Information Technology -- 8-bitSingle-Byte Coded Graphic Character Sets- Part 15: Latin Alphabet No. 9, ISO/IEC 8859-10:1999,1st ed.[ISO-10646]ISO/IEC 10646-1:1993(E), "Information technology --Universal Multiple-Octet Coded Character Set (UCS) --Part 1: Architecture and Basic Multilingual Plane",JTC1/SC2, 1993.Freed & Postel Best Current Practice [Page 8][RFC-1590] Postel, J., "Media Type Registration Procedure", RFC1590,March 1994.[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.[RFC-1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.Gyllenskog, "Printer MIB", RFC 1759, March 1995.[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet MessageBodies", RFC 2045, November 1996.[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046,November 1996.[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME)Part Three: Representation of Non-Ascii Text in InternetMessage Headers", RFC 2047, November 1996.[RFC-2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC-2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,Atkinson, R., Crispin, M. and P. Svanberg, "Report fromthe IAB Character Set Workshop", RFC 2130, April 1997.[RFC-2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, andContinuations", RFC 2184, August 1997.[RFC-2468] Cerf, V., "I Remember IANA", RFC 2468, October 1998.[RFC-2278] Freed, N. and J. Postel, "IANA Charset RegistrationProcedures", BCP 19, RFC 2278, January 1998.[US-ASCII] Coded Character Set -- 7-Bit American Standard Code forInformation Interchange, ANSI X3.4-1986.Freed & Postel Best Current Practice [Page 9]10. Authors’ AddressesNed FreedInnosoft International, Inc.1050 Lakes DriveWest Covina, CA 91790 USAPhone: +1 626 919 3600Fax: +1 626 919 3614EMail: ned.freed@Jon PostelSadly, Jon Postel, the co-author of this document, passed away onOctober 16, 1998 [RFC-2468]. Any omissions or errors are solely the responsibility of the remaining co-author.Freed & Postel Best Current Practice [Page 10]RFC 2978 IANA Charset Registration Procedures October 2000 11. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Freed & Postel Best Current Practice [Page 11]。
