rfc2653.txt

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

   502   Request is missing        Retry with correct CIP attributes.
         required CIP attributes

   520   Aborting connection for   Alert local administrator.
         some unexpected reason

   530   Request requires valid    Sign the request, if possible, and
         signature                 retry. Otherwise, report problem to
                                   the administrator.

   531   Request has invalid       Report problem to the administrator.
         signature

   532   Cannot check signature    Alert local administrator, who should
                                   cooperate with remote administrator
                                   tp diagnose and resolve the problem.
                                   (Probably missing a public key.)









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


2.2  Internet mail infrastructure as transport

   As an alternative to TCP streams, CIP transactions can take place
   over the existing Internet mail infrastructure. There are two
   motivations for this feature of CIP. First, it lowers the barriers to
   entry for leaf servers. When the need for a full TCP implementation
   is relaxed, leaf nodes (which, by definition, only send index
   objects) can consist of as little as a database and an indexing
   program (possibly written in a very high level language) to
   participate in the mesh.

   Second, it keeps with the philosophy of making use of existing
   Internet technology. The MIME messages used for requests and
   responses are, by definition of the MIME specification, suitable for
   transport via the Internet mail infrastructure. With a few simple
   rules, we open up an entirely different way to interact with CIP
   servers which choose to implement this transport. See Protocol
   Conformance, below, for details on what options server implementers
   have about supporting the various transports.

   The basic rhythm of request/response is maintained when using the
   mail transport. The following sections clarify some special cases
   which need to be considered for mail transport of CIP objects. In
   general, all mail protocols and mail format specifications
   (especially MIME Security Multiparts) can be used with the CIP mail
   transport.

2.2.1     CIP-Version negotiation

   Since no information on which CIP-version is in use is present in the
   MIME message, this information has to be carried in the mailheader.
   Therefore CIP requests sent using the mail transport MUST include a
   CIP-version headerline, to be registered according to [MHREG].
   The format of this line is:

   DIGIT       =  %x30-39
   number      =  1*DIGIT
   cipversion  =  "CIP-Version:" <sp> number["." number]

2.2.2     Return path

   When CIP transactions take place over a bidirectional stream, the
   return path for errors and results is implicit. Using mail as a
   transport introduces difficulties to the recipient, because it's not
   always clear from the headers exactly where the reply should go,
   though in practice there are some heuristics used by MUA's.





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


   CIP solves this problem by fiat. CIP requests sent using the mail
   transport MUST include a Reply-To header as specified by RFC-822.
   Any mail received for processing by a CIP server implementing the
   mail transport without a Reply-To header MUST be ignored, and a
   message should be logged for the local administrator. The receiver
   MUST not attempt to reply with an error to any address derived from
   the incoming mail.

   If there are no circumstances under which a response is to be sent to
   a CIP request, the sender should include a Reply-To header with the
   address "<>" in it.  Receivers MUST never attempt to  send replies to
   that address, as it is defined to be invalid (both here, and by the
   BNF grammar in RFC-822). It should be noted that, in general, it is a
   bad idea to turn off error reporting in this way. However, in the
   simplest case of an index pushing program, this MAY be a desirable
   simplification.

2.3  HTTP transport

   HTTP MAY also be used to transport CIP objects, since they are just
   MIME objects. A transaction is performed by using the POST method to
   send an application/index.cmd and returning an
   application/index.response or an application/index.obj in the HTTP
   reply. The URL that is the target of the post is a configuration
   parameter of the CIP-sender to CIP-receiver relationship.

   Example:

      { the client opens the connection and sends a POST }
   >>> POST / HTTP/1.1<cr><lf>
   >>> Host: cip.some.corp<cr><lf>
   >>> Content-type: application/index.cmd.noop<cr><lf>
   >>> Date: Thu, 6 Jun 1997 18:16:03 GMT<cr><lf>
   >>> Content-Length: 2<cr><lf>
   >>> Connection: close<cr><lf>
   >>> <cr><lf>
      { the server processes the request }
   <<< HTTP/1.1 204 No Content<cr><lf>
      { the server closes the connection }

   In addition to leveraging the security capabilities that come with
   HTTP, there are other HTTP features that MAY be useful in a CIP
   context. A CIP client MAY use the Accept-Charset and Accept-Language
   HTTP headers to express a desire to retrieve an index in a particular
   character set or natural language. It MAY use the Accept-Encoding
   header to (e.g.) indicate that it can handle compressed responses,
   which the CIP server MAY send in conjunction with the Transfer-
   Encoding header. It MAY use the If-Modified-Since header to prevent



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


   wasted transmission of an index that has not changed since the last
   poll. A CIP server can use the Retry-After header to request that the
   client retry later when the server is less busy.

3.   Security Considerations

   There are two levels at which the index information can be protected;
   the first is by use of the technology available for securing MIME
   [MIME-SEC] objects, and secondly by using the technology available
   for securing the transport.

   When it comes to transport the stream transport can be protected by
   the use of TLS [TLS] . For HTTP the Security is handled by using HTTP
   Basic Authentication [RFC 2616], HTTP Message Digest Authentication
   [RFC2617] or SSL/TLS. Extra protection for the SMTP exchange can be
   achieve by the use of Secure SMTP over TLS [SMTPTLS].

4.   References

   [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC 2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A. and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [CIP-ARCH] Allen, J. and M. Mealling, "The Architecture of the Common
              Indexing Protocol (CIP)", RFC 2651, August 1999.

   [CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for
              the Common Indexing Protocol (CIP)", RFC 2652, August
              1999.

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [CIP-TIO]  Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A
              Tagged Index Object for use in the Common Indexing
              Protocol", RFC 2654, August 1999.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



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


   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, October 1995.

   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              TLS", RFC 2487, January 1999.

   [MHREG]    Jacob, P., "Mail and Netnews Header Registration
              Procedure", Work in Progress.

5.   Authors' Addresses

   Jeff R. Allen
   246 Hawthorne St.
   Palo Alto, CA  94301

   EMail: [e-mail]


   Paul J. Leach
   Microsoft
   1 Microsoft Way
   Redmond, WA 98052

   EMail: [e-mail]


   Roland Hedberg
   Catalogix
   Dalsveien 53
   0775 Oslo
   Norway

   EMail: [e-mail]














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


6.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Allen, et al.               Standards Track                    [Page 11]