A Common Schema for Internet Registry Information Service Transfer Protocols
RFC 4991
|
| Document |
Type |
|
RFC - Proposed Standard
(August 2007; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4991 (Proposed Standard)
|
|
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
Show full document text