Subject: Unified RFC Protocol...

From: "Thomas J. Hruska" <[email-masked]>
Date: Thu, 01 Aug 2002 17:55:24 -0400

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.

          Thomas J. Hruska -- [email-masked]
Shining Light Productions -- "Meeting the needs of fellow programmers"
                  http://www.shininglightpro.com/

---

From: "Thomas J. Hruska" <[email-masked]>
Date: Thu, 01 Aug 2002 19:10:33 -0400

>here is something to discuss.
<snip>

Is anyone else getting duplicates of this?  I sent it only one time and it
has appeared three times in my in-box.  I realize I sent it to the wrong
location, although it is good discussion material.

Again, I don't know what is going on, but I apologize for sending it to the
wrong location in the first place.

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 1 Aug 2002 21:08:49 -0500

On 8/1/02, Thomas J. Hruska wrote:

>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.
>

There is indeed a wealth of simplification that could be
accomplished with many of the common internet application
layer protocols.

However this is not the time to fix those problems. No true
simplification will result. Every new client would have to
be compatible with old and new servers. Every new server
would have to be compatible with old and new clients.

No matter how elegant the new protocol was defined,
implementations would still be additional logic, new cases
for network monitors to learn, additional test cases and
additional points of failure.

The appropriate time to consider consolidation of
application layer protocols might be when client and server
changes would be required anyway. When the Remote Direct
Data Placement (RDDP) work is completed it might be worth
considering a consolidation for the RDDP-optimized versions
of the applications this proposal cites.

Because of the indefinite transition problems, a mere
cleanup will only add logic, not subtract it. Combining a
consolidation with the work to standardize application
specific use of RDDP capabilities would be a different
matter.

---

From: Timur Shemsedinov <[email-masked]>
Date: Fri, 2 Aug 2002 16:41:09 +0300

Friday, August 02, 2002, 12:55:24 AM, you wrote:

TJH> Attached is the first Internet Draft of the Unified RFC Protocol.  IETF 54
TJH> is long over and the mailing lists need something else to talk about...so
TJH> here is something to discuss.

  General purpose of your draft is quite clear for me. Many protocols
  can be presented as remote procedure call (RPC) and can be unified.
  But historically all protocols are different. Alteration of STD or
  BCP protocols or something settled long time ago (FTP, SMTP, POP3,
  HTTP etc.) is not possible at all, since it will demand of
  alteration of all software, (servers and operational systems).
  But unification of new protocols is good task if purpose of those
  protocols is exactly RPC. Necessity of such RPC standard frequently
  feels applied software developers. They use either RPC protocols
  from large corporations (as SOAP or DCOM) or develop something
  non-standard. Corporate standards frequently are not open.
  Certainly, it would be great to see unified standard of RPC in
  the near future. Probably, it is preferably to create new working
  group in IETF to develop such protocol. SOAP is based on XML
  (markup language) and does not approach for those purposes. It
  can be usable only to interaction between Web application through
  HTTP, but nowise to be RPC standard. However, main idea of SOAP is
  very useful. Parameters and results of RPC calls can be structurally
  complex objects constructed in hierarchy. Since 1999-2000 RIST
  (research institute of system technologies, Ukraine, Kiev) developed
  such protocol (USP - Universal Service Protocol). We use it for
  communication with Object-Oriented database server (UOD) and for
  other tasks where object transmission and RPC is needed. The fourth
  version of USP specification is available here:
  http://search.ietf.org/internet-drafts/draft-shemsedinov-usp-03.txt.
  I understand that it is still rather crude, since it lags behind
  the real project. I think, if you will read this document, you
  will found in it many things for solving such problems as in
  your project.

-- 
Best regards,
 Timur                            mailto:[email-masked]

---

From: "Thomas J. Hruska" <[email-masked]>
Date: Fri, 02 Aug 2002 12:30:31 -0400

At 05:25 PM 8/2/2002 +0200, JFC (Jefsey) Morfin writeth:
>I like the idea. I am not good enough to respond on the public list. Might 

