GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc2652

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:
    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: jeff.allen@acm.org
 Michael Mealling
 Network Solutions, Inc.
 505 Huntmar Park Drive
 Herndon, VA 22070
 Phone: +1-703-742-0400
 EMail: michael.mealling@RWhois.net

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: ietf-types@iana.org
 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
 Applications which use this media type:
    This media type is used to contain information about indices and
    how they inter-operate to form meshes of index servers.
 Additional information:
    This media type is not a standalone type. It is the top level of a
    tree similar to the vnd or prs trees specified in Section 2.1 of
    RFC2048. There are four specified branches to this tree:
          application/index.cmd
          application/index.response
          application/index.obj
          application/index.vnd

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

    Each of these branches is a tree in its own right with types
    registered below them. See those registrations for more
    information on the types allowed below those branches.
 Person & email address to contact for further information:
 Intended usage: LIMITED USE
 Author/Change controller:

Command tree

 To: ietf-types@iana.org
 Subject: Registration of MIME media type application/index.cmd
 MIME media type name: application
 MIME subtype name: index.cmd
 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:
    Implementors should handle unknown commands gracefully.
 Published specification:
    RFC 2652

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

 Applications which use this media type:
    This media type is the top of a tree of media types that express
    commands between hosts that exchange indices for the purpose of
    routing referrals.
 Additional information:
    This media type is not a standalone type. It is the top of a tree
    similar to the vnd and prs trees specified in Section 2.1 of
    RFC2048. Types registered within this tree are limited to being
    commands as specified in the document(s) referenced in the
    "Published specifications" section.
 Person & email address to contact for further information:
 Intended usage: LIMITED USE
 Author/Change controller:

Response tree

 To: ietf-types@iana.org
 Subject: Registration of MIME media type application/index.response
 MIME media type name: application
 MIME subtype name: index.response
 Required parameters: code
 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:
    Implementors should handle unknown responses gracefully.

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

 Published specification:
    RFC 2652
 Applications which use this media type:
    This media type is used to encode responses to CIP commands passed
    between hosts that exchange indices for the purpose of routing
    referrals.
 Additional information:
    This media type _is_ a standalone type. The code parameter
    contains the specific response code as specified by Appendix B of
    the specification document.
 Person & email address to contact for further information:
 Intended usage: LIMITED USE
 Author/Change controller:

Index Object tree

 To: ietf-types@iana.org
 Subject: Registration of MIME media type application/index.obj
 MIME media type name: application
 MIME subtype name: index.obj
 Required parameters: type, dsi, base-uri
 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.

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

 Interoperability considerations:
    Implementors should handle unknown index objects according to
    rules specified in the published specification.
 Published specification:
    RFC 2652
 Applications which use this media type:
    This media type is the top of a tree of media types that express
    indexes that are exchanged between hosts that operate within a
    referral mesh.
 Additional information:
    This media type is not a standalone type. It is the top of a tree
    similar to the vnd and prs trees specified in Section 2.1 of
    RFC2048. Types registered within this tree are limited to being
    representations of indexes that contain some summary of the data
    found in some database and is used to generate referrals as
    specified in the above specified publication.
 Person & email address to contact for further information:
 Intended usage: LIMITED USE
 Author/Change controller:

Vendor tree

 To: ietf-types@iana.org
 Subject: Registration of MIME media type application/index.vnd
 MIME media type name: application
 MIME subtype name: index.vnd
 Required parameters: none
 Optional parameters: none
 Encoding considerations: none

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

 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:
    Implementors should handle unknown objects gracefully.
 Published specification:
    RFC 2652
 Applications which use this media type:
    This media type is the top of a tree of media types that express
    vendor specific extensions to the framework specified in the
    published specifications.
 Additional information:
    This media type is not a standalone type. It is the top of a tree
    similar to the vnd and prs trees specified in Section 2.1 of
    RFC2048. Types registered within this tree are limited to being
    vendor specific extensions to the CIP framework as specified in
    the publications. Any registrations within this tree are still
    limited to dealing with indexes, meshes and referrals.
 Person & email address to contact for further information:
 Intended usage: LIMITED USE

Appendix B: Response Codes

 The meaning of the various digits in the response codes is discussed
 in RFC-821, Appendix E.
 The following response codes are defined for use by CIPv3 servers.
 Implementors must use these exact codes; undefined codes should be
 interpreted by CIP servers as fatal protocol errors.  Instead of
 defining new codes for unforeseen situations, implementors must adapt
 one of the given codes. The implementation should attach a useful
 alternative comment to the reused response code.

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

    Code    Suggested description text
            Sender-CIP action
    --------------------------------------------------------
    220     Initial server banner message
    300     Requested CIP version accepted
            Continue with CIP transaction, in the specified
            version.
    222     Connection closing (in response to sender-CIP close)
            Done with transaction.
    200     MIME request received and processed
            Expect no output, continue session (or close)
    201     MIME request received and processed, output follows
            Read a response, delimited by SMTP-style message
            delimiter.
    400     Temporarily unable to process request
            Retry at a later time. May be used 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 request.
    501     Unknown or missing request in application/index.cmd
            Retry with correct CIP command.
    502     Request is missing required CIP attributes
            Retry with correct CIP attributes.
    520     Aborting connection for some unexpected reason
            Retry and/or alert local administrator.
    530     Request requires valid signature
            Sign the request, if possible, and retry.
            Otherwise, report problem to the administrator.
    531     Request has invalid signature
            Report problem to the administrator.
    532     Cannot check signature
            Alert local administrator, who should cooperate with
            remote administrator to diagnose and resolve the
            problem. (Probably missing a public key.)

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

5. 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 & Mealling Standards Track [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2652.txt · Last modified: 1999/08/10 00:31 (external edit)