rfc2652.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/3 页

      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 body of a DataChanged command is formatted as a simple set of
   attribute value pairs following the rules of RFC822. The actual
   attributes and values allowed are defined by the index type
   specification.

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

   Example:

   [begin MIME]
   Content-type: application/index.cmd.datachanged;
           type="simple"; dsi= "1.3.5.7.9"<linebreak>

   Time-of-latest-change: Fri May 30 14:25:30 EDT 1997<linebreak>
   Time-of-message-generation: Fri May 30 14:25:30 EDT 1997<linebreak>
   Host-Name: cip.rwhois.net<linebreak>
   Host-Port: 4322<linebreak>
   Protocol: RWhois2.0<linebreak>
   [end MIME]







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


2.3.4 Additional Requests

   The requests specified above are those required to implement a simple
   mesh. It is expected that other requests will be developed to handle
   issues of mesh-management and statistics gathering requests. At this
   point this is an area of additional work. Specifically more work is
   needed in the area of mesh management as meshes will tend to be
   organized around the characteristics of their index type.

2.4. Index Object format

   In reply to the "poll" command, a server may choose to send one or
   more index objects. Regardless of the number of index objects
   returned, the response must take the form of a MIME multipart/mixed
   message. Each part must itself be a MIME object of type
   "application/index.obj._type_". The definition for this type follows:

      MIME type name:          application
      MIME subtype name:       index.obj._type_
      Required parameters:     dsi, base-uri
      Optional parameters:     none
      Security considerations: (See Section 4)

      As previously described, each index object is of a particular
      type.  This type is specified in the MIME subtype name since some
      types may have a different syntax.

      The required parameters are to be used as follows:

      DSI:       The DSI is a string which globally uniquely identifies
                 the dataset from which the index was created.

      base-URI:  One or more URI's will form the base of any referrals
                 created based upon this index object.

3. Index Type Definition Requirements

   Because of the need for application domain specific indices, CIP
   index objects are abstract; they must be defined by a separate
   specification. The basic protocols for moving index objects are
   widely applicable, but the specific design of the index, and the
   structure of the mesh of servers which pass a particular type of
   index is dependent on the application domain. While companion
   documents will describe index objects, there is a set of base
   requirements and questions those documents must address. This is to
   ensure that the base assumptions that the CIP protocol makes about
   its indexes are actually expressible within the index.




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


   Since each type is a MIME type all its own, registration of new types
   follows the standard registration policies specified in RFC2048.

3.1 Type specific requests

   Any index type definition must address the type specific bodies of
   the Poll and DataChanged requests. All parameters included in the
   body must be specified.

3.2 The index.obj parameters

3.2.1 Type

   See the above definitions for allowed values for type.

   A new name must be assigned when any changes to the document
   describing the index object type are not completely backwards
   compatible.

3.2.2 DSI

   Another attribute is the "DSI", or Dataset Identifier, which uniquely
   identifies the dataset from which the index was created. The index
   specification should define the policies for how the DSI is
   generated. This includes the concept of what a data-set means for the
   given index.

