XML Pipelining with Chunks for the Internet Registry Information Service
draft-ietf-crisp-iris-xpc-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    crisp mailing list <crisp@ietf.org>, 
    crisp chair <crisp-chairs@tools.ietf.org>
Subject: Protocol Action: 'XML Pipelining with Chunks for the 
         Information Registry Information Service' to Proposed Standard 

The IESG has approved the following document:

- 'XML Pipelining with Chunks for the Information Registry Information 
   Service '
   <draft-ietf-crisp-iris-xpc-07.txt> as a Proposed Standard

This document is the product of the Cross Registry Information Service 
Protocol Working Group. 

The IESG contact persons are Ted Hardie and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-xpc-07.txt

Ballot Text

Technical Summary
 
 This document describes a simple TCP transfer protocol for the
   Internet Registry Information Service (IRIS).  Data is transfered
   between clients and servers using chunks to achieve pipelining.
 
Working Group Summary
 
 There was consensus in the working group for publication of this
  document.  There were IETF Last Call comments and the document
  has been updated as a result.
 
Protocol Quality
 
  This document was reviewed for the IESG by Ted Hardie.  April Marine
  is the Shepherd.

Note to RFC Editor
 
 In Section 7:

OLD
7.  Idle Sessions

   An XPC session may become idle between request/response transactions.
   This can occur when a server honors a client's request to keep the
   TCP connection running (see the keep-open or KO flag in the block
   header (Section 5)).  Servers are not expected to allow XPC sessions
   remain idle between requests indefinitely.

   Clients MUST use the keep-alive feature of TCP to keep the connection
   active during idle periods.

   If a server has not received a request block after sending a response
   block (either RSB or CRB) and the TCP connection fails to keep-alive,
   it SHOULD do the following:

   1.  Send an unsolicited response block containing an idle timeout
       error (see 'idle-timeout' in Section 6.4) with the keep-open (or
       KO) flag in the block header (Section 5) set to a value of 0.

   2.  Close the TCP connection.


NEW 
7.  Idle Sessions

   If a server needs to close a connection due to it being idle,
   it SHOULD do the following:

   1.  Send an unsolicited response block containing an idle timeout
       error (see 'idle-timeout' in Section 6.4) with the keep-open (or
       KO) flag in the block header (Section 5) set to a value of 0.

   2.  Close the TCP connection.

The document also currently has the following normative reference:

[10]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
         RFC 1166, July 1990.

This reference is an informative reference to the origin of a format, and
is not needed to implement or understand the format.  Please create
an Informative references section, and move this reference there.

RFC Editor Note