As per Relevance of the word definition, we have this rfc below:
Network Working Group J.
Request for Comments: 2652 WebTV Networks, Inc
Category: Standards Track M.
Network Solutions, Inc
August 1999
MIME Object Definitions for the Common Indexing Protocol (CIP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The Common Indexing Protocol (CIP) is used to pass
information from server to server in order to facilitate
routing. The protocol is comprised of several MIME objects
passed from server to server. This document describes the
of those objects as well as the methods and requirements needed
define a new index type
1.
The Common Indexing Protocol (CIP) is used to pass indexes
servers that combine multiple indexes and/or route queries based
those indexes. The overall framework for the protocol is specified
the CIP Framework document [FRAMEWORK]. This document should be
within the context of that document as there are fundamental
contained in the framework that are not fully explained here
Since there are several different ways to index a given
there will be multiple types of indexes to pass. These indexes
have different transport requirements, different ways of
parameters, and different referral rules. These
requirements are handled by encapsulating the indexes within
wrappers in order to have a standardized way to specify
different parameters
Allen & Mealling Standards Track [Page 1]
RFC 2652 MIME Definitions for CIP August 1999
Appendix A contains the actual MIME [RFC2046] registration
sent to the IANA for registration [RFC2048].
This document uses language like SHOULD and SHALL that have
meaning as specified in "Key words for use in RFCs to
Requirement Levels" [RFC2119].
2.0 CIP
Messages passed by CIP implementations over reliable
mechanisms fall into three categories: requests, responses
results. All requests result in either a response or a result.
result sent in response to a request must be interpreted as
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
multipart package to provide authentication and privacy. The
policy with respect to all messages is implementation defined,
not explicitly discussed below. CIP implementors are strongly
to allow server administrators maximum configurability to
their servers against maliciously sent anonymous CIP messages.
general, operations which can permanently change the server's
in a harmful way should only take place upon receipt of a
signed message from a trusted CIP peer or administrator.
should provide appropriate auditing capabilities so that
successful and failed requests can be tracked by the
administrator
Since these MIME objects can and will be sent over several
protocols, body termination is specified by the transfer protocol
New protocols are encouraged to use SMTP [RFC821] style
termination
Finally, since MIME objects can specify their own encoding,
line-breaks contained within each body are defined by the encoding
Thus, instead of specifying them as carriage-return and/or linefeed
the identifier is used. Linebreaks in the headers
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
There are certain syntactic elements common to all of the
transactions. These include type, DSI and the Base-URI
2.1.1 The "application/index" MIME type
Due to requirements in RFC2048 concerning objects that have the
type but different syntaxes, CIP objects will use
application/index tree but include "facets" [RFC2048] which extend
as other types have done with respect to global elements and
specific enhancements. Thus the tree is divided up into the
branches
application/index.cmd._command
application/index.
application/index.obj._type
application/index.vnd._xxx
_command_ is a command as specified here. It contains commands
their arguments
_type_ identifies what type of CIP index object is
within the body. It is unique among all other reserved types
Reserved types are those previously documented by other CIP
object specifications, according to standard IETF processes
_xxx_ is an identifier specified by a vendor for use by
vendor in operations specifically to do with indexes
All of the above identifiers follow the rules in RFC2048 for
MIME types. In addition commands, responses and types are limited
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,
the ASCII minus character (decimal 45). Though type names may
specified case sensitively, they must be compared and
processed case insensitively
Appendix A contains the registration template for
application/index tree
2.1.2
A dataset identifier is an identifier chosen from any part of
ISO/CCITT OID space. The DSI uniquely identifies a given
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
integers. While this creates an infinite numbering space, it
problems for implementors dealing with machines with
resources. To ease implementation, this document specifies an
encoding of the OID, and specifies limits which make
easier
For the purposes of interchange in CIP messages, an OID must
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-
Under no circumstances shall the total length of the resulting
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
unless it is prepared to handle arbitrary-length integers.
the DSI as anything other than an opaque string of US-
characters is not recommended
Two CIP DSI's are considered to match if both conform to the
rules and every number matches
2.1.3. Base-
CIP index objects carry base-URI's to facilitate referral
based on the index object. The base-URI parameter carries
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 = "" (decimal 32) /
"" (decimal 9) /
"" (decimal 13) /
"" (decimal 10)
genericurl = { as specified in RFC-1738, section 5 }
2.2 Response
All requests must be followed by a response code, except in the
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:
MIME subtype name: index.
Required parameters:
Optional parameters:
Security considerations: (See Section 4)
The code parameter contains a 3 digit return code that denotes
status of the last command
The format of the body is such that the first line is interpreted
the comment corresponding to the code. As with most response
this comment is intended for human consumption and may not exist
must not be depended on by the protocol. Subsequent lines in the
are reserved for each response to define. In the case where
comment is not given the first must be an empty line
body = comment linebreak
comment = { any text }
linebreak = (decimal 13) (decimal 10)
payload = { any text }
The charset parameter has its normal MIME meaning. Below are
examples
[begin MIME
Content-type: application/index.response; code=220
CIP Server v1.0 ready!
[end MIME
[begin MIME
Content-type: application/index.response; code=500
MIME formatting problem
[end MIME
[begin MIME
Content-type: application/index.response; code=520
[end MIME
While the responses described in this document do not utilize
rest of the lines in the body of a response implementors should
care to not disallow it in the future. A good example would be
message specifying that a poll request did not contain
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
Missing-Attribute: attribute
Missing-Attribute: attribute
Missing-Attribute: attribute
[end MIME
The meaning of the various digits in the response codes is
in RFC-821, Appendix E
See Appendix B for a list of the valid response codes
2.3 Command
A CIP command either initiates an index transfer, interrogates
state of the receiver-CIP (or the server's participation in
mesh), or changes the state of the server (or the server's place
the mesh).
CIP commands are sent as a MIME message of
"application/index.cmd._command_". The definition for this MIME
tree follows
MIME type name:
MIME subtype name: index.cmd._command
Optional parameters: type,
Security considerations: (See Section 4)
The format of the body is defined by each command. A
attribute/value pair orientation is preserved throughout
following specified commands. Those developing future command
attempt to maintain that orientation but are not required to do so
In the following sections, the server's response for each
value for "command" is defined. Note that the parameters listed
optional above are only optional with respect to the generic
form. The optional parameters are only optional with respect to
parsing. If one or more of the parameters needed to fulfill a
is missing, a response code of 502 is returned
Extra optional parameters which are unrecognized must be
ignored
Allen & Mealling Standards Track [Page 6]
RFC 2652 MIME Definitions for CIP August 1999
2.3.1 No-
Command Name: application/index.cmd.
Required parameters: (none
A CIP command with the "command" parameter set to "noop" must
acknowledged with response type code 200 (command OK, no
forthcoming).
This command must not require a signed MIME object.
should accept commands which have been validly signed
Example
[begin MIME
Content-type: application/index.cmd.
[end MIME
Note the lack of a body but how the pair is
preserved after the Content-type header
2.3.2
Request Name: application/index.cmd.
Required parameters: type,
The "poll" command is used by a poller to request the transfer of
index object. It requires the following parameters
type: The index object type
dsi: The dataset which the index should
If there are no index objects available for a given DSI, or
receiver-CIP does not support a given index object type,
receiver-CIP must respond with response code 200, (successful,
response forthcoming). Otherwise, the response code must be 201
(successful, response is forthcoming).
The security policy for polling commands is wholly
defined. Implementations may be configured to accept or
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
Start-time: Fri May 30 14:25:30 EDT 1997
End-time: Sat May 31 14:25:30 EDT 1997
[end MIME
2.3.3
Request Name: application/index.cmd.
Required parameters: type,
The "datachanged" command is used by a pollee to notify a poller
the data within an index has changed. It requires the
parameters
type: The index object type
dsi: The dataset which the index should
If there are no index objects available for a given DSI, or
receiver-CIP does not support a given index object type,
receiver-CIP must respond with response code 200, (successful,
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
attribute value pairs following the rules of RFC822. The
attributes and values allowed are defined by the index
specification
The security policy for DataChanged commands is wholly
defined. Implementations may be configured to accept or
anonymous DataChanged commands
Example
[begin MIME
Content-type: application/index.cmd.datachanged
type="simple"; dsi= "1.3.5.7.9"
Time-of-latest-change: Fri May 30 14:25:30 EDT 1997
Time-of-message-generation: Fri May 30 14:25:30 EDT 1997
Host-Name: cip.rwhois.net
Host-Port: 4322
Protocol: RWhois2.0
[end MIME
Allen & Mealling Standards Track [Page 8]
RFC 2652 MIME Definitions for CIP August 1999
2.3.4 Additional
The requests specified above are those required to implement a
mesh. It is expected that other requests will be developed to
issues of mesh-management and statistics gathering requests. At
point this is an area of additional work. Specifically more work
needed in the area of mesh management as meshes will tend to
organized around the characteristics of their index type
2.4. Index Object
In reply to the "poll" command, a server may choose to send one
more index objects. Regardless of the number of index
returned, the response must take the form of a MIME multipart/
message. Each part must itself be a MIME object of
"application/index.obj._type_". The definition for this type follows
MIME type name:
MIME subtype name: index.obj._type
Required parameters: dsi, base-
Optional parameters:
Security considerations: (See Section 4)
As previously described, each index object is of a
type. This type is specified in the MIME subtype name since
types may have a different syntax
The required parameters are to be used as follows
DSI: The DSI is a string which globally uniquely
the dataset from which the index was created
base-URI: One or more URI's will form the base of any
created based upon this index object
3. Index Type Definition
Because of the need for application domain specific indices,
index objects are abstract; they must be defined by a
specification. The basic protocols for moving index objects
widely applicable, but the specific design of the index, and
structure of the mesh of servers which pass a particular type
index is dependent on the application domain. While
documents will describe index objects, there is a set of
requirements and questions those documents must address. This is
ensure that the base assumptions that the CIP protocol makes
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
follows the standard registration policies specified in RFC2048.
3.1 Type specific
Any index type definition must address the type specific bodies
the Poll and DataChanged requests. All parameters included in
body must be specified
3.2 The index.obj
3.2.1
See the above definitions for allowed values for type
A new name must be assigned when any changes to the
describing the index object type are not completely
compatible
3.2.2
Another attribute is the "DSI", or Dataset Identifier, which
identifies the dataset from which the index was created. The
specification should define the policies for how the DSI
generated. This includes the concept of what a data-set means for
given index
3.2.3. Base-
An attribute of the index object which is crucial for
referrals is the "Base-URI". The URI (or URI's) contained in
attribute form the basis of any referrals generated based on
index block. The URI is also used as input during the
aggregation process to constrain the possible types of aggregation
This use of the Base-URI is used to deal with meshes that
multiple protocols
Thus, an index specification should define how the Base-URI
to the underlying index and how it is changed during the
process
Allen & Mealling Standards Track [Page 10]
RFC 2652 MIME Definitions for CIP August 1999
3.3
All index object specifications must address the issue
aggregation. This is the method by which an index server takes
or more indexes and combines them into one index to be passed on.
is not required that a given index-type aggregate. If it does not
must explicitly address the reasons why and what affect that has
scalability
If a given index does aggregate, the algorithm for that
must be given. It must also address how that algorithm affects
organization and scalability
Index object document authors should remember that any kind
aggregation should be performed without compromising the ability
correctly route queries while avoiding excessive numbers of
results. The acceptable likelihood of false negatives must
established on a per-application-domain basis, and is controlled
the granularity of the index and the aggregation rules defined for
by the particular specification
Nothing in these documents specifically disallows aggregation
that deal with different index object types. This type
heterogeneous mesh is difficult to formulate at best and thus is
covered by these documents. If document authors wish to attempt
a mesh they should be aware that it is considered an ill
concept that contains many pitfalls for the mesh builder
3.4 Referral Generation
Since the method by which a client navigates the mesh is
referrals, the document must address how a given access
generates a referral from the index. Authors should pay
attention to the case where an index is accessed by
protocols and the interaction between them. For example, an
that supports referrals being generated for both RWhois and LDAP
understand that one uses a Distinguished Name while the
doesn't. The impacts of these differences on the referral should
clear
3.5 Matching
In order to generate a referral the decision of whether or not to
so must be handled by the access protocol. The semantics
this decision have a large impact on the efficiency of searches
well as the requirements on aggregation. Thus, index
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
As is customary with Internet protocol documentation, a brief
of security implications of the proposed object must be included
This section may need to do little more than echo the
expressed in this document's Security Considerations section
3.7 Optional
Because indexing algorithms, stop-lists, and data
technologies are considered by some index object designers to
proprietary, it is not necessary to discuss the process used
derive indexing information from a body of source material.
proprietary indexing technologies are used in a public mesh, all
servers in the mesh should be able to parse the index object (
perform aggregation operations, if necessary), though not all of
need to be able to create these proprietary indices from source data
Thus, index object designers may choose to remain silent on
algorithms used for the generation of indices, as long as
adequately document how to participate in a mesh of servers
these proprietary indices
Designers should also seriously consider including useful examples
source data, the generated index, and the expected results
example matches. When the aggregation algorithm is complex, it
recommended that a table showing two indices and the
aggregate index be included
4. Security
Security considerations come into play in at least the following
scenarios. Indexing information can leak undesirable amounts
proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires external
services to operate in a safe manner. Both topics are covered below
4.1 Secure
CIP is designed to index all kinds of data. Some of this data
be considered valuable, proprietary, or even highly sensitive by
data maintainer. Take, for example, a human resources database
Certain bits of data, in moderation, can be very helpful for
company to make public. However, the database in its entirety is
very valuable asset, which the company must protect. Much
has been gained in the directory service community over the years
to how best to walk this fine line between completely revealing
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
publisher who would like to participate in a CIP mesh. The data
publisher creates and manages is the prime asset of the company
There is a financial incentive to participate in a CIP mesh,
exporting indices of the data will make it more likely that
will search your database. (Making profit off of the search
is left as an exercise to the entrepreneur.) Once again, the
must be designed carefully to protect the database while providing
useful synopsis of the data
One of the basic premises of CIP is that data providers will
willing to provide indices of their data to peer indexing servers
Unless they are carefully constructed, these indices could
a threat to the security of the database. Thus, security of the
must be a prime consideration when developing a new index
type. The risk of reverse engineering a database based only on
index exported from it must be kept to a level consistent with
value of the data and the need for fine-grained indexing
Since CIP is encoded as MIME objects, MIME security solutions
be used whenever possible. Specifically when dealing with
between index servers
4.2 Protocol
CIP protocol exchanges, taking the form of MIME messages, can
secured using any technology available for securing MIME objects.
particular, use of RFC-1847's Security Multiparts are recommended.
solid application of RFC-1847 using widely available
software is PGP/MIME, RFC-2016. Implementors are encouraged
support PGP/MIME, as it is the first viable application of the
Security Multiparts architecture. As other technologies
available, they may be incorporated into the CIP mesh
If an incoming request does not have a valid signature, it must
considered anonymous for the purposes of access control. Servers
choose to allow certain requests from anonymous peers,
when the request cannot cause permanent damage to the local server
In particular, answering anonymous poll requests encourages
builders to poll a server, making the server's resources
known
The explicit security policy with respect to incoming requests
outside the scope of this specification. Implementors are free
accept or reject any request based on the security attributes of
incoming message. When a request is rejected due to
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
Thanks to the many helpful members of the FIND working group
discussions leading to this specification
Specific acknowledgment is given to Jeff Allen formerly of
Information Systems. His original version of these documents
enormously in crystallizing the debate and consensus. Most of
actual text in this document was originally authored by Jeff
Authors'
Jeff R.
246 Hawthorne St
Palo Alto, CA 94301
EMail: jeff.allen@acm.
Michael
Network Solutions, Inc
505 Huntmar Park
Herndon, VA 22070
Phone: +1-703-742-0400
EMail: michael.mealling@RWhois.
[FRAMEWORK] Allen, J. and M. Mealling, "The Architecture of
Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
January 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "
Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC 2048, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, August 1992.
Allen & Mealling Standards Track [Page 14]
RFC 2652 MIME Definitions for CIP August 1999
Appendix A: Media Type Registration
The following templates have been registered with the IANA
Index
To: ietf-types@iana.
Subject: Registration of MIME media type tree application/
MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations
Security considerations come into play in at least the
two scenarios. Indexing information can leak undesirable
of proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires
security services to operate in a safe manner. Both topics
covered below
Interoperability considerations
Published specification
RFC 2652
Applications which use this media type
This media type is used to contain information about indices
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
tree similar to the vnd or prs trees specified in Section 2.1
RFC2048. There are four specified branches to this tree
application/index.
application/index.
application/index.
application/index.
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
registered below them. See those registrations for
information on the types allowed below those branches
Person & email address to contact for further information
Intended usage: LIMITED
Author/Change controller
Command
To: ietf-types@iana.
Subject: Registration of MIME media type application/index.
MIME media type name:
MIME subtype name: index.
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations
Security considerations come into play in at least the
two scenarios. Indexing information can leak undesirable
of proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires
security services to operate in a safe manner. Both topics
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
commands between hosts that exchange indices for the purpose
routing referrals
Additional information
This media type is not a standalone type. It is the top of a
similar to the vnd and prs trees specified in Section 2.1
RFC2048. Types registered within this tree are limited to
commands as specified in the document(s) referenced in
"Published specifications" section
Person & email address to contact for further information
Intended usage: LIMITED
Author/Change controller
Response
To: ietf-types@iana.
Subject: Registration of MIME media type application/index.
MIME media type name:
MIME subtype name: index.
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations
Security considerations come into play in at least the
two scenarios. Indexing information can leak undesirable
of proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires
security services to operate in a safe manner. Both topics
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
between hosts that exchange indices for the purpose of
referrals
Additional information
This media type _is_ a standalone type. The code
contains the specific response code as specified by Appendix B
the specification document
Person & email address to contact for further information
Intended usage: LIMITED
Author/Change controller
Index Object
To: ietf-types@iana.
Subject: Registration of MIME media type application/index.
MIME media type name:
MIME subtype name: index.
Required parameters: type, dsi, base-
Optional parameters:
Encoding considerations:
Security considerations
Security considerations come into play in at least the
two scenarios. Indexing information can leak undesirable
of proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires
security services to operate in a safe manner. Both topics
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
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
indexes that are exchanged between hosts that operate within
referral mesh
Additional information
This media type is not a standalone type. It is the top of a
similar to the vnd and prs trees specified in Section 2.1
RFC2048. Types registered within this tree are limited to
representations of indexes that contain some summary of the
found in some database and is used to generate referrals
specified in the above specified publication
Person & email address to contact for further information
Intended usage: LIMITED
Author/Change controller
Vendor
To: ietf-types@iana.
Subject: Registration of MIME media type application/index.
MIME media type name:
MIME subtype name: index.
Required parameters:
Optional parameters:
Encoding considerations:
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
two scenarios. Indexing information can leak undesirable
of proprietary information, unless carefully controlled. At a
fundamental level, the CIP protocol itself requires
security services to operate in a safe manner. Both topics
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
vendor specific extensions to the framework specified in
published specifications
Additional information
This media type is not a standalone type. It is the top of a
similar to the vnd and prs trees specified in Section 2.1
RFC2048. Types registered within this tree are limited to
vendor specific extensions to the CIP framework as specified
the publications. Any registrations within this tree are
limited to dealing with indexes, meshes and referrals
Person & email address to contact for further information
Intended usage: LIMITED
Appendix B: Response
The meaning of the various digits in the response codes is
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
interpreted by CIP servers as fatal protocol errors. Instead
defining new codes for unforeseen situations, implementors must
one of the given codes. The implementation should attach a
alternative comment to the reused response code
Allen & Mealling Standards Track [Page 20]
RFC 2652 MIME Definitions for CIP August 1999
Code Suggested description
Sender-CIP
--------------------------------------------------------
220 Initial server banner
300 Requested CIP version
Continue with CIP transaction, in the
version
222 Connection closing (in response to sender-CIP close
Done with transaction
200 MIME request received and
Expect no output, continue session (or close
201 MIME request received and processed, output
Read a response, delimited by SMTP-style
delimiter
400 Temporarily unable to process
Retry at a later time. May be used to
that the server does not currently have
resources available to accept an index
500 Bad MIME message
Retry with correctly formatted MIME request
501 Unknown or missing request in application/index.
Retry with correct CIP command
502 Request is missing required CIP
Retry with correct CIP attributes
520 Aborting connection for some unexpected
Retry and/or alert local administrator
530 Request requires valid
Sign the request, if possible, and retry
Otherwise, report problem to the administrator
531 Request has invalid
Report problem to the administrator
532 Cannot check
Alert local administrator, who should cooperate
remote administrator to diagnose and resolve
problem. (Probably missing a public key.)
Allen & Mealling Standards Track [Page 21]
RFC 2652 MIME Definitions for CIP August 1999
5. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Allen & Mealling Standards Track [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
