Attached is the first Internet Draft of the Unified RFC Protocol. IETF 54
is long over and the mailing lists need something else to talk about...so
here is something to discuss.
The IETF Secretariat should note that Shining Light Productions has
implemented the Unified RFC Protocol into the ProtoNova Web Server
providing standardized remote module support for the server. The IETF
Secretariat should also note that the Unified RFC Protocol is not
necessarily a lock-step protocol (like SMTP, POP3, and other protocols),
although the document is written in such a fashion.
The ProtoNova Web Server is available as a Shining Light Productions
commercial product and people are already using the server given that it
has only been 24 hours since its release. As such, the ProtoNova Web
Server demonstrates that the Unified RFC Protocol is a viable communication
protocol for generic data transfer and data packaging purposes as well as a
potential replacement protocol for ailing, ancient, and insecure protocols.
While the document I am submitting is probably not 100% perfect, it should
be close enough for accepting it as a first draft.
INTERNET-DRAFT
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
??? Working Group T. Hruska
Category: Internet Drafts Shining Light Productions
June 2002
*********************** The Unified RFC Protocol ***********************
1. Abstract.........................................................2
2. Introduction.....................................................2
3. The Unified RFC Protocol.........................................2
3.1 Assumptions...................................................2
3.2 Protocol Preservation.........................................3
3.3 Command/Response Sequence.....................................3
3.4 Initial Communication.........................................4
3.5 Server Information............................................5
3.6 Data Transfer.................................................5
3.7 Transfers over SSL/TLS........................................5
3.8 Command Help..................................................6
3.9 Unknown Lengths...............................................6
3.10 Closing Communication........................................7
3.11 Sample Transactions..........................................7
3.12 Coding Tips..................................................8
3.13 Security Considerations......................................9
4. Credits.........................................................10
5. Conclusion......................................................11
Hruska Internet Draft [Page 1]
Internet-Draft Unified RFC Protocol June 2002
1. Abstract
The goal of this Draft is to define a single protocol that envelops
all RFCs of the past, present, and future. This document describes
communication across the Unified RFC Protocol, preserving ancient
protocols, and a framework for new protocols.
2. Introduction
Developers everywhere work with Internet RFCs every single day
writing slightly different code to do the exact same thing. Whether
the protocol is SMTP or HTTP, each one is exactly the same in nature.
However, each protocol is different enough to warrant writing a
completely new code base to do something so simple as retrieve and send
data. To complicate matters even more, most protocols are stagnant and
are unable to be expanded upon due to lack of security and
backwards-compatability issues. Also, many protocols have been
"hacked" in the sense that, for instance, to transmit an attachment
across SMTP requires encoding the file using Base64 (which increases
the file size by one-third) or UUEncode and using MIME headers with an
SMTP header "hack".
Obviously, SMTP is not the only ailing protocol. It quickly becomes
apparent that something needs to be done without interfering with the
current (ancient) technologies. What follows this section is the first
Internet Draft under which any type of transaction can take place.
Under the Unified RFC Protocol, mail can be sent, webpages retrieved,
files transferred all with one base protocol. Thus, the
programmer/developer only has to write one code base and every protocol
based on the Unified RFC Protocol is readily supported.
3. The Unified RFC Protocol
The goal of this protocol is to unify the separate RFCs into one
combined protocol in such a way as to not interfere with the
aforementioned ancient technology, but provide a jump point for all
clients and servers to move quickly away from the old RFCs into more
robust, more secure, more expandable environments.
3.1 Assumptions
1 bit = a zero (0) or a one (1).
1 byte = 8 bits.
ASCII is the ONLY communication character set (not EBCDIC or any
other character set...this means that the programmer for such
systems will have to use a translation table to and from ASCII).
RAW is defined as a series of bytes of data. RAW is used for the
transmission of data.
The end of a line is a <cr><lf> in ASCII.
Hruska Internet Draft [Page 2]
Internet-Draft Unified RFC Protocol June 2002
3.2 Protocol Preservation
Obviously, no one likes change. So, to make the move simpler and
easier, all formerly defined protocols will be preserved by providing
_minimal_ functionality for that protocol. New protocols and changes
to old protocols are required to base their documentation on the
Unified RFC Protocol.
3.3 Command/Response Sequence
When a command is sent, the server will respond to it. The proper
form of a client command request is:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
CommandName<cr><lf>
NumberOfBytesOfAdditionalData<cr><lf>
Additional Data or Information goes here
Where CommandName is the name of a recognized command.
NumberOfBytesOfAdditionalData is the number of bytes that will follow
the <cr><lf> pair.
Beyond the third line, RAW data may or may not follow depending on
the value in the third line. Note that RAW data may or may not be
"chunked" (see section G on unknown lengths and large amounts of data).
Once a command is issued, the server will respond in this fashion on
an 'OK' response:
**** UNIFIED RFC PROTOCOL SomethingUsuallyHere ****<cr><lf>
OK CommandName command valid. Some string goes here<cr><lf>
NumberOfBytesOfAdditionalData<cr><lf>
Additional Data or Information goes here
However, if the server determines that there is an error either in
the command or in general, it will reply in this fashion:
**** UNIFIED RFC PROTOCOL ERROR ****<cr><lf>
ERR CommandName command invalid. Some string goes here<cr><lf>
NumberOfBytesOfAdditionalData<cr><lf>
Additional Data or Information goes here
The only thing required to be standard are the <cr><lf>'s and
'OK'/'ERR' responses. So, an okay response could just be (depends on
the situation):
**** UNIFIED RFC PROTOCOL ****<cr><lf>
OK<cr><lf>
0<cr><lf>
Therefore, the only reliable things for a response from the server
are three lines of data. The first line consists of the declared base
protocol (should always be a case-insensitive "UNIFIED RFC PROTOCOL").
The second line consists of either an 'OK' or an 'ERR'. The third line
consists of the number of bytes of additional information (RAW data)
beyond that line that can be read by the client.
Hruska Internet Draft [Page 3]
Internet-Draft Unified RFC Protocol June 2002
3.4 Initial Communication
The first question any programmer will ask is how to handle the issue
of sending and receiving the initial data. This is a difficult issue
to deal with because the default protocol (if any) is being overridden.
So, the following steps are to be taken to determine if the server
supports the Unified RFC Protocol or not:
1) The client sends the server a communication request:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Start<cr><lf>
0<cr><lf>
2) The client then waits for a response from the server. The proper
server response to this request is:
**** UNIFIED RFC PROTOCOL READY ****<cr><lf>
OK Start command valid. Welcome message follows.<cr><lf>
74<cr><lf>
Welcome to the local web server!<cr><lf>
We hope that you will enjoy your stay!<cr><lf>
3) If the client/server times out or returns an improper response, the
server does not support the Unified RFC Protocol. At that point,
the client should revert to ancient methods of communication.
4) Assuming the communication succeeded, the client needs information
on how to communicate with the server. So, the client must send:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
RetrieveCommands<cr><lf>
0<cr><lf>
5) The server then replies with a list of allowed commands at this
point:
**** UNIFIED RFC PROTOCOL COMMANDS ****<cr><lf>
OK RetrieveCommands command valid. Data follows.<cr><lf>
7<cr><lf>
Login<cr><lf>
6) If a client does not understand any of the commands, it may not
communicate with the server.
Hruska Internet Draft [Page 4]
Internet-Draft Unified RFC Protocol June 2002
3.5 Server Information
Obviously, it can be useful to obtain information about a server.
Particularly, timeouts, the primary server name, the server IP address,
etc. To obtain this information (for display only...not to be used for
any authentication purposes), the client must send:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
GetServerInfo<cr><lf>
0<cr><lf>
The server must respond with proper information in the fields:
**** UNIFIED RFC PROTOCOL SERVER INFORMATION ****<cr><lf>
OK GetServerInfo command valid. Information follows.<cr><lf>
209<cr><lf>
Server Name: MyWebServ<cr><lf>
Server Address: www.mywebsite.com<cr><lf>
Server IP: 185.23.4.10<cr><lf>
Server Type: HTTP under the Unified RFC Protocol<cr><lf>
Server Port: 80<cr><lf>
Max Header: 255<cr><lf>
Max Command: 255<cr><lf>
Max Data: 4096<cr><lf>
3.6 Data Transfer
Raw data may be transferred over the connection using the additional
data section. If the server or client determines that too much data is
being sent (usually through some sort of configuration mechanism),
either side may drop the connection.
3.7 Transfers over SSL/TLS
In today's world there needs to be security. However, SSL/TLS only
allows for IP-based virtual hosting (e.g. HTTP/1.1). So, to overcome
this issue, the Unified RFC Protocol declares itself to be superior to
SSL/TLS and therefore SSL/TLS must run _UNDER_ the Unified RFC
Protocol. Based on this, the following command is added to tell
SSL/TLS or other server/protocol which certificate chain/virtual host
to use:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
SetServerInfo<cr><lf>
41<cr><lf>
Host: www.myvirtualhost.com<cr><lf>
Port: 80<cr><lf>
If the command is valid, the server must reply:
**** UNIFIED RFC PROTOCOL SET SERVER ****<cr><lf>
OK SetServerInfo command valid. Server information set.<cr><lf>
0<cr><lf>
The SSL/TLS protocol will then use the certificate chain for
'www.myvirtualhost.com' for that communication. This stops
man-in-the-middle attacks since changing the host will change the
certificates returned, which can be verified using standard host
matching from the certificate.
Hruska Internet Draft [Page 5]
Internet-Draft Unified RFC Protocol June 2002
3.8 Command Help
All servers implementing the Unified RFC Protocol are required to
provide detailed instructions on each command when the HELP command is
sent by the client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
HELP Login<cr><lf>
0<cr><lf>
The server replies:
**** UNIFIED RFC PROTOCOL COMMAND HELP ****<cr><lf>
OK HELP Login command valid. Details on this command follow.<cr><lf>
162<cr><lf>
The 'Login' command is used to gain access to restricted
resources.<cr><lf>
If you are logging in from a console, you will be stepped through the
process by the server.<cr><lf>
3.9 Unknown Lengths
The server may not always know the length of the data that it is
returning. This is particularly true for large data sets. To help
ease this problem, the server is allowed to transfer the data to the
client in pieces. The header is required as usual, but the raw data
can be tranferred in pieces. This piecemeal transaction method could
occur as early as the initial handshake:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Start<cr><lf>
0<cr><lf>
The server replies:
**** UNIFIED RFC PROTOCOL READY ****<cr><lf>
OK Start command valid. Welcome message follows.<cr><lf>
=34<cr><lf>
Welcome to the local web server!<cr><lf>
=4<cr><lf>
We h
36<cr><lf>
ope that you will enjoy your stay!<cr><lf>
The client may also send data of unknown length to the server in the
same fashion:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
SetServerInfo<cr><lf>
=32<cr><lf>
Host: www.shininglightpro.com<cr><lf>
11<cr><lf>
Port: 80<cr><lf>
The server replies:
**** UNIFIED RFC PROTOCOL SET SERVER ****<cr><lf>
OK SetServerInfo command valid. Server information set.<cr><lf>
0<cr><lf>
Hruska Internet Draft [Page 6]
Internet-Draft Unified RFC Protocol June 2002
3.10 Closing Communication
When all communications with the server are finished, the client
sends:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Quit<cr><lf>
0<cr><lf>
The server replies:
**** UNIFIED RFC PROTOCOL EXITING ****<cr><lf>
OK Quit command valid. Exiting.<cr><lf>
10<cr><lf>
Goodbye!<cr><lf>
Both ends drop the connection and communication is finished.
3.11 Sample Transactions
The following is a sample transaction with a HTTP server under the
Unified RFC Protocol (NOTE: Until the HTTP protocol is re-designed to
work under the Unified RFC Protocol, this is to be used only as an
example and not as an actual communication):
<Client establishes a connection with a server>
Client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Start<cr><lf>
0<cr><lf>
Server:
**** UNIFIED RFC PROTOCOL READY ****<cr><lf>
OK Start command valid. Welcome message follows.<cr><lf>
74<cr><lf>
Welcome to the local web server!<cr><lf>
We hope that you will enjoy your stay!<cr><lf>
Client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
RetrieveCommands<cr><lf>
0<cr><lf>
Server:
**** UNIFIED RFC PROTOCOL COMMANDS ****<cr><lf>
OK RetrieveCommands command valid. Data follows.<cr><lf>
19<cr><lf>
Login<cr><lf>
GetWebPage<cr><lf>
Client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
SetServerInfo<cr><lf>
43<cr><lf>
Host: www.shininglightpro.com<cr><lf>
Port: 80<cr><lf>
Server:
**** UNIFIED RFC PROTOCOL SET SERVER ****<cr><lf>
OK SetServerInfo command valid. Server information set.<cr><lf>
0<cr><lf>
Hruska Internet Draft [Page 7]
Internet-Draft Unified RFC Protocol June 2002
Client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
GetWebPage<cr><lf>
29<cr><lf>
/<cr><lf>
19<cr><lf>
Connection: close<cr><lf>
0<cr><lf>
Server:
**** UNIFIED RFC PROTOCOL HTTP WEBPAGE ****<cr><lf>
OK GetWebPage command valid. Webpage follows.<cr><lf>
1746<cr><lf>
<Raw data goes here>...
Client:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Quit<cr><lf>
0<cr><lf>
Server:
**** UNIFIED RFC PROTOCOL EXITING ****<cr><lf>
OK Quit command valid. Exiting.<cr><lf>
10<cr><lf>
Goodbye!<cr><lf>
3.12 Coding Tips
Writing a client/server pair for the Unified RFC Protocol is simple.
Using the C/C++ language and BSD-style sockets, a single set of
functions can be written that both the client and server can use.
Shining Light Productions has a fully functional set of functions
(500 lines of C code) that perform the necessary communications across
the Unified RFC Protocol. The function names and what each one does is
listed below (from Shining Light Productions' closed source,
proprietary library LibLink):
InitUnifiedRFC - Performs initialization of a generic socket
structure for use with the other Unified RFC Protocol functions.
Returns 1 if allocation and initialization was successful, 0 on error.
CloseUnifiedRFC - Cleans up Unified RFC Protocol specific items from
the generic socket structure in preparation for another connection or
shutdown. Returns 1 if successful, 0 on error.
SetUnifiedRFCServer - Sets the server and port to connect to.
Returns 1 if successful, 0 on error.
OpenUnifiedRFCConnection - This is a client-specific function that
opens the connection to a server and performs the initial handshake.
Returns 1 if the connection and handshake were successful, 0 if either
one failed.
CloseUnifiedRFCConnection - This is a client-specific function that
sends the closing communication message, retrieves the response, and
closes the connection. Returns 1 if successful, 0 on error.
Hruska Internet Draft [Page 8]
Internet-Draft Unified RFC Protocol June 2002
GetUnifiedRFCResponse - This function can be used both by clients and
servers when getting data across the Unified RFC Protocol. Six
different "Modes" (or "States") are used by this function to determine
what to do next:
1) Header ("**** UNIFIED RFC PROTOCOL ****")
2) Command/Response
3) Size of Additional Data
4) Additional Data (Unknown Length data)
5) Final Data
6) Communication Completed
This function reads in data each time and processes as much of it as
it can. Whenever the function returns and Additional Data exists, the
Additional Data should be stored/processed as it will be destroyed on
the next function call. This function returns 1 on success, 0 on error
or if the server/client disconnected.
SendUnifiedRFCCommand
SendUnifiedRFCData
SendUnifiedRFCCommandData
The three functions above can be used by both the client and server
for sending commands/responses. The first two are designed to send
data of unknown length in small pieces. The last function sends data
in one complete package all at once. All of them return 1 on success,
0 on error.
3.13 Security Considerations
Obviously, no protocol exists without its own security implications.
The major thing to remember is that any implementation of the Unified
RFC Protocol may disconnect (either server or client) at any point that
either deems the other to be invalid or not following the protocol
correctly.
The first security consideration any developer must take into account
is illegal requests from clients. Particularly buffer underflows and
overflows. For example, the following request is to be considered
malicious:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Login<cr><lf>
-1<cr><lf>
Hruska Internet Draft [Page 9]
Internet-Draft Unified RFC Protocol June 2002
All servers can either respond with an 'ERR' response or disconnect
from the client. A disconnect is probably preferred when a request has
harmful intent such as the aforementioned buffer underflow. A buffer
overflow request such as:
**** UNIFIED RFC PROTOCOL ****<cr><lf>
Login<cr><lf>
50000000000000000000000000000000000<cr><lf>
Should also be considered malicious and appropriate action taken.
Also, overflows can occur in the first two lines of a request:
**** UNIFIED RFC PROTOCOL adsfasdfasfdasdf...adsfasdfasdfasdf ****
<cr><lf>
MySuperDuperUltraLongCommandWouldProbablyGoHereAndCrashTheServerOrBring
ItToItsKnees...<cr><lf>
123<cr><lf>
As with every protocol, timeouts on both servers and clients should
be implemented for every connection to avoid consuming resources for an
extended amount of time. For instance, if the previous request did not
send 123 bytes of data, the connection should close after a while.
Finally, buffers should be limited to a certain maximum size set by
the server. These sizes can be determined by the client via the
GetServerInfo command. If the maximum size is exceeded by the client,
the server should drop the connection.
4. Credits
Name E-mail Address
-----------------------------------------------------------------------
Thomas J. Hruska shinelight@shininglightpro.com
Hruska Internet Draft [Page 10]
Internet-Draft Unified RFC Protocol June 2002
5. Conclusion
This document is being submitted to both the IETF as an Internet
Draft and placed on the Shining Light Productions website under the
Shining Light Productions Open Documentation Agreement with full
modification and distribution rights given to the IETF.
Shining Light Productions hopes that this document will spur on an
Internet RFC to quickly form and eliminate ancient protocols with more
secure, robust, and easy to use protocols with a standard set of
library functions.
Legal Note: This document is subject to the Shining Light Productions
Open Documentation Agreement ("SLPODA").
Shining Light Productions is the claimant and holder of
Copyright of this document.
Shining Light Productions grants the Internet Engineering
Task Force ("IETF") unrestrictive rights to use, modify,
distribute, and create derivative works of this document.
Signed,
Thomas J. Hruska
shinelight@shininglightpro.com
Shining Light Productions
"Meeting the Needs of Fellow Programmers"
(C) 2002 Shining Light Productions
Hruska Internet Draft [Page 11]
Thomas J. Hruska -- shinelight@shininglightpro.com
Shining Light Productions -- "Meeting the needs of fellow programmers"
http://www.shininglightpro.com/