MIME Object Definitions for the Common Indexing Protocol (CIP)
RFC 2652

Document Type RFC - Proposed Standard (August 1999; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2652 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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

   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
Show full document text