rfc2652.txt

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

Network Working Group                                          J. Allen
Request for Comments: 2652                         WebTV Networks, Inc.
Category: Standards Track                                   M. Mealling
                                                Network Solutions, Inc.
                                                            August 1999


     MIME Object Definitions for the Common Indexing Protocol (CIP)

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

   The Common Indexing Protocol (CIP) is used to pass indexing
   information from server to server in order to facilitate query
   routing. The protocol is comprised of several MIME objects being
   passed from server to server. This document describes the definitions
   of those objects as well as the methods and requirements needed to
   define a new index type.

1. Introduction

   The Common Indexing Protocol (CIP) is used to pass indexes between
   servers that combine multiple indexes and/or route queries based on
   those indexes. The overall framework for the protocol is specified in
   the CIP Framework document [FRAMEWORK]. This document should be read
   within the context of that document as there are fundamental concepts
   contained in the framework that are not fully explained here.

   Since there are several different ways to index a given database
   there will be multiple types of indexes to pass.  These indexes may
   have different transport requirements, different ways of specifying
   parameters, and different referral rules. These different
   requirements are handled by encapsulating the indexes within MIME
   wrappers in order to have a standardized way to specify those
   different parameters.





Allen & Mealling            Standards Track                     [Page 1]

RFC 2652               MIME Definitions for CIP              August 1999


   Appendix A contains the actual MIME [RFC2046] registration templates
   sent to the IANA for registration [RFC2048].

   This document uses language like SHOULD and SHALL that have special
   meaning as specified in "Key words for use in RFCs to Indicate
   Requirement Levels" [RFC2119].

2.0 CIP Transactions

   Messages passed by CIP implementations over reliable transport
   mechanisms fall into three categories: requests, responses and
   results. All requests result in either a response or a result. A
   result sent in response to a request must be interpreted as a
   successful operation.

   Requests, responses and results are formatted as MIME [RFC2046]
   messages. The specific MIME types involved are defined below.

   As with all MIME objects, CIP messages may be wrapped in a security
   multipart package to provide authentication and privacy. The security
   policy with respect to all messages is implementation defined, when
   not explicitly discussed below. CIP implementors are strongly urged
   to allow server administrators maximum configurability to secure
   their servers against maliciously sent anonymous CIP messages. In
   general, operations which can permanently change the server's state
   in a harmful way should only take place upon receipt of a properly
   signed message from a trusted CIP peer or administrator. Implementors
   should provide appropriate auditing capabilities so that both
   successful and failed requests can be tracked by the server
   administrator.

   Since these MIME objects can and will be sent over several different
   protocols, body termination is specified by the transfer protocol.
   New protocols are encouraged to use SMTP [RFC821] style body
   termination.

   Finally, since MIME objects can specify their own encoding, the
   line-breaks contained within each body are defined by the encoding.
   Thus, instead of specifying them as carriage-return and/or linefeed,
   the identifier <linebreak> is used. Linebreaks in the headers and
   separating the body from the headers follow existing standards.










Allen & Mealling            Standards Track                     [Page 2]

RFC 2652               MIME Definitions for CIP              August 1999


2.1 Common syntactic definitions

   There are certain syntactic elements common to all of the CIP
   transactions. These include type, DSI and the Base-URI.

2.1.1 The "application/index" MIME type tree

   Due to requirements in RFC2048 concerning objects that have the same
   type but different syntaxes, CIP objects will use the
   application/index tree but include "facets" [RFC2048] which extend it
   as other types have done with respect to global elements and vendor
   specific enhancements. Thus the tree is divided up into the following
   branches:

      application/index.cmd._command_
      application/index.response
      application/index.obj._type_
      application/index.vnd._xxx_

      _command_ is a command as specified here. It contains commands and
      their arguments.

      _type_ identifies what type of CIP index object is contained
      within the body. It is unique among all other reserved types.
      Reserved types are those previously documented by other CIP index
      object specifications, according to standard IETF processes.

      _xxx_ is an identifier specified by a vendor for use by that
      vendor in operations specifically to do with indexes.

   All of the above identifiers follow the rules in RFC2048 for valid
   MIME types. In addition commands, responses and types are limited by
   this document to consist of from 1 to 20 characters from the set [a-
   zA-Z0-9-]; that is, all upper and lower case letters, all digits, and
   the ASCII minus character (decimal 45). Though type names may be
   specified case sensitively, they must be compared and otherwise
   processed case insensitively.

   Appendix A contains the registration template for the
   application/index tree.

2.1.2 DSI

   A dataset identifier is an identifier chosen from any part of the
   ISO/CCITT OID space. The DSI uniquely identifies a given dataset
   among all datasets indexed by CIP.





Allen & Mealling            Standards Track                     [Page 3]

RFC 2652               MIME Definitions for CIP              August 1999


   As currently defined, OID's are an unbounded sequence of unbounded
   integers. While this creates an infinite numbering space, it presents
   problems for implementors dealing with machines with finite
   resources. To ease implementation, this document specifies an ASCII
   encoding of the OID, and specifies limits which make implementation
   easier.

   For the purposes of interchange in CIP messages, an OID must conform
   to the following rules:

      dsi          = integer *( "." integer)
      integer      = all-digits / (one-to-nine *all-digits)
      one-to-nine  = "1" / "2" / "3" / "4" / "5" / "6" / "7" /
                     "8" / "9"
      all-digits   = "0" / one-to-nine

   Under no circumstances shall the total length of the resulting string
   exceed 255 characters. OID's which cannot, due to their length,
   conform to these rules must not be used as CIP dataset identifiers.

   An implementation must not attempt to parse the individual integers
   unless it is prepared to handle arbitrary-length integers. Treating
   the DSI as anything other than an opaque string of US-ASCII
   characters is not recommended.

   Two CIP DSI's are considered to match if both conform to the above
   rules and every number matches.

