As per Relevance of the word transport, we have this rfc below:
Network Working Group J.
Request for Comments: 2653 WebTV Networks, Inc
Category: Standards Track P.
R.
August 1999
CIP Transport
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
This document specifies three protocols for transporting
requests, responses and index objects, utilizing TCP, mail, and HTTP
The objects themselves are defined in [CIP-MIME] and the overall
architecture is defined in [CIP-ARCH].
1.
In this section, the actual protocol for transmitting CIP
objects and maintaining the mesh is presented. While
documents ([CIP-ARCH] and [CIP-MIME]) describe the concepts
and the formats of the CIP MIME objects, this document is
authoritative definition of the message formats and
mechanisms of CIP used over TCP, HTTP and mail
1.1
The philosophy of the CIP protocol design is one of building-
design. Instead of relying on bulky protocol definition tools,
ad-hoc text encodings, CIP draws on existing, well
Internet technologies like MIME, RFC-822, Whois++, FTP, and SMTP
Hopefully this will serve to ease implementation and
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
leverage existing Internet technologies to easily implement
application-level services
1.2
The key words "MUST" and "MAY" in this document are to be
as described in "Key words for use in RFCs to Indicate
Levels" [KEYWORDS].
Formal syntax is defined using ABNF [ABNF].
In examples octets sent by the sender-CIP are preceded by ">>> "
those sent by the receiver-CIP by "<<< ".
2 MIME message exchange
CIP relies on interchange of standard MIME messages for all
and replies. These messages are passed over a bidirectional,
transport system. This document defines transport over
network streams (via TCP), via HTTP, and via the Internet
infrastructure
The CIP server which initiates the connection (
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
responds to the sender-CIP's requests is called a receiver-CIP
2.1 The Stream
CIP messages are transmitted over bi-directional TCP connections
a simple text protocol. The transaction can take place over any
port, as specified by the mesh configuration. There is no "well
port" for CIP transactions. All configuration information in
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-
with a response code. See section 2.1.1 for the format of
codes, a list of the responses a CIP server may generate, and
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
is supported. They do this by sending the following illegal Whois++
system command: "# CIP-Version: 3". 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.
Allen, et al. Standards Track [Page 2]
RFC 2653 CIP Transport Protocols August 1999
the server implements CIPv3, it MUST instead respond with
code 300. Future versions of CIP can be correctly negotiated
this technique with a different string (i.e. "CIP-Version: 4").
example of this short interchange is given below
Note: If a sender-CIP can safely assume that the server
CIPv3, it may choose to send the "# CIP-Version: 3" string
immediately follow it with the CIPv3 request. This optimization
useful only in known homogeneous CIPv3 meshes, avoids waiting for
roundtrip inherent in the negotiation
Once a sender-CIP has successfully verified that the server
CIPv3 requests, it can send the request, formatted as a MIME
with Mime-Version and Content-Type headers (only), using the
standard line ending: "".
Cip-Req = Req-Hdrs CRLF Req-
Req-Hdrs = *( Version-Hdr | Req-Cntnt-Hdr )
Req-Body = Body ; format of request body as in [CIP-MIME
Body = Data CRLF "."
Data = ; data with CRLF "." CRLF replaced
; CRLF ".."
Version-Hdr = "Mime-Version:" "1.0"
Req-Cntnt-Hdr = "Content-Type:" Req-Content
Req-Content = ; format is specified in [CIP-MIME
Cip-Rsp = Rsp-Code CRLF [ Rsp-Hdrs CRLF Rsp-Body ]
[ Indx-Cntnt-Hdr CRLF Index-Body ]
Rsp-Code = DIGIT DIGIT DIGIT
Comment = ; any chars except CR and
Rsp-Hdrs = *( Version-Hdr | Rsp-Cntnt-Hdr )
Rsp-Cntnt-Hdr = "Content-Type:" Rsp-Content
Rsp-Content = ; format is specified in [CIP-MIME
Rsp-Body = Body ; format of response body as in [CIP-MIME
Indx-Cntnt-Hdr = "Content-Type:" Indx-Obj-Type
Indx-Obj-Type = ; any registered index object's MIME-
; the format is specified in [RFC2045]
Index-Body = Body ; format defined in each
;
CRLF = CR LF ; Internet standard
CR = %x0D ; carriage
LF = %x0A ;
DIGIT = %x30-39
Allen, et al. Standards Track [Page 3]
RFC 2653 CIP Transport Protocols August 1999
The message is terminated using SMTP-style message termination.
data is sent octet-for-octet, except when the
1*["."] is seen, in which case one more period
added
When the data is finished, the octet pattern "."
transmitted to the receiver-CIP
On the receiver-CIP's side, the reverse transformation is applied
and the message read consists of all bytes up to, but not including
the terminating pattern
In response to the request, the receiver-CIP sends a response code
from either the 200, 400, or 500 series. The receiver-CIP
processes the request and replies, if necessary, with a MIME message
This reply is also delimited by an SMTP-style message terminator
After responding with a response code, the receiver-CIP MUST
to read another request message, resetting state to the point
the sender-CIP has just verified the CIP version. If the sender-
is finished making requests, it may close the connection. In
the receiver-CIP MUST abort reading the message and prepare for a
sender-CIP connection (resetting its state completely).
An example is given below. It is again worth reiterating that
command format is defined in [CIP-MIME] whereas the message body
defined in each index object definition. In this example the
object definition in [CIP-TIO] will be used. Line endings
explicitly shown in anglebrackets; newlines in this text are
only for readability. Comments occur in curly-brackets
{ sender-CIP connects to receiver-CIP }
<<< % 220 Example CIP server ready
>>> # CIP-Version: 3
<<< % 300 CIPv3 OK!
>>> Mime-Version: 1.0
>>> Content-type: application/index.cmd.datachanged; type
>>> x-tagged-index-1; dsi=1.2.752.17.5.10
>>>
>>> updatetype: incremental tagbased
>>> thisupdate: 855938804
>>> lastupdate: 855940000
>>> .
<<< % 200 Good MIME message
>>> MIME-Version: 1.0
>>> Content-Type: application/index.obj.tagged
>>> dsi=1.2.752.17.5.10;
>>> base-uri="ldap://ldap.umu.se/dc=umu,dc=se"
Allen, et al. Standards Track [Page 4]
RFC 2653 CIP Transport Protocols August 1999
>>>
>>> version: x-tagged-index-1
>>> updatetype: incremental
>>> lastupdate: 855940000
>>> thisupdate: 855938804
>>> BEGIN IO-schema
>>> cn: TOKEN
>>> sn: FULL
>>> title: FULL
>>> END IO-Schema
>>> BEGIN Update Block
>>> BEGIN Old
>>> title: 3/testpilot
>>> END Old
>>> BEGIN New
>>> title: 3/chiefpilot
>>> END New
>>> END Update Block
>>> .
<<< % 200 Good MIME message
{ Sender-CIP shuts down socket for writing }
<<< % 222 Connection closing in response to sender-CIP
{ receiver-CIP closes its side, resets, and awaits
new sender-CIP }
An example of an unsuccessful version negotiation looks like this
{ sender-CIP connects to receiver-CIP }
<<< % 220 Whois++ server ready
>>> # CIP-Version: 3
<<< % 500 Syntax error
{ server closes connection }
The sender-CIP may attempt to retry using version 1 or 2 protocol
Sender-CIP may cache results of this unsuccessful negotiation
avoid later attempts
2.1.1 Transport specific response
The following response codes are used with the stream transport
Code Suggested description Sender-CIP
200 MIME request received Expect no output, continue
and processed (or close
Allen, et al. Standards Track [Page 5]
RFC 2653 CIP Transport Protocols August 1999
201 MIME request received Read a response, delimited by SMTP
and processed, output style message delimiter
220 Initial server banner Continue with Whois++ interaction
message or attempt CIP version negotiation
222 Connection closing (in Done with transaction
response to sender-
close
300 Requested CIP version Continue with CIP transaction,
accepted the specified version
400 Temporarily unable to Retry at a later time. May be
process request to indicate that the server does
currently have the
available to accept an index
500 Bad MIME message format Retry with correctly formatted
501 Unknown or missing Retry with correct CIP
request
application/index.
502 Request is missing Retry with correct CIP attributes
required CIP
520 Aborting connection for Alert local administrator
some unexpected
530 Request requires valid Sign the request, if possible,
signature retry. Otherwise, report problem
the administrator
531 Request has invalid Report problem to the administrator
532 Cannot check signature Alert local administrator, who
cooperate with remote
tp diagnose and resolve the problem
(Probably missing a public key.)
Allen, et al. Standards Track [Page 6]
RFC 2653 CIP Transport Protocols August 1999
2.2 Internet mail infrastructure as
As an alternative to TCP streams, CIP transactions can take
over the existing Internet mail infrastructure. There are
motivations for this feature of CIP. First, it lowers the barriers
entry for leaf servers. When the need for a full TCP
is relaxed, leaf nodes (which, by definition, only send
objects) can consist of as little as a database and an
program (possibly written in a very high level language)
participate in the mesh
Second, it keeps with the philosophy of making use of
Internet technology. The MIME messages used for requests
responses are, by definition of the MIME specification, suitable
transport via the Internet mail infrastructure. With a few
rules, we open up an entirely different way to interact with
servers which choose to implement this transport. See
Conformance, below, for details on what options server
have about supporting the various transports
The basic rhythm of request/response is maintained when using
mail transport. The following sections clarify some special
which need to be considered for mail transport of CIP objects.
general, all mail protocols and mail format
(especially MIME Security Multiparts) can be used with the CIP
transport
2.2.1 CIP-Version
Since no information on which CIP-version is in use is present in
MIME message, this information has to be carried in the mailheader
Therefore CIP requests sent using the mail transport MUST include
CIP-version headerline, to be registered according to [MHREG].
The format of this line is
DIGIT = %x30-39
number = 1*
cipversion = "CIP-Version:" number["." number
2.2.2 Return
When CIP transactions take place over a bidirectional stream,
return path for errors and results is implicit. Using mail as
transport introduces difficulties to the recipient, because it's
always clear from the headers exactly where the reply should go
though in practice there are some heuristics used by MUA's
Allen, et al. Standards Track [Page 7]
RFC 2653 CIP Transport Protocols August 1999
CIP solves this problem by fiat. CIP requests sent using the
transport MUST include a Reply-To header as specified by RFC-822.
Any mail received for processing by a CIP server implementing
mail transport without a Reply-To header MUST be ignored, and
message should be logged for the local administrator. The
MUST not attempt to reply with an error to any address derived
the incoming mail
If there are no circumstances under which a response is to be sent
a CIP request, the sender should include a Reply-To header with
address "<>" in it. Receivers MUST never attempt to send replies
that address, as it is defined to be invalid (both here, and by
BNF grammar in RFC-822). It should be noted that, in general, it is
bad idea to turn off error reporting in this way. However, in
simplest case of an index pushing program, this MAY be a
simplification
2.3 HTTP
HTTP MAY also be used to transport CIP objects, since they are
MIME objects. A transaction is performed by using the POST method
send an application/index.cmd and returning
application/index.response or an application/index.obj in the
reply. The URL that is the target of the post is a
parameter of the CIP-sender to CIP-receiver relationship
Example
{ the client opens the connection and sends a POST }
>>> POST / HTTP/1.1
>>> Host: cip.some.corp
>>> Content-type: application/index.cmd.noop
>>> Date: Thu, 6 Jun 1997 18:16:03 GMT
>>> Content-Length: 2
>>> Connection: close
>>>
{ the server processes the request }
<<< HTTP/1.1 204 No Content
{ the server closes the connection }
In addition to leveraging the security capabilities that come
HTTP, there are other HTTP features that MAY be useful in a
context. A CIP client MAY use the Accept-Charset and Accept-
HTTP headers to express a desire to retrieve an index in a
character set or natural language. It MAY use the Accept-
header to (e.g.) indicate that it can handle compressed responses
which the CIP server MAY send in conjunction with the Transfer
Encoding header. It MAY use the If-Modified-Since header to
Allen, et al. Standards Track [Page 8]
RFC 2653 CIP Transport Protocols August 1999
wasted transmission of an index that has not changed since the
poll. A CIP server can use the Retry-After header to request that
client retry later when the server is less busy
3. Security
There are two levels at which the index information can be protected
the first is by use of the technology available for securing
[MIME-SEC] objects, and secondly by using the technology
for securing the transport
When it comes to transport the stream transport can be protected
the use of TLS [TLS] . For HTTP the Security is handled by using
Basic Authentication [RFC 2616], HTTP Message Digest
[RFC2617] or SSL/TLS. Extra protection for the SMTP exchange can
achieve by the use of Secure SMTP over TLS [SMTPTLS].
4.
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996.
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[CIP-ARCH] Allen, J. and M. Mealling, "The Architecture of the
Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions
the Common Indexing Protocol (CIP)", RFC 2652,
1999.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[CIP-TIO] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "
Tagged Index Object for use in the Common
Protocol", RFC 2654, August 1999.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
Allen, et al. Standards Track [Page 9]
RFC 2653 CIP Transport Protocols August 1999
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed
"Security Multiparts for MIME: Multipart/Signed
Multipart/Encrypted", RFC 1847, October 1995.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
TLS", RFC 2487, January 1999.
[MHREG] Jacob, P., "Mail and Netnews Header
Procedure", Work in Progress
5. Authors'
Jeff R.
246 Hawthorne St
Palo Alto, CA 94301
EMail: jeff.allen@acm.
Paul J.
1 Microsoft
Redmond, WA 98052
EMail: paulle@microsoft.
Roland
Dalsveien 53
0775
EMail: roland@catalogix.ac.
Allen, et al. Standards Track [Page 10]
RFC 2653 CIP Transport Protocols August 1999
6. 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, et al. Standards Track [Page 11]
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
