doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc3470.txt b/doc/rfc/rfc3470.txt
new file mode 100644
index 0000000..c5af414
--- /dev/null
+++ b/doc/rfc/rfc3470.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+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
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 1]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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].
+
+1. Introduction and Overview
+
+   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.
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 2]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+1.1 Intended Audience
+
+   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.
+
+1.2 Scope
+
+   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.
+
+   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.
+
+   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.
+
+1.3 XML Evolution
+
+   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.
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 3]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+1.4 XML Users, Support Groups, and Additional Information
+
+   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.
+
+   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.
+
+2. XML Selection Considerations
+
+   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:
+
+   1.  XML is a meta-markup language that can be used to define markup
+       languages for specific domains and problem spaces.
+
+   2.  XML provides both logical structure and physical structure to
+       describe data.  Data framing is built-in.
+
+   3.  XML instances can be validated against the formal definition of a
+       protocol specification.
+
+   4.  XML supports internationalization.
+
+   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.
+
+   6.  XML is still evolving.  The formal specifications are still being
+       influenced and updated as use experience is gained and applied.
+
+   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.
+
+   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,
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 4]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+       debugging, and logging.  A simple "canned" XML fragment can be
+       embedded within a program as a string constant, rather than
+       having to be constructed.
+
+   9.  Binary data has to be encoded into a text-based form to be
+       represented in 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.
+
+   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.
+
+   12. XML support is available in a large number of software
+       development utilities, available in both open source and
+       proprietary products.
+
+   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.
+
+3. XML Alternatives
+
+   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.
+
+   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.
+
+   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
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 5]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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.
+
+   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.
+
+   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.
+
+   Other representation methods may differ from XML in several important
+   ways:
+
+   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.
+
+   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.
+
+   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
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 6]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   framing and data types are implicit and not self-describing.  The
+   extensibility of BNF-based protocol elements needs to be explicitly
+   planned.
+
+   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.
+
+4. XML Use Considerations and Recommendations
+
+   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.
+
+4.1 XML Syntax and Well-Formedness
+
+   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].
+
+   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").
+
+   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.
+
+4.2 XML Information Set
+
+   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.
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 7]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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.
+
+   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.
+
+4.3 Syntactic Restrictions
+
+   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].
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 8]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+4.4 XML Declarations
+
+   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 version="1.0" encoding="UTF-8"?>
+
+   specifies the use of XML version 1 and UTF-8 character encoding.
+
+   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.
+
+   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.
+
+4.5 XML Processing Instructions
+
+   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:
+
+   <?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
+
+
+
+Hollenbeck, et al.       Best Current Practice                  [Page 9]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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  Processing instruction use can not be constrained by most schema
+      languages,
+
+   o  Character references are not recognized within a processing
+      instruction.
+
+   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.
+
+4.6 XML Comments
+
+   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:
+
+   <!-- 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.
+
+4.7 Validity and Extensibility
+
+   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:
+
+   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.
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 10]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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  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.
+
+   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.
+
+   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.
+
+   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.
+
+   This document makes the following recommendations for the definition
+   of protocols using XML:
+
+   o  Protocols should use an appropriate formalism for defining
+      validity of XML protocol elements.
+
+   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  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.
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 11]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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.
+
+   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.
+
+4.8 Semantics as Well as Syntax
+
+   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.
+
+4.9 Namespaces
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 12]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+4.9.1 Namespaces and Attributes
+
+   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:
+
+   <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.
+
+   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:
+
+   <xsl:value-of select="."/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 13]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   they are prefixed when they appear in non-XSLT elements, such as the
+   "xsl:version" attribute when using "literal result element
+   stylesheets":
+
+   <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>
+
+4.10 Element and Attribute Design Considerations
+
+   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.
+
+   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  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  Attribute values can have no internal XML markup for providing
+      internal structure, and
+
+   o  Attribute values are normalized ([8], section 3.3) before
+      processing
+
+   Consider the following example that describes an IP address using an
+   attribute to describe the address value:
+
+   <address addrType="ipv4">10.1.2.3</address>
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 14]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   One might encode the same information using an <addrType> element
+   instead of an "addrType" attribute:
+
+   <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":
+
+   <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.
+
+   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.
+
+   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).
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 15]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+4.11 Binary Data and Text with Control Characters
+
+   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.
+
+   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 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.
+
+4.12 Incremental Processing
+
+   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.
+
+4.13 Entity Declarations and Entity References
+
+   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.
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 16]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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.
+
+   On the other hand, there are five standard entity references built
+   into XML: "&amp;", "&lt;", "&gt;", "&apos;", and "&quot;".  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.
+
+4.14 External References
+
+   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.
+
+4.15 URI Processing
+
+   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].
+
+   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.
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 17]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+4.16 White Space
+
+   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:
+
+   <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:
+
+   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  one or more white space characters prefixing the <addrType> and
+      <value> elements, which an XML processor will make visible to
+      software reading the instance.
+
+   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>
+     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.
+
+   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.
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 18]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+4.17 Interaction with the IANA
+
+   When XML is used in an IETF protocol there are multiple factors that
+   might require IANA action, including:
+
+   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.
+
+      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.
+
+   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.
+
+5. Internationalization Considerations
+
+   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.
+
+5.1 Character Sets and Encodings
+
+   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.
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 19]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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).
+
+   IETF policy [3] requires that the UTF-8 charset be allowed for all
+   text.
+
+   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.
+
+   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.
+
+5.2 Language Declaration
+
+   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].
+
+   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.
+
+5.3 Other Internationalization Considerations
+
+   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"
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 20]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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:
+
+   o  There are different ways of representing characters consisting of
+      combining characters, and
+
+   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]).
+
+   Some of these issues are discussed, with recommendations, in the
+   W3C's "Character Model for the World Wide Web" document [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.
+
+6. IANA Considerations
+
+   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.
+
+7. Security Considerations
+
+   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.
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 21]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   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.
+
+   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 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.
+
+8. Acknowledgements
+
+   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.
+
+9. Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+         2246, January 1999.
+
+   [3]   Alvestrand, H., "IETF Policy on Character Sets and Languages",
+         BCP 18, RFC 2277, January 1998.
+
+   [4]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+         2279, January 1998.
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 22]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   [5]   Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
+         3023, January 2001.
+
+   [6]   Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
+
+   [7]   Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
+         Language) XML-Signature Syntax and Processing", RFC 3275, March
+         2002.
+
+   [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>.
+
+   [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>.
+
+   [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. Informative References
+
+   [11]  Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF
+         URN Sub-namespace for Registered Protocol Parameters", Work in
+         Progress.
+
+   [12]  Mealling, M., "The IETF XML Registry", Work in Progress.
+
+   [13]  Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
+         Network Management Protocol (SNMP)", STD 15, RFC 1157, May
+         1990.
+
+   [14]  Srinivasan, R., "XDR: External Data Representation Standard",
+         RFC 1832, August 1995.
+
+   [15]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [16]  Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", RFC 2234, November 1997.
+
+   [17]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+         1998.
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 23]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   [18]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [19]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
+         1999.
+
+   [20]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
+         RFC 2781, February 2000.
+
+   [21]  Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821,
+         April 2001.
+
+   [22]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
+         C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
+         3010, December 2000.
+
+   [23]  Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252,
+         April 2002.
+
+   [24]  Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
+         Protocol (CNRP)", RFC 3367, August 2002.
+
+   [25]  Backus, J., "The syntax and semantics of the proposed
+         international algebraic language of the Zurich ACM-GAMM
+         conference", June 1959.
+
+   [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.
+
+   [27]  American National Standards Institute, "Information Retrieval:
+         Application Service Definition and Protocol Specification",
+         ANSI Z39.50, ISO Standard 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.
+
+   [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.
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 24]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   [30]  International Organization for Standardization, "Information
+         processing - Text and office systems - Standard Generalized
+         Markup Language (SGML)", ISO Standard 8879, 1988.
+
+   [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.
+
+   [32]  International Organization for Standardization, "DSDL Part 0 -
+         Overview", December 2001, <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>.
+
+   [34]  Duerst, M. and A. Freytag, "Unicode in XML and other Markup
+         Languages", February 2002, <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/>.
+
+   [36]  Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <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/>.
+
+   [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>.
+
+   [39]  Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby
+         Annotation", W3C REC-RUBY, May 2001, <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/>.
+
+   [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/>.
+
+   [42]  Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
+         REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 25]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+   [43]  Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-
+         xslt, November 1999, <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/>.
+
+   [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/>.
+
+   [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/>.
+
+   [47]  W3C Communications Team, "XML in 10 points", November 2001,
+         <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>.
+
+   [49]  Jelliffe, R., "The Schematron", November 2001, <http://
+         www.ascc.net/xml/schematron/>.
+
+URIs
+
+   [50]  <http://www.imc.org/ietf-xml-use/>
+
+   [51]  <http://xml.org/>
+
+   [52]  <http://xmlhack.com/>
+
+   [53]  <http://oasis-open.org/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 26]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+11. Authors' Addresses
+
+   Scott Hollenbeck
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   US
+
+   Phone: +1 703 948 3257
+   EMail: shollenbeck@verisign.com
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   POB 255268
+   Sacramento, CA  95865-5268
+   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
+
+   Phone: +1 408 536 3024
+   EMail: LMM@acm.org
+   URI:   http://larry.masinter.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 27]
+
+RFC 3470               XML within IETF Protocols            January 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck, et al.       Best Current Practice                 [Page 28]
+