3.2.3. Base-URI

   An attribute of the index object which is crucial for generating
   referrals is the "Base-URI". The URI (or URI's) contained in this
   attribute form the basis of any referrals generated based on this
   index block. The URI is also used as input during the index
   aggregation process to constrain the possible types of aggregation.
   This use of the Base-URI is used to deal with meshes that support
   multiple protocols.

   Thus, an index specification should define how the Base-URI applies
   to the underlying index and how it is changed during the aggregation
   process.











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


3.3 Aggregation

   All index object specifications must address the issue of
   aggregation.  This is the method by which an index server takes two
   or more indexes and combines them into one index to be passed on. It
   is not required that a given index-type aggregate. If it does not it
   must explicitly address the reasons why and what affect that has on
   scalability.

   If a given index does aggregate, the algorithm for that aggregation
   must be given. It must also address how that algorithm affects mesh
   organization and scalability.

   Index object document authors should remember that any kind of
   aggregation should be performed without compromising the ability to
   correctly route queries while avoiding excessive numbers of missed
   results. The acceptable likelihood of false negatives must be
   established on a per-application-domain basis, and is controlled by
   the granularity of the index and the aggregation rules defined for it
   by the particular specification.

   Nothing in these documents specifically disallows aggregation rules
   that deal with different index object types. This type of
   heterogeneous mesh is difficult to formulate at best and thus is not
   covered by these documents. If document authors wish to attempt such
   a mesh they should be aware that it is considered an ill understood
   concept that contains many pitfalls for the mesh builder.

3.4 Referral Generation Semantics

   Since the method by which a client navigates the mesh is by
   referrals, the document must address how a given access protocol
   generates a referral from the index. Authors should pay particular
   attention to the case where an index is accessed by different
   protocols and the interaction between them. For example, an index
   that supports referrals being generated for both RWhois and LDAP must
   understand that one uses a Distinguished Name while the other
   doesn't. The impacts of these differences on the referral should be
   clear.

3.5 Matching Semantics

   In order to generate a referral the decision of whether or not to do
   so must be handled by the access protocol. The semantics surrounding
   this decision have a large impact on the efficiency of searches as
   well as the requirements on aggregation. Thus, index specification
   authors must be very clear about how a match is determined.




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


3.6 Security Considerations

   As is customary with Internet protocol documentation, a brief review
   of security implications of the proposed object must be included.
   This section may need to do little more than echo the considerations
   expressed in this document's Security Considerations section.

3.7 Optional Coverage

   Because indexing algorithms, stop-lists, and data reduction
   technologies are considered by some index object designers to be
   proprietary, it is not necessary to discuss the process used to
   derive indexing information from a body of source material. When
   proprietary indexing technologies are used in a public mesh, all CIP
   servers in the mesh should be able to parse the index object (and
   perform aggregation operations, if necessary), though not all of them
   need to be able to create these proprietary indices from source data.

   Thus, index object designers may choose to remain silent on the
   algorithms used for the generation of indices, as long as they
   adequately document how to participate in a mesh of servers passing
   these proprietary indices.

   Designers should also seriously consider including useful examples of
   source data, the generated index, and the expected results from
   example matches. When the aggregation algorithm is complex, it is
   recommended that a table showing two indices and the resultant
   aggregate index be included.

4. Security Considerations

   Security considerations come into play in at least the following two
   scenarios.  Indexing information can leak undesirable amounts of
   proprietary information, unless carefully controlled. At a more
   fundamental level, the CIP protocol itself requires external security
   services to operate in a safe manner. Both topics are covered below.

4.1 Secure Indexing

   CIP is designed to index all kinds of data. Some of this data might
   be considered valuable, proprietary, or even highly sensitive by the
   data maintainer. Take, for example, a human resources database.
   Certain bits of data, in moderation, can be very helpful for a
   company to make public. However, the database in its entirety is a
   very valuable asset, which the company must protect. Much experience
   has been gained in the directory service community over the years as
   to how best to walk this fine line between completely revealing the
   database and making useful pieces of it available.



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


   Another example where security becomes a problem is for a data
   publisher who would like to participate in a CIP mesh. The data that
   publisher creates and manages is the prime asset of the company.
   There is a financial incentive to participate in a CIP mesh, since
   exporting indices of the data will make it more likely that people
   will search your database. (Making profit off of the search activity
   is left as an exercise to the entrepreneur.) Once again, the index
   must be designed carefully to protect the database while providing a
   useful synopsis of the data.

   One of the basic premises of CIP is that data providers will be
   willing to provide indices of their data to peer indexing servers.
   Unless they are carefully constructed, these indices could constitute
   a threat to the security of the database. Thus, security of the data
   must be a prime consideration when developing a new index object
   type. The risk of reverse engineering a database based only on the
   index exported from it must be kept to a level consistent with the
   value of the data and the need for fine-grained indexing.

   Since CIP is encoded as MIME objects, MIME security solutions should
   be used whenever possible. Specifically when dealing with security
   between index servers.

4.2 Protocol Security

   CIP protocol exchanges, taking the form of MIME messages, can be
   secured using any technology available for securing MIME objects. In
   particular, use of RFC-1847's Security Multiparts are recommended.  A
   solid application of RFC-1847 using widely available encryption
   software is PGP/MIME, RFC-2016. Implementors are encouraged to
   support PGP/MIME, as it is the first viable application of the MIME
   Security Multiparts architecture. As other technologies become
   available, they may be incorporated into the CIP mesh.

   If an incoming request does not have a valid signature, it must be
   considered anonymous for the purposes of access control. Servers may
   choose to allow certain requests from anonymous peers, especially
   when the request cannot cause permanent damage to the local server.
   In particular, answering anonymous poll requests encourages index
   builders to poll a server, making the server's resources better
   known.

   The explicit security policy with respect to incoming requests is
   outside the scope of this specification. Implementors are free to
   accept or reject any request based on the security attributes of the
   incoming message. When a request is rejected due to authentication
   reasons, a response code from the 530 series must be issued.




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


Acknowledgments

   Thanks to the many helpful members of the FIND working group for
   discussions leading to this specification.

   Specific acknowledgment is given to Jeff Allen formerly of Bunyip
   Information Systems. His original version of these documents helped
   enormously in crystallizing the debate and consensus. Most of the
   actual text in this document was originally authored by Jeff.

Authors' Addresses

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

   EMail: [e-mail]


   Michael Mealling
   Network Solutions, Inc.
   505 Huntmar Park Drive
   Herndon, VA 22070

   Phone: [phone]
   EMail: [e-mail]

References

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

   [RFC2046]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types", RFC 2046,
                January 1996.

   [RFC2048]    Freed, N., Klensin, J. and J. Postel, "Multipurpose
                Internet Mail Extensions (MIME) Part Four: MIME
                Registration Procedures", RFC 2048, January 1996.

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

   [RFC821]     Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
                821, August 1992.






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


Appendix A: Media Type Registration Templates

   The following templates have been registered with the IANA:

Index tree

   To: [e-mail]
   Subject: Registration of MIME media type tree application/index

   MIME media type name: application

   MIME subtype name: index

   Required parameters: none

   Optional parameters: none

   Encoding considerations: none

   Security considerations:

      Security considerations come into play in at least the following
      two scenarios.  Indexing information can leak undesirable amounts
      of proprietary information, unless carefully controlled. At a more
      fundamental level, the CIP protocol itself requires external
      security services to operate in a safe manner. Both topics are
      covered below.

   Interoperability considerations:

   Published specification:

      RFC 2652