Network Working Group T. Goddard
Request for Comments: 4743 ICEsoft Technologies Inc.
Category: Standards Track December 2006
Network Working Group T. Goddard
Request for Comments: 4743 ICEsoft Technologies Inc.
Category: Standards Track December 2006
Using NETCONF over the Simple Object Access Protocol (SOAP)
通过简单对象访问协议（SOAP）使用NETCONF
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF.
网络配置协议（NETCONF）适用于各种环境中的各种设备。Web服务就是这样一种环境，目前的特点是使用简单对象访问协议（SOAP）。NETCONF在这种环境中发现了许多好处：从重用现有标准到简化软件开发，再到与部署的系统集成。在此，我们描述了HTTP上的SOAP和NETCONF上的块上的SOAP交换可扩展协议（BEEP）绑定。
Table of Contents
目录
1. Introduction ....................................................2
2. SOAP Background for NETCONF .....................................3
2.1. Use and Storage of WSDL and XSD ............................4
2.2. SOAP over HTTP .............................................4
2.3. HTTP Drawbacks .............................................4
2.4. BCP56: On the Use of HTTP as a Substrate ...................5
2.5. Important HTTP 1.1 Features ................................6
2.6. SOAP over BEEP .............................................7
2.7. SOAP Implementation Considerations .........................7
2.7.1. SOAP Feature Exploitation ...........................7
2.7.2. SOAP Headers ........................................7
2.7.3. SOAP Faults .........................................8
3. A SOAP Service for NETCONF ......................................9
3.1. Fundamental Use Case .......................................9
3.2. NETCONF Session Establishment ..............................9
3.3. NETCONF Capabilities Exchange ..............................9
3.4. NETCONF Session Usage .....................................11
3.5. NETCONF Session Teardown ..................................11
3.6. A NETCONF over SOAP Example ...............................11
3.7. NETCONF SOAP WSDL .........................................13
3.8. Sample Service Definition WSDL ............................14
4. Security Considerations ........................................15
4.1. Integrity, Privacy, and Authentication ....................15
4.2. Vulnerabilities ...........................................16
4.3. Environmental Specifics ...................................16
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
1. Introduction ....................................................2
2. SOAP Background for NETCONF .....................................3
2.1. Use and Storage of WSDL and XSD ............................4
2.2. SOAP over HTTP .............................................4
2.3. HTTP Drawbacks .............................................4
2.4. BCP56: On the Use of HTTP as a Substrate ...................5
2.5. Important HTTP 1.1 Features ................................6
2.6. SOAP over BEEP .............................................7
2.7. SOAP Implementation Considerations .........................7
2.7.1. SOAP Feature Exploitation ...........................7
2.7.2. SOAP Headers ........................................7
2.7.3. SOAP Faults .........................................8
3. A SOAP Service for NETCONF ......................................9
3.1. Fundamental Use Case .......................................9
3.2. NETCONF Session Establishment ..............................9
3.3. NETCONF Capabilities Exchange ..............................9
3.4. NETCONF Session Usage .....................................11
3.5. NETCONF Session Teardown ..................................11
3.6. A NETCONF over SOAP Example ...............................11
3.7. NETCONF SOAP WSDL .........................................13
3.8. Sample Service Definition WSDL ............................14
4. Security Considerations ........................................15
4.1. Integrity, Privacy, and Authentication ....................15
4.2. Vulnerabilities ...........................................16
4.3. Environmental Specifics ...................................16
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
Given the use of Extensible Markup Language (XML) [2] and the remote procedure call characteristics, it is natural to consider a binding of the NETCONF [1] operations to a SOAP [3] application protocol. This document proposes a binding of this form.
考虑到使用可扩展标记语言（XML）〔2〕和远程过程调用特性，考虑NETCONF[ 1 ]操作绑定到SOAP（3）应用协议是很自然的。本文件建议对本表格进行约束。
In general, SOAP is a natural messaging scheme for NETCONF, essentially because of the remote procedure call character of both. However, care must be taken with SOAP over HTTP as it is inherently synchronous and client-driven. SOAP over BEEP [11] is technically superior, but is not as widely adopted.
通常，SOAP是NETCONF的一种自然消息传递方案，这主要是因为两者都具有远程过程调用的特性。但是，必须小心使用HTTP上的SOAP，因为它本质上是同步的和客户端驱动的。SOAP-over-BEEP[11]在技术上是优越的，但并没有被广泛采用。
Four basic topics are presented: SOAP specifics of interest to NETCONF, specifics on implementing NETCONF as a SOAP-based web service, security considerations, and functional Web Services
本文介绍了四个基本主题：NETCONF感兴趣的SOAP细节、将NETCONF实现为基于SOAP的web服务的细节、安全注意事项和功能性web服务
Description Language (WSDL) definitions. In some sense, the most important part of the document is the brief WSDL document presented in Section 3.7. With the right tools, the WSDL combined with the base NETCONF XML Schemas provides machine-readable descriptions sufficient for the development of software applications using NETCONF.
描述语言（WSDL）定义。从某种意义上讲，文档最重要的部分是第3.7节中介绍的简短WSDL文档。有了正确的工具，WSDL与基本的NETCONF XML模式相结合，提供了机器可读的描述，足以使用NETCONF开发软件应用程序。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8].
不得解释为[本文件第19条]中的“可选”字样。
Why introduce SOAP as yet another wrapper around what is already a remote procedure call message? There are, in fact, both technical and practical reasons. The technical reasons are perhaps less compelling, but let's examine them first.
为什么要引入SOAP作为已经是远程过程调用消息的另一个包装器？事实上，有技术和实际两方面的原因。技术上的原因也许不那么令人信服，但让我们先来分析一下。
The use of SOAP does offer a few technical advantages. SOAP is fundamentally an XML messaging scheme (which is capable of supporting remote procedure call), and it defines a simple message format composed of a "header" and a "body" contained within an "envelope". The "header" contains meta-information relating to the message and can be used to indicate such things as store-and-forward behaviour or transactional characteristics. In addition, SOAP specifies an optional encoding for the "body" of the message. However, this encoding is not applicable to NETCONF as one of the goals is to have highly readable XML, and SOAP-encoding is optimized instead for ease of automated de-serialization. These benefits of the SOAP message structure are simple, but worthwhile because they are already standardized.
SOAP的使用确实提供了一些技术优势。SOAP基本上是一种XML消息传递方案（能够支持远程过程调用），它定义了一种简单的消息格式，由“信封”中包含的“头”和“正文”组成。“头”包含与消息相关的元信息，可用于指示存储转发行为或事务特征等。此外，SOAP为消息的“正文”指定可选编码。但是，这种编码不适用于NETCONF，因为其目标之一是具有高度可读性的XML，而SOAP编码被优化以便于自动反序列化。SOAP消息结构的这些好处很简单，但值得一提，因为它们已经标准化了。
It is the practical reasons that truly make SOAP an interesting choice for device management. It is not difficult to invent a mechanism for exchanging XML messages over TCP, but what is difficult is getting that mechanism supported in a wide variety of tools and operating systems and having that mechanism understood by a great many developers. SOAP over HTTP (with WSDL) is seeing good success at this, and this means that a device management protocol making use of these technologies has advantages in being implemented and adopted. Admittedly, there are interoperability problems with SOAP and WSDL, but such problems have wide attention and can be expected to be resolved.
正是这些实际原因使SOAP成为设备管理的有趣选择。发明一种通过TCP交换XML消息的机制并不困难，但困难的是在各种工具和操作系统中获得该机制的支持，并让许多开发人员理解该机制。HTTP上的SOAP（带有WSDL）在这方面取得了很好的成功，这意味着使用这些技术的设备管理协议在实现和采用方面具有优势。诚然，SOAP和WSDL存在互操作性问题，但此类问题受到广泛关注，有望得到解决。
One of the advantages of using machine-readable formats (such as Web Services Description Language (WSDL) [16] and XML Schemas [4]) is that they can be used automatically in the software development process. With appropriate tools, WSDL and XSD can be used to generate classes that act as remote interfaces or application-specific data structures. Other uses, such as document generation and service location, are also common. A great innovation found with many XML-based definition languages is the use of hyperlinks for referring to documents containing supporting definitions.
使用机器可读格式（如Web服务描述语言（WSDL）[16]和XML模式[4]）的优点之一是，它们可以在软件开发过程中自动使用。通过适当的工具，可以使用WSDL和XSD生成充当远程接口或特定于应用程序的数据结构的类。其他用途，如文档生成和服务位置，也很常见。许多基于XML的定义语言的一个重大创新是使用超链接引用包含支持定义的文档。
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
For instance, in WSDL, the above import statement imports the definitions of XML types and elements from the base NETCONF schema. Ideally, the file containing that schema is hosted on a web server under the authority of the standards body that defined the schema. In this way, dependent standards can be built up over time, and all are accessible to automated software tools that ensure adherence to the standards. The IANA-maintained registry for this purpose is described in "The IETF XML Registry" [13].
例如，在WSDL中，上面的import语句从基本NETCONF模式导入XML类型和元素的定义。理想情况下，包含该模式的文件托管在web服务器上，由定义该模式的标准机构授权。通过这种方式，可以随着时间的推移建立相关标准，并且所有标准都可以通过自动化软件工具访问，以确保遵守标准。“IETF XML注册表”[13]中描述了IANA为此目的维护的注册表。
Note that WSDL declarations for SOAP over BEEP bindings are not yet standardized.
请注意，SOAP over BEEP绑定的WSDL声明尚未标准化。
Although SOAP focuses on messages and can be bound to different underlying protocols such as HTTP, SMTP, or BEEP, most existing SOAP implementations support only HTTP or HTTP/TLS.
尽管SOAP关注于消息，并且可以绑定到不同的底层协议，如HTTP、SMTP或BEEP，但大多数现有的SOAP实现只支持HTTP或HTTP/TLS。
There are a number of advantages to considering SOAP over protocols other than HTTP, as HTTP assigns the very distinct client and server roles by connection initiation. This causes difficulties in supporting asynchronous notification and can be relieved in many ways by replacing HTTP with BEEP.
在HTTP以外的协议上考虑SOAP有许多优点，因为HTTP通过连接启动分配非常不同的客户机和服务器角色。这给支持异步通知带来了困难，可以通过将HTTP替换为BEEP以多种方式缓解这一问题。
HTTP is not the ideal transport for messaging, but it is adequate for the most basic interpretation of "remote procedure call". HTTP is based on a communication pattern whereby the client (which initiates the TCP connection) makes a "request" to the server. The server returns a "response", and this process is continued (possibly over a
HTTP不是消息传递的理想传输，但它足以解释“远程过程调用”的最基本含义。HTTP基于一种通信模式，客户机（启动TCP连接）向服务器发出“请求”。服务器返回一个“响应”，并且该过程将继续（可能通过
persistent connection, as described below). This matches the basic idea of a remote procedure call where the caller invokes a procedure on a remote server and waits for the return value.
持久连接，如下所述）。这与远程过程调用的基本思想相匹配，即调用方调用远程服务器上的过程并等待返回值。
Potential criticisms of HTTP could include the following:
对HTTP的潜在批评可能包括以下几点：
o Server-initiated data flow is awkward to provide.
o 服务器启动的数据流很难提供。
o Headers are verbose and text-based
o 标题冗长且基于文本
o Idle connections may be closed by intermediate proxies
o 空闲连接可由中间代理关闭
o Data encapsulation must adhere to Multipurpose Internet Mail Extensions (MIME) [15].
o 数据封装必须遵循多用途Internet邮件扩展（MIME）[15]。
o Bulk transfer relies on stream-based ordering.
o 批量传输依赖于基于流的排序。
In many ways, these criticisms are directed at particular compromises in the design of HTTP. As such, they are important to consider, but it is not clear that they result in fatal drawbacks for a device management protocol.
在许多方面，这些批评都是针对HTTP设计中的某些妥协。因此，它们是很重要的考虑，但不清楚它们会导致设备管理协议的致命缺陷。
Best Current Practice 56 [6] presents a number of important considerations on the use of HTTP in application protocols. In particular, it raises the following concerns:
当前最佳实践56[6]介绍了在应用程序协议中使用HTTP的一些重要注意事项。特别是，它引起了以下关注：
o HTTP may be more complex than is necessary for the application.
o HTTP可能比应用程序所需的复杂。
o The use of HTTP may mask the application from some firewalls.
o HTTP的使用可能会屏蔽某些防火墙对应用程序的影响。
o A substantially new service should not reuse port 80 as assigned to HTTP.
o 实质上新的服务不应重用分配给HTTP的端口80。
o HTTP caching may mask connection state.
o HTTP缓存可能会屏蔽连接状态。
Fundamentally, these concerns lie directly with common usage of SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF. As BCP 56 indicates, it is debatable whether HTTP is an appropriate protocol for SOAP at all, and it is likely that BEEP would be a superior protocol for most SOAP applications. Unfortunately, SOAP over HTTP is in common use and must be supported if the practical benefits of SOAP are to be realized. Note that the verbose nature of SOAP actually makes it more readily processed by firewalls, albeit firewalls designed to process SOAP messages.
从根本上说，这些问题直接涉及到SOAP over HTTP的常见用法，而不是SOAP over HTTP到NETCONF的应用。正如BCP 56所指出的，HTTP是否是SOAP的合适协议还存在争议，对于大多数SOAP应用程序来说，BEEP很可能是一个更好的协议。不幸的是，HTTP上的SOAP是常用的，如果要实现SOAP的实际好处，就必须支持它。请注意，SOAP的详细特性实际上使它更容易被防火墙处理，尽管防火墙设计用于处理SOAP消息。
HTTP caches SHOULD NOT be inserted between NETCONF managers and agents as NETCONF session state is tied to the state of the underlying transport connection. Three defensive actions can be taken:
不应在NETCONF管理器和代理之间插入HTTP缓存，因为NETCONF会话状态与基础传输连接的状态相关联。可以采取三种防御措施：
o Caching MUST be prohibited through the use of HTTP headers Cache-Control and Pragma: no-cache.
o 必须通过使用HTTP头缓存控制和Pragma:no Cache禁止缓存。
o HTTP proxies SHOULD NOT be deployed within the management network.
o 不应在管理网络中部署HTTP代理。
o Use HTTPS.
o 使用HTTPS。
It is also possible to respond to the concern on the reuse of port 80. Any NETCONF SOAP service MUST always be supported over the new standard port for NETCONF over SOAP, and all conforming implementations MUST default to attempting connections over this new standard port for NETCONF. A standard port for NETCONF over SOAP (over HTTP) has been assigned in the IANA considerations of this document.
还可以对重新使用端口80的问题作出回应。任何NETCONF SOAP服务必须始终通过新的标准端口（NETCONF over SOAP）得到支持，并且所有符合要求的实现都必须默认尝试通过新的标准端口（NETCONF over SOAP）进行连接。在本文档的IANA注意事项中，已为通过SOAP（通过HTTP）的NETCONF分配了一个标准端口。
HTTP 1.1 [5] includes two important features that provide for relatively efficient transport of SOAP messages. These features are "persistent connections" and "chunked transfer-coding".
HTTP 1.1[5]包括两个重要特性，它们提供了相对高效的SOAP消息传输。这些特性是“持久连接”和“分块传输编码”。
Persistent connections allow a single TCP connection to be used across multiple HTTP requests. This permits multiple SOAP request/ response message pairs to be exchanged without the overhead of creating a new TCP connection for each request. Given that a single stream is used for both requests and responses, it is clear that some form of framing is necessary. For messages whose length is known in advance, this is handled by the HTTP header "Content-length". For messages of dynamic length, "Chunking" is required.
持久连接允许跨多个HTTP请求使用单个TCP连接。这允许交换多个SOAP请求/响应消息对，而无需为每个请求创建新的TCP连接。鉴于请求和响应都使用单个流，显然需要某种形式的帧。对于长度预先已知的消息，这由HTTP头“Content length”处理。对于动态长度的消息，需要“分块”。
HTTP "Chunking" or "chunked transfer-coding" allows the sender to send an indefinite amount of binary data. This is accomplished by informing the receiver of the size of each "chunk" (substring of the data) before the chunk is transmitted. The last chunk is indicated by a chunk of zero length. Chunking can be effectively used to transfer a large XML document where the document is generated on-line from a non-XML form in memory.
HTTP“分块”或“分块传输编码”允许发送方发送无限量的二进制数据。这是通过在发送块之前通知接收器每个“块”（数据的子串）的大小来实现的。最后一个区块由长度为零的区块表示。分块可以有效地用于传输大型XML文档，其中文档是从内存中的非XML表单在线生成的。
In terms of its application to SOAP message exchanges, persistent connections are clearly important for performance reasons and are particularly important when the persistence of authenticated connections is at stake. When one considers that messages of dynamic length are the rule rather than the exception for SOAP messages, it
就其在SOAP消息交换中的应用而言，出于性能原因，持久性连接显然很重要，并且在认证连接的持久性受到威胁时尤为重要。如果认为动态长度的消息是SOAP消息的规则而不是例外，那么
is also clear that Chunking is very useful. In some cases, it is possible to buffer a SOAP response and determine its length before sending, but the storage requirements for this are prohibitive for many devices. Together, these two features provide a good foundation for device management using SOAP over HTTP. HTTP chunking and persistent connections [5] SHOULD be used.
很明显，分块是非常有用的。在某些情况下，可以在发送前缓冲SOAP响应并确定其长度，但这方面的存储要求对于许多设备来说是禁止的。这两个特性一起为使用HTTP的SOAP设备管理提供了良好的基础。应该使用HTTP分块和持久连接[5]。
Although not widely adopted by the Web Services community, BEEP is an excellent substrate for SOAP [12]. In particular, it provides for request/response message exchanges initiated by either BEEP peer and allows the number of response messages to be arbitrary (including zero). The BEEP profile for SOAP simply makes use of a single BEEP channel for exchanging SOAP messages and benefits from BEEP's inherent strengths for message exchange over a single transport connection.
虽然没有被Web服务社区广泛采用，但BEEP是SOAP的优秀基础[12]。特别是，它提供了由任何一个BEEP对等方发起的请求/响应消息交换，并允许响应消息的数量是任意的（包括零）。SOAP的BEEP配置文件仅使用一个BEEP通道来交换SOAP消息，并受益于BEEP在单个传输连接上进行消息交换的固有优势。
It is not the goal of this document to cover the SOAP [3] specification in detail. Instead, we provide a few comments that may be of interest to an implementor of NETCONF over SOAP.
本文档的目标不是详细介绍SOAP[3]规范。相反，我们提供了一些注释，这些注释可能是通过SOAP实现NETCONF的人感兴趣的。
NETCONF over SOAP does not make extensive use of SOAP features. For instance, NETCONF operations are not broken into SOAP message parts, and the SOAP header is not used to convey <rpc> metadata. This is a deliberate design decision as it allows the implementor to provide NETCONF over multiple substrates easily while handling the messages over those different substrates in a common way.
基于SOAP的NETCONF没有广泛使用SOAP特性。例如，NETCONF操作不会被分解为SOAP消息部分，SOAP头也不会用于传递<rpc>元数据。这是一个经过深思熟虑的设计决策，因为它允许实现者轻松地在多个基板上提供NETCONF，同时以通用方式处理这些不同基板上的消息。
Implementers of NETCONF over SOAP should be aware of the following characteristic of SOAP headers: a SOAP header may have the attribute "mustUnderstand", and, if it does, the recipient must either process the header block or not process the SOAP message at all, and instead generate a fault. A "mustUnderstand" header must not be silently discarded.
通过SOAP的NETCONF的实现者应该了解SOAP头的以下特征：SOAP头可能具有属性“mustUnderstand”，如果具有该属性，则接收方必须处理头块或根本不处理SOAP消息，并生成错误。“mustUnderstand”标题不能被自动丢弃。
In general, however, SOAP headers are intended for application-specific uses. The NETCONF SOAP binding does not make use of SOAP headers.
但是，一般来说，SOAP头用于特定于应用程序的用途。NETCONF SOAP绑定不使用SOAP头。
A SOAP Fault is returned in the event of a NETCONF <rpc-error>. It is constructed essentially as a wrapper for the <rpc-error>, but it allows SOAP processors to propagate the <rpc-error> to application code using a language-appropriate exception mechanism.
如果发生NETCONF<rpc错误>，则返回SOAP错误。它基本上被构造为<rpc error>的包装器，但它允许SOAP处理器使用适合语言的异常机制将<rpc error>传播到应用程序代码。
A SOAP Fault is constructed from an <rpc-error> as follows: the SOAP Fault Code Value is "Receiver" in the SOAP envelope namespace, the SOAP Fault Reason Text is the contents of the NETCONF <rpc-error> "error-tag", and the SOAP Fault detail is the original <rpc-error> structure.
SOAP错误由<rpc error>构造，如下所示：SOAP错误代码值是SOAP信封名称空间中的“Receiver”，SOAP错误原因文本是NETCONF<rpc error>“error tag”的内容，SOAP错误详细信息是原始的<rpc error>结构。
For instance, given the following <rpc-error>,
例如，给定以下<rpc error>，
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
the associated SOAP Fault message is
关联的SOAP故障消息为
<soapenv:Envelope
xmlns:soapenv=
"http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>env:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text
xml:lang="en">MISSING_ATTRIBUTE</soapenv:Text>
</soapenv:Reason>
<detail>
<rpc-error xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<soapenv:Envelope
xmlns:soapenv=
"http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>env:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text
xml:lang="en">MISSING_ATTRIBUTE</soapenv:Text>
</soapenv:Reason>
<detail>
<rpc-error xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
The fundamental use case for NETCONF over SOAP is that of a management console ("manager" role) managing one or more devices running NETCONF agents ("agent" role). The manager initiates an HTTP or BEEP connection to an agent and drives the NETCONF session via a sequence of SOAP messages. When the manager closes the connection, the NETCONF session is also closed.
基于SOAP的NETCONF的基本用例是管理控制台（“管理者”角色），管理一个或多个运行NETCONF代理的设备（“代理”角色）。管理器启动到代理的HTTP或BEEP连接，并通过一系列SOAP消息驱动NETCONF会话。当管理器关闭连接时，NETCONF会话也将关闭。
A NETCONF over SOAP session is established by the initial message exchange on the underlying substrate. For HTTP, a NETCONF session is established once a SOAP message is POSTed to the NETCONF web application URI. For BEEP, a NETCONF session is established once the BEEP profile for SOAP handshake establishes the SOAP channel.
通过底层基础上的初始消息交换，建立基于SOAP的NETCONF会话。对于HTTP，一旦将SOAP消息发布到NETCONF web应用程序URI，就会建立NETCONF会话。对于BEEP，一旦SOAP握手的BEEP配置文件建立SOAP通道，就会建立NETCONF会话。
Capabilities exchange and session ID establishment are performed through the exchange of <hello> messages. In the case of SOAP over HTTP, the HTTP client MUST send the first <hello> message. The case of SOAP over BEEP imposes no ordering constraints. For instance, the following example shows the exchange of <hello> messages and establishes a session ID value of 4. Observe that the management client initiates the exchange and the server agent assigns the session ID.
通过交换<hello>消息执行功能交换和会话ID建立。对于HTTP上的SOAP，HTTP客户端必须发送第一条<hello>消息。SOAP over BEEP的情况不施加排序约束。例如，下面的示例显示了<hello>消息的交换，并将会话ID值设置为4。请注意，管理客户端会启动exchange，而服务器代理会分配会话ID。
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 376
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <capabilities>
C: <capability>
C: urn:ietf:params:netconf:base:1.0
C: </capability>
C: </capabilities>
C: </hello>
C: </soapenv:Body>
C: </soapenv:Envelope>
S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 600
S:
S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <capabilities>
S: <capability>
S: urn:ietf:params:netconf:base:1.0
S: </capability>
S: <capability>
S: urn:ietf:params:netconf:capability:startup:1.0
S: </capability>
S: <capability>
S: http:/example.net/router/2.3/myfeature
S: </capability>
S: </capabilities>
S: <session-id>4</session-id>
S: </hello>
S: </soapenv:Body>
S: </soapenv:Envelope>
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 376
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <capabilities>
C: <capability>
C: urn:ietf:params:netconf:base:1.0
C: </capability>
C: </capabilities>
C: </hello>
C: </soapenv:Body>
C: </soapenv:Envelope>
S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 600
S:
S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <capabilities>
S: <capability>
S: urn:ietf:params:netconf:base:1.0
S: </capability>
S: <capability>
S: urn:ietf:params:netconf:capability:startup:1.0
S: </capability>
S: <capability>
S: http:/example.net/router/2.3/myfeature
S: </capability>
S: </capabilities>
S: <session-id>4</session-id>
S: </hello>
S: </soapenv:Body>
S: </soapenv:Envelope>
NETCONF sessions are persistent for both performance and semantic reasons. NETCONF session state contains the following:
NETCONF和NETCONF会话都是出于语义性能的考虑。NETCONF会话状态包含以下内容：
1. Authentication Information
1. 认证信息
2. Capability Information
2. 能力信息
3. Locks
3. 锁
4. Pending Operations
4. 未决业务
5. Operation Sequence Numbers
5. 操作序列号
Authentication must be maintained throughout a session due to the fact that it is expensive to establish. Capability Information is maintained so that appropriate operations can be applied during a session. Locks are released upon termination of a session as this makes the protocol more robust. Pending operations come and go from existence during the normal course of remote procedure call (RPC) operations. Operation sequence numbers provide the small but necessary state information to refer to operations during the session.
由于建立身份验证的成本很高，因此必须在整个会话中保持身份验证。维护功能信息，以便在会话期间应用适当的操作。会话终止时会释放锁，因为这使协议更加健壮。在远程过程调用（RPC）操作的正常过程中，挂起的操作来来去去去。操作序列号提供了小但必要的状态信息，以参考会话期间的操作。
In the case of SOAP over HTTP, a NETCONF session is supported by an HTTP connection with an authenticated user. For SOAP over BEEP, a NETCONF session is supported by a BEEP channel operating according to the BEEP profile for SOAP [12].
对于HTTP上的SOAP，NETCONF会话由与经过身份验证的用户的HTTP连接支持。对于SOAP over BEEP，NETCONF会话由根据SOAP的BEEP配置文件运行的BEEP通道支持[12]。
To allow automated cleanup, NETCONF over SOAP session teardown takes place when the underlying connection (in the case of HTTP) or channel (in the case of BEEP) is closed. Note that the root cause of such teardown may be the closure of the TCP connection under either HTTP or BEEP as the case may be. NETCONF managers and agents must be capable of programatically closing the transport connections associated with NETCONF sessions, such as in response to a <close-session> operation; thus, the HTTP or BEEP substrate implementation must expose this appropriately.
为了允许自动清理，当底层连接（在HTTP情况下）或通道（在BEEP情况下）关闭时，会发生NETCONF over SOAP会话拆卸。请注意，这种拆卸的根本原因可能是HTTP或BEEP（视情况而定）下TCP连接的关闭。NETCONF管理器和代理必须能够通过编程关闭与NETCONF会话相关的传输连接，例如响应<close session>操作；因此，HTTP或BEEP基板实现必须适当地公开这一点。
Since the proposed WSDL (in Section 3.7) uses document/literal encoding, the use of a SOAP header and body has little impact on the representation of a NETCONF operation. This example shows HTTP/1.1 for simplicity. An example for BEEP would be similar.
由于提议的WSDL（在第3.7节中）使用文档/文字编码，所以SOAP头和主体的使用对NETCONF操作的表示几乎没有影响。为了简单起见，此示例显示了HTTP/1.1。BEEP的示例与此类似。
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 465
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <rpc message-id="101"
C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <filter type="subtree">
C: <top xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </top>
C: </filter>
C: </get-config>
C: </rpc>
C: </soapenv:Body>
C: </soapenv:Envelope>
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 465
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <rpc message-id="101"
C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <filter type="subtree">
C: <top xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </top>
C: </filter>
C: </get-config>
C: </rpc>
C: </soapenv:Body>
C: </soapenv:Envelope>
The HTTP/1.1 response is also straightforward:
HTTP/1.1响应也很简单：
S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 917
S:
S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body>
S: <rpc-reply message-id="101"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <data>
S: <top xmlns="http://example.com/schema/1.2/config">
S: <users>
S: <user>
S: <name>root</name>
S: <type>superuser</type>
S: <full-name>Charlie Root</full-name>
S: <dept>1</dept>
S: <id>1</id>
S: </company-info>
S: </user>
S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 917
S:
S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body>
S: <rpc-reply message-id="101"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <data>
S: <top xmlns="http://example.com/schema/1.2/config">
S: <users>
S: <user>
S: <name>root</name>
S: <type>superuser</type>
S: <full-name>Charlie Root</full-name>
S: <dept>1</dept>
S: <id>1</id>
S: </company-info>
S: </user>
S: <user>
S: <name>fred</name>
S: <type>admin</type>
S: <full-name>Fred Flintstone</full-name>
S: <dept>2</dept>
S: <id>2</id>
S: </company-info>
S: </user>
S: </users>
S: </top>
S: </data>
S: </rpc-reply>
S: </soapenv:Body>
S: </soapenv:Envelope>
S: <user>
S: <name>fred</name>
S: <type>admin</type>
S: <full-name>Fred Flintstone</full-name>
S: <dept>2</dept>
S: <id>2</id>
S: </company-info>
S: </user>
S: </users>
S: </top>
S: </data>
S: </rpc-reply>
S: </soapenv:Body>
S: </soapenv:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0"
xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
name="netconf-soap_1.0.wsdl">
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0"
xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
name="netconf-soap_1.0.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<message name="helloRequest">
<part name="in" element="netb:hello"/>
</message>
<message name="helloResponse">
<part name="out" element="netb:hello"/>
</message>
<message name="helloRequest">
<part name="in" element="netb:hello"/>
</message>
<message name="helloResponse">
<part name="out" element="netb:hello"/>
</message>
<message name="rpcRequest">
<part name="in" element="netb:rpc"/>
</message>
<message name="rpcResponse">
<part name="out" element="netb:rpc-reply"/>
</message>
<message name="rpcRequest">
<part name="in" element="netb:rpc"/>
</message>
<message name="rpcResponse">
<part name="out" element="netb:rpc-reply"/>
</message>
<portType name="netconfPortType">
<operation name="rpc">
<input message="tns:rpcRequest"/>
<output message="tns:rpcResponse"/>
<portType name="netconfPortType">
<operation name="rpc">
<input message="tns:rpcRequest"/>
<output message="tns:rpcResponse"/>
</operation>
<operation name="hello">
<input message="tns:helloRequest"/>
<output message="tns:helloResponse"/>
</operation>
</portType>
</operation>
<operation name="hello">
<input message="tns:helloRequest"/>
<output message="tns:helloResponse"/>
</operation>
</portType>
<binding name="netconfBinding" type="tns:netconfPortType">
<SOAP:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="hello">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</output>
</operation>
<operation name="rpc">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</output>
</operation>
</binding>
<binding name="netconfBinding" type="tns:netconfPortType">
<SOAP:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="hello">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</output>
</operation>
<operation name="rpc">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</output>
</operation>
</binding>
</definitions>
</definitions>
The following WSDL document assumes a local location for the NETCONF over SOAP WSDL definitions. A typical deployment of a device manageable via NETCONF over SOAP would provide a service definition similar to the following to identify the address of the device.
以下WSDL文档假定NETCONF over SOAP WSDL定义的本地位置。通过NETCONF over SOAP管理的设备的典型部署将提供类似于以下内容的服务定义，以标识设备的地址。
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:nets="urn:ietf:params:xml:ns:netconf:soap:1.0"
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:nets="urn:ietf:params:xml:ns:netconf:soap:1.0"
targetNamespace="urn:myNetconfService"
name="myNetconfService.wsdl">
targetNamespace="urn:myNetconfService"
name="myNetconfService.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
location="http://localhost:8080/netconf/
schema/netconf-soap_1.0.wsdl"/>
<import namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
location="http://localhost:8080/netconf/
schema/netconf-soap_1.0.wsdl"/>
<service name="netconf">
<port name="netconfPort" binding="nets:netconfBinding">
<SOAP:address location="http://localhost:8080/netconf"/>
</port>
</service>
<service name="netconf">
<port name="netconfPort" binding="nets:netconfBinding">
<SOAP:address location="http://localhost:8080/netconf"/>
</port>
</service>
</definitions>
</definitions>
NETCONF is used to access and modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view or modify the agent's configuration data.
NETCONF用于访问和修改配置信息，因此访问此协议的能力应限于有权查看或修改代理配置数据的用户和系统。
Because configuration information is sent in both directions, it is not sufficient for just the client or user to be authenticated with the server. The identity of the server should also be authenticated with the client.
由于配置信息是双向发送的，因此仅对客户端或用户使用服务器进行身份验证是不够的。服务器的身份也应该通过客户端的身份验证。
Configuration data may include sensitive information, such as user names or security keys. So, NETCONF should only be used over communications channels that provide strong encryption for data privacy.
配置数据可能包括敏感信息，如用户名或安全密钥。因此，NETCONF只应在为数据隐私提供强加密的通信信道上使用。
If the NETCONF server provides remote access through insecure protocols, such as HTTP, care should be taken to prevent execution of the NETCONF program when strong user authentication or data privacy is not available.
如果NETCONF服务器通过不安全的协议（如HTTP）提供远程访问，则应注意防止在无法获得强用户身份验证或数据隐私时执行NETCONF程序。
The IANA assigned port SHOULD be used, as this provides a means for efficient firewall filtering during possible denial-of-service attacks.
应使用IANA分配的端口，因为这提供了在可能的拒绝服务攻击期间进行有效防火墙过滤的方法。
The NETCONF SOAP binding relies on an underlying secure transport for integrity and privacy. Such transports are expected to include TLS [9] (which, when combined with HTTP, is referred to as HTTPS) and IPsec. There are a number of options for authentication (some of which are deployment-specific):
NETCONF SOAP绑定依赖于底层的安全传输来保证完整性和隐私。此类传输预计包括TLS[9]（与HTTP结合时称为HTTPS）和IPsec。有许多用于身份验证的选项（其中一些是特定于部署的）：
o within the transport (such as with TLS client certificates)
o 在传输中（例如使用TLS客户端证书）
o within HTTP (such as Digest Access Authentication [7])
o 在HTTP内（例如摘要访问身份验证[7]）
o within SOAP (such as a digital signature in the header [17])
o 在SOAP中（例如标头中的数字签名[17]）
HTTP, BEEP, and SOAP level authentication can be integrated with Remote Authentication Dial-In User Service (RADIUS) [10] to support remote authentication databases.
HTTP、BEEP和SOAP级别的身份验证可以与远程身份验证拨入用户服务（RADIUS）[10]集成，以支持远程身份验证数据库。
At a miniumum, all conforming NETCONF over SOAP implementations MUST support TLS. Specifically, NETCONF over SOAP over HTTP MUST support NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST support NETCONF over SOAP over BEEP over TLS.
至少，所有符合标准的NETCONF over SOAP实现都必须支持TLS。具体来说，HTTP上的SOAP上的NETCONF必须支持HTTPS上的SOAP上的NETCONF，而BEEP上的SOAP上的NETCONF必须支持TLS上的SOAP上的NETCONF。
The above protocols may have various vulnerabilities, and these may be inherited by NETCONF over SOAP.
上述协议可能有各种漏洞，这些漏洞可能由NETCONF通过SOAP继承。
NETCONF itself may have vulnerabilities because an authorization model is not currently specified.
NETCONF本身可能存在漏洞，因为当前未指定授权模型。
It is important that device capabilities and authorization remain constant for the duration of any outstanding NETCONF session. In the case of NETCONF, it is important to consider that device management may be taking place over multiple substrates (in addition to SOAP), and it is important that the different substrates have a common authentication model.
重要的是，在任何未完成的NETCONF会话期间，设备功能和授权保持不变。在NETCONF的情况下，重要的是考虑设备管理可能发生在多个衬底上（除了SOAP），并且重要的是，不同的衬底具有共同的认证模型。
Some deployments of NETCONF over SOAP may choose to use transports without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios.
某些通过SOAP部署的NETCONF可能会选择使用不加密的传输。这会出现漏洞，但可能会选择用于涉及封闭网络或调试场景的部署。
A device managed by NETCONF may interact (over protocols besides NETCONF) with devices managed by other protocols, all of differing security. Each point of entry brings with it a potential vulnerability.
由NETCONF管理的设备可以（通过NETCONF以外的协议）与由其他协议管理的设备进行交互，所有这些都具有不同的安全性。每个进入点都会带来潜在的漏洞。
IANA assigned TCP port (833) for NETCONF over SOAP over BEEP, and TCP port (832) for NETCONF over SOAP over HTTPS.
IANA通过SOAP通过BEEP为NETCONF分配了TCP端口（833），通过HTTPS为NETCONF通过SOAP分配了TCP端口（832）。
IANA will allow for the assignment of an XML namespace within the NETCONF namespace "urn:ietf:params:xml:ns:netconf" for the NETCONF over SOAP WSDL definitions. Following the policies outlined in RFC 2434 [14], assigned values in this subordinate namespace are requested to be allocated according to the "Specification Required" policy.
IANA将允许在NETCONF命名空间“urn:ietf:params:XML:ns:NETCONF”中为NETCONF over SOAP WSDL定义分配XML命名空间。按照RFC 2434[14]中概述的策略，要求根据“所需规范”策略分配此从属命名空间中的赋值。
URI: urn:ietf:params:xml:ns:netconf:soap
URI: urn:ietf:params:xml:ns:netconf:soap
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[1] Enns，R.，编辑，“网络配置协议”，RFC 47412006年12月。
[2] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] Bray，T.，Paoli，J.，Sperberg McQueen，C.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC-XML-20001006，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
[3] Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation REC-soap12-part1-20030624, June 2002, <http://www.w3.org/TR/soap12-part1/>.
[3] Gudgin，M.，Hadley，M.，Moreau，JJ.，和H.Nielsen，“SOAP版本1.2第1部分：消息传递框架”，W3C建议REC-soap12-part1-20030624，2002年6月<http://www.w3.org/TR/soap12-part1/>.
[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation REC-xmlschema-1-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[4] Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构”，W3C建议REC-xmlschema-1-20010502，2001年5月<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[6] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, February 2002.
[6] Moore，K.，“关于HTTP作为基板的使用”，RFC 3205，2002年2月。
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[7] Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Sink，E.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[10] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[11] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[11] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[12] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 4227, January 2006.
[12] O'Tuathail，E.和M.Rose，“在块可扩展交换协议（BEEP）中使用简单对象访问协议（SOAP）”，RFC 4227，2006年1月。
[13] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[13] Mealling，M.，“IETFXML注册表”，RFC3688，2004年1月。
[14] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[14] Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
[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] Christensen, E., Curbera, F., Meredith, G., and S. Weerawarana, "Web Services Description Language (WSDL) 1.1", W3C Note NOTE-wsdl-20010315, March 2001, <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[16] Christensen，E.，Curbera，F.，Meredith，G.，和S.Weerawarana，“Web服务描述语言（WSDL）1.1”，W3C Note-WSDL-20010315，2001年3月<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[17] Brown, A., Fox, B., Hada, S., LaMacchia, B., and H. Maruyama, "SOAP Security Extensions: Digital Signature", W3C Note NOTE-SOAP-dsig-20010206, Feb 2001, <http://www.w3.org/TR/SOAP-dsig/>.
[17] Brown，A.，Fox，B.，Hada，S.，LaMacchia，B.，和H.Maruyama，“SOAP安全扩展：数字签名”，W3C Note-SOAP-dsig-200102062001年2月<http://www.w3.org/TR/SOAP-dsig/>.
Author's Address
作者地址
Ted Goddard ICEsoft Technologies Inc. Suite 300, 1717 10th St. NW Calgary, AB T2M 4S2 Canada
Ted Goddard ICEsoft Technologies Inc.套房300，1717加拿大AB T2M 4S2卡尔加里西北第10街
Phone: (403) 663-3322
EMail: ted.goddard@icesoft.com
URI: http://www.icesoft.com
Phone: (403) 663-3322
EMail: ted.goddard@icesoft.com
URI: http://www.icesoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。