A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
RFC 4993
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
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.
Copyright Notice
Copyright (C) The IETF Trust (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.
Newton Standards Track [Page 1]
RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
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
Newton Standards Track [Page 2]
RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
1. Introduction
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.
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.
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.
2. Document Terminology
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].
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
Show full document text