INTERNET-DRAFT J. Guerin Intended Status: Proposed Standard Shooting Soul, LLC Expires: January 25, 2012 July 24, 2011 Pay It Proper Protocol -- PIPP draft-jguerin-pipp-02.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 January 25, 2012 [Page 1] INTERNET DRAFT PIPP July 24, 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 uses 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 is given. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Sub Streaming . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 5 3.1.1 Frame Header Format . . . . . . . . . . . . . . . . . . 6 3.2 End Point to Output Main Stream and Output Sub Stream . . . 6 3.3 End Point to Input Main Stream and Input Sub Stream . . . . 7 3.4 Design Considerations . . . . . . . . . . . . . . . . . . . 7 3.4.1 Separation of Concerns . . . . . . . . . . . . . . . . 7 3.4.2 Inclusiveness . . . . . . . . . . . . . . . . . . . . . 8 3.4.3 Anticipation of Change . . . . . . . . . . . . . . . . 8 4 String Instruction Format . . . . . . . . . . . . . . . . . . . . 8 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 J. Guerin Expires January 25, 2012 [Page 2] INTERNET DRAFT PIPP July 24, 2011 1 Introduction PIPP uses sub streaming to allow instructions and data to be streamed on the same tape. This creates a universal 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 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. PIPP is flexible enough to run over HTTP or TCP and flexible enough to be implemented in several languages including javascript. This will be sufficient for the short term to allow applications to take advantage of sub streaming with current technology. Eventually, applications will use higher level languages with compilers creating instructions in optimized formats using optimized network protocols relegating PIPP to the dust bin of computing history along side punch cards. 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 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 universal Turing machine by using the main stream as a call stack with instructions and finite length data while the sub stream is used for streaming data. Since the sub stream is itself a stream, you can recursively define universal 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 :) J. Guerin Expires January 25, 2012 [Page 3] INTERNET DRAFT PIPP July 24, 2011 It's useful to think of an application as having a main stream call stack with instructions and finite length data. So one application communicates with another application and eventually they want to work with streamed 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 bytes 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 stomping and stream leaking. A data sub stream may try to read main stream call stack 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 call stack 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 call stack 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 J. Guerin Expires January 25, 2012 [Page 4] INTERNET DRAFT PIPP July 24, 2011 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. 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 J. Guerin Expires January 25, 2012 [Page 5] INTERNET DRAFT PIPP July 24, 2011 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) 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 J. Guerin Expires January 25, 2012 [Page 6] INTERNET DRAFT PIPP July 24, 2011 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. 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 J. Guerin Expires January 25, 2012 [Page 7] INTERNET DRAFT PIPP July 24, 2011 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, including text based scripting 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 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 optional 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 ) ] J. Guerin Expires January 25, 2012 [Page 8] INTERNET DRAFT PIPP July 24, 2011 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"[] 5 Security Considerations PIPP addresses potential security issues 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. Sub streams may leak and stomp on each other, however the application code 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. It is recommended PIPP always run over a secure transport layer. 6 IANA Considerations It is suggested port 4 be reserved for PIPP running over TCP with a secure transport layer. PIPP running over HTTP is implemented on top of the existing HTTP connection in application code. Therefore there is no change to the HTTP ports used. 7 References 7.1 Normative References J. Guerin Expires January 25, 2012 [Page 9] INTERNET DRAFT PIPP July 24, 2011 [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. 8 Acknowledgements "Pay It Proper" is a philosophy based on the idea of rewarding people for what they have already done. This work was done as part of the development of new institutions and tools for society to use based on this philosophy. Viva La Revolution! Mahalo to all of my friends and family for being supportive. Author's Addresses Jon Guerin Shooting Soul, LLC 1215 S. Kihei Rd Suite O-608 Kihei, HI 96753 USA Phone: +1 808-269-7475 EMail: jguerin@shootingsoul.com J. Guerin Expires January 25, 2012 [Page 10]