Network Working Group S. Hollenbeck
Request for Comments: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Category: Best Current Practice Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
January 2003
Network Working Group S. Hollenbeck
Request for Comments: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Category: Best Current Practice Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
January 2003
Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols
IETF协议中可扩展标记语言（XML）的使用指南
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
可扩展标记语言（XML）是结构化数据的框架。虽然XML是从标准通用标记语言（SGML）——一种主要关注结构化文档的标记语言——发展而来的，但它已经发展成为一种广泛使用的表示结构化数据的机制。
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.
正在开发各种各样的互联网协议；许多人需要与应用程序相关的结构化数据表示。使用XML作为一种表示方法引起了人们极大的兴趣。本文档描述了基本的XML概念，分析了使用XML的各种备选方案，并提供了在IETF标准跟踪协议中使用XML的指南。
Table of Contents
目录
Conventions Used In This Document . . . . . . . . . . . . . . . . 2
1. Introduction and Overview . . . . . . . . . . . . . . . . . 2
1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3
1.4 XML Users, Support Groups, and Additional
Information. . . . . . . . . . . . . . . . . . . . . . 4
2. XML Selection Considerations . . . . . . . . . . . . . . . . 4
3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5
Conventions Used In This Document . . . . . . . . . . . . . . . . 2
1. Introduction and Overview . . . . . . . . . . . . . . . . . 2
1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3
1.4 XML Users, Support Groups, and Additional
Information. . . . . . . . . . . . . . . . . . . . . . 4
2. XML Selection Considerations . . . . . . . . . . . . . . . . 4
3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5
4. XML Use Considerations and Recommendations . . . . . . . . . 7
4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7
4.2 XML Information Set . . . . . . . . . . . . . . . . . 7
4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8
4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9
4.5 XML Processing Instructions . . . . . . . . . . . . . 9
4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10
4.7 Validity and Extensibility . . . . . . . . . . . . . . 10
4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12
4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13
4.10 Element and Attribute Design Considerations. . . . . . 14
4.11 Binary Data and Text with Control Characters . . . . . 16
4.12 Incremental Processing . . . . . . . . . . . . . . . . 16
4.13 Entity Declarations and Entity References . . . . . . 16
4.14 External References . . . . . . . . . . . . . . . . . 17
4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17
4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18
4.17 Interaction with the IANA . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . 19
5.1 Character Sets and Encodings . . . . . . . . . . . . . 19
5.2 Language Declaration . . . . . . . . . . . . . . . . . 20
5.3 Other Internationalization Considerations . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
4. XML Use Considerations and Recommendations . . . . . . . . . 7
4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7
4.2 XML Information Set . . . . . . . . . . . . . . . . . 7
4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8
4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9
4.5 XML Processing Instructions . . . . . . . . . . . . . 9
4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10
4.7 Validity and Extensibility . . . . . . . . . . . . . . 10
4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12
4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13
4.10 Element and Attribute Design Considerations. . . . . . 14
4.11 Binary Data and Text with Control Characters . . . . . 16
4.12 Incremental Processing . . . . . . . . . . . . . . . . 16
4.13 Entity Declarations and Entity References . . . . . . 16
4.14 External References . . . . . . . . . . . . . . . . . 17
4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17
4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18
4.17 Interaction with the IANA . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . 19
5.1 Character Sets and Encodings . . . . . . . . . . . . . 19
5.2 Language Declaration . . . . . . . . . . . . . . . . . 20
5.3 Other Internationalization Considerations . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
Conventions Used In This Document
本文件中使用的公约
This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 [1].
本文件建议，作为政策，互联网协议——特别是IETF标准跟踪协议文件——的规范性语言应包括哪些规范。大写关键词“应该”、“必须”、“必需”等的含义与BCP 14、RFC 2119[1]中规定含义的其他文件中的用法相同。
The Extensible Markup Language (XML, [8]) is a framework for structuring data. While it evolved from the Standard Generalized Markup Language (SGML, [30]) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data in protocol exchanges. See "XML in 10 points" [47] for an introduction to XML.
可扩展标记语言（XML，[8]）是用于结构化数据的框架。虽然XML是从标准的通用标记语言（SGML，[30]）演变而来的，SGML是一种主要关注结构化文档的标记语言，但它已经演变为一种广泛使用的机制，用于在协议交换中表示结构化数据。有关XML的介绍，请参见“10点中的XML”[47]。
Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well.
许多Internet协议设计者正在考虑在现有和新的Internet协议的上下文中使用XML和XML片段。本文档旨在作为XML使用指南和标准跟踪文档的IETF策略。有经验的XML从业人员可能已经熟悉这里的背景资料，但这些指导原则也适用于这些读者。
This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the "best" or "preferred" way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP, [24]) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content.
本文档旨在为在更大的协议中使用XML内容提供指导。我们的目标不是暗示XML是表示数据的“最佳”或“首选”方式；相反，我们的目标是一旦其他因素指出XML是一种可能的数据表示解决方案，就为在协议中使用XML设置上下文。通用名称解析协议（CNRP，[24]）是一个新定义的协议示例，该协议将由这些指南解决。本文档不涉及使用SMTP或HTTP等协议将XML文档作为普通电子邮件或web内容发送。
There are a number of protocol frameworks already in use or under development which focus entirely on "XML protocol" -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP ([45] and [46]). The applicability of such protocols is not part of the scope of this document.
有许多协议框架已经在使用中或正在开发中，它们完全关注“XML协议”——在协议中独家使用XML作为数据表示。例如，万维网联盟（W3C）正在开发一个基于SOAP的XML协议框架（[45]和[46]）。此类协议的适用性不属于本文件的范围。
In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF, [38]) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks.
此外，还有基于XML的高级表示框架，它们被设计为特定类别信息的载体；例如，资源描述框架（RDF，[38]）是用于逻辑断言的基于XML的表示。本文件不提供使用此类框架的指南。
XML 1.0 was originally published as a W3C recommendation in February 1998 [35], and was revised in a 2nd edition [8] in October 2000. Several additional facilities have also been defined that layer on the base specification. Although these additions are designed to be consistent with XML 1.0, they have varying levels of stability, consensus, and implementation. Accordingly, this document identifies the major evolutionary features of XML and makes suggestions as to the circumstances in which each feature should be used.
XML 1.0最初于1998年2月作为W3C建议发布[35]，并于2000年10月在第二版[8]中进行了修订。在基本规范的基础上，还定义了几个附加设施。尽管这些新增内容旨在与XML1.0保持一致，但它们具有不同的稳定性、一致性和实现级别。因此，本文档确定了XML的主要演变特征，并就每个特征的使用环境提出了建议。
There are many XML support groups, with some devoted to the entire XML industry [51], some devoted to developers [52], some devoted to the business applications of XML [53], and many, many groups devoted to the use of XML in a particular context.
有许多XML支持小组，其中一些致力于整个XML行业[51]，一些致力于开发人员[52]，一些致力于XML的业务应用[53]，还有许多很多小组致力于在特定上下文中使用XML。
It is beyond the scope of this document to provide a comprehensive list of referrals. Interested readers are directed to the three references above as starting points, as well as their favorite Internet search engine.
提供全面的转介清单超出了本文件的范围。感兴趣的读者可以从上述三个参考文献以及他们最喜欢的互联网搜索引擎开始。
XML is a tool that provides a means towards an end. Choosing the right tool for a given task is an essential part of ensuring that the task can be completed in a satisfactory manner. This section describes factors to be aware of when considering XML as a tool for use in IETF protocols:
XML是一种工具，它提供了实现目标的手段。为给定的任务选择正确的工具是确保以令人满意的方式完成任务的重要部分。本节描述了将XML作为IETF协议中使用的工具时应注意的因素：
1. XML is a meta-markup language that can be used to define markup languages for specific domains and problem spaces.
1. XML是一种元标记语言，可用于为特定域和问题空间定义标记语言。
2. XML provides both logical structure and physical structure to describe data. Data framing is built-in.
2. XML提供了描述数据的逻辑结构和物理结构。数据帧是内置的。
3. XML instances can be validated against the formal definition of a protocol specification.
3. XML实例可以根据协议规范的正式定义进行验证。
4. XML supports internationalization.
4. XML支持国际化。
5. XML is extensible. Unlike some other markup languages (such as HTML), new tags (and thus new protocol elements) can be defined without requiring changes to XML itself.
5. XML是可扩展的。与其他一些标记语言（如HTML）不同，可以定义新的标记（从而定义新的协议元素），而无需更改XML本身。
6. XML is still evolving. The formal specifications are still being influenced and updated as use experience is gained and applied.
6. XML仍在发展中。随着使用经验的获得和应用，正式规范仍在受到影响和更新。
7. XML does not provide native mechanisms to support detailed data typing. Additional mechanisms (such as those described in Section 4.7) are required to specify abstract protocol data types.
7. XML不提供本机机制来支持详细的数据类型。需要其他机制（如第4.7节所述）来指定抽象协议数据类型。
8. XML is text-based, so XML fragments are easily created, edited, and managed using common utilities. Further, being text-based means it more readily supports incremental development,
8. XML是基于文本的，因此可以使用通用工具轻松创建、编辑和管理XML片段。此外，基于文本意味着它更容易支持增量开发，
debugging, and logging. A simple "canned" XML fragment can be embedded within a program as a string constant, rather than having to be constructed.
调试和日志记录。简单的“罐装”XML片段可以作为字符串常量嵌入到程序中，而不必构造。
9. Binary data has to be encoded into a text-based form to be represented in XML.
9. 二进制数据必须编码成基于文本的形式，以XML表示。
10. XML is verbose when compared with many other structured data representation languages. A representation with element extensibility and human readability typically requires more bits when compared to one optimized for efficient machine processing.
10. 与许多其他结构化数据表示语言相比，XML是冗长的。与为高效机器处理而优化的表示相比，具有元素扩展性和人类可读性的表示通常需要更多的位。
11. XML implementations are still relatively new. As designers and implementers gain experience, it is not uncommon to find defects in early and current products.
11. XML实现仍然相对较新。随着设计师和实施者获得经验，在早期和当前产品中发现缺陷并不罕见。
12. XML support is available in a large number of software development utilities, available in both open source and proprietary products.
12. XML支持可以在大量软件开发实用程序中使用，包括开源和专有产品。
13. XML processing speed can be an issue in some environments. XML processing can be slower because XML data streams may be larger than other representations, and the use of general purpose XML parsers will add a software layer with its own performance costs (though these costs can be reduced through consistent use of an optimized parser). In some situations, processing XML requires examining every byte of the entire XML data stream, with higher overhead than with representations where uninteresting segments can be skipped.
13. 在某些环境中，XML处理速度可能是一个问题。XML处理可能会较慢，因为XML数据流可能比其他表示形式更大，而使用通用XML解析器将增加一个软件层，并带来其自身的性能成本（尽管可以通过一致使用优化的解析器来降低这些成本）。在某些情况下，处理XML需要检查整个XML数据流的每个字节，与可以跳过不感兴趣的段的表示相比，开销更大。
This document focuses on guidelines for the use of XML. It is useful to consider why one might use XML as opposed to some other mechanism. This section considers some other commonly used representation mechanisms and compares XML to those alternatives.
本文档重点介绍XML的使用指南。考虑为什么使用XML而不是其他机制是有用的。本节考虑一些其他常用的表示机制，并将XML与这些替代方案进行比较。
For many fundamental protocols, the extensibility requirements are modest, and the performance requirements are high enough that fixed binary data blocks are the appropriate representation; mechanisms such as XML merely add bloat. RFC 3252 [23] describes a humorous example of XML as protocol bloat.
对于许多基本协议，可扩展性要求适中，性能要求足够高，固定二进制数据块是合适的表示；像XML这样的机制只会增加膨胀。RFC 3252[23]描述了XML作为协议膨胀的一个幽默例子。
In addition, there are other representation and extensibility frameworks that have been used successfully within communication protocols. For example, Abstract Syntax Notation 1 (ASN.1) [28] along with the corresponding Basic Encoding Rules (BER, [29]) are part of the OSI communication protocol suite, and have been used in
此外，还有其他已在通信协议中成功使用的表示和可扩展性框架。例如，抽象语法符号1（ASN.1）[28]以及相应的基本编码规则（BER）[29]）是OSI通信协议套件的一部分，并已在OSI中使用
many subsequent communications standards (e.g., the ANSI Information Retrieval protocol [27] and the Simple Network Management Protocol (SNMP, [13]). The External Data Representation (XDR, [14]) and variations of it have been used in many other distributed network applications (e.g., the Network File System (NFS) protocol [22]). With some ASN.1 encoding types, data types are explicit in the representation, while with XDR, the data types of components are described externally as part of an interface specification.
许多后续通信标准（例如，ANSI信息检索协议[27]和简单网络管理协议（SNMP[13]）。外部数据表示（XDR[14]）及其变体已用于许多其他分布式网络应用程序（例如，网络文件系统（NFS）协议[22]）对于某些ASN.1编码类型，数据类型在表示中是显式的，而对于XDR，组件的数据类型在外部作为接口规范的一部分进行描述。
Many other protocols use data structures directly (without data encapsulation) by describing the data structure with Backus Normal Form (BNF, [25]); many IETF protocols use an Augmented Backus-Naur Form (ABNF, [16]). The Simple Mail Transfer Protocol (SMTP, [21]) is an example of a protocol specified using ABNF.
许多其他协议通过使用巴科斯范式（BNF，[25]）描述数据结构，直接使用数据结构（无数据封装）；许多IETF协议使用一种扩展的巴科斯-诺尔形式（ABNF，[16]）。简单邮件传输协议（SMTP[21]）是使用ABNF指定的协议的一个示例。
ASN.1, XDR, and BNF are described here as examples of alternatives to XML for use in IETF protocols. There are other alternatives, but a complete enumeration of all possible alternatives is beyond the scope of this document.
ASN.1、XDR和BNF在这里被描述为在IETF协议中使用的XML替代品的示例。还有其他备选方案，但所有可能备选方案的完整列举超出了本文件的范围。
Other representation methods may differ from XML in several important ways:
其他表示方法可能在几个重要方面不同于XML：
Text Encoding and character sets: the character encoding used to represent a formal specification. XML defines a consistent character model based on the Universal Character Set (UCS, [31] and [33]), and requires that XML parsers accept at least UTF-8 [4] and UTF-16 [20], and allows for other encodings. While ASN.1 and XDR may carry strings in any encoding, there is no common mechanism for defining character encodings within them. Typically, ABNF definitions tend to be defined in terms of octets or characters in ASCII.
文本编码和字符集：用于表示正式规范的字符编码。XML定义了基于通用字符集（UCS[31]和[33]）的一致字符模型，要求XML解析器至少接受UTF-8[4]和UTF-16[20]，并允许其他编码。虽然ASN.1和XDR可以在任何编码中携带字符串，但它们中没有定义字符编码的通用机制。通常，ABNF定义倾向于以八位字节或ASCII字符来定义。
Data Encoding: XML is defined as a sequence of characters, rather than a sequence of bytes. XML Schema [42] includes mechanisms for representing some data types (integer, date, array, etc.) but many binary data types are encoded in Base64 [15] or hexadecimal. ASN.1 and XDR have rich mechanisms for encoding a wide variety of data types.
数据编码：XML定义为字符序列，而不是字节序列。XML模式[42]包括表示某些数据类型（整数、日期、数组等）的机制，但许多二进制数据类型是用Base64[15]或十六进制编码的。ASN.1和XDR有丰富的机制来编码各种各样的数据类型。
Extensibility: XML has a rich extensibility model such that XML specifications can frequently be versioned independently. Specifications can be extended by adding new element names and attributes (if done compatibly); other extensions can be added by defining new XML namespaces [9], though there is no standard mechanism in XML to indicating whether or not new extensions are mandatory to recognize. Similarly, there are several techniques available to extend ASN.1 specifications. XDR specifications tend to not be independently extensible by different parties because the
可扩展性：XML具有丰富的可扩展性模型，因此经常可以独立地对XML规范进行版本控制。可以通过添加新元素名称和属性（如果兼容的话）来扩展规范；可以通过定义新的XML名称空间[9]来添加其他扩展，尽管XML中没有标准机制来指示是否必须识别新扩展。类似地，有几种技术可用于扩展ASN.1规范。XDR规范往往不能由不同的方独立扩展，因为
framing and data types are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned.
框架和数据类型是隐式的，不是自描述的。需要明确规划基于BNF的协议元素的可扩展性。
Legibility of protocol elements: As noted above, XML is text-based, and thus carries the advantages (and disadvantages) of text-based protocol elements. Typically this is shared with (A)BNF-defined protocol elements. ASN.1 and XDR use binary encodings which are not easily human readable.
协议元素的易读性：如上所述，XML是基于文本的，因此具有基于文本的协议元素的优点（和缺点）。通常与（A）BNF定义的协议元素共享。ASN.1和XDR使用二进制编码，这不容易被人阅读。
This section notes several aspects of XML and makes recommendations for use. Since the 1998 publication of XML version 1 [35], an editorial second edition [8] was published in 2000; this section refers to the second edition.
本节说明了XML的几个方面，并提出了使用建议。自1998年XML第1版[35]出版以来，2000年出版了第二版编辑[8]；本节指的是第二版。
XML [8] is defined in terms of a concrete syntax: a sequence of characters, using the characters "<", "=", "&", etc. as delimiters. An instance is XML if and only if it is well-formed, i.e., all character and markup data conforms to the structural rules defined in section 2.1 of [8].
XML[8]是根据具体语法定义的：一系列字符，使用字符“<”、“=”、“&”等作为分隔符。当且仅当实例格式良好时，即所有字符和标记数据都符合[8]第2.1节中定义的结构规则，则实例为XML。
Character and markup data that is not well-formed is not XML; well-formedness is the basis for syntactic compatibility with XML. Without well-formedness, all of the advantages of using XML disappear. For this reason, it is recommended that protocol specifications explicitly require XML well-formedness ("MUST be well-formed").
格式不正确的字符和标记数据不是XML；格式良好是与XML语法兼容的基础。如果没有良好的格式，使用XML的所有优势都将消失。因此，建议协议规范明确要求XML格式良好（“必须格式良好”）。
The IETF has a long-standing tradition of "be liberal in what you accept" that might seem to be at odds with this recommendation. Given that XML requires well-formedness, conforming XML parsers are intolerant of well-formedness errors. When specifying the handing of erroneous XML protocol elements, a protocol design must never recommend attempting to partially interpret non-well-formed instances of an element which is required to be XML. Reasonable behaviors in such a scenario could include attempting retransmission or aborting an in-progress session.
IETF有一个长期的传统，“在你接受的东西上要自由”，这似乎与这一建议不符。鉴于XML要求格式良好，一致性XML解析器不能容忍格式良好的错误。当指定处理错误的XML协议元素时，协议设计决不能建议尝试部分解释要求为XML的元素的非良好格式实例。在这种情况下，合理的行为可能包括尝试重新传输或中止正在进行的会话。
In addition to the concrete syntax of XML, there is an abstract model of XML content known as the "Information Set" (infoset) [37]. One might think of an XML parser as consuming the concrete syntax and producing an XML Information Set for further processing.
除了XML的具体语法外，还有一个XML内容的抽象模型，称为“信息集”（infoset）[37]。人们可能会认为XML解析器使用具体语法并生成XML信息集以供进一步处理。
In typical use of XML, the definition of allowable XML documents is often defined in terms of the Information Set of the XML and not the concrete syntax. The notion is that any syntactic representation which yielded the same information set would be treated equivalently.
在XML的典型使用中，允许的XML文档的定义通常是根据XML的信息集定义的，而不是具体的语法。其概念是，产生相同信息集的任何语法表示都将被同等对待。
It some cases, protocols have been defined solely in terms of the XML Information Set, or by allowing other concrete syntax representations. However, since the context of XML embedded within other Internet protocols requires an unambiguous definition of the concrete syntax, defining an XML protocol element in terms of its XML Information Set alone and allowing other concrete syntax representations is out of scope for this document.
在某些情况下，协议仅根据XML信息集定义，或者允许其他具体的语法表示。但是，由于嵌入其他Internet协议中的XML上下文需要明确定义具体语法，因此仅根据XML信息集定义XML协议元素并允许其他具体语法表示超出了本文档的范围。
In some circumstances a protocol designer may be tempted to define an XML-based protocol element as "XML", but at the same time imposing additional restrictions beyond those imposed by the XML recommendation itself -- for example, restricting the document character encoding, or avoiding CDATA sections, character entity references, imposing additional restrictions on use of white space, etc. The general category of restrictions addressed by this section are ones that would allow some but not other of the set of syntactic representations which have the same canonical representation according to canonical XML described in RFC 3076 [6].
在某些情况下，协议设计者可能会尝试将基于XML的协议元素定义为“XML”，但同时会施加XML建议本身以外的附加限制，例如，限制文档字符编码，或避免CDATA节、字符实体引用，对空白等的使用施加额外的限制。本节所述的限制的一般类别是允许某些语法表示，但不允许其他语法表示，根据RFC 3076[6]中描述的规范XML，这些语法表示具有相同的规范表示。
Making these kinds of restrictions in a protocol definition may have the disadvantage that an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements. In some cases, the motivation for subsetting XML is to allow implementers to build special-purpose processors that are lighter weight than a full-scale conforming XML processor. There are a number of good, conforming XML parsers that are small, fast, and free, while special-purpose processors have frequently been known to fail to handle some cases of legal XML syntax.
在协议定义中进行这些类型的限制可能具有以下缺点：协议的实现者可能无法使用其他一致性XML处理器来解析基于XML的协议元素。在某些情况下，对XML进行子集的动机是允许实现者构建比完整的XML处理器重量更轻的专用处理器。有许多好的、一致的XML解析器，它们体积小、速度快、免费，而众所周知，专用处理器常常无法处理某些合法XML语法的情况。
In general, such syntactic restrictions should be avoided. In circumstances where restrictions on the variability of the syntactic representation of XML is necessary for one reason or another, designers should consider using "Canonical XML" [6] as the definition of the protocol element, since all such variability has been removed. Some specific issues are discussed in Section 4.4, Section 4.13, and Section 5.1 below.
一般来说，应该避免这种语法限制。在限制XML语法表示的可变性的情况下，出于某种原因，设计者应该考虑使用“规范XML”（6）作为协议元素的定义，因为所有这些可变性都被去除了。下文第4.4节、第4.13节和第5.1节讨论了一些具体问题。
An XML declaration (defined in section 2.8 of [8]) is a small header at the beginning of an XML data stream that indicates the XML version and the character encoding used. For example,
XML声明（在[8]的第2.8节中定义）是XML数据流开头的一个小标题，指示XML版本和使用的字符编码。例如
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
specifies the use of XML version 1 and UTF-8 character encoding.
指定使用XML版本1和UTF-8字符编码。
In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set.
在一些使用XML作为嵌入式协议元素的情况下，使用的XML是较大上下文中的一个小片段，其中XML版本固定为“1.0”，字符编码为“UTF-8”。在这些情况下，XML声明可能会增加额外的开销。如果XML是一个较大的组件，它可能单独作为一个外部实体体（例如，作为MIME消息传输），那么XML声明是一个重要的标记，对于可靠性和可扩展性非常有用。如果使用UTF-8或UTF-16以外的任何编码，XML声明也是字符集/编码的重要标记（参见第5.1节）。注意，在UTF-16的情况下，XML要求实体以字节顺序标记（BOM）开头，它不是字符数据的一部分。请注意，XML声明本身不是XML文档信息集的一部分。
Protocol specifications must be clear about use of XML declarations. XML [8] notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16.
协议规范必须明确XML声明的使用。XML[8]指出，“XML文档应以指定所使用XML版本的XML声明开头。”一般来说，应鼓励（“应存在”）XML声明，并且必须始终允许（“可发送”）。如果允许，字符编码不是UTF-8或UTF-16，则需要XML声明。
An XML processing instruction (defined in section 2.6 of [8]) is a component of an XML document that signals extra "out of band" information to the receiver; a common use of XML processing instructions are for document applications. For example, the XML2RFC application used to generate this document and described in RFC 2629 [19] supports a "table of contents" processing instruction:
XML处理指令（定义见[8]第2.6节）是XML文档的一个组成部分，向接收方发送额外的“带外”信息；XML处理指令通常用于文档应用程序。例如，RFC 2629[19]中描述的用于生成此文档的XML2RFC应用程序支持“目录”处理指令：
<?rfc toc="yes"?>
<?rfc toc="yes"?>
As described in section 2.6 of [8], processing instructions are not part of the document's character data, but must be passed through to the application. As a consequence, it is recommended that processing instructions be ignored when encountered in normal protocol processing. It is thus also recommended that processing instructions
如[8]第2.6节所述，处理指令不是文档字符数据的一部分，但必须传递给应用程序。因此，建议在正常协议处理中遇到处理指令时忽略。因此，还建议处理指令
not be used to define normative protocol data structures or extensions for the following reasons:
由于以下原因，不得用于定义标准协议数据结构或扩展：
o Processing instructions are not namespace aware; there is no way to qualify a processing instruction target with a namespace.
o 处理指令不知道名称空间；无法用名称空间限定处理指令目标。
o Processing instruction use can not be constrained by most schema languages,
o 处理指令的使用不受大多数模式语言的限制，
o Character references are not recognized within a processing instruction.
o 处理指令中无法识别字符引用。
o Processing instructions don't have any XML-defined structure beyond the division between the target and everything else. This means that applications typically have to parse the content of the processing instruction in a system-dependent way; if the content was provided within an element instead, the structure could be expressed in the XML and the parsing could be done by the XML parser.
o 处理指令没有任何XML定义的结构，除了目标和其他内容之间的划分。这意味着应用程序通常必须以依赖于系统的方式解析处理指令的内容；如果内容是在元素中提供的，那么结构可以用XML表示，解析可以由XML解析器完成。
An XML comment (defined in section 2.5 of [8]) is a component of an XML document that provides descriptive information that is not part of the document's character data. XML comments, like comments used in programming languages, are often used to provide explanatory information in human-understandable terms. An example:
XML注释（定义见[8]第2.5节）是XML文档的一个组件，它提供的描述性信息不是文档字符数据的一部分。XML注释与编程语言中使用的注释一样，通常用于以人类可以理解的术语提供解释性信息。例如：
<!-- This is a example comment. -->
<!-- This is a example comment. -->
XML comments can be ignored by conformant processors. As a consequence, it is strongly recommended that comments not be used to define normative protocol data structures or extensions. It is thus also strongly recommended that comments be ignored if encountered in normal protocol processing.
XML注释可以被一致的处理器忽略。因此，强烈建议不要使用评论来定义规范性协议数据结构或扩展。因此，如果在正常协议处理中遇到注释，也强烈建议忽略注释。
One important value of XML is that there are formal mechanisms for defining structural and data content constraints; these constrain the identity of elements or attributes or the values contained within them. There is more than one such formalism:
XML的一个重要价值是，有正式的机制来定义结构和数据内容约束；这些约束约束元素或属性的标识或其中包含的值。这种形式主义不止一种：
o A "Document Type Definition" (DTD) is defined in section 2.8 of [8]; the concept came from a similar mechanism for SGML. There is significant experience with using DTDs, including in IETF protocols.
o [8]第2.8节定义了“文件类型定义”（DTD）；这个概念来自SGML的类似机制。在使用DTD方面有丰富的经验，包括在IETF协议中。
o XML Schema (defined in [41] and [42]) provides additional features to allow a tighter and more precise specification of allowable protocol syntax and data type specifications.
o XML模式（在[41]和[42]中定义）提供了额外的功能，允许更严格、更精确地规范允许的协议语法和数据类型规范。
o There are also a number of other mechanisms for describing XML instance validity; these include, for example, Schematron [49] and RELAX NG [48]. Part 2 of the ISO/IEC Document Schema Definition Language (DSDL, [32]) standard is based on RELAX NG.
o 还有许多其他机制用于描述XML实例的有效性；例如，其中包括Schematron[49]和RELAX NG[48]。ISO/IEC文档模式定义语言（DSDL，[32]）标准的第2部分基于RELAXNG。
There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints.
关于各种有效性约束机制的使用和适用性，XML社区正在进行讨论（并存在争议）。工具的选择取决于对可扩展性的需求，或者对约束允许值和验证对约束的遵从性的正式语言和机制的需求。
There are cases where protocols have defined validity using one or another validity mechanism, but the protocol definitions have not insisted that all corresponding protocol elements be "valid". The decision depends in part on the design for protocol extensibility. Each formalism has different ways of allowing for future extensions; in addition, a protocol design may have its own versioning mechanism, way of updating the schema, or pointing to a new one. For example, the use of XML namespaces (Section 4.9) with XML Schema allows other kinds of extensibility without compromising schema validity.
在某些情况下，协议使用一种或另一种有效性机制定义了有效性，但协议定义并未坚持所有相应的协议元素都是“有效的”。决策部分取决于协议扩展性的设计。每种形式主义都有不同的方式来允许未来的扩展；此外，协议设计可能有自己的版本控制机制、更新模式的方式或指向新模式的方式。例如，在XML模式中使用XML名称空间（第4.9节）可以在不影响模式有效性的情况下实现其他类型的扩展。
No matter what formalism is chosen, there are usually additional syntactic constraints, and inevitably additional semantic constraints, on the validity of XML elements that cannot be expressed in the formalism.
无论选择何种形式主义，对于无法用形式主义表示的XML元素的有效性，通常都会有额外的语法约束，而且不可避免地会有额外的语义约束。
This document makes the following recommendations for the definition of protocols using XML:
本文档对使用XML定义协议提出以下建议：
o Protocols should use an appropriate formalism for defining validity of XML protocol elements.
o 协议应该使用适当的形式来定义XML协议元素的有效性。
o Protocols may or may not insist that all corresponding protocol elements be valid, according to the validity mechanism chosen; in either case, the extensibility design should be clear. What happens if the data is not valid?
o 根据所选择的有效性机制，协议可能会或可能不会坚持所有相应的协议元素都是有效的；无论哪种情况，扩展性设计都应该是明确的。如果数据无效怎么办？
o As described in Section 3 there is no standard mechanism in XML for indicating whether or not new extensions are mandatory to recognize. XML-based protocol specifications should thus explicitly describe extension mechanisms and requirements to recognize or ignore extensions.
o 如第3节所述，XML中没有用于指示是否必须识别新扩展的标准机制。因此，基于XML的协议规范应该明确描述识别或忽略扩展的扩展机制和需求。
An idealized model for XML processing might first check for well-formedness; if OK, apply the primary formalism and, if the instances "passes", apply the other constraints so that the entire set (or as much as is machine processable) can be checked at the same time.
XML处理的理想模型可能首先检查格式是否良好；如果确定，则应用主要形式主义，如果实例“通过”，则应用其他约束，以便可以同时检查整个集合（或尽可能多的可由机器处理）。
However, it is reasonable to allow conforming implementations to avoid doing validation at run-time and rely instead on ad-hoc code to avoid the higher expense, for example, of schema validation, especially given that there will likely be additional hand-crafted semantic validation.
然而，允许一致性实现避免在运行时进行验证，并依赖特定代码来避免更高的费用（例如模式验证），这是合理的，特别是考虑到可能会有额外的手工语义验证。
While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics. Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.
虽然使用有效性形式定义XML协议元素很有用，但这还不够。XML本身不提供语义。任何用XML定义协议元素的文档在文档中也必须有足够的文字描述文档选择定义的XML的语义。
XML namespaces, defined in [9], provide a means of assigning markup to a specific vocabulary. If two elements or attributes from different vocabularies have the same name, they can be distinguished unambiguously if they belong to different namespaces. Additionally, namespaces provide significant support for protocol extensibility as they can be defined, reused, and processed dynamically.
[9]中定义的XML名称空间提供了一种将标记分配给特定词汇表的方法。如果来自不同词汇表的两个元素或属性具有相同的名称，那么如果它们属于不同的名称空间，则可以明确区分它们。此外，名称空间为协议扩展性提供了重要支持，因为它们可以动态定义、重用和处理。
Markup vocabulary collisions are very possible when namespaces are not used to separate and uniquely identify vocabularies. Protocol definitions should use existing XML namespaces where appropriate. When a new namespace is needed, the "namespace name" is a URI that is used to identify the namespace; it's also useful for that URI to point to a description of the namespace. Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs.
当名称空间不用于分隔和唯一标识词汇表时，标记词汇表冲突是非常可能的。协议定义应在适当的情况下使用现有的XML名称空间。当需要新名称空间时，“名称空间名称”是用于标识名称空间的URI；该URI指向名称空间的描述也很有用。通常（在W3C中也是推荐的做法）是使用持久http URI分配命名空间名称。
In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged.
对于IETF标准跟踪文档中的名称空间，如果IETF自己的web空间中有一些永久性部分可用于此目的，这将非常有用。作为替代，可以使用其他永久URI，例如IETF URN命名空间中的URN（参见[11]和[12]）。尽管有IETF规范创建新URI方案来定义XML名称空间的实例，但强烈反对这种做法。
There is a frequently misunderstood aspect of the relationship between unprefixed attributes and the default XML namespace - the natural assumption is that an unprefixed attribute is qualified by the default namespace, but this is not true. Rather, the unprefixed attribute belongs to no namespace at all. Thus, in the following example:
非固定属性和默认XML名称空间之间的关系有一个经常被误解的方面——自然的假设是非固定属性由默认名称空间限定，但事实并非如此。相反，unfixed属性根本不属于任何名称空间。因此，在以下示例中：
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
the attribute "a" is in no namespace, while "ns1:b" is the same namespace as the containing element. A specific description of the relationship between default namespaces and attributes can be found in section 5.2 of [9]. The practical implication of the relationship between namespaces and attributes is that care must be taken to ensure that no element contains multiple attributes that have identical names or have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
属性“a”不在名称空间中，而“ns1:b”与包含元素的名称空间相同。有关默认名称空间和属性之间关系的具体说明，请参见[9]的第5.2节。名称空间和属性之间关系的实际含义是，必须注意确保任何元素都不包含具有相同名称的多个属性，或者包含具有相同本地部分的限定名称以及具有绑定到相同名称空间名称的前缀的多个属性。
In XML applications, the choice between prefixed and non-prefixed attributes frequently is based on whether they always appear inside elements of the same namespace (in which case non-prefixed and thereby non-namespaced names are used) or whether it's required that they can be applied to elements in other arbitrary namespaces (in which case a prefixed name is used). Both situations occur in the XSLT [43] language: while attributes are unprefixed when they occur inside elements in the XSLT namespace, such as:
在XML应用程序中，前缀属性和非前缀属性之间的选择通常基于它们是否总是出现在同一名称空间的元素中（在这种情况下，使用非前缀名称，从而使用非名称空间名称），或者是否需要将它们应用于其他任意名称空间中的元素（在这种情况下使用带前缀的名称）。这两种情况都发生在XSLT[43]语言中：当属性出现在XSLT命名空间的元素中时，它们是不固定的，例如：
<xsl:value-of select="."/>
<xsl:value-of select="."/>
they are prefixed when they appear in non-XSLT elements, such as the "xsl:version" attribute when using "literal result element stylesheets":
当它们出现在非XSLT元素中时，例如使用“文本结果元素样式表”时的“xsl:version”属性时，它们会加上前缀：
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
XML provides much flexibility in allowing a designer to use either elements, attributes, or element content to carry data. This section gives a flavor of the design considerations; there is much written about this in the XML literature. Consistent use of elements, attributes, and values is an important characteristic of a sound design.
XML提供了很大的灵活性，允许设计者使用元素、属性或元素内容来携带数据。本节介绍了设计注意事项；XML文献中有很多关于这方面的文章。元素、属性和值的一致使用是声音设计的一个重要特征。
Attributes are generally intended to contain meta-data that describes the element, and as such they are subject to the following restrictions:
属性通常用于包含描述元素的元数据，因此它们受到以下限制：
o Attributes are unordered,
o 属性是无序的，
o There can be no more than one instance of a given attribute within a given element, though an attribute may contain several values separated by white space ([8], section 2.3 and 3.3.1),
o 给定元素中给定属性的实例不能超过一个，尽管一个属性可能包含多个由空格分隔的值（[8]，第2.3节和第3.3.1节），
o Attribute values can have no internal XML markup for providing internal structure, and
o 属性值不能有用于提供内部结构的内部XML标记，以及
o Attribute values are normalized ([8], section 3.3) before processing
o 属性值在处理前进行规范化（[8]，第3.3节）
Consider the following example that describes an IP address using an attribute to describe the address value:
考虑下面的示例，该示例使用属性描述地址值来描述IP地址：
<address addrType="ipv4">10.1.2.3</address>
<address addrType="ipv4">10.1.2.3</address>
One might encode the same information using an <addrType> element instead of an "addrType" attribute:
可以使用<addrType>元素而不是“addrType”属性来编码相同的信息：
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
Another way of encoding the same information would be to use markup for the "addrType":
编码相同信息的另一种方法是对“addrType”使用标记：
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
Choosing between these designs involves tradeoffs concerning, among other considerations, the likely extensibility patterns and the ability of the formalism to constrain the values appropriately. In the first example, the attribute can be thought of as meta-data to the element which it modifies, and provides for a kind of "element extensibility". The third example allows for a different kind of extensibility: the "ipv4" space can be extended using other namespaces, and the <ipv4> element can include additional markup.
在这些设计之间进行选择需要权衡可能的可扩展性模式和形式主义适当约束值的能力。在第一个示例中，属性可以被认为是它所修改的元素的元数据，并提供了一种“元素可扩展性”。第三个示例允许一种不同的扩展性：“ipv4”空间可以使用其他名称空间进行扩展，<ipv4>元素可以包含其他标记。
Many protocols include parameters that are selected from an enumerated set of values. Such enumerated values can be encoded as elements, attributes, or strings within element values. Any protocol design should consider how the set of enumerated values is to be extended: by revising the protocol, by including different values in different XML namespaces, or by establishing an IANA registry (as per RFC 2434 [18]). In addition, a common practice in XML is to use a URI as an XML attribute value or content.
许多协议包括从枚举值集中选择的参数。这种枚举值可以编码为元素值中的元素、属性或字符串。任何协议设计应该考虑如何扩展枚举值的集合：通过修改协议，通过在不同的XML命名空间中包含不同的值，或者通过建立IANA注册表（如RFC 2434（18））。此外，XML中的一种常见做法是使用URI作为XML属性值或内容。
Languages that describe syntactic validity (including XML Schema and DTDs) often provide a mechanism for specifying "default" values for an attribute. If an element does not specify a value for the attribute, then the "default" value is used. The use of default values for attributes is discouraged by this document. Although the use of this feature can reduce both the size and clutter of XML documents, it has a negative impact on software which doesn't know the document's validity constraints (e.g., for packet tracing or digital signature).
描述语法有效性的语言（包括XML模式和DTD）通常提供一种为属性指定“默认”值的机制。如果元素没有为属性指定值，则使用“默认”值。本文档不鼓励对属性使用默认值。尽管使用此功能可以减少XML文档的大小和混乱程度，但它对不知道文档有效性约束的软件（例如，数据包跟踪或数字签名）有负面影响。
XML is defined as a character stream rather than a stream of octets. There is no way to embed raw binary data directly within an XML data stream; all binary data must be encoded as characters. There are a number of possible encodings; for example, XML Schema [42] defines encodings using decimal digits for integers, Base64 [15], or hexadecimal digits. In addition, binary data might be transmitted using some other communication channel, and referenced within the XML data itself using a URI.
XML被定义为字符流而不是八位字节流。无法将原始二进制数据直接嵌入XML数据流中；所有二进制数据必须编码为字符。有许多可能的编码；例如，XML模式[42]定义了使用十进制数字表示整数、Base64[15]或十六进制数字的编码。此外，二进制数据可能使用其他通信通道传输，并使用URI在XML数据本身中引用。
Protocols that need a container that can hold both structural data and large quantities of binary data should consider carefully whether XML is appropriate, since the Base64 and hex encodings are inefficient. Otherwise, protocols should use the mechanisms of XML Schema to represent binary data; the Base64 encoding is best for larger quantities of data.
需要一个能够保存结构数据和大量二进制数据的容器的协议应该仔细考虑XML是否合适，因为BASE64和HEX编码是低效的。否则，协议应该使用XMLSchema机制来表示二进制数据；Base64编码最适合于较大数量的数据。
XML does not allow "control" characters (0x00-0x1F) except for TAB (0x09), CR (0x0A), and LF (0x0D). They can not be specified even using character entity references. There is currently no common way of encoding them within what is otherwise ordinary text. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation, or some other encoding mechanism might need to be invented.
XML不允许使用“控制”字符（0x00-0x1F），但TAB（0x09）、CR（0x0A）和LF（0x0D）除外。即使使用字符实体引用也无法指定它们。目前还没有一种通用的方式在普通文本中对它们进行编码。这意味着在ABNF定义的协议元素中可能被视为“文本”的字符串可能需要在XML表示中被视为二进制数据，或者可能需要发明一些其他编码机制。
In some situations, it is possible to incrementally process an XML document as each tag is received; this is analogous to the process by which browsers incrementally render HTML pages as they are received. Note that incremental processing is difficult to implement if interspersed across multiple interactions. In other words, if a protocol requires incremental processing across both directions of a bidirectional stream, then it may place an unusual burden on protocol implementers.
在某些情况下，可以在接收到每个标记时以增量方式处理XML文档；这类似于浏览器在接收HTML页面时增量呈现HTML页面的过程。请注意，如果增量处理分散在多个交互中，则很难实现。换句话说，如果协议需要跨双向流的两个方向进行增量处理，那么它可能会给协议实现者带来不寻常的负担。
In addition to its role as a validity mechanism, an XML DTD provides a facility for "entity declarations" ([8], section 4.2). An entity declaration defines, in the DTD, a kind of macro capability where an "entity reference" may be used to call up and include the content of the entity declaration.
除了作为有效性机制的作用外，XML DTD还为“实体声明”提供了便利（见[8]，第4.2节）。实体声明在DTD中定义了一种宏功能，其中“实体引用”可用于调用并包含实体声明的内容。
This feature adds complexity to XML processing, and seems more appropriate for use of XML in document processing than in data representation. As such, this document recommends avoiding entity declarations in protocol specifications.
此功能增加了XML处理的复杂性，似乎更适合在文档处理中使用XML，而不是在数据表示中使用XML。因此，本文件建议避免协议规范中的实体声明。
On the other hand, there are five standard entity references built into XML: "&", "<", ">", "'", and """. XML also has the ability to write character data using numeric entity references (using the Unicode [33] value for the character). Entity references are normally expanded before the XML Information Set is computed. Restricting the use of these entity references would introduce an additional syntactic restriction (see Section 4.3) unnecessarily; these entity references should be allowed.
另一方面，XML中内置了五个标准实体引用：“&；”、“<；”、“>；”、“&apos；”和“"；”。XML还能够使用数字实体引用（使用字符的Unicode[33]值）写入字符数据。实体引用通常在计算XML信息集之前展开。限制这些实体引用的使用将不必要地引入额外的语法限制（见第4.3节）；应该允许这些实体引用。
When using XML in the context of a stateless protocol, be it the protocol itself (e.g., SOAP), or simply as content transferred by an existing protocol (e.g., XML/HTTP), care must be taken to not make the meaning of a message depend on information outside the message itself. XML provides external entities (see Section 4.13), which are an easy way to make the meaning of a message depend on something external. Using schema languages that can change the Infoset, like XML Schema, is another way.
在无状态协议的上下文中使用XML时，无论是协议本身（例如SOAP），还是仅仅作为由现有协议传输的内容（例如XML/HTTP），都必须注意不要使消息的含义依赖于消息本身之外的信息。XML提供了外部实体（参见第4.13节），这是一种使消息的含义依赖于外部内容的简单方法。使用可以更改信息集的模式语言（如XMLSchema）是另一种方法。
The XML Base specification [36] defines an attribute "xml:base" in the XML namespace that is intended to affect the "base" to be used for relative URI processing described in RFC 2396 [17]. The facilities of xml:base for controlling URI processing may be useful to protocol designers, but if xml:base is allowed the interaction with any other protocol facilities for establishing URI context must be specified clearly. Note that use of relative URIs in namespace declarations has been deprecated by the W3C; some specific issues with relative URIs in namespace declarations and canonical XML can be found in section 1.3 of RFC 3076 [6].
XML基本规范[36]在XML命名空间中定义了一个属性“XML:Base”，该属性旨在影响RFC 2396[17]中描述的用于相对URI处理的“Base”。用于控制URI处理的xml:base工具可能对协议设计者有用，但如果允许使用xml:base，则必须明确指定用于建立URI上下文的与任何其他协议工具的交互。请注意，W3C不赞成在命名空间声明中使用相对URI；在RFC 3076[6]的第1.3节中可以找到有关命名空间声明和规范XML中的相对URI的一些具体问题。
Note also that, in many cases, the term "URI" and the syntactic use of URIs within XML allows non-ASCII characters within URIs. For example, the XML Schema "anyURI" datatype ([42] section 3.2.17) allows for direct encoding of characters outside of the US-ASCII range. Most current IETF protocols and specifications do not allow this syntax. Protocol specifications should be clear about the range of characters specified, e.g., by adding a restriction to the range of characters allowed in the anyURI schema datatype, or by specifying that characters outside the US-ASCII range should be escaped when passed to older protocols or APIs.
还要注意，在许多情况下，术语“URI”和XML中URI的语法用法允许URI中使用非ASCII字符。例如，XML模式“anyURI”数据类型（[42]第3.2.17节）允许直接编码US-ASCII范围之外的字符。大多数当前的IETF协议和规范不允许这种语法。协议规范应明确指定的字符范围，例如，通过对anyURI架构数据类型中允许的字符范围添加限制，或通过指定在传递到旧协议或API时应转义US-ASCII范围之外的字符。
XML's prescribed white space handling behavior can be a source of confusion between protocol designers and implementers. In XML instances all white space is considered significant and is by default visible to processing applications. Consider this example from Section 4.10:
XML规定的空白处理行为可能导致协议设计者和实现者之间的混淆。在XML实例中，所有空白都被认为是重要的，并且默认情况下对处理应用程序可见。从第4.10节考虑这个例子：
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
This fragment contains an <address> element and two child elements. It also contains white space for pretty-printing purposes:
这个片段包含一个<address>元素和两个子元素。它还包含用于打印目的的空白：
o at least three line separators, which will be converted by the XML processor to newline (U+000A) characters (see section 2.11 of [8]), and
o 至少三个行分隔符，将由XML处理器转换为换行符（U+000A）（请参见[8]第2.11节），以及
o one or more white space characters prefixing the <addrType> and <value> elements, which an XML processor will make visible to software reading the instance.
o 一个或多个空白字符作为<addrType>和<value>元素的前缀，XML处理器将使读取实例的软件可见这些元素。
Implementers might safely assume that they can ignore the white space in the example above, but white space used for pretty-printing can be a source of confusion in other situations. Consider a minor change to the <value> element:
实现者可以安全地假设他们可以忽略上面示例中的空白，但是用于漂亮打印的空白在其他情况下可能会造成混淆。考虑到<value >元素的微小变化：
<value>
10.1.2.3
</value>
<value>
10.1.2.3
</value>
where white space is found on both sides of the IP address. XML processors treat the white space surrounding "10.1.2.3" as an integral part of the <value> element. A failure to recognize this behavior can lead to confusion and errors in both design and implementation.
在IP地址的两侧都有空白。XML处理器将“10.1.2.3”周围的空白视为<value>元素不可分割的一部分。未能认识到这种行为可能会导致设计和实现中的混乱和错误。
All white space is considered significant in XML instances. As a consequence, it is recommended that protocol designers provide specific guidelines to address white space handling within protocols that use XML.
在XML实例中，所有空白都被认为是重要的。因此，建议协议设计者提供特定的指导方针，以解决使用XML的协议中的空白处理问题。
When XML is used in an IETF protocol there are multiple factors that might require IANA action, including:
当在IETF协议中使用XML时，可能有多个因素需要IANA采取行动，包括：
o XML media types. A piece of XML in a protocol element is sometimes intrinsically bound to the protocol context in which it appears, and in particular might be directly derived from and/or input to protocol state-machine implementations. In cases where the XML content has no relevant meaning outside it's original protocol context, there is no reason to register a MIME type. When it is possible that XML content can be interpreted outside of its original context (such as when that XML content is being stored in a file system or tunneled over another protocol), then a MIME type can be registered to specify the specific format for the data and to provide a hint as to how it might be processed.
o XML媒体类型。协议元素中的一段XML有时本质上绑定到它出现的协议上下文，特别是可能直接从协议状态机实现派生和/或输入。如果XML内容在其原始协议上下文之外没有相关含义，则没有理由注册MIME类型。如果可以在XML内容的原始上下文之外对其进行解释（例如，当XML内容存储在文件系统中或通过另一个协议进行隧道传输时），则可以注册MIME类型，以指定数据的特定格式，并提供有关如何处理该数据的提示。
If MIME labeling is needed, then the advice of RFC 3023 [5] applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered for the reasons described in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" might be appropriate ("MAY be used"). The "text/xml" media type is not recommended ("SHOULD NOT be used") because of issues involving display behavior and default charsets.
如果需要MIME标签，则RFC 3023[5]的建议适用。特别是，如果XML表示新的语言或文档类型，则应根据RFC 3023第7节和a.1节中所述的原因注册新的MIME媒体类型。在使用XML对通用结构化数据进行编码的情况下（例如，涉及将XML与样式表相结合的面向文档的应用程序），“application/XML”可能是合适的（“可以使用”）。由于涉及显示行为和默认字符集的问题，不建议使用“text/xml”媒体类型（“不应使用”）。
o URI registration. There is an ongoing effort ([11], [12]) to create a URN namespace explicitly for defining URIs for namespace names and other URI-designated protocol elements for use within IETF standards track documents; it might also establish IETF policy for such use.
o URI注册。目前正在努力（[11]、[12]）创建一个URN名称空间，以明确定义名称空间名称的URI和其他URI指定的协议元素，以便在IETF标准跟踪文档中使用；它还可以为这种使用制定IETF策略。
This section describes internationalization considerations for the use of XML to represent data in IETF protocols. In addition to the recommendations here, IETF policy on the use of character sets and languages described in RFC 2277 [3] also applies.
本节介绍在IETF协议中使用XML表示数据的国际化注意事项。除了此处的建议外，RFC 2277[3]中描述的IETF字符集和语言使用政策也适用。
IETF protocols frequently speak of the "character set" or "charset" of a string, which is used to denote both the character repertoire and the encoding used to represent sequences of characters as sequences of bytes.
IETF协议经常提到字符串的“字符集”或“字符集”，用于表示字符集和用于将字符序列表示为字节序列的编码。
XML performs all character processing in terms of the Universal Character Set (UCS, [31] and [33]). XML requires all XML processors to support both the UTF-8 [4] and UTF-16 [20] encodings of UCS, although other encodings (charsets) compatible with UCS may be allowed. Documents and external parsed entities encoded in UTF-16 are required to begin with a Byte Order Mark ([8] section 4.3.3).
XML根据通用字符集（UCS、[31]和[33]）执行所有字符处理。XML要求所有XML处理器同时支持UCS的UTF-8[4]和UTF-16[20]编码，尽管可能允许使用与UCS兼容的其他编码（字符集）。以UTF-16编码的文档和外部解析实体必须以字节顺序标记开头（[8]第4.3.3节）。
IETF policy [3] requires that the UTF-8 charset be allowed for all text.
IETF策略[3]要求所有文本都允许UTF-8字符集。
This document requires that IETF protocols using XML allow for the UTF-8 encoding of XML data. Since conforming XML processors are mandated to also accept UTF-16 encoding, also allowing for UTF-16 encoding (with the mandated Byte Order Mark) is recommended. Some XML applications are using a Byte Order Mark with UTF-8 encoding, but this use should not be encouraged and isn't appropriate for XML embedded in other protocols.
本文档要求使用XML的IETF协议允许对XML数据进行UTF-8编码。由于一致性XML处理器也被强制接受UTF-16编码，因此也建议允许UTF-16编码（使用强制字节顺序标记）。一些XML应用程序使用UTF-8编码的字节顺序标记，但不应鼓励这种使用，并且不适合嵌入其他协议中的XML。
Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3) which, depending on circumstances, might add additional implementation complexity. When encodings other than UTF-8 or UTF-16 are used, the encoding must be specified using an "encoding" attribute in the XML declaration (see Section 4.4), even if there might be other protocol mechanisms for designating the encoding.
将XML数据限制为仅以UTF-8表示是一个额外的语法限制（参见第4.3节），这可能会根据具体情况增加额外的实现复杂性。当使用UTF-8或UTF-16以外的编码时，必须使用XML声明中的“encoding”属性指定编码（参见第4.4节），即使可能有其他协议机制指定编码。
Text encapsulated in XML can be represented in many different human languages, and it is often useful to explicitly identify the language used to present the text. XML defines a special attribute in the "xml" namespace, xml:lang, that can be used to specify the language used to represent data in an XML document. The xml:lang attribute (which has to be explicitly declared for use within a DTD or XML Schema) and the values it can assume are defined in section 2.12 of [8].
用XML封装的文本可以用多种不同的人类语言表示，明确标识用于表示文本的语言通常很有用。XML在“XML”名称空间中定义了一个特殊属性XML:lang，可用于指定用于表示XML文档中数据的语言。xml:lang属性（必须显式声明以便在DTD或xml模式中使用）及其可以假定的值在[8]的第2.12节中定义。
It is strongly recommended that protocols representing data in a human language mandate use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts.
强烈建议使用人类语言表示数据的协议强制使用xml:lang属性，前提是xml实例可能在依赖于语言的上下文中进行解释。
There are standard mechanisms in the typography of some human languages that can be difficult to represent using merely XML character string data types. For example, pronunciation clues can be provided using Ruby annotation [39], and embedding controls (such as those described in section 3.4 of [34]) or an XHTML [40] "dir"
在某些人类语言的排版中有一些标准机制，仅使用XML字符串数据类型很难表示这些机制。例如，可以使用Ruby注释[39]和嵌入控件（如[34]第3.4节所述）或XHTML[40]“dir”提供发音线索
attribute can be used to note the proper display direction for bidirectional text.
属性可用于注意双向文本的正确显示方向。
There are a number of tricky issues that can arise when using extended character sets with XML document formats. For example:
在使用XML文档格式的扩展字符集时，可能会出现许多棘手的问题。例如：
o There are different ways of representing characters consisting of combining characters, and
o 有多种不同的字符表示方式，包括组合字符，以及
o There has been some debate about whether URIs should be represented using a restricted US-ASCII subset or arbitrary Unicode (e.g., "URI character sequence" vs "original character sequence" in RFC 2396 [17]).
o 关于URI是否应该使用受限US-ASCII子集或任意Unicode来表示（例如，RFC 2396[17]中的“URI字符序列”与“原始字符序列”）存在一些争论。
Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44].
W3C的“万维网字符模型”文档[44]对其中一些问题进行了讨论，并提出了建议。
It is strongly recommended that protocols representing data in a human language reuse existing mechanisms as needed to ensure proper display of human-legible text.
强烈建议使用人类语言表示数据的协议根据需要重用现有机制，以确保正确显示人类易读的文本。
This memo, per se, has no impact on the IANA. Section 4.17 notes some factors that might require IANA action when protocols using XML are defined.
本备忘录本身对IANA没有影响。第4.17节说明了定义使用XML的协议时可能需要IANA操作的一些因素。
Network protocols face many different kinds of threats, including unintended disclosure, modification, and replay. Passive attacks, such as packet sniffing, allow an attacker to capture and view information intended for someone else. Captured data can be modified and replayed to the original intended recipient, with the recipient having no way to know that the information has been compromised, detect modifications, be assured of the sender's identity, or to confirm which protocol instance is legitimate.
网络协议面临许多不同类型的威胁，包括非故意的泄露、修改和重播。被动攻击（如数据包嗅探）允许攻击者捕获和查看打算提供给其他人的信息。捕获的数据可以修改并重放到原始的预期接收者，接收者无法知道信息已被泄露、检测修改、确保发送者的身份或确认哪个协议实例是合法的。
Several security service options for XML are available to help mitigate these risks. Though XML does not include any built-in security services, other protocols and protocol layers provide services that can be used to protect XML protocols. XML encryption [10] provides privacy services to prevent unintended disclosure. Canonical XML [6] and XML digital signatures [7] provide integrity services to detect modification and authentication services to confirm the identity of the data source. Other IETF security protocols (e.g., the Transport Layer Security (TLS) protocol [2]) are also available to protect data and service endpoints as appropriate.
有几种XML安全服务选项可用于帮助减轻这些风险。尽管XML不包括任何内置的安全服务，但其他协议和协议层提供了可用于保护XML协议的服务。XML加密[10]提供隐私服务以防止意外泄露。规范XML[6]和XML数字签名[7]提供完整性服务来检测修改，并提供身份验证服务来确认数据源的身份。其他IETF安全协议（例如，传输层安全（TLS）协议[2]）也可用于保护数据和服务端点（视情况而定）。
Given the lack of security services in XML, it is imperative that protocol specifications mandate additional security services to counter common threats and attacks; the specific required services will depend on the protocol's threat model.
鉴于XML中缺乏安全服务，协议规范必须要求提供额外的安全服务，以应对常见的威胁和攻击；所需的具体服务将取决于协议的威胁模型。
Experience has shown that code that parses network traffic is often a "soft target" for blackhats. Accordingly, implementers MUST take great care to ensure that their XML handling code is robust with respect to malformed XML, buffer overruns, misuse of entity declarations, and so on.
经验表明，解析网络流量的代码通常是黑帽的“软目标”。因此，实现者必须非常小心地确保他们的XML处理代码对于格式错误的XML、缓冲区溢出、滥用实体声明等具有健壮性。
XML mechanisms that follow external references (Section 4.14) may also expose an implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources. Many XML grammars define constructs using URIs for external references; in such cases, the same precautions must be taken.
遵循外部引用（第4.14节）的XML机制也可能导致实现自动访问外部资源，从而使实现面临各种威胁。禁止从不受信任的源任意访问XML数据中的此类外部引用非常重要。许多XML语法定义使用URI进行外部引用的结构；在这种情况下，必须采取同样的预防措施。
The authors would like to thank the following people who have provided significant contributions to the development of this document:
作者要感谢为本文件的编写做出重大贡献的以下人员：
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer-Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz, Peter Saint-Andre, Simon St Laurent, Margaret Wasserman, and Daniel Veillard.
马克·贝克、蒂姆·伯纳斯·李、蒂姆·布雷、詹姆斯·克拉克、乔什·科恩、约翰·考恩、艾伦·克劳奇、马丁·杜尔斯特、藤泽俊、克里斯蒂安·盖尔·波尔曼、雅伦·格兰德、格雷厄姆·克莱恩、丹·科恩、里克·杰利夫、克里斯·利利、穆拉塔·马科托、迈克尔·米林、让·雅克·莫罗、安德鲁·牛顿、朱利安·雷什克、乔纳森·罗森博格、迈尔斯·萨宾、里奇·萨尔茨、，彼得·圣安德烈、西蒙·圣罗兰、玛格丽特·瓦瑟曼和丹尼尔·维拉德。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[4] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[6] Boyer，J.，“规范XML版本1.0”，RFC 30762001年3月。
[7] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[7] Eastlake，D.，Reagle，J.和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[8] Bray，T.，Paoli，J.，Sperberg McQueen，C.和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC XML，2000年10月<http://www.w3.org/TR/REC-xml>.
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[9] Bray，T.，Hollander，D.和A.Layman，“XML中的名称空间”，W3C REC XML名称，1999年1月<http://www.w3.org/TR/REC-xml-names>.
[10] Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML Encryption Syntax and Processing", W3C REC-xmlenc-core, October 2001, <http://www.w3.org/TR/xmlenc-core/>.
[10] Imamura，T.，Dillaway，B.，Schaad，J.和E.Simon，“XML加密语法和处理”，W3C REC xmlenc core，2001年10月<http://www.w3.org/TR/xmlenc-core/>.
[11] Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF URN Sub-namespace for Registered Protocol Parameters", Work in Progress.
[11] Masinter，L.，Mealling，M.，Klyne，G.和T.Hardie，“注册协议参数的IETF URN子名称空间”，工作正在进行中。
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[12] Mealling，M.，“IETFXML注册表”，正在进行中。
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[13] Case，J.，Fedor，M.，Schoffstall，M.和C.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[14] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[14] Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[15] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[16] Crocker，D.（Ed.）和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[17] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[18] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[19] Rose，M.“使用XML编写I-D和RFC”，RFC 2629，1999年6月。
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[20] Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[21] Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[21] 《简单邮件传输协议》，RFC 28212001年4月。
[22] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.
[22] Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.和D.Noveck，“NFS版本4协议”，RFC3010，2000年12月。
[23] Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252, April 2002.
[23] Kennedy，H.，“二进制词汇八位组临时传输”，RFC 3252，2002年4月。
[24] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution Protocol (CNRP)", RFC 3367, August 2002.
[24] Popp，N.，Mealling，M.和M.Moseley，“共同名称解析协议（CNRP）”，RFC 3367，2002年8月。
[25] Backus, J., "The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference", June 1959.
[25] 《苏黎世ACM-GAMM会议提出的国际代数语言的语法和语义》，巴科斯，J.，1959年6月。
[26] American National Standards Institute, "Code Extension Techniques for Use with the 7-bit Coded Character Set of American National Standard Code (ASCII) for Information Interchange", ANSI X3.41, FIPS PUB 35, 1974.
[26] 美国国家标准协会，“用于信息交换的美国国家标准代码（ASCII）的7位编码字符集的代码扩展技术”，ANSI X3.41，FIPS PUB 35，1974年。
[27] American National Standards Institute, "Information Retrieval: Application Service Definition and Protocol Specification", ANSI Z39.50, ISO Standard 23950, 1995.
[27] 美国国家标准协会，“信息检索：应用服务定义和协议规范”，ANSI Z39.50，ISO标准23950，1995年。
[28] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", ISO Standard 8824, December 1990.
[28] 国际标准化组织，“信息处理系统-开放系统互连-抽象语法符号1规范（ASN.1）”，ISO标准88241990年12月。
[29] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", ISO Standard 8825, December 1990.
[29] 国际标准化组织，“信息处理系统-开放系统互连-抽象语法符号1（ASN.1）基本编码规则规范”，ISO标准8825，1990年12月。
[30] International Organization for Standardization, "Information processing - Text and office systems - Standard Generalized Markup Language (SGML)", ISO Standard 8879, 1988.
[30] 国际标准化组织，“信息处理-文本和办公系统-标准通用标记语言（SGML）”，ISO标准88791988。
[31] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
[31] 国际标准化组织，“信息技术-通用多八位编码字符集（UCS）-第1部分：体系结构和基本多语言平面”，ISO标准10646-11993年5月。
[32] International Organization for Standardization, "DSDL Part 0 - Overview", December 2001, <http://www.jtc1.org/FTP/Public/SC34/ DOCREG/0275.htm>.
[32] 国际标准化组织，“DSDL第0部分-概述”，2001年12月<http://www.jtc1.org/FTP/Public/SC34/ DOCREG/0275.htm>。
[33] Unicode Consortium, "The Unicode Standard, as it may from time to time be revised or amended", March 2002, <http:// www.unicode.org/unicode/standard/standard.html>.
[33] Unicode联合会，“Unicode标准，可能不时修订或修订”，2002年3月，<http://www.Unicode.org/Unicode/Standard/Standard.html>。
[34] Duerst, M. and A. Freytag, "Unicode in XML and other Markup Languages", February 2002, <http://www.w3.org/TR/unicode-xml/>.
[34] Duerst，M.和A.Freytag，“XML和其他标记语言中的Unicode”，2002年2月<http://www.w3.org/TR/unicode-xml/>.
[35] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C REC-xml-1998, February 1998, <http:// www.w3.org/TR/1998/REC-xml-19980210/>.
[35] Bray，T.，Paoli，J.和C.Sperberg McQueen，“可扩展标记语言（XML）1.0”，W3C REC-XML-1998，1998年2月，<http://www.w3.org/TR/1998/REC-XML-19980210/>。
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http:// www.w3.org/TR/xmlbase/>.
[36] Marsh，J.，“XML库”，W3C REC xmlbase，2001年6月，<http://www.w3.org/TR/xmlbase/>。
[37] Cowan, J. and R. Tobin, "XML Information Set", W3C REC-infoset, October 2001, <http://www.w3.org/TR/xml-infoset/>.
[37] Cowan，J.和R.Tobin，“XML信息集”，W3C REC信息集，2001年10月<http://www.w3.org/TR/xml-infoset/>.
[38] Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", W3C REC-rdf-syntax, February 1999, <http://www.w3.org/TR/REC-rdf-syntax>.
[38] Lassila，O.和R.Swick，“资源描述框架（RDF）模型和语法规范”，W3C REC RDF语法，1999年2月<http://www.w3.org/TR/REC-rdf-syntax>.
[39] Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby Annotation", W3C REC-RUBY, May 2001, <http://www.w3.org/TR/ ruby/>.
[39] Suignard，M.，Ishikawa，M.，Duerst，M.和T.Texin，“Ruby注释”，W3C REC-Ruby，2001年5月<http://www.w3.org/TR/ ruby/>。
[40] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup Language", W3C REC-XHTML, January 2000, <http://www.w3.org/TR/ xhtml1/>.
[40] Pemberton，S.，“XHTML 1.0：可扩展超文本标记语言”，W3C REC-XHTML，2000年1月<http://www.w3.org/TR/ xhtml1/>。
[41] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[41] Thompson，H.，Beech，D.，Maloney，M.和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-12001年5月<http://www.w3.org/TR/xmlschema-1/>.
[42] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[42] Biron，P.和A.Malhotra，“XML模式第2部分：数据类型”，W3C REC-xmlschema-2，2001年5月<http://www.w3.org/TR/xmlschema-2/>.
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-xslt, November 1999, <http://www.w3.org/TR/xslt>.
[43] Clark，J.，“XSL转换（XSLT）1.0版”，W3C REC XSLT，1999年11月<http://www.w3.org/TR/xslt>.
[44] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A. and T. Texin, "Character Model for the World Wide Web 1.0", April 2002, <http://www.w3.org/TR/charmod/>.
[44] Duerst，M.，Yergeau，F.，Ishida，R.，Wolf，M.，Freytag，A.和T.Texin，“万维网1.0的角色模型”，2002年4月<http://www.w3.org/TR/charmod/>.
[45] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", June 2002, <http://www.w3.org/TR/soap12-part1/>.
[45] 古德金，M.，哈德利，M.，莫罗，JJ。H.Nielsen，“SOAP版本1.2第1部分：消息传递框架”，2002年6月<http://www.w3.org/TR/soap12-part1/>.
[46] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", June 2002, <http://www.w3.org/TR/soap12-part2/>.
[46] 古德金，M.，哈德利，M.，莫罗，JJ。和H.Nielsen，“SOAP版本1.2第2部分：附件”，2002年6月<http://www.w3.org/TR/soap12-part2/>.
[47] W3C Communications Team, "XML in 10 points", November 2001, <http://www.w3.org/XML/1999/XML-in-10-points>.
[47] W3C通信团队，“10点中的XML”，2001年11月<http://www.w3.org/XML/1999/XML-in-10-points>.
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification", December 2001, <http://www.oasis-open.org/committees/relax-ng/ spec-20011203.html>.
[48] 绿洲技术委员会：RELAX NG，“RELAX NG规范”，2001年12月<http://www.oasis-open.org/committees/relax-ng/ spec-20011203.html>。
[49] Jelliffe, R., "The Schematron", November 2001, <http:// www.ascc.net/xml/schematron/>.
[49] Jelliffe，R.，“Schematron”，2001年11月，<http://www.ascc.net/xml/Schematron/>。
URIs
URI
[50] <http://www.imc.org/ietf-xml-use/>
[50] <http://www.imc.org/ietf-xml-use/>
[51] <http://xml.org/>
[51] <http://xml.org/>
[52] <http://xmlhack.com/>
[52] <http://xmlhack.com/>
[53] <http://oasis-open.org/>
[53] <http://oasis-open.org/>
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
Phone: +1 703 948 3257
EMail: shollenbeck@verisign.com
Phone: +1 703 948 3257
EMail: shollenbeck@verisign.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
马歇尔T.罗斯多佛海滩咨询公司POB 255268萨克拉门托，加利福尼亚州95865-5268美国
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Larry Masinter Adobe Systems Incorporated Mail Stop W14 345 Park Ave. San Jose, CA 95110 US
美国加利福尼亚州圣何塞公园大道345号W14邮政站，邮编95110
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。