2.1.3. Base-URI

   CIP index objects carry base-URI's to facilitate referral generation
   based on the index object. The base-URI parameter carries a
   whitespace-delimited list of URL's. URL's are defined in RFC-1738.
   The exact rules are as follows:

      base-uri    = genericurl *( 1*whitespace genericurl )
      whitespace  = "<space>" (decimal 32) /
                    "<tab>"   (decimal 9)  /
                    "<cr>"    (decimal 13) /
                    "<lf>"    (decimal 10)
      genericurl = { as specified in RFC-1738, section 5 }

2.2 Response format

   All requests must be followed by a response code, except in the cases
   where a return path is unavailable.

   The definition for this MIME type is:



Allen & Mealling            Standards Track                     [Page 4]

RFC 2652               MIME Definitions for CIP              August 1999


      MIME type name:          application
      MIME subtype name:       index.response
      Required parameters:      code
      Optional parameters:     charset
      Security considerations: (See Section 4)

   The code parameter contains a 3 digit return code that denotes the
   status of the last command.

   The format of the body is such that the first line is interpreted as
   the comment corresponding to the code. As with most response codes
   this comment is intended for human consumption and may not exist and
   must not be depended on by the protocol. Subsequent lines in the body
   are reserved for each response to define.  In the case where the
   comment is not given the first must be an empty line.

      body = comment linebreak payload
      comment = { any text }
      linebreak = (decimal 13) (decimal 10)
      payload = { any text }

   The charset parameter has its normal MIME meaning. Below are several
   examples:

   [begin MIME]
   Content-type: application/index.response; code=220

   CIP Server v1.0 ready!<linebreak>
   [end MIME]

   [begin MIME]
   Content-type: application/index.response; code=500

   MIME formatting problem<linebreak>
   [end MIME]

   [begin MIME]
   Content-type: application/index.response; code=520

   <linebreak>
   [end MIME]

   While the responses described in this document do not utilize the
   rest of the lines in the body of a response implementors should take
   care to not disallow it in the future. A good example would be a
   message specifying that a poll request did not contain required
   attributes. This message might look like this:




Allen & Mealling            Standards Track                     [Page 5]

RFC 2652               MIME Definitions for CIP              August 1999


   [begin MIME]
   Content-type: application/index.response; code=502

   Request is missing required CIP attributes
   Missing-Attribute: attribute1
   Missing-Attribute: attribute2
   Missing-Attribute: attribute3
   [end MIME]

   The meaning of the various digits in the response codes is discussed
   in RFC-821, Appendix E.

   See Appendix B for a list of the valid response codes.

2.3 Command format

   A CIP command either initiates an index transfer, interrogates the
   state of the receiver-CIP (or the server's participation in the
   mesh), or changes the state of the server (or the server's place in
   the mesh).

   CIP commands are sent as a MIME message of type
   "application/index.cmd._command_". The definition for this MIME type
   tree follows:

      MIME type name:          application
      MIME subtype name:       index.cmd._command_
      Optional parameters:     type, dsi
      Security considerations: (See Section 4)

   The format of the body is defined by each command. A general
   attribute/value pair orientation is preserved throughout the
   following specified commands. Those developing future command should
   attempt to maintain that orientation but are not required to do so.

   In the following sections, the server's response for each possible
   value for "command" is defined. Note that the parameters listed as
   optional above are only optional with respect to the generic MIME
   form. The optional parameters are only optional with respect to MIME
   parsing. If one or more of the parameters needed to fulfill a command
   is missing, a response code of 502 is returned.

   Extra optional parameters which are unrecognized must be silently
   ignored.







Allen & Mealling            Standards Track                     [Page 6]

RFC 2652               MIME Definitions for CIP              August 1999


2.3.1 No-operation

      Command Name:        application/index.cmd.noop
      Required parameters: (none)

   A CIP command with the "command" parameter set to "noop" must be
   acknowledged with response type code 200 (command OK, no response
   forthcoming).

   This command must not require a signed MIME object. Implementations
   should accept commands which have been validly signed.

   Example:

   [begin MIME]
   Content-type: application/index.cmd.noop

   [end MIME]

   Note the lack of a body but how the <linebreak> pair is still
   preserved after the Content-type header.

2.3.2 Poll

      Request Name:        application/index.cmd.poll
      Required parameters: type, dsi

   The "poll" command is used by a poller to request the transfer of an
   index object. It requires the following parameters:

      type:      The index object type requested
      dsi:       The dataset which the index should cover

   If there are no index objects available for a given DSI, or the
   receiver-CIP does not support a given index object type, the
   receiver-CIP must respond with response code 200, (successful, no
   response forthcoming).  Otherwise, the response code must be 201
   (successful, response is forthcoming).

   The security policy for polling commands is wholly implementation
   defined. Implementations may be configured to accept or reject
   anonymous poll commands.

   Example:

   [begin MIME]
   Content-type: application/index.cmd.poll; type="simple";
           dsi= "1.3.5.7.9"



Allen & Mealling            Standards Track                     [Page 7]

RFC 2652               MIME Definitions for CIP              August 1999


   Template: contact name address phone<linebreak>
   Start-time: Fri May 30 14:25:30 EDT 1997<linebreak>
   End-time: Sat May 31 14:25:30 EDT 1997<linebreak>
   [end MIME]

2.3.3 DataChanged

      Request Name:        application/index.cmd.datachanged
      Required parameters: type, dsi

   The "datachanged" command is used by a pollee to notify a poller that
   the data within an index has changed. It requires the following
   parameters: