rfc2653.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          J. Allen
Request for Comments: 2653                         WebTV Networks, Inc.
Category: Standards Track                                      P. Leach
                                                              Microsoft
                                                             R. Hedberg
                                                              Catalogix
                                                            August 1999


                        CIP Transport 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 Internet Society (1999).  All Rights Reserved.

Abstract

   This document specifies three protocols for transporting CIP
   requests, responses and index objects, utilizing TCP, mail, and HTTP.
   The objects themselves are defined in [CIP-MIME] and the overall CIP
   architecture is defined in [CIP-ARCH].

1.   Protocol

   In this section, the actual protocol for transmitting CIP index
   objects and maintaining the mesh is presented. While companion
   documents ([CIP-ARCH] and [CIP-MIME]) describe the concepts involved
   and the formats of the CIP MIME objects, this document is the
   authoritative definition of the message formats and transfer
   mechanisms of CIP used over TCP, HTTP and mail.

1.1  Philosophy

   The philosophy of the CIP protocol design is one of building-block
   design. Instead of relying on bulky protocol definition tools, or
   ad-hoc text encodings, CIP draws on existing, well understood
   Internet technologies like MIME, RFC-822, Whois++, FTP, and SMTP.
   Hopefully this will serve to ease implementation and consensus





Allen, et al.               Standards Track                     [Page 1]

RFC 2653                CIP Transport Protocols              August 1999


   building. It should also stand as an example of a simple way to
   leverage existing Internet technologies to easily implement new
   application-level services.

1.2  Conventions

   The key words "MUST" and "MAY" in this document are to be interpreted
   as described in "Key words for use in RFCs to Indicate Requirement
   Levels" [KEYWORDS].

   Formal syntax is defined using ABNF [ABNF].

   In examples octets sent by the sender-CIP are preceded by ">>> " and
   those sent by the receiver-CIP by "<<< ".

2  MIME message exchange mechanisms

   CIP relies on interchange of standard MIME messages for all requests
   and replies. These messages are passed over a bidirectional, reliable
   transport system. This document defines transport over reliable
   network streams (via TCP), via HTTP, and via the Internet mail
   infrastructure.

   The CIP server which initiates the connection (conventionally
   referred to as a client) will be referred to below as the sender-CIP.
   The CIP server which accepts a sender-CIP's incoming connection and
   responds to the sender-CIP's requests is called a receiver-CIP.

2.1  The Stream Transport

   CIP messages are transmitted over bi-directional TCP connections via
   a simple text protocol. The transaction can take place over any TCP
   port, as specified by the mesh configuration. There is no "well known
   port" for CIP transactions. All configuration information in the
   system must include both a hostname and a port.

   All sender-CIP actions (including requests, connection initiation,
   and connection finalization) are acknowledged by the receiver-CIP
   with a response code. See section 2.1.1 for the format of these
   codes, a list of the responses a CIP server may generate, and the
   expected sender-CIP action for each.

   In order to maintain backwards compatibility with existing Whois++
   servers, CIPv3 sender-CIPs MUST first verify that the newer protocol
   is supported. They do this by sending the following illegal Whois++
   system command: "# CIP-Version: 3<cr><lf>". On existing Whois++
   servers implementing version 1 and 2 of CIP, this results in a 500-
   series response code, and the server terminates the connection.  If



Allen, et al.               Standards Track                     [Page 2]

RFC 2653                CIP Transport Protocols              August 1999


   the server implements CIPv3, it MUST instead respond with response
   code 300. Future versions of CIP can be correctly negotiated using
   this technique with a different string (i.e. "CIP-Version: 4"). An
   example of this short interchange is given below.

   Note: If a sender-CIP can safely assume that the server implements
   CIPv3, it may choose to send the "# CIP-Version: 3" string and
   immediately follow it with the CIPv3 request. This optimization,
   useful only in known homogeneous CIPv3 meshes, avoids waiting for the
   roundtrip inherent in the negotiation.

   Once a sender-CIP has successfully verified that the server supports
   CIPv3 requests, it can send the request, formatted as a MIME message
   with Mime-Version and Content-Type headers (only), using the network
   standard line ending: "<cr><lf>".

   Cip-Req        = Req-Hdrs CRLF Req-Body

   Req-Hdrs       = *( Version-Hdr | Req-Cntnt-Hdr )
   Req-Body       = Body     ; format of request body as in [CIP-MIME]

   Body           = Data CRLF "." CRLF
   Data           =          ; data with CRLF "." CRLF replaced by
                             ; CRLF ".." CRLF

   Version-Hdr    = "Mime-Version:" "1.0" CRLF
   Req-Cntnt-Hdr  = "Content-Type:" Req-Content CRLF
   Req-Content    =          ; format is specified in [CIP-MIME]

   Cip-Rsp        = Rsp-Code CRLF [ Rsp-Hdrs CRLF Rsp-Body ]
                     [ Indx-Cntnt-Hdr CRLF Index-Body ]
   Rsp-Code       = DIGIT DIGIT DIGIT Comment
   Comment        =          ; any chars except CR and LF
   Rsp-Hdrs       = *( Version-Hdr | Rsp-Cntnt-Hdr )
   Rsp-Cntnt-Hdr  = "Content-Type:" Rsp-Content CRLF
   Rsp-Content    =          ; format is specified in [CIP-MIME]
   Rsp-Body       = Body     ; format of response body as in [CIP-MIME]

   Indx-Cntnt-Hdr = "Content-Type:" Indx-Obj-Type CRLF
   Indx-Obj-Type  =          ; any registered index object's MIME-type
                             ; the format is specified in [RFC2045]
   Index-Body     = Body     ; format defined in each index
                             ; specifications

   CRLF           =  CR LF   ; Internet standard newline
   CR             =  %x0D    ; carriage return
   LF             =  %x0A    ; linefeed
   DIGIT          =  %x30-39



Allen, et al.               Standards Track                     [Page 3]

RFC 2653                CIP Transport Protocols              August 1999


   The message is terminated using SMTP-style message termination. The
   data is sent octet-for-octet, except when the pattern
   <cr><lf>1*["."]<cr><lf> is seen, in which case one more period is
   added.

   When the data is finished, the octet pattern "<cr><lf>.<cr><lf>" is
   transmitted to the receiver-CIP.

   On the receiver-CIP's side, the reverse transformation is applied,
   and the message read consists of all bytes up to, but not including,
   the terminating pattern.

   In response to the request, the receiver-CIP sends a response code,
   from either the 200, 400, or 500 series. The receiver-CIP then
   processes the request and replies, if necessary, with a MIME message.
   This reply is also delimited by an SMTP-style message terminator.

   After responding with a response code, the receiver-CIP MUST prepare
   to read another request message, resetting state to the point when
   the sender-CIP has just verified the CIP version. If the sender-CIP
   is finished making requests, it may close the connection. In response
   the receiver-CIP MUST abort reading the message and prepare for a new
   sender-CIP connection (resetting its state completely).

   An example is given below. It is again worth reiterating that the
   command format is defined in [CIP-MIME] whereas the message body is
   defined in each index object definition. In this example the index
   object definition in [CIP-TIO] will be used. Line endings are
   explicitly shown in anglebrackets; newlines in this text are added
   only for readability. Comments occur in curly-brackets.

      { sender-CIP connects to receiver-CIP }
   <<< % 220 Example CIP server ready<cr><lf>
   >>> # CIP-Version: 3<cr><lf>
   <<< % 300 CIPv3 OK!<cr><lf>
   >>> Mime-Version: 1.0<cr><lf>
   >>> Content-type: application/index.cmd.datachanged; type=
   >>> x-tagged-index-1; dsi=1.2.752.17.5.10<cr><lf>
   >>> <cr><lf>
   >>> updatetype: incremental tagbased<cr><lf>
   >>> thisupdate: 855938804<cr><lf>
   >>> lastupdate: 855940000<cr><lf>
   >>> .<cr><lf>
   <<< % 200 Good MIME message received
   >>> MIME-Version: 1.0<cr><lf>
   >>> Content-Type: application/index.obj.tagged;
   >>> dsi=1.2.752.17.5.10;
   >>> base-uri="ldap://ldap.umu.se/dc=umu,dc=se"<cr><lf>



Allen, et al.               Standards Track                     [Page 4]

RFC 2653                CIP Transport Protocols              August 1999


   >>> <cr><lf>
   >>> version: x-tagged-index-1<cr><lf>
   >>> updatetype: incremental<cr><lf>
   >>> lastupdate: 855940000<cr><lf>
   >>> thisupdate: 855938804<cr><lf>
   >>> BEGIN IO-schema<cr><lf>
   >>> cn: TOKEN<cr><lf>
   >>> sn: FULL<cr><lf>
   >>> title: FULL<cr><lf>
   >>> END IO-Schema<cr><lf>
   >>> BEGIN Update Block<cr><lf>
   >>> BEGIN Old<cr><lf>
   >>> title: 3/testpilot<cr><lf>
   >>> END Old<cr><lf>
   >>> BEGIN New<cr><lf>
   >>> title: 3/chiefpilot<cr><lf>
   >>> END New<cr><lf>
   >>> END Update Block<cr><lf>
   >>> .<cr><lf>
   <<< % 200 Good MIME message received
      { Sender-CIP shuts down socket for writing }
   <<< % 222 Connection closing in response to sender-CIP shutdown
      { receiver-CIP closes its side, resets, and awaits a
        new sender-CIP }

   An example of an unsuccessful version negotiation looks like this:

      { sender-CIP connects to receiver-CIP }
   <<< % 220 Whois++ server ready<cr><lf>
   >>> # CIP-Version: 3<cr><lf>
   <<< % 500 Syntax error<cr><lf>
      { server closes connection }

   The sender-CIP may attempt to retry using version 1 or 2 protocol.
   Sender-CIP may cache results of this unsuccessful negotiation to
   avoid later attempts.

2.1.1     Transport specific response codes

   The following response codes are used with the stream transport:

   Code  Suggested description     Sender-CIP action
         text

   200   MIME request received     Expect no output, continue session
         and processed             (or close)





Allen, et al.               Standards Track                     [Page 5]

RFC 2653                CIP Transport Protocols              August 1999


   201   MIME request received     Read a response, delimited by SMTP-
         and processed, output     style message delimiter.
         follows

   220   Initial server banner     Continue with Whois++ interaction,
         message                   or attempt CIP version negotiation.

   222   Connection closing (in    Done with transaction.
         response to sender-CIP
         close)

   300   Requested CIP version     Continue with CIP transaction, in
         accepted                  the specified version.

   400   Temporarily unable to     Retry at a later time. May be used
         process request           to indicate that the server does not
                                   currently have the resources
                                   available to accept an index.

   500   Bad MIME message format   Retry with correctly formatted MIME

   501   Unknown or missing        Retry with correct CIP command
         request in
         application/index.cmd