RFC 2652
MIME Object Definitions for the Common Indexing Protocol (CIP)
RFC 2652 is titled MIME Object Definitions for the Common Indexing Protocol (CIP) 🎀. It was written by J. Allen of WebTV Networks, Inc. and M. Mealling of Network Solutions, Inc. It's a Standards Track document from August 1999, and its header doesn't list any Obsoletes or Updates entries. Let's get into it 💅
Status of this Memo 🌸
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice 💜
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🧚
okay so CIP (the Common Indexing Protocol) is how servers pass indexing info from server to server to help with query routing 🔥 It's made up of several MIME objects that get passed between servers. This document defines those objects, and it also covers the methods and requirements you'd need to define a new index type. iconic 👑
1. Introduction 🎀
So CIP is how indexes get passed between servers that either combine multiple indexes or route queries based on those indexes 💖 The overall framework is in the CIP Framework document [FRAMEWORK]. Read this one alongside that doc, bestie, because the framework has some fundamental concepts that aren't fully explained here 🫶
Here's the thing: there are a bunch of different ways to index a database, so there will be multiple types of indexes to pass around 🍓 These indexes might have different transport requirements, different ways of specifying parameters, and different referral rules. To handle all of those differences, each index gets wrapped in a MIME wrapper. That gives everyone a standardized way to specify those parameters, and it's giving organized energy 😭
Appendix A has the actual MIME [RFC2046] registration templates that get sent to the IANA for registration [RFC2048] 📝
This document uses language like SHOULD and SHALL that has special meaning as specified in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Those words are doing a lot of work here, so pay attention 🙈
2.0 CIP Transactions 💅
Messages that CIP implementations pass over reliable transport mechanisms fall into three categories: requests, responses and results ✨ Every request ends up with 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 are defined below 🦋
Like all MIME objects, CIP messages can be wrapped in a security multipart package for authentication and privacy 🔒 The security policy for all messages is implementation defined, unless it's explicitly discussed below. Now, this part is serious. CIP implementors are strongly urged to give server administrators maximum configurability so they can protect their servers from maliciously sent anonymous CIP messages 💀 In general, operations that can permanently change the server's state in a harmful way should only happen after receiving a properly signed message from a trusted CIP peer or administrator. Implementors should also provide appropriate auditing capabilities, so the server administrator can track both successful and failed requests. Keep your receipts, bestie 🧾
Since these MIME objects can and will be sent over several different protocols, the transfer protocol specifies how the body gets terminated. New protocols are encouraged to use SMTP [RFC821] style body termination 🎀
Last thing in this section: since MIME objects can specify their own encoding, the line-breaks in each body are defined by that encoding. So instead of writing carriage-return and/or linefeed, the identifier <linebreak> gets used. Linebreaks in the headers, and the ones separating the body from the headers, follow existing standards 🌸
2.1 Common syntactic definitions 🧚
There are some syntactic elements that all CIP transactions share. These include type, DSI and the Base-URI 💖
2.1.1 The "application/index" MIME type tree 🍓
Because of the requirements in RFC2048 about objects that have the same type but different syntaxes, CIP objects will use the application/index tree. They also include "facets" [RFC2048] to extend it, the same way other types have done for global elements and vendor-specific enhancements 👑 So the tree is split up into these 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 in the body. It's unique among all other reserved types. Reserved types are the ones that other CIP index object specifications have already documented, following standard IETF processes 🦋
_xxx_ is an identifier that a vendor specifies for that vendor's own operations on indexes 🫶
All of the identifiers above follow the rules in RFC2048 for valid MIME types. On top of that, this document limits commands, responses and types to 1 to 20 characters from the set [a-zA-Z0-9-]. That's all upper and lower case letters, all digits, and the ASCII minus character (decimal 45) 🔥 Type names can be specified case sensitively, but they must be compared and otherwise processed case insensitively. Keep that in mind, or you'll get messed up 🙈
Appendix A has 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 the datasets that CIP indexes ✨
Right now, OID's are an unbounded sequence of unbounded integers. That gives you an infinite numbering space, but it's a nightmare for implementors working with machines that have finite resources 😭 To make things easier, this document specifies an ASCII encoding of the OID, and it sets limits that make implementation simpler 💜
For interchange in CIP messages, an OID must conform to these 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-nineUnder no circumstances shall the total length of the resulting string exceed 255 characters. OID's that can't conform to these rules because of their length must not be used as CIP dataset identifiers 🚫
An implementation must not try to parse the individual integers unless it can 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 help generate referrals based on the index object. The base-URI parameter carries a whitespace-delimited list of URL's. URL's are defined in RFC-1738. Here are the exact rules:
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 cases where a return path isn't available 📬
The definition for this MIME type looks like this:
MIME type name: application
MIME subtype name: index.response
Required parameters: code
Optional parameters: charset
Security considerations: (See Section 4)The code parameter holds a 3 digit return code that shows the status of the last command 🔢
The first line of the body is read as the comment that goes with the code. Like most response codes, this comment is meant for humans. It might not exist, and the protocol must not depend on it 💬 Lines after that are reserved for each response to define. If the comment isn't given, the first line 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. Here are some 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]The responses in this document don't use the rest of the lines in a response body, but implementors should be careful not to rule that out for the future. A good example is a message saying a poll request didn't have required attributes. It might look like this 🧐
[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]What the different digits in the response codes mean 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 starts an index transfer, checks 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 looks like this:
MIME type name: application
MIME subtype name: index.cmd._command_
Optional parameters: type, dsi
Security considerations: (See Section 4)The body format is defined by each command. A general attribute/value pair orientation is kept throughout the commands specified below. People developing future commands should try to keep that orientation, but they aren't required to 🧸
In the sections that follow, the server's response for each possible value of "command" is defined. The parameters listed as optional above are only optional with respect to the generic MIME form. They're 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 that aren't recognized must be silently ignored 🫥
2.3.1 No-operation
Command Name: application/index.cmd.noop
Required parameters: (none)Okay bestie, this one is so chill 🌸 A CIP command with the "command" parameter set to "noop" must be acknowledged with response type code 200 (command OK, no response forthcoming). Basically it's a little "hey, got it" with no follow-up. 🫶
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]Look at that empty body 🙈 Notice how the <linebreak> pair is still there after the Content-type header, even though there's nothing else in it. Iconic consistency, no cap. 💅
2.3.2 Poll
Request Name: application/index.cmd.poll
Required parameters: type, dsiThe "poll" command is how a poller asks for an index object to be transferred. 🦋 It needs these parameters:
type: The index object type requested
dsi: The dataset which the index should coverIf 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"
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, dsiThe "datachanged" command is how a pollee tells a poller that the data inside an index has changed. 🌈 It needs these parameters:
type: The index object type requested
dsi: The dataset which the index should coverIf 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]2.3.4 Additional Requests
The requests above are the ones needed to build a simple mesh. 🍓 It's expected that other requests will be developed to handle mesh-management and statistics gathering. That's still an area of additional work, bestie. Mesh management especially needs more attention, because 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 how many index objects get 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_". Here's the definition for this type:
MIME type name: application
MIME subtype name: index.obj._type_
Required parameters: dsi, base-uri
Optional parameters: none
Security considerations: (See Section 4)As mentioned before, each index object is of a particular type. That type goes in the MIME subtype name, because some types may have a different syntax. 🦋
The required parameters are used like this:
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 application domains need their own kinds of 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, depends on the application domain. Companion documents will describe index objects, and there is a set of base requirements and questions those documents must address. This is to make sure the base assumptions the CIP protocol makes about its indexes can actually be expressed within the index. 💅
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
The "Base-URI" is a crucial attribute of the index object when it comes to generating referrals. 💖 The URI (or URI's) 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 is how meshes that support multiple protocols get handled. 🧚
So an index specification should define how the Base-URI applies to the underlying index and how it changes during the aggregation process. ✨
3.3 Aggregation
All index object specifications must address the issue of aggregation. Aggregation is the method by which an index server takes two or more indexes and combines them into one index to pass 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, so it 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 with many pitfalls for the mesh builder. 💀
3.4 Referral Generation Semantics
Since a client navigates the mesh 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 to 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
To generate a referral, the decision of whether or not to do so must be handled by the access protocol. The semantics around this decision have a big impact on the efficiency of searches, as well as on the requirements for aggregation. So index specification authors must be very clear about how a match is determined. 🔥
3.6 Security Considerations
As is customary with Internet protocol documentation, a brief review of the 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
Some index object designers consider indexing algorithms, stop-lists, and data reduction technologies to be proprietary. So it's 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. ✨
So index object designers may choose to stay silent on the algorithms used to generate 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. 😭 First, indexing information can leak undesirable amounts of proprietary information unless it's carefully controlled. Second, and 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 ✨
okay so CIP is built to index ALL kinds of data 👀 and some of that data is valuable, proprietary, or even highly sensitive 🔒 (the data maintainer gets to decide what counts). Take an HR database 🙈 Certain bits of it, in moderation, can be super helpful for a company to make public. But the whole database is a seriously valuable asset the company has to protect. The directory service crowd has been walking this fine line for years, figuring out how to share useful pieces without fully revealing the database. Iconic work tbh 💅
Another situation where security becomes a problem is a data publisher who wants to join a CIP mesh 🕸️ The data they create and manage is literally the prime asset of the company. There's a financial incentive to join, since exporting indices makes people more likely to search your database. (Making profit off that search activity is left as an exercise for the entrepreneur 💸) Once again, the index has to be designed carefully to protect the database while still giving a useful synopsis of the data 🎀
The main premise of CIP is that data providers are willing to share indices of their data with peer indexing servers 🧚 But unless they're carefully built, those indices could be a threat to the security of the database 😬 So 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 has to stay at a level that matches the value of the data and the need for fine-grained indexing. Balance is everything, bestie ⚖️
Last thing: CIP is encoded as MIME objects, so MIME security solutions should be used whenever possible. Specifically when dealing with security between index servers 🔐
4.2. Protocol Security 🔐
CIP protocol exchanges take the form of MIME messages, so they can be secured with any technology available for securing MIME objects 💖 In particular, use of RFC-1847's Security Multiparts is recommended. A solid way to apply RFC-1847 with widely available encryption software is PGP/MIME, RFC-2016. Implementors are encouraged to support PGP/MIME, since it's 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 access control purposes. Servers may choose to allow certain requests from anonymous peers, especially when the request cannot cause permanent damage to the local server. Like, answering anonymous poll requests encourages index builders to poll a server, which makes the server's resources better known 👀
The explicit security policy for 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 for authentication reasons, a response code from the 530 series must be issued. No skipping this one, periodt 💀
Acknowledgments 🙏
Thanks to the many helpful members of the FIND working group for the discussions that led to this specification 🫶
Specific shoutout 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 written by Jeff, so he's the real MVP 👑
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.netReferences 📚
[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.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
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
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.
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.
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 🦋
Okay bestie, this is the registration template for the vendor tree, and it's giving careful 💅 Here's the header:
To: ietf-types@iana.org
Subject: Registration of MIME media type application/index.vndNow the fields, one by one:
MIME media type name:application🌸MIME subtype name:index.vnd💖Required parameters:noneOptional parameters:noneEncoding considerations:none
Security considerations: okay so this is serious 😭 Security stuff matters in at least two situations. First, indexing info can leak way more proprietary stuff than you'd want, unless you lock it down properly. Second, and this is the deeper one, the CIP protocol itself needs outside security services to run safely. We'll cover both topics below ✨
Interoperability considerations: Implementors SHOULD handle unknown objects gracefully 🧚 Don't crash on stuff you don't recognise, bestie.
Published specification: RFC 2652 📜
Applications which use this media type: This type is the top of a whole tree of media types for vendor-specific extensions to the framework in the published specs. It's giving family tree 🌳
Additional information: Not a standalone type, so don't try to use it alone 🙅♀️ It's the top of a tree that works like the vnd and prs trees described in Section 2.1 of RFC2048. Anything registered in this tree has to stay a vendor-specific extension to the CIP framework from the published specs. And any registrations here are still only for indexes, meshes and referrals. No going rogue 🦋
Person & email address to contact for further information:
Intended usage: LIMITED USE 🎀
Appendix B: Response Codes 💅
Okay so the digits in the response codes are explained in RFC-821, Appendix E, so go check that out if you're curious 🤓
These are the response codes defined for CIPv3 servers. Implementors MUST use these exact codes, and undefined codes SHOULD be treated by CIP servers as fatal protocol errors ❌ Don't invent new codes for surprise situations. Instead, implementors MUST adapt one of the codes that already exist, and the implementation SHOULD attach a useful alternative comment to the reused code 💜 Here's the table:
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.)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 🫶
Big thank you to the Internet Society, which currently funds the RFC Editor function 💖
📦 where this page comes from
- ietf: rfc2652 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms