Network Working Group A. Newton
Request for Comments: 4993 VeriSign, Inc.
Category: Standards Track August 2007
Network Working Group A. Newton
Request for Comments: 4993 VeriSign, Inc.
Category: Standards Track August 2007
A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
Internet注册表信息服务的轻量级UDP传输协议
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 (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet.
本文档描述了Internet注册表信息服务（IRIS）的轻量级UDP传输协议。该传输协议对每个请求和响应使用单个数据包，并且可选地对数据包的内容进行压缩。
Table of Contents
目录
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Packet Format ...................................................4
3.1. Payload Descriptor .........................................4
3.1.1. Payload Request Descriptor ..........................4
3.1.2. Payload Response Descriptor .........................5
3.1.3. Payload Header ......................................6
3.1.4. Payload Types .......................................6
3.1.5. Version Information .................................7
3.1.6. Size Information ....................................8
3.1.7. Other Information ...................................8
4. Interactions ....................................................9
5. Internationalization Considerations ............................10
6. IRIS Transport Mapping Definitions .............................10
6.1. URI Scheme ................................................10
6.2. Application Protocol Label ................................10
7. IANA Considerations ............................................10
7.1. Registrations .............................................10
7.1.1. URI Scheme Registration ............................10
7.1.2. Well-known UDP Port Registration ...................11
7.1.3. S-NAPTR Registration ...............................11
8. Security Considerations ........................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Appendix A. Examples ..............................................14
Appendix B. Contributors ..........................................18
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Packet Format ...................................................4
3.1. Payload Descriptor .........................................4
3.1.1. Payload Request Descriptor ..........................4
3.1.2. Payload Response Descriptor .........................5
3.1.3. Payload Header ......................................6
3.1.4. Payload Types .......................................6
3.1.5. Version Information .................................7
3.1.6. Size Information ....................................8
3.1.7. Other Information ...................................8
4. Interactions ....................................................9
5. Internationalization Considerations ............................10
6. IRIS Transport Mapping Definitions .............................10
6.1. URI Scheme ................................................10
6.2. Application Protocol Label ................................10
7. IANA Considerations ............................................10
7.1. Registrations .............................................10
7.1.1. URI Scheme Registration ............................10
7.1.2. Well-known UDP Port Registration ...................11
7.1.3. S-NAPTR Registration ...............................11
8. Security Considerations ........................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Appendix A. Examples ..............................................14
Appendix B. Contributors ..........................................18
Using Straightforward Name Authority Pointers (S-NAPTR) [4], IRIS has the ability to define the use of multiple application transports or transfer protocols for different types of registry services, all at the discretion of the server operator. The UDP transfer protocol defined in this document is completely independent of the registry types for which it can carry data.
使用简单的名称授权指针（S-NAPTR）[4]，IRIS能够为不同类型的注册表服务定义多个应用程序传输或传输协议的使用，所有这些都由服务器运营商自行决定。本文档中定义的UDP传输协议完全独立于它可以承载数据的注册表类型。
The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ (for IRIS Lightweight using Compression). Its message exchange pattern is simple: a client sends a request in one UDP packet, and a server responds with an answer in one UDP packet.
此UDP传输协议与IRIS的绑定称为IRIS-LWZ（用于使用压缩的IRIS轻量级）。它的消息交换模式很简单：客户端在一个UDP数据包中发送请求，服务器在一个UDP数据包中响应响应。
IRIS-LWZ packets are composed of two parts, a binary payload descriptor and a request/response transaction payload. The request/ response transaction payload may be compressed using the DEFLATE [1] algorithm.
IRIS-LWZ数据包由两部分组成，一个二进制负载描述符和一个请求/响应事务负载。可以使用DEFLATE[1]算法压缩请求/响应事务有效负载。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
Octet fields with numeric values are given according to the conventions in RFC 1166 [10]: the leftmost bit of the whole field is the most significant bit; when a multi-octet quantity is transmitted the most significant octet is transmitted first. Bits signifying flags in an octet are numbered according to the conventions of RFC 1166 [10]: bit 0 is the most significant bit and bit 7 is the least significant bit. When a diagram describes a group of octets, the order of transmission for the octets starts from the left.
根据RFC 1166[10]中的约定，给出了具有数值的八位字段：整个字段最左边的位是最高有效位；当传输多个八位组数量时，首先传输最重要的八位组。表示八位字节中标志的位根据RFC 1166[10]的约定进行编号：位0为最高有效位，位7为最低有效位。当图表描述一组八位字节时，八位字节的传输顺序从左边开始。
The packet format for IRIS-LWZ is as follows:
IRIS-LWZ的数据包格式如下：
+------------+---------+
field | payload | payload |
| descriptor | |
+------------+---------+
octets 3 or 6..261* 0..n
+------------+---------+
field | payload | payload |
| descriptor | |
+------------+---------+
octets 3 or 6..261* 0..n
* In request packets, the payload descriptor can vary in length from 6 to 261 octets (i.e., 6..261). In response packets, the payload descriptor is always 3 octets.
* 在请求分组中，有效负载描述符的长度可以从6到261个八位字节（即6..261）不等。在响应数据包中，有效负载描述符始终为3个八位字节。
IRIS-LWZ Packet
IRIS-LWZ数据包
Each IRIS-LWZ query or response is contained in a single UDP packet. Servers MUST be prepared to accept packets as large as 4000 octets, and clients MUST NOT send packets larger than 4000 octets.
每个IRIS-LWZ查询或响应都包含在单个UDP数据包中。服务器必须准备好接受多达4000个八位字节的数据包，客户端发送的数据包不得超过4000个八位字节。
The payload descriptor has two different formats, one for a request and one for a response. However, each format shares a common 1-octet payload header described in Section 3.1.3.
有效负载描述符有两种不同的格式，一种用于请求，另一种用于响应。但是，每种格式共享第3.1.3节中描述的公共1-octet有效载荷头。
The payload descriptor for request packets varies from 6 to 261 octets in length and has the following format:
请求数据包的有效负载描述符的长度从6到261个八位字节不等，格式如下：
+--------+-------------+----------+-----------+-----------+
field | header | transaction | maximum | authority | authority |
| | ID | response | length | |
| | | length | | |
+--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255
+--------+-------------+----------+-----------+-----------+
field | header | transaction | maximum | authority | authority |
| | ID | response | length | |
| | | length | | |
+--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255
Request Payload Descriptor
请求有效负载描述符
These fields have the following meanings:
这些字段具有以下含义：
o header - as described in Section 3.1.3.
o 标题-如第3.1.3节所述。
o transaction ID - a 16-bit value identifying the transaction. This value will be returned in the payload response descriptor (Section 3.1.2) and can be used by clients to match requests with
o 事务ID—标识事务的16位值。该值将在有效负载响应描述符（第3.1.2节）中返回，客户端可使用该值将请求与
responses. Clients SHOULD NOT use sequential values (see Section 8). Clients MUST NOT set all the bits in this value to 1 (i.e., use a value of 0xFFFF).
响应。客户端不应使用顺序值（参见第8节）。客户端不得将该值中的所有位设置为1（即，使用0xFFFF值）。
o maximum response length - the total length of the UDP packet (i.e., UDP header length + payload descriptor length + XML payload length) that should not be exceeded when responding to this request. If the server cannot provide a response that is equal to or less than this value, then it MUST respond with size information (Section 3.1.6).
o 最大响应长度—响应此请求时不应超过的UDP数据包总长度（即UDP报头长度+负载描述符长度+XML负载长度）。如果服务器无法提供等于或小于此值的响应，则必须使用大小信息进行响应（第3.1.6节）。
o authority length - the length of the authority field in this payload descriptor.
o authority length—此有效负载描述符中权限字段的长度。
o authority - a string of octets describing the authority against which this request is to be executed. See [3] for the definition and description of an authority. The number of octets in this string MUST be no more and no less than the number specified by the authority length.
o authority（权限）-描述要针对其执行此请求的权限的八进制字符串。有关权限的定义和说明，请参见[3]。此字符串中的八位字节数不得大于或小于权限长度指定的数字。
The payload descriptor for response packets is always 3 octets and consists of a payload header (Section 3.1.3) and a transaction ID.
响应数据包的有效负载描述符始终为3个八位字节，由有效负载头（第3.1.3节）和事务ID组成。
+--------+-------------+
field | header | transaction |
| | ID |
+--------+-------------+
octets 1 2
+--------+-------------+
field | header | transaction |
| | ID |
+--------+-------------+
octets 1 2
Payload Response Descriptor
有效负载响应描述符
The purpose of the transaction ID is to allow clients to match requests to responses. A value of 0xFFFF is reserved for server use. The value of the transaction ID is as follows:
事务ID的用途是允许客户端将请求与响应进行匹配。保留0xFFFF值供服务器使用。事务ID的值如下所示：
1. If the transaction ID in the corresponding request could not be read due to truncation, servers MUST use a transaction ID with all bits set to 1 (i.e., a value of OxFFFF) and send a descriptor error (see Section 3.1.7).
1. 如果由于截断而无法读取相应请求中的事务ID，则服务器必须使用一个事务ID，将所有位设置为1（即，值为OxFFFF），并发送一个描述符错误（见第3.1.7节）。
2. If the transaction ID in the corresponding request is a value of 0xFFFF, servers MUST use a transaction ID of 0xFFFF and send a descriptor error (see Section 3.1.7).
2. 如果相应请求中的事务ID值为0xFFFF，则服务器必须使用0xFFFF事务ID并发送描述符错误（请参阅第3.1.7节）。
3. Otherwise, the transaction ID MUST be the value of the transaction ID of the corresponding request.
3. 否则，事务ID必须是相应请求的事务ID的值。
The bits of the payload header are ordered according to RFC 1166 [10], where bit 0 is the most significant and bit 7 is the least significant. Each bit in the 1-octet payload header has the following meaning:
有效载荷报头的位根据RFC 1166[10]进行排序，其中位0为最高有效位，位7为最低有效位。1-octet有效负载报头中的每一位具有以下含义：
o bits 0 and 1 - version number ('V' field) - If 0 (both bits are zero), the protocol is the version defined in this document. Otherwise, the rest of the bits in the header and the payload may be interpreted as another version.
o 第0位和第1位-版本号（“V”字段）-如果为0（两位均为零），则协议为本文档中定义的版本。否则，报头和有效载荷中的其余位可能被解释为另一个版本。
o bit 2 - request/response flag ('RR' flag) - If 0, this packet is a request (Section 3.1.1) packet. If 1, this packet is a response (Section 3.1.2) packet.
o 第2位-请求/响应标志（“RR”标志）-如果为0，则该数据包为请求（第3.1.1节）数据包。如果为1，则该数据包为响应（第3.1.2节）数据包。
o bits 3 - payload deflated ('PD' flag) - If 1, the payload is compressed using the DEFLATE [1] algorithm.
o 位3-有效载荷已放气（“PD”标志）-如果为1，则使用放气[1]算法压缩有效载荷。
o bit 4 - deflate supported ('DS' flag) - If 1, the sender of this packet supports compression using the DEFLATE algorithm. When this bit is 0 in a request, the payload of the response MUST NOT be compressed with DEFLATE.
o 第4位-支持deflate（'DS'标志）-如果为1，则此数据包的发送方支持使用deflate算法进行压缩。当请求中的该位为0时，不得使用DEFLATE压缩响应的有效负载。
o bit 5 - reserved - This MUST be 0.
o 第5位-保留-必须为0。
o bits 6 and 7 - The value of these bits indicates payload types (Section 3.1.4) ('PT' field).
o 位6和7-这些位的值表示有效负载类型（第3.1.4节）（“PT”字段）。
A payload type indicates the type of content in the UDP packet following the payload descriptor. Some payload types have no meaning in request packets, and some payload types differ in meaning between requests and responses. Some payload types indicate an empty payload.
有效负载类型指示有效负载描述符后面的UDP数据包中的内容类型。某些有效负载类型在请求数据包中没有意义，而某些有效负载类型在请求和响应之间的意义不同。某些有效负载类型指示空有效负载。
The payload type values in binary are as follows:
二进制有效负载类型值如下所示：
00 - xml payload ('xml' type). The payload is either an IRIS-based XML request or an IRIS-based XML response.
00-xml有效负载（'xml'类型）。有效负载是基于IRIS的XML请求或基于IRIS的XML响应。
01 - version info ('vi' type). In a request packet, this payload type indicates that the server is to respond with version information (Section 3.1.5), and that the payload is empty. In a response packet, this payload type indicates that the payload is version information (Section 3.1.5).
01-版本信息（“vi”类型）。在请求数据包中，此有效负载类型表示服务器将使用版本信息进行响应（第3.1.5节），并且有效负载为空。在响应数据包中，该有效载荷类型表示有效载荷是版本信息（第3.1.5节）。
10 - size info ('si' type). This payload type has no meaning in a request packet and is a descriptor error. In a response packet, this payload type indicates that the payload is size information (Section 3.1.6).
10-尺寸信息（“si”类型）。此有效负载类型在请求数据包中没有意义，是一个描述符错误。在响应数据包中，该有效载荷类型表示有效载荷是大小信息（第3.1.6节）。
11 - other info ('oi' type). This payload type has no meaning in a request packet and is a descriptor error. In a response packet, this payload type indicates that the payload is other information (Section 3.1.7).
11-其他信息（“oi”类型）。此有效负载类型在请求数据包中没有意义，是一个描述符错误。在响应数据包中，该有效载荷类型表示有效载荷是其他信息（第3.1.7节）。
A payload type with version information ('vi') MUST be conformant to the XML defined in [8] and use the <versions> element as the root element.
具有版本信息（“vi”）的有效负载类型必须符合[8]中定义的XML，并使用<versions>元素作为根元素。
In the context of IRIS-LWZ, the protocol identifiers for these elements are as follows:
在IRIS-LWZ的上下文中，这些元素的协议标识符如下所示：
<transferProtocol> - the value "iris.lwz1" to indicate the protocol specified in this document.
<transferProtocol>-值“iris.lwz1”表示本文档中指定的协议。
<application> - the XML namespace identifier for IRIS [3].
<application>-IRIS的XML命名空间标识符[3]。
<dataModel> - the XML namespace identifier for IRIS registries.
<dataModel>-IRIS注册表的XML命名空间标识符。
This document defines no extension identifiers and no authentication mechanism identifiers.
本文档未定义扩展标识符和身份验证机制标识符。
Servers SHOULD send version information in the following cases:
在以下情况下，服务器应发送版本信息：
1. In response to a version information request (i.e., the PT field is set to 'vi').
1. 响应版本信息请求（即PT字段设置为“vi”）。
2. The version in a payload descriptor header does not match a version the server supports.
2. 负载描述符标头中的版本与服务器支持的版本不匹配。
3. The IRIS-based XML payload does not match a version the server supports.
3. 基于IRIS的XML负载与服务器支持的版本不匹配。
The protocols identified by the <transferProtocol> element MUST only indicate protocols running on the same socket as the sender of the corresponding response. In other words, while a server operator may also be running IRIS-XPC [9], this XML instance is only intended to describe version negotiation for IRIS-LWZ.
<transferProtocol>元素标识的协议必须仅指示与相应响应的发送方在同一套接字上运行的协议。换句话说，虽然服务器操作员可能也在运行IRIS-XPC[9]，但此XML实例仅用于描述IRIS-LWZ的版本协商。
The octet size for the 'requestSizeOctets' and 'responseSizeOctets' attributes of the <tranferProtocol> element are defined in Section 3.1.6.
<TransferProtocol>元素的“requestSizeOctets”和“responseSizeOctets”属性的八位字节大小在第3.1.6节中定义。
A payload type with size information ('si') MUST be conformant to the XML defined in [8] and use the <size> element as the root element.
具有大小信息（“si”）的有效负载类型必须符合[8]中定义的XML，并使用<size>元素作为根元素。
Octet counts provided by this information are defined as the total length of the UDP packet (i.e., UDP header length + payload descriptor length + XML payload length).
此信息提供的八位字节计数定义为UDP数据包的总长度（即UDP报头长度+有效负载描述符长度+XML有效负载长度）。
A payload type with other information ('oi') MUST be conformant to the XML defined in [8] and use the <other> element as the root element.
包含其他信息的有效负载类型（“oi”）必须符合[8]中定义的XML，并使用<other>元素作为根元素。
The values for the 'type' attribute of <other> are as follows:
<other>的“type”属性的值如下所示：
'descriptor-error' - indicates there was an error decoding the descriptor. Servers SHOULD send a descriptor error in the following cases:
“描述符错误”-表示解码描述符时出错。在以下情况下，服务器应发送描述符错误：
1. When a request is received with a payload type indicating size information (i.e., the PT field is 'si').
1. 当接收到指示大小信息的有效负载类型的请求时（即，PT字段为“si”）。
2. When a request is received with a payload type indicating other information (i.e., the PT field is 'oi').
2. 当接收到带有指示其他信息的有效负载类型的请求时（即，PT字段为“oi”）。
3. When a request is sent with a transaction ID of 0xFFFF (which is reserved for server use).
3. 发送事务ID为0xFFFF（保留供服务器使用）的请求时。
4. When a request is received with an incomplete or truncated payload descriptor.
4. 当使用不完整或截断的有效负载描述符接收到请求时。
5. When reserved bits in the payload descriptor are set to values other than zero.
5. 当有效负载描述符中的保留位设置为零以外的值时。
'payload-error' - indicates there was an error interpreting the payload. Servers MUST send a payload error if they receive XML (i.e., the PT field is set to 'xml') and the XML cannot be parsed.
“有效负载错误”-表示解释有效负载时出错。如果服务器接收到XML（即PT字段设置为“XML”），并且无法解析XML，则必须发送有效负载错误。
'system-error' - indicates that the receiver cannot process the request due to a condition not related to this protocol. Servers SHOULD send a system-error when they are capable of responding to requests but not capable of processing requests.
“系统错误”-表示由于与此协议无关的情况，接收器无法处理请求。当服务器能够响应请求但不能处理请求时，应发送系统错误。
'authority-error' - indicates that the intended authority specified in the corresponding request is not served by the receiver. Servers SHOULD send an authority error when they receive a request directed to an authority other than those they serve.
“授权错误”-表示接收方未提供相应请求中指定的预期授权。当服务器收到指向其服务机构以外的机构的请求时，应发送一个机构错误。
'no-inflation-support-error' - indicates that the receiver does not support payloads that have been compressed with DEFLATE [1]. Servers MUST send this error when they receive a request that has been compressed with DEFLATE but they do not support inflation.
“无充气支持错误”-表示接收器不支持使用DEFLATE[1]压缩的有效载荷。当服务器收到使用DEFLATE压缩但不支持膨胀的请求时，必须发送此错误。
The intent of IRIS-LWZ is to utilize UDP for IRIS requests and responses when UDP is appropriate. Not all IRIS requests and responses will be able to utilize UDP and may require the use of other transfer protocols (i.e., IRIS-XPC [9] and/or Blocks Extensible Exchange Protocol (BEEP)). The following strategy SHOULD be used:
IRIS-LWZ的目的是在UDP合适的情况下，将UDP用于IRIS请求和响应。并非所有IRIS请求和响应都能够使用UDP，并且可能需要使用其他传输协议（即IRIS-XPC[9]和/或块可扩展交换协议（BEEP））。应采用以下策略：
1. If a request requires authentication, confidentiality, or other security, use another transfer protocol. IRIS-XPC [9] is RECOMMENDED.
1. 如果请求需要身份验证、机密性或其他安全性，请使用其他传输协议。建议使用IRIS-XPC[9]。
2. The maximum packet size should be calculated as follows:
2. 最大数据包大小的计算如下：
a. If the path MTU is unknown, the maximum packet size MUST be 1500 octets.
a. 如果路径MTU未知，则最大数据包大小必须为1500个八位字节。
b. If the path MTU is known, the maximum packet size MUST NOT exceed the path MTU and MUST NOT exceed 4000 octets.
b. 如果路径MTU已知，则最大数据包大小不得超过路径MTU，且不得超过4000个八位字节。
3. If a request is less than or equal to the maximum packet size, send it uncompressed.
3. 如果请求小于或等于最大数据包大小，请将其解压缩发送。
4. If a request can be compressed to a size less than or equal to the maximum packet size, send the request using compression. Otherwise, use another transfer protocol. In cases where another transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED.
4. 如果可以将请求压缩到小于或等于最大数据包大小的大小，请使用压缩发送请求。否则，请使用其他传输协议。如果需要另一种传输协议，建议使用IRIS-XPC[9]。
5. If a request yields a size error, send the request with another transfer protocol. IRIS-XPC [9] is RECOMMENDED.
5. 如果请求产生大小错误，请使用其他传输协议发送请求。建议使用IRIS-XPC[9]。
For retransmission of requests considered to be unanswered, a client SHOULD retransmit using a timeout value initially set to 1 second. This timeout value SHOULD be doubled for every retransmission, and a client SHOULD NOT retransmit any request once the timeout value has reached 60 seconds.
对于被认为未响应的请求的重新传输，客户端应使用初始设置为1秒的超时值重新传输。每次重新传输时，此超时值应加倍，并且一旦超时值达到60秒，客户端不应重新传输任何请求。
Clients that use timeout values other than the recommendations above MUST allocate or have allocated dedicated network resources that will ensure fairness to other network packets and avoid network congestion.
使用上述建议以外的超时值的客户端必须分配或已分配专用网络资源，以确保对其他网络数据包的公平性并避免网络拥塞。
Clients MUST NOT have more than one outstanding request (i.e., an unanswered request that has not timed out) at a time unless they allocate or have been allocated dedicated network bandwidth and resources reserved specifically for this purpose.
客户端一次不得有多个未完成的请求（即未响应的请求未超时），除非它们分配或已分配专门为此目的保留的专用网络带宽和资源。
Finally, if a client intends multiple requests to the same server in a short amount of time, this protocol offers no real advantage over IRIS-XPC [9]. In such a case, IRIS-XPC is RECOMMENDED to be used as it would be similarly or more efficient and would offer greater response sizes and allow better security.
最后，如果客户机希望在短时间内向同一台服务器发送多个请求，那么该协议与IRIS-XPC相比没有真正的优势[9]。在这种情况下，建议使用IRIS-XPC，因为它将具有类似或更高的效率，并将提供更大的响应大小和更好的安全性。
XML processors are obliged to recognize both UTF-8 and UTF-16 [2] encodings. Use of the XML defined by [8] MUST NOT use any other character encodings other than UTF-8 or UTF-16.
XML处理器必须同时识别UTF-8和UTF-16[2]编码。使用[8]定义的XML不得使用UTF-8或UTF-16以外的任何其他字符编码。
This section lists the definitions required by IRIS [3] for transport mappings.
本节列出了IRIS[3]对传输映射所需的定义。
See Section 7.1.1.
见第7.1.1节。
See Section 7.1.3.
见第7.1.3节。
URL scheme name: iris.lwz
URL方案名称：iris.lwz
Status: permanent
地位：永久
URL scheme syntax: defined in [3].
URL方案语法：在[3]中定义。
Character encoding considerations: as defined in RFC 3986 [5].
字符编码注意事项：如RFC 3986[5]中所定义。
Intended usage: identifies an IRIS entity made available using XML over UDP
预期用途：标识通过UDP使用XML提供的IRIS实体
Applications using this scheme: defined in IRIS [3].
使用此方案的应用程序：在IRIS[3]中定义。
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 8.
安全注意事项：定义见第8节。
Relevant Publications: IRIS [3].
相关出版物：IRIS[3]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
Protocol Number: UDP
协议编号：UDP
UDP Port Number: 715
UDP端口号：715
Message Formats, Types, Opcodes, and Sequences: defined in Sections 3 and 3.1.
消息格式、类型、操作码和序列：在第3节和第3.1节中定义。
Functions: defined in IRIS [3].
功能：在IRIS[3]中定义。
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: IRIS-LWZ
拟议名称：IRIS-LWZ
Short name: iris.lwz
简称：iris.lwz
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Application Protocol Label (see [4]): iris.lwz
应用程序协议标签（见[4]）：iris.lwz
Intended usage: identifies an IRIS server using XML over UDP
预期用途：通过UDP使用XML标识IRIS服务器
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 8.
安全注意事项：定义见第8节。
Relevant Publications: IRIS [3].
相关出版物：IRIS[3]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
IRIS-LWZ is intended for serving public data; it provides no in-band mechanisms for authentication or confidentiality. Any application with these needs must provide out-of-band mechanisms (e.g., IPsec), or use the IRIS transfer protocols that provide such capabilities, such as IRIS-XPC [9].
IRIS-LWZ旨在为公共数据服务；它不提供带内认证或保密机制。具有这些需求的任何应用程序都必须提供带外机制（如IPsec），或使用提供此类功能的IRIS传输协议，如IRIS-XPC[9]。
Due to this lack of security, it is possible for an attacker to alter IRIS-LWZ messages sent from the client to the server and from the server to the client. Such an attack can result in denying usage of an IRIS service or in supplying false information to end users and many other scenarios.
由于缺乏安全性，攻击者可能会更改从客户端发送到服务器以及从服务器发送到客户端的IRIS-LWZ消息。此类攻击可导致拒绝使用IRIS服务或向最终用户提供虚假信息以及许多其他情况。
Because IRIS-LWZ is a UDP-based protocol, it is possible for servers using IRIS-LWZ to be used in a type of distributed denial-of-service attack known as a reflection attack. This type of attack affects other types of UDP-using protocols, such as DNS. Server operators should be prepared to apply the same methods used for mitigating reflection attacks with other protocols, such as DNS, when using IRIS-LWZ. All operators should follow the advice given in BCP 38 [7].
由于IRIS-LWZ是一种基于UDP的协议，因此使用IRIS-LWZ的服务器有可能被用于一种称为反射攻击的分布式拒绝服务攻击。这种类型的攻击会影响使用协议的其他类型的UDP，例如DNS。当使用IRIS-LWZ时，服务器运营商应准备使用与其他协议（如DNS）相同的方法来缓解反射攻击。所有操作员应遵循BCP 38[7]中给出的建议。
IRIS-LWZ uses transaction IDs in the payload descriptors to better enable a client to match a response to a request. By randomizing the transaction IDs being used (i.e., not using sequential numbers), attackers flooding the network with a large amount of spoofed packets have a lesser chance of succeeding with the attack. This measure is not guaranteed to thwart any such attack. Client implementers MUST take appropriate measures when ignoring this advice.
IRIS-LWZ在有效负载描述符中使用事务ID，以更好地使客户端能够匹配请求的响应。通过将正在使用的事务ID随机化（即，不使用序列号），攻击者用大量伪造数据包充斥网络，从而降低了攻击成功的几率。这项措施不能保证阻止任何此类攻击。当忽略此建议时，客户端实现者必须采取适当的措施。
[1] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[1] Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[2] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[2] Unicode联盟，“Unicode标准，第3版”，ISBN 0-201-61633-52000，<Unicode标准，第3版>。
[3] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[3] Newton，A.和M.Sanz，“IRIS：互联网注册信息服务（IRIS）核心协议”，RFC 3981，2005年1月。
[4] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[4] Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[8] Newton, A., "A Common Schema for Internet Registry Information Service Transfer Protocols", RFC 4991, August 2007.
[8] Newton，A.，“Internet注册表信息服务传输协议的通用模式”，RFC 4991，2007年8月。
[9] Newton, A., "XML Pipelining with Chunks for the Internet Registry Information Service", RFC 4992, August 2007.
[9] Newton，A.，“Internet注册表信息服务的XML块流水线”，RFC 4992，2007年8月。
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[10] Kirkpatrick，S.，Stahl，M.和M.Recker，“互联网号码”，RFC1166，1990年7月。
This section gives examples of IRIS-LWZ exchanges. Lines beginning with "C:" denote data sent by the client to the server, and lines beginning with "S:" denote data sent by the server to the client. Following the "C:" or "S:", the line contains either octet values in hexadecimal notation with comments or XML fragments. No line contains both octet values with comments and XML fragments. Comments are contained within parentheses.
本节给出了IRIS-LWZ交换的示例。以“C:”开头的行表示客户机发送到服务器的数据，以“S:”开头的行表示服务器发送到客户机的数据。在“C:”或“S:”之后，该行包含十六进制注释的八位字节值或XML片段。没有一行同时包含带注释的八位字节值和XML片段。注释包含在括号内。
The following example demonstrates an IRIS client requesting a lookup of 'AUP' in the 'local' entity class of a 'dreg1' registry. The client passes a bag (see [3]) with the search request. The server responds with a 'nameNotFound' response and an explanation.
下面的示例演示了一个IRIS客户端请求在“dreg1”注册表的“本地”实体类中查找“AUP”。客户通过搜索请求传递一个包（参见[3]）。服务器以“nameNotFound”响应和解释进行响应。
C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9)
C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C: <searchSet>
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: <salt>127.0.0.1:3434</salt>
C: <md5>4LnQ1KdCahzyvwBqJis5rw==</md5>
C: </simpleBag>
C: </bag>
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C: </searchSet>
C: </request>
C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9)
C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C: <searchSet>
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: <salt>127.0.0.1:3434</salt>
C: <md5>4LnQ1KdCahzyvwBqJis5rw==</md5>
C: </simpleBag>
C: </bag>
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer></iris:answer>
S: <iris:nameNotFound><iris:explanation language="en-US">
S: The name 'AUP' is not found in 'local'.</iris:explanation>
S: </iris:nameNotFound></iris:resultSet></iris:response>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer></iris:answer>
S: <iris:nameNotFound><iris:explanation language="en-US">
S: The name 'AUP' is not found in 'local'.</iris:explanation>
S: </iris:nameNotFound></iris:resultSet></iris:response>
Example 1
例1
The following example demonstrates an IRIS client requesting domain availability information for 'milo.example.com'. The server responds that the domain is assigned and active.
下面的示例演示了一个IRIS客户端，该客户端请求“milo.example.com”的域可用性信息。服务器响应域已分配并处于活动状态。
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x0B 0xE7 (transaction ID=3047)
C: 0x0F 0xA0 (maximum response size=4000)
C: 0x0B (authority length=11)
C: (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C: <searchSet>
C: <lookupEntity
C: registryType="urn:ietf:params:xml:ns:dchk1"
C: entityClass="domain-name"
C: entityName="milo.example.com" />
C: </searchSet>
C: </request>
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x0B 0xE7 (transaction ID=3047)
C: 0x0F 0xA0 (maximum response size=4000)
C: 0x0B (authority length=11)
C: (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C: <searchSet>
C: <lookupEntity
C: registryType="urn:ietf:params:xml:ns:dchk1"
C: entityClass="domain-name"
C: entityName="milo.example.com" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x0B 0xE7 (transaction ID=3047)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer><domain
S: authority="example.com" registryType="dchk1"
S: entityClass="domain-name" entityName="tcs-com-1"
S: temporaryReference="true"
S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
S: milo.example.com</domainName><status><assignedAndActive/>
S: </status></domain></iris:answer>
S: </iris:resultSet></iris:response>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x0B 0xE7 (transaction ID=3047)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer><domain
S: authority="example.com" registryType="dchk1"
S: entityClass="domain-name" entityName="tcs-com-1"
S: temporaryReference="true"
S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
S: milo.example.com</domainName><status><assignedAndActive/>
S: </status></domain></iris:answer>
S: </iris:resultSet></iris:response>
Example 2
例2
The following example demonstrates an IRIS client requesting domain availability information for felix.example.net, hobbes.example.net, and daffy.example.net. The client does not support responses compressed with DEFLATE, and the maximum UDP packet it can safely receive is 498 octets. The server responds with size information indicating that it would take 1211 octets to provide an answer.
下面的示例演示了一个IRIS客户端，该客户端请求felix.example.net、hobbes.example.net和daffy.example.net的域可用性信息。客户端不支持使用DEFLATE压缩的响应，它可以安全接收的最大UDP数据包为498个八位字节。服务器用大小信息响应，表明需要1211个八位字节才能提供答案。
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x7E 0x8A (transaction ID=32394)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris1.xsd">
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="felix.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="hobbes.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="daffy.example.net" />
C: </searchSet>
C: </request>
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x7E 0x8A (transaction ID=32394)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris1.xsd">
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="felix.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="hobbes.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="daffy.example.net" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si)
S: 0x7E 0x8A (transaction ID=32394)
S: (Size Information XML response)
S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <octets>1211</octets>
S: </responseSize>
S: (response packet)
S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si)
S: 0x7E 0x8A (transaction ID=32394)
S: (Size Information XML response)
S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <octets>1211</octets>
S: </responseSize>
Example 3
例3
The following example illustrates an IRIS client requesting the version information from a server, and the server returning the version information.
以下示例说明了IRIS客户端从服务器请求版本信息，服务器返回版本信息。
C: (request packet)
C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi)
C: 0x2E 0x9C (transaction ID=11932)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
C: (request packet)
C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi)
C: 0x2E 0x9C (transaction ID=11932)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
S: (response packet)
S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi)
S: 0x2E 0x9C (transaction ID=11932)
S: (Version Information XML response)
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.lwz1">
S: <application protocolId="urn:ietf:params:xml:ns:iris1">
S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S: </application>
S: </transferProtocol>
S: </versions>
S: (response packet)
S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi)
S: 0x2E 0x9C (transaction ID=11932)
S: (Version Information XML response)
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.lwz1">
S: <application protocolId="urn:ietf:params:xml:ns:iris1">
S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S: </application>
S: </transferProtocol>
S: </versions>
Example 4
例4
Substantive contributions to this document have been provided by the members of the IETF's CRISP Working Group, especially Milena Caires and David Blacka.
IETF CRISP工作组成员，特别是Milena Caires和David Black，对本文件做出了实质性贡献。
Author's Address
作者地址
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew L.Newton VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345，邮编20166
Phone: +1 703 948 3382
EMail: andy@hxr.us
URI: http://www.verisignlabs.com/
Phone: +1 703 948 3382
EMail: andy@hxr.us
URI: http://www.verisignlabs.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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编辑功能的资金目前由互联网协会提供。