INTERNET-DRAFT J. Guerin Intended Status: Proposed Standard Independent Expires: December 3, 2011 June 1, 2011 Pay It Proper Protocol -- PIPP draft-jguerin-pipp-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 Comments are solicited and should be addressed to the author at jguerin@shootingsoul.com Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. J. Guerin Expires December 3, 2011 [Page 1] INTERNET DRAFT PIPP June 1, 2011 Abstract The Pay It Proper Protocol (PIPP) is an application-level network protocol for inter-process communication that defines a universal Turing machine. PIPP introduces the concept of a sub stream to the traditional network stream allowing instructions and data to be streamed on a single tape. All processes on a sub stream aware network are programmable against instruction sets allowing for more expressive languages and compilers to be developed. PIPP is designed to be the universal bootstrapping protocol and instruction format for the Internet until more advanced protocols, compilers and formats are developed. This RFC defines sub streaming and the PIPP protocol. A proof of concept has been implemented, and a sample instruction format and some implementation details are also discussed. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Sub Streaming . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Implementation Considerations . . . . . . . . . . . . . . . 4 2.2 Instruction and Data Considerations . . . . . . . . . . . . 5 3 Pay It Proper Protocol . . . . . . . . . . . . . . . . . . . . . 5 3.1 End Point to End Point . . . . . . . . . . . . . . . . . . . 6 3.1.1 Frame Header Format . . . . . . . . . . . . . . . . . . 6 3.2 End Point to Output Main Stream and Output Sub Stream . . . 7 3.3 End Point to Input Main Stream and Input Sub Stream . . . . 7 3.4 Design Considerations . . . . . . . . . . . . . . . . . . . 8 3.4.1 Separation of Concerns . . . . . . . . . . . . . . . . 8 3.4.2 Inclusiveness . . . . . . . . . . . . . . . . . . . . . 8 3.4.3 Anticipation of Change . . . . . . . . . . . . . . . . 8 4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 String Instruction Format . . . . . . . . . . . . . . . . . 9 4.2 Browser and Operating System . . . . . . . . . . . . . . . 9 4.3 Language Design . . . . . . . . . . . . . . . . . . . . . 10 4.3.1 Destructors . . . . . . . . . . . . . . . . . . . . . 10 4.3.2 Exception Handling . . . . . . . . . . . . . . . . . 10 6 Security Considerations . . . . . . . . . . . . . . . . . . . 11 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . 12 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 J. Guerin Expires December 3, 2011 [Page 2] INTERNET DRAFT PIPP June 1, 2011 1 Introduction PIPP uses sub streaming to allow instructions and data to be streamed on the same tape. This creates a Turing machine allowing for languages and compilers to be developed for processes connected on the Internet. Each process connected on the network can be thought of as a finite state machine that communicates with other processes on the network by streaming instructions and data. The concept of sub streaming can and should be applied to other network protocols. The focus of PIPP is on bootstrapping and universal communication. Applications can define their own instructions in a standard, recommended format allowing for communication between processes. This will be sufficient for the short term. Eventually, applications will use higher level languages with compilers creating instructions in optimized formats relegating PIPP to the dust bin of computing history along side punch cards. However, just as the concept of the stored computer program is still in use today, the concept of sub streaming will be around for a long time. There is a working proof of concept that implements PIPP. PIPP is used to directly stream data into and out of a database over TCP using java. The data is optionally compressed. PIPP is also used in a javascript web site to communicate to the same java server over HTTP. The same exact java server code communicates with either the javascript client or the java client. The java client is optimized to used compressed streaming over TCP, while the javascript client does no compression and uses HTTP with simulated streaming similar to packet switching. The java server code does not care if it is a nice direct TCP stream or a clunky HTTP request/response flow. PIPP properly abstracts away the details of the network stack from the application code. This illustrates how universal and expressive PIPP is. The server code is modeled as a finite state machine, and there are practical concerns and limitations. In order to be compatible with HTTP communication, the automata must be capable of a single entry/exit point and complete within HTTP timeout and message size constraints in order to actually run over HTTP. A persistent TCP connection can use more advanced states and stream more data. In short, PIPP streams instructions and data between processes making the Internet a universal Turing machine. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this J. Guerin Expires December 3, 2011 [Page 3] INTERNET DRAFT PIPP June 1, 2011 document are to be interpreted as described in RFC 2119 [RFC2119]. The grammatical rules in this document are to be interpreted as described in RFC 5234 [RFC5234]. 2 Sub Streaming Sub streaming creates the concept of a single main stream and a single sub stream. It's all the same stream, just given a very basic structure. The main stream can give control of the stream to the sub stream, and the sub stream can give control back to the main stream. This allows creation of a Turing machine by using the main stream for instructions and the sub stream for data on the same stream. Since the sub stream is itself a stream, you can recursively define Turing machines all on a single original stream. This is not to be confused with multiplexing which creates separate, independent streams on a stream. There is no communication between the streams being multiplexed. The subtle communication of control between main and sub stream makes all the difference in this world :) It's useful to think of an application as a main stream of instructions. So one application communicates with another application and eventually they want to work with data. Sub streaming allows an application to simply transfer control of the stream to the data stream. So app "A" main stream gives control to app "A" data sub stream to be given to app "B" main stream for processing. Once app "A" data sub stream reaches its end of sub stream, control is given back to app "A" main stream. Now app "A" main stream and app "B" main stream are communicating with each other again. What just happened is a continuous flow of instructions and data on the same stream between processes. Therefore the two process communicating together act as a universal Turing machine since they use the same stream for instructions and data. Processes can be added and removed creating one large, dynamic universal Turing machine. 2.1 Implementation Considerations Implementing this in a network protocol has a few issues to address. You need to identify data as belonging to either the main stream or the sub stream and make sure instructions and data are sent in a timely manner to prevent applications from hanging. At some point in the network stack, data is framed. In theory, you can minimally define a frame with zero data as the end of the sub stream and trust the application to transfer control accordingly. This is fine for applications that behave perfectly when opening and closing sub streams. In practice, you have the issue of stream J. Guerin Expires December 3, 2011 [Page 4] INTERNET DRAFT PIPP June 1, 2011 stomping and stream leaking. A data sub stream may try to read main stream instructions or a data sub stream may close early and leave it's data on the stream to be treated as instructions. The goal is to protect the main instruction stream against such issues. This is achieved by using a stream type indicator in the frame header. You have three types: main stream, sub stream or end of sub stream. The end of sub stream frame also has 0 data. This is sufficient to guard against stream stomping and leaking to protect the main application instruction stream. Flushing is a concern. You can't have an application waiting for data or instructions that are buffered at the other end point. A simple solution is to flush after each instruction and flush on the close of a data sub stream. This is fine for simple inter-process communication. Once compilers get involved creating large, complex instructions they can optimize flushing by grouping instructions together. Applications already have control over flushing the data sub stream, so the application logic can handle optimizing that. These are the general considerations that all network protocols need to address to implement sub streaming. 2.2 Instruction and Data Considerations The network protocol is not concerned with what bytes are on the main stream or data sub stream. It only provides the distinction for applications to use. Applications will process and interpret the instructions and data. Moreover, applications may mix instructions and data on the main stream. The framing of instructions is not part of the network protocol. Applications decide what instruction formats and sets to use and work with. Instruction framing can be done by using a well defined grammar or an instruction header with a size. Again, that is outside the scope of the network protocol. 3 Pay It Proper Protocol PIPP is designed to be run at the highest level of the network stack and defines sub streaming communication between two end-points. There is no handshake or connection process between end points, and no guarantees of message delivery or receipt. The protocol makes no distinction between client and server. The protocol is independent of the underlying transport layer and connection. The protocol itself is stateless. If an underlying persistent connection is available to allow for end points to freely communicate, then an application can take advantage of that situation. If a connection can only be initiated by one end point and stay open for a short time, then an application can work with that situation as well. J. Guerin Expires December 3, 2011 [Page 5] INTERNET DRAFT PIPP June 1, 2011 PIPP provides sub streaming leaving all other details to the underlying network stack and the applications themselves. Instruction formats are outside the scope of the network protocol. 3.1 End Point to End Point The following defines the requirements for a PIPP end point communicating with another PIPP end point. In general, the data must be framed by the end point with a standard header that defines the stream type and payload size. The end point places no requirements on the payload format or encoding. The only requirement is that the entire payload content MUST belong to the stream type indicated in the header. The frames MUST be sent and received in order. 1. MUST frame data starting with a PIPP header followed by payload 2. MUST have payload start on the byte following the header 3. MUST send/receive frames next to each with no gaps 4. MUST send/receive frames in order 5. MUST match entire payload contents to stream type 3.1.1 Frame Header Format The header MUST be a variable length sequence of UTF-8 encoded text conforming to the following grammar. The encoding is described in RFC 3629 [RFC3629]. In general, it's a single letter indicating the stream type followed by an integer in quotes representing the payload size. The header size is not explicitly given. header = stream-type payload-size stream-type = %x6D / ; m for main stream %x73 / ; s for sub stream %x74 ; t for end of sub stream payload-size = quotation-mark ;an integer in quotes digit * ( digit ) quotation-mark quotation-mark = %x22 ; " digit = %x30-39 ; a text number Payload Size Requirements 1. MUST be convertible to an integer 2. MUST NOT exceed 32767 numeric value 2. MUST match number of bytes in payload 2. MUST be zero for stream-type %x74 (end of sub stream) J. Guerin Expires December 3, 2011 [Page 6] INTERNET DRAFT PIPP June 1, 2011 3. MUST NOT be zero for stream-type %x6D / %x73 (main/sub stream) Header Samples m"42" ; frame of main stream data with 42 bytes s"243" ; frame of sub stream data with 243 bytes t"0" ; end of sub stream frame with no payload 3.2 End Point to Output Main Stream and Output Sub Stream The stream behavior is the same for writing and flushing bytes for an output main stream and output sub stream as the well known output stream. It's a continuous stream of bytes. The following requirements deal with how the end point manages sharing the stream between the main stream and sub stream. 1. MUST create a new frame when writing bytes for a different stream type. 2. MUST write a frame with end of sub stream type when closing a sub stream 3. MUST flush when closing a sub stream or a main stream It is left to applications and compilers to flush instructions on the main stream when needed. That is outside the scope of the network protocol. Moreover, applications may still use the main stream for data as well. 3.3 End Point to Input Main Stream and Input Sub Stream The stream behavior is the same for reading bytes for an input main stream and input sub stream as the well known input stream. It's a continuous stream of bytes. The following requirements deal with how the end point manages sharing the stream between the main stream and sub stream. 1. On a read request, end point MUST block until a frame is available unless the end of main stream has been reached. 2. When a read requests a main stream byte and the current frame is main stream a byte MUST be returned. 3. When a read requests a main stream byte and current frame is sub stream or end of sub stream, then the end point MUST skip all sub stream frames and end of sub stream frames until a main stream frame is reached. The end point blocks until a main stream frame or end of main stream is reached. J. Guerin Expires December 3, 2011 [Page 7] INTERNET DRAFT PIPP June 1, 2011 4. When a read requests a sub stream byte and the current frame is sub stream a byte MUST be returned. 5. When a read requests a sub stream byte and the current frame is main stream, then the end of stream indicator is returned and no frames or bytes are read from the stream. 6. When a read requests a sub stream byte and the current frame is end of sub stream, then the end of stream indicator is returned and no frames are requested from the stream. If the very next read request is also for a sub stream byte, then the next frame is read from the stream and processed accordingly. This allows two sub streams to be processed one after the other. 3.4 Design Considerations 3.4.1 Separation of Concerns PIPP is designed specifically for the task of inter-process sub streaming communication over the Internet. Authentication, compression, and so on are left to applications and outside the scope of a network protocol. For example, the proof of concept uses an end point application to build the underlying network stack and optionally use compression. 3.4.2 Inclusiveness PIPP is designed to allow as many applications as possible to communicate over the Internet. The design is minimal, yet still functional. Because of it's simplicity, resource limited applications can use it. No response is defined to allow for asynchronous communication between applications. Applications needing a synchronous response can use PIPP and wait for instructions in return. UTF-8 encoding allows for applications written in various languages to communicate with each other. 3.4.3 Anticipation of Change PIPP allows for peer to peer communication between web servers and eventually for client applications as improvements to telecommunications are made. In some cases, persistent connections are available and/or servers are able to initiate communication with clients. By being independent of the transport layer, PIPP can be used with new and improved network protocols as they are developed. 4 Recommendations J. Guerin Expires December 3, 2011 [Page 8] INTERNET DRAFT PIPP June 1, 2011 4.1 String Instruction Format Instruction formats and sets will be developed and driven by social and political influences. This section informally describes an instruction format that is very portable and similar to a command line argument or function call. The instruction is a text UTF-8 encoded string. In general, it's a string function name followed by list of option string arguments that must be enclosed with [ ]. This grammar can be parsed as instructions stream in, so an instruction header with a size is not needed. Strings are well understood. By not using any implicit numeric/boolean types applications know they will always be responsible for type conversion. Besides, why pretend it's not a text string. Nulls are supported for applications that need to make a distinction between null and a zero length string. A null is not in quotes where all other strings are in quotes. instruction = function-name arg-list function-name = quote escaped-string quote arg-list = start-arg-list [ arg *(arg-separator arg ) ] end-arg-list arg = null / quote escaped-string quote quote = %x22 ; " start-arg-list = %x5B ; [ end-arg-list = %x5D ; ] arg-separator = %x2C ; , Example instructions "huh"["I didn't understand your last instruction."] "setToken"[ "123978987lnlj129" ] ; super secure login token "con.open"[ null, "40" ] ; whatever that means "run_proc"[ "userDelete", "jon" ] ; permission validated "con.close"[] "stop"[] 4.2 Browser and Operating System It's useful to make a distinction between an application process and resources used by an application process. The application code itself is a resource used by the application process. A browser is very similar to a command prompt. A user enters a J. Guerin Expires December 3, 2011 [Page 9] INTERNET DRAFT PIPP June 1, 2011 command, a resource is loaded and code is executed to run the application. HTML is code, javascript is code, java is code and so on. A command prompt runs programs in their own process and gives programs a user interface to work in. A browser should run programs in their own process. Internet applications should have two connections. One for secure instruction and data communication using a sub streaming protocol and another connection for downloading large unsecured resources such as code, images, and so on using a protocol optimized for that purpose. Operating Systems and programing platforms should focus on improving support for dynamic resource loading and caching including dynamically loading code for the application to execute. The proof of concept illustrates this with an index.html that calls a javascript main function. The rest of the web site is in static javascript files with functions to return html elements with dynamic element id's. The html displayed to the user is dynamically created by javascript functions with server communication done using so-called ajax. This simulates an application running in it's own process using static resources that could potentially be loaded dynamically. This is an efficient model for the Internet as the only communication made is needed for data transmission and all code is static that can be treated as a cached resource. 4.3 Language Design 4.3.1 Destructors Stream-based applications require management of resources. Garbage collection helps prevent memory stomping, but does not prevent resource leaking. Forgetting to call delete has been replaced by forgetting to call close. The lack of destructors with a well-defined execution time, and the inability to create objects on the stack is a hindrance to building stream-based applications. Protecting memory is important and having garbage collection is an important safety net to have as well. Just as important is the need to have destructors with a well defined execution time to allow for more elegant program designs with resources automatically closed in destructors. 4.3.2 Exception Handling Using automata to model software means all known/potential/common error conditions are modeled through function calls. Exception handling is a great safety net to have when a true exception to J. Guerin Expires December 3, 2011 [Page 10] INTERNET DRAFT PIPP June 1, 2011 the automata occurs. However, it should only be used as a safety net. For example, a file i/o library should provide an efficient way to open a file and report a problem status if the open fails without throwing an exception. Exception handling is great for unexpected conditions and providing synchronization points to protect other sub systems in a large complex program. However, applications should model and handle expected potential errors in the automata. 6 Security Considerations PIPP addresses potential security issues to by preventing stream leaks and stream stomping on the main stream by the sub stream. This is needed as the main stream has no control once the sub stream has control. The main stream may allow sub streams to leak and stomp on each other, however the main stream has control over that situation. This issue can be handled by language and application design. A more advanced network protocol may also handle this issue by using stream numbers created during the handshaking process of a connection and designing a connection process for sub streams. PIPP is designed to be a simple, lightweight protocol without a connection process of it's own. Therefore, this issue is outside the scope of PIPP. A secure transport layer is recommended for use by applications communicating instructions and sensitive data. It is also recommended that applications have a separate, unsecured connection available to download large, insensitive data such as code, images, etc. A protocol that takes uses caching can be used for this. Authentication is an issue for applications. PIPP and sub streaming dramatically increased the ability for applications to communicate with each other. It is strongly recommended that each application handle its own authentication using standard libraries and techniques as opposed to using a single shared authentication sign-on application service. A shared authentication service will expose your entire api to all applications apart of the sign-on service. It is more secure to expose a limited api for other applications while your application has access to the entire api. Automated, secure communication between software can still be achieved by having users explicitly setup public/private key pairs to allow communication between two applications. Once the setup is complete, the applications can freely communicate with each other. This way, each connection between applications is verified J. Guerin Expires December 3, 2011 [Page 11] INTERNET DRAFT PIPP June 1, 2011 by the user. All applications need to re-validate security permission on the server side for all functions run to guard against attacks by outside users or users that are supposed to have limited permission. GUI security is great for usability, but real security is applied in the service. The proof of concepts illustrates techniques to do this. 6 IANA Considerations At some point, links to run applications will need to be defined along with a reserved port for a standard, optimized sub streaming protocol. A new, currently unreserved port should be used leaving port 80 for HTTP. 7 References 8.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC5234] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 9 Acknowledgements "Pay It Proper" is a web site I'm developing as part of an experimental economic system based on the idea of rewarding people for what they have already done. I came up with the protocol while developing the site. Mahalo to all of my friends and family for being supportive. Author's Addresses Jon Guerin 1215 S. Kihei Rd Suite O-608 Kihei, HI 96753 USA Phone: +1 808-269-7475 J. Guerin Expires December 3, 2011 [Page 12] INTERNET DRAFT PIPP June 1, 2011 EMail: jguerin@shootingsoul.com J. Guerin Expires December 3, 2011 [Page 13]