A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
RFC 4993
Document | Type | RFC - Proposed Standard (August 2007; Errata) | |
---|---|---|---|
Author | Andrew Newton | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4993 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
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, theShow full document text