CIP Transport Protocols
RFC 2653
Network Working Group J. Allen
Request for Comments: 2653 WebTV Networks, Inc.
Category: Standards Track P. Leach
Microsoft
R. Hedberg
Catalogix
August 1999
CIP Transport Protocols
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
This document specifies three protocols for transporting CIP
requests, responses and index objects, utilizing TCP, mail, and HTTP.
The objects themselves are defined in [CIP-MIME] and the overall CIP
architecture is defined in [CIP-ARCH].
1. Protocol
In this section, the actual protocol for transmitting CIP index
objects and maintaining the mesh is presented. While companion
documents ([CIP-ARCH] and [CIP-MIME]) describe the concepts involved
and the formats of the CIP MIME objects, this document is the
authoritative definition of the message formats and transfer
mechanisms of CIP used over TCP, HTTP and mail.
1.1 Philosophy
The philosophy of the CIP protocol design is one of building-block
design. Instead of relying on bulky protocol definition tools, or
ad-hoc text encodings, CIP draws on existing, well understood
Internet technologies like MIME, RFC-822, Whois++, FTP, and SMTP.
Hopefully this will serve to ease implementation and consensus
Allen, et al. Standards Track [Page 1]
RFC 2653 CIP Transport Protocols August 1999
building. It should also stand as an example of a simple way to
leverage existing Internet technologies to easily implement new
application-level services.
1.2 Conventions
The key words "MUST" and "MAY" in this document are to be interpreted
as described in "Key words for use in RFCs to Indicate Requirement
Levels" [KEYWORDS].
Formal syntax is defined using ABNF [ABNF].
In examples octets sent by the sender-CIP are preceded by ">>> " and
those sent by the receiver-CIP by "<<< ".
2 MIME message exchange mechanisms
CIP relies on interchange of standard MIME messages for all requests
and replies. These messages are passed over a bidirectional, reliable
transport system. This document defines transport over reliable
network streams (via TCP), via HTTP, and via the Internet mail
infrastructure.
The CIP server which initiates the connection (conventionally
referred to as a client) will be referred to below as the sender-CIP.
The CIP server which accepts a sender-CIP's incoming connection and
responds to the sender-CIP's requests is called a receiver-CIP.
2.1 The Stream Transport
CIP messages are transmitted over bi-directional TCP connections via
a simple text protocol. The transaction can take place over any TCP
port, as specified by the mesh configuration. There is no "well known
port" for CIP transactions. All configuration information in the
system must include both a hostname and a port.
All sender-CIP actions (including requests, connection initiation,
and connection finalization) are acknowledged by the receiver-CIP
with a response code. See section 2.1.1 for the format of these
codes, a list of the responses a CIP server may generate, and the
expected sender-CIP action for each.
In order to maintain backwards compatibility with existing Whois++
servers, CIPv3 sender-CIPs MUST first verify that the newer protocol
is supported. They do this by sending the following illegal Whois++
system command: "# CIP-Version: 3<cr><lf>". On existing Whois++
servers implementing version 1 and 2 of CIP, this results in a 500-
series response code, and the server terminates the connection. If
Allen, et al. Standards Track [Page 2]
RFC 2653 CIP Transport Protocols August 1999
the server implements CIPv3, it MUST instead respond with response
code 300. Future versions of CIP can be correctly negotiated using
this technique with a different string (i.e. "CIP-Version: 4"). An
example of this short interchange is given below.
Note: If a sender-CIP can safely assume that the server implements
CIPv3, it may choose to send the "# CIP-Version: 3" string and
immediately follow it with the CIPv3 request. This optimization,
Show full document text