CIP Transport Protocols
Extracted elements (18)
CIP protocol design uses a building-block philosophy, drawing on existing Internet technologies like MIME, RFC-822, Whois++, FTP, and SMTP rather than bulky protocol definition tools or ad-hoc text encodings, to ease implementation and consensus building.
Mail transport is supported as an alternative to TCP to lower the barrier to entry for leaf servers, which only send index objects and can be implemented as a simple database plus indexing program without a full TCP stack.
There is no well-known port for CIP transactions; all configuration must include both a hostname and a port. This means CIP can operate over any TCP port as specified by the mesh configuration.
A sender-CIP in a known homogeneous CIPv3 mesh MAY send the '# CIP-Version: 3' string and immediately follow it with the CIPv3 request without waiting for the 300 response, as an optimization to avoid the negotiation roundtrip.
CIP over HTTP MAY leverage Accept-Charset, Accept-Language, Accept-Encoding/Transfer-Encoding (for compression), If-Modified-Since (to skip unchanged indexes), and Retry-After (for server backpressure) HTTP headers.
A CIPv3-capable receiver-CIP MUST respond with response code 300 (rather than a 500-series error) when it receives the '# CIP-Version: 3' negotiation string.
After responding with a response code, the receiver-CIP MUST prepare to read another request message, resetting state to the point when the sender-CIP has just verified the CIP version. If the sender-CIP closes the connection, the receiver-CIP MUST abort reading and prepare for a new sender-CIP connection.
CIP requests sent using the mail transport MUST include a Reply-To header as specified by RFC-822. Mail received without a Reply-To header MUST be ignored (with a log message), and the receiver MUST NOT attempt to reply to any address derived from the incoming mail.
CIPv3 sender-CIPs MUST first verify that the newer protocol is supported by sending the illegal Whois++ system command '# CIP-Version: 3<cr><lf>' before transmitting CIPv3 requests.
Receivers MUST never attempt to send replies to the special Reply-To address '<>', which signals that no response is desired and is defined to be an invalid address by RFC-822 BNF.
HTTP transport uses the POST method to send an application/index.cmd object and receive an application/index.response or application/index.obj in the HTTP reply. The target URL is a configuration parameter of the sender-to-receiver relationship.
SMTP-style dot-stuffing message termination is used for TCP transport: data is sent octet-for-octet except that the pattern CRLF 1*['.'] CRLF has one extra period added, and the sequence CRLF '.' CRLF signals end-of-message.
Stream transport response codes include: 200 (request processed), 201 (request processed, output follows), 220 (server banner), 222 (connection closing), 300 (CIP version accepted), 400 (temporarily unable), 500 (bad MIME), 501 (unknown request), 502 (missing attributes), 520 (aborting), 530–532 (signature errors).
Index information can be protected at two levels: by securing the MIME objects using MIME Security Multiparts [RFC 1847], and by securing the transport layer (TLS for TCP streams, HTTP Basic/Digest Authentication or SSL/TLS for HTTP, Secure SMTP over TLS for mail).
The TCP stream session progresses through states: (1) connected/banner received, (2) version negotiated (300 received), (3) request sent and acknowledged (200/201), (4) session closed (222). A 500-series response during negotiation causes the server to terminate the connection and sender may retry with an older protocol version.
CIP requests over TCP are formatted as MIME messages with Mime-Version and Content-Type headers using CRLF line endings. The ABNF defines Cip-Req as Req-Hdrs CRLF Req-Body, where Body is Data CRLF '.' CRLF with dot-stuffing applied.
CIP responses over TCP follow the pattern Cip-Rsp = Rsp-Code CRLF [Rsp-Hdrs CRLF Rsp-Body] [Indx-Cntnt-Hdr CRLF Index-Body], where Rsp-Code is three decimal digits followed by a comment.
The mail transport CIP-Version header has the ABNF: cipversion = 'CIP-Version:' SP number['.' number], where number = 1*DIGIT and DIGIT = %x30-39.