Updated Internet Relay Chat (IRC) Client to Client Protocol (DCC2) File Transfers

The Direct Client Connection 2.0 (DCC2) is a specification currently under development by the Client Connection 2.0 community. DCC2 creates a framework for standardized connection negotiation between IRC clients. DCC2's design allows clients to automatically negotiate acceptable connection parameters, and makes it possible for users' clients to review the parameters and automate decision-making in the connection negotiation process. For more information on the DCC2 specification please consult the DCC2 community documentation.

The current DCC protocol does not address IPv4 vs. IPv6 issues, SSL/TLS encryption negotiation, NAT and Firewall traversal, and multiple file/directory file transfers. DCC file transfers are also flawed in requiring acknowledgement of received bytes during the transfer, something that the underlying TCP protocol already ensures. Many IRC clients have implemented extensions that try to solve these problems, but the result has been fragmentation of the DCC protocol. This fragmentation is to a point where only the most simple functions work between different clients. DCC2 has been introduced to solve these problems and insure interoperability between all IRC clients. The DCC2 negotiation system has also been designed to be extensible to incorporate future technological developments more easily that the original IRCII DCC implementation.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" in this document are to be interpreted as described in RFC-2119.

DCC2 allows IRC clients to negotiate connection settings using a handshake mechanism for agreement to protocol usage. Protocols available on the offering client are published to the receiving client. The receiving client can then reply to the offering client, listing the subset of the available protocols that must be used. The receiving client also has the option to open the connection if the offering client cannot accept incoming connections. The available protocols and options are presented as a list of space separated tokens or token=value pairs. These tokens are standardized and listed here. Additional tokens can be added through the DCC2.org community process.

Single file transfers are initiated over IRC using the DCC2 negotiation protocol. File name, size, and an optional offset are exchanged via IRC messages. This exchange is covered in the DCC2 negotiation documentation. After a TCP connection has been established, the offering client sends all the bytes of the file to the receiving client. The receiving client reads bytes from the connection until SIZE bytes have been read. In the case of an offset, the client will read SIZE-OFFSET bytes. When all bytes have been transferred, the receiving client must close the connection.

With a file transfer established outside of IRC, it is possible to send multiple files and directories since message length is not restricted. This is useful for sending multiple files without possibly being kicked off an IRC server for flooding, or for sending documents in a directory structure. With additional file metadata, file hashes can optionally be obtained and checked. Privacy is also increased since file name and size information can be transferred directly between clients without revealing information to a IRC server. For added privacy, file transfers can optionally be encrypted.

After a TCP connection has been established, the offering client sends all the bytes of the Multi File header description to the receiving client. The receiving client reads the header description and sends requests for files over the connection using an identifier, or an identifier and an offset. The offering client sends the bytes of the requested files in the order the requests arrived. When the receiving client has received a the files that it wants from the published files list, the receiving client sends a complete message and closes the connection.

The DCC2 MULTI protocol allows the receiving client to request a file from a published set, resuming of a file in a published set, and the ability to end a session. Only the receiving client may send any commands over the connection. All messages end with the newline character. The offering client must not send any command syntax. The syntax follows, specified using ABNF rules (as per RFC2234):

dcc2-multi = dcc2-multireq | dcc2-multiend LF dcc2-multireq = `SEND FILE=' 1*(alpha|digit) [ space 'OFFSET=' 1*digit ] dcc2-multiend = 'COMPLETE'

Example Receiving client commands SEND FILE=0 SEND FILE=1 OFFSET=3429342 SEND FILE=2 COMPLETE

The header defines all files that are present in a file transfer. Each file consists of a series of name:value pairs of metadata. Each file section is seperated by a double newline. The syntax follows, specified using ABNF rules (as per RFC2234):

multi = file-section 0*(LF LF file-section) file-section = header-section 0*(header-section) header-section = 1*(alpha | digit | '-') ':' SPACE header-value LF header-value = 1*(%x01-09 | %x0B-7F)

A unique value in this header, used to request a file.

A file name, or a relative path and file name.

The file size in bytes.

A human readable file description.

A SHA1 file hash, as described by RFC 3174.

The MIME type of the file.

Example Header document:

Ports under 1024 are privileged on most systems, and should not be used for direct client connections. IRC client writers should be careful with directory structures when dealing with file sharing operations. Relative paths can using ../ can lead to security risks IRC clients should look carefully at the speed of sending DCC2 REFUSED and DCC2 CANNOTACCEPT due to the potential for flooding attacks. When possible the messages should be sent to give the user context as to why the transfer failed

This draft is also present on the DCC2 site at the address http://www.dcc2.org/specifications/draft-smith-irc-dcc2-files-00.txt. Enriched HTML and XML versions can be found at the addresses http://www.dcc2.org/specifications/draft-smith-irc-dcc2-files-00.htm and http://www.dcc2.org/specifications/draft-smith-irc-dcc2-files-00.xml respectively. The XML version is compliant to RFC-2629.

This draft was produced by the DCC2 community; please see authors and contributors. Thanks to Marshall Rose for his conversion tools from the RFC-2629 XML format to HTML and RFC.