A Common Schema for Internet Registry Information Service Transfer Protocols
RFC 4991
Document | Type | RFC - Proposed Standard (August 2007; Errata) | |
---|---|---|---|
Author | Andrew Newton | ||
Last updated | 2020-01-21 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4991 (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: 4991 VeriSign, Inc. Category: Standards Track August 2007 A Common Schema for Internet Registry Information Service Transfer Protocols 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 an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 2 3. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 3 4. Version Information . . . . . . . . . . . . . . . . . . . . . 6 5. Size Information . . . . . . . . . . . . . . . . . . . . . . . 7 6. Authentication Success Information . . . . . . . . . . . . . . 8 7. Authentication Failure Information . . . . . . . . . . . . . . 8 8. Other Information . . . . . . . . . . . . . . . . . . . . . . 9 9. Internationalization Considerations . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. XML Namespace URN Registration . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 Newton Standards Track [Page 1] RFC 4991 Common Schema for IRIS Transfer Protocols August 2007 1. Introduction IRIS [8] has two transfer protocols, LWZ (lightweight using compression) [9] and XPC (XML pipelining with chunks) [10], that share common negotiation mechanisms. Both transfer protocols have a need for the server to provide rich status information to clients during protocol negotiation. In many cases, this status information would be too complex to describe using simple bit fields and length- specified octet sequences. This document defines an XML Schema for this rich status information and describes the usage of conformant XML for conveying this status information. This document defines five types of information used in the negotiation of protocol capabilities: version, size, authentication success, authentication failure, and other information. The version information is used to negotiate the versions and extensions to the transfer protocol, the application operations protocol, and data models used by the application operations. Size information is used to indicate request and response size capabilities and errors. Authentication success and failure information is used to indicate the outcome of an authentication action. Other types of information may also be conveyed that is generally a result of an error but cannot be corrected through defined protocol behavior. As an example, upon initiation of a connection, a server may send version information informing the client of the data models supported by the server and the security mechanisms supported by the server. The client may then respond appropriately. For example, the client may not recognize any of the data models supported by the server, and therefore close the connection. On the other hand, the client may recognize the data models and the security mechanisms and begin the procedure to initialize a security mechanism with the server before proceeding to query data according to a recognized data model. Both LWZ [9] and XPC [10] provide examples of the usage of the XML Schema defined in this document. 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]. Newton Standards Track [Page 2] RFC 4991 Common Schema for IRIS Transfer Protocols August 2007 3. Formal XML Syntax The following is the XML Schema used to define transfer protocolShow full document text