I highly doubt this list does not welcome new people to the list.  Being
"good enough" is just in your own imaginative mind.  As far as I know,
people are allowed to express their own opinions on new protocols on this
list (that's what it is here for).  Personally, I welcome any new ideas and
suggestions on this particular draft.

>I suggest that a good thing would be to try to test the concept with a few 
>simple applications? They would then serve as examples for developpers. I 
>am considering ways to address the following two problems which might be 
>generic needs (support under MS, MAC and Linux) and the occasion to include 
>librairies for theses platforms?

Shining Light Productions is thinking of providing full ANSI-C source for
the functions listed in the implementation section.  This would allow
developers to cut-and-paste the code into their applications...allowing for
ultra-fast development.  Also, sample server and client code would be
added.  However, the Company still has yet to decide if releasing portions
of LibLink will occur since much time was spent crafting the socket section.

This concept is already implemented in the commercial ProtoNova Web Server.
 If people just want to check it out to see that it really works, they can
download and install the software.

The protocol is generic enough that it will probably work on any network
stack.  So, Windows, Linux, Macintosh, OpenBSD, and anything with
networking support will work fine with the Unified RFC Protocol.

>1. to have a direct interface to a web service on my screen. Able to be 
>interactive and to support file transfer (printing, filing). I suppose this 
>is something you know doing may be off the shelves?

I'm not exactly sure what you are wanting to do here.  Perhaps you can
clarify what you mean by being "interactive."  The Unified RFC Protocol is
designed to be readable by Telnet clients (up to the point of RAW data).
The Unified RFC Protocol is optimal for data transfers like those found in
FTP...however, the protocol I've defined is far more versatile and robust
than FTP.

>2. to resolve the DNS on a remote server in the background (intercept the 
>request, resolve and enter the IPs) without having to change the used PC, 
>MAC, Linux station parameters (this is to study a secure DNS resolution 
>scheme): a plug-in + relation with the server.

Again, I'm not quite sure what exactly you want to do with the protocol
here and clarification is needed.

>A question: the protocol is quite readable. But is there no room for saving 
>space in the header?

The header is not likely to change because it guarantees that the protocol
is still functional and the server/client hasn't gone haywire.  Granted it
consumes quite a bit of space, but if space is an issue (e.g. via UDP), a
positive response packet can be reduced to a minimum of 39-50 bytes.

Hope this helps!

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Aug 2002 10:05:14 -0400

Timur Shemsedinov wrote:

>  But unification of new protocols is good task
>
>
Yeah, but that's what BEEP's for--and we don't need *two* unification
protocols.  :-)

-- 
/================================================================\
|John Stracke      [email-masked]                       |
|Principal Engineer|http://www.centivinc.com                     |
|Centiv            |My opinions are my own.                      |
|================================================================|
|"What now, Brain?" "We should flee in terror. Yes, that would be|
|the wisest course."                                             |
\================================================================/

---

From: Timur Shemsedinov <[email-masked]>
Date: Tue, 6 Aug 2002 16:49:49 +0300

Friday, August 02, 2002, 5:49:11 PM, you wrote:
TJH> Well, the Unified RFC Protocol can be used for RPCs, but that is a fairly
TJH> limited view of it (perhaps you misread 'rfc' as 'rpc'?).

  There is no any misreading. I really mean RPC, since I interpret it
  as the protocol of dialogue between Client and Server, i.e. sequence
  of inquiry and answer. Besides, USP supports some more then dialog.
  Events, it is packets, generated by server without client's inquiry.
  Events are notifying clients about status/mode/data changing.
  USP allows packing and transferring any information as well. But it
  describes not only the format of RCP; USP also regulates the unified
  format of data representation. Thus application can unpack and
  represent answers of any USP-based protocol to the user or store
  them to object-oriented database. This format of data representation
  is readable (it is similar XML but short-spoken). It is possible to
  describe any objects and data with its help. The unification of data
  representation is another degree of unification and protocol's
  integration than unification of call/response only. Besides one USP
  server can share some affiliated protocols and the client can switch
  between those sub-protocols as between interfaces. In this case
  saying "interface", I mean set of functions.

---

From: Timur Shemsedinov <[email-masked]>
Date: Tue, 6 Aug 2002 17:44:21 +0300

Concerning the project:

Friday, August 02, 2002, 12:55:24 AM, you wrote:
TJH> 1.  Abstract
TJH> The goal of this Draft is to define a single protocol that
TJH> envelops all RFCs of the past, present, and future.
TJH> This document describes communication across the Unified
TJH> RFC Protocol, preserving ancient protocols, and a framework
TJH> for new protocols.

  First of all I want to observe that RFC is not only
  specifications of the Telnet-compatible or TCP-based protocols.
  There are many RFCs describing binary data transfer and other
  technologies. So, it is absolutely incorrect to name your
  protocol "Unified RFC Protocol".
  Better to say "Unified Application Level Protocol".

TJH>**** UNIFIED RFC PROTOCOL ***
TJH>**** UNIFIED RFC PROTOCOL READY ****
TJH>**** UNIFIED RFC PROTOCOL COMMANDS ****
TJH>**** UNIFIED RFC PROTOCOL COMMAND HELP ****

  I suppose it is possible to reduce such lines.

TJH> **** UNIFIED RFC PROTOCOL READY ****<cr><lf>
TJH> OK Start command valid.  Welcome message follows.<cr><lf>
TJH> =34<cr><lf>
TJH> Welcome to the local web server!<cr><lf>
TJH> =4<cr><lf>
TJH> We h
TJH> 36<cr><lf>
TJH> ope that you will enjoy your stay!<cr><lf>

  So, you can not use "=" in raw data at the line begin?

---

From: Timur Shemsedinov <[email-masked]>
Date: Tue, 6 Aug 2002 18:04:12 +0300

Friday, August 02, 2002, 6:25:58 PM, you wrote:
JJM> I like the idea.
JJM> Might I suggest that a good thing would be to try to test the
JJM> concept with a few simple applications? They would then serve
JJM> as examples for developpers.

  The examples and sources and APIs for different platforms are not
  connected with RFCs or IETF.
  But ours research institute offers open-source libraries on
  ObjectPascal/Delphi for USP protocol, about which I have mentioned
  in connection with a current subject. In near future we are going to
  provide developers with Java API and C ++ libraries.