A Common Schema for Internet Registry Information Service Transfer Protocols
RFC 4991

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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 protocol