INTERNET-DRAFT J. Guerin Intended Status: Proposed Standard Independent Expires June 6, 2011 December 3, 2010 Pay It Proper Protocol -- PIPP draft-jguerin-pipp-00.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) 2010 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 June 6, 2011 [Page 1] INTERNET DRAFT PIPP December 3, 2010 Abstract The Pay It Proper Protocol (PIPP) is an application-level network protocol for inter-process communication over the Internet using batches of function calls. PIPP is to replace the use of HTTP for inter-process communication over the Internet, e.g. between a browser and a web server, leaving HTTP the task of downloading resources. A distinction is made between HTTP links to resources and PIPP application links. PIPP allows as many applications as possible to communicate over the Internet. This RFC defines the protocol and application links, explains how to use PIPP to develop applications, explains how to develop browsers for PIPP applications, and explains how to develop secure applications. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Pay It Proper Protocol . . . . . . . . . . . . . . . . . . . . . 4 2.1 End Point Requirements . . . . . . . . . . . . . . . . . . . 5 2.2 Data Format . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 JSON Grammar . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 Batch of Function Calls . . . . . . . . . . . . . . . . 7 2.3 Design Considerations . . . . . . . . . . . . . . . . . . . 8 2.3.1 Separation of Concerns . . . . . . . . . . . . . . . . 8 2.3.2 Inclusiveness . . . . . . . . . . . . . . . . . . . . . 8 2.3.3 Anticipation of Change . . . . . . . . . . . . . . . . 8 3 PIPP Communication . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Function Mapping . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 State . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Callback Functions . . . . . . . . . . . . . . . . . . . . 10 4 Browser Design . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Browser and the Command Prompt . . . . . . . . . . . . . . 11 4.2 Application Links . . . . . . . . . . . . . . . . . . . . 12 4.3 Browser Application Bootstrapping . . . . . . . . . . . . 13 4.4 Client Application Interaction . . . . . . . . . . . . . . 14 5 Internet Application Architecture . . . . . . . . . . . . . . 15 5.1 Dynamic HTML Internet Application . . . . . . . . . . . . 15 5.2 PIPP over HTTP . . . . . . . . . . . . . . . . . . . . . 16 6 Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 Client Code . . . . . . . . . . . . . . . . . . . . . . . 18 6.3 Server Code . . . . . . . . . . . . . . . . . . . . . . . 18 6.4 Authentication . . . . . . . . . . . . . . . . . . . . . 19 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 J. Guerin Expires June 6, 2011 [Page 2] INTERNET DRAFT PIPP December 3, 2010 8.1 Normative References . . . . . . . . . . . . . . . . . . 21 8.2 Informative References . . . . . . . . . . . . . . . . . 22 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 J. Guerin Expires June 6, 2011 [Page 3] INTERNET DRAFT PIPP December 3, 2010 1 Introduction The Pay It Proper Protocol (PIPP) is an application-level network protocol designed to be used for inter-process communication over the Internet through batches of function calls. A clear distinction is made between resources and processes with new application links defined for processes. PIPP replaces the use of HTTP when HTTP is used to effectively make function calls over the Internet between processes, leaving HTTP the task of downloading resources. The protocol has a minimalist design to allow as many applications as possible to communicate over the Internet regardless of the underlying network stack. Yet at the same time, the protocol has enough definition and structure to allow applications to communicate effectively over the Internet. This RFC defines the protocol and application links, explains how to use the protocol to develop applications, explains how to develop browsers for PIPP applications, and explains how to develop secure applications. PIPP is designed specifically for the task of process communication through batched function calls over the Internet. This protocol is not intended to be used for caching, streaming or other communication. HTTP can be used for caching and other protocols for streaming. PIPP is a protocol designed for Internet application developers. PIPP is a proposed standard interface for application developers to communicate with and between Internet applications. PIPP will remain useful and effective as the Internet evolves. Similar to how TCP reliably streams bytes, PIPP sends batches of function calls. 1.3 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 Pay It Proper Protocol PIPP defines communication between two end-points by sending a batch of function calls without any response. A batch of function calls may prompt another end point to send a batch of function calls to the other end point. Other outside factors may also prompt an end point to send a batch of function calls to another end point. Multiple batches of function calls may be sent one after the other for processing. J. Guerin Expires June 6, 2011 [Page 4] INTERNET DRAFT PIPP December 3, 2010 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 a persistent connection is available to allow for end points to freely send batches of function calls, 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. If a "response" is needed, then the other end point will have to send it's batches of function calls before the connection is closed. This is a common connection situation for client/server web applications. The PIPP data format is designed for use as a batch of function calls to execute, but can be interpreted in any way by an application. How the functions are processed is also up to an application. 2.1 End Point Requirements The following defines the requirements for a PIPP end point. A batch is defined as one batch of function calls as specified in the data format section. A secure request means an application decides not to secure the data itself and requests the communication to be secured by the underlying network stack. This is usually done through a secured transport layer, but may be implemented in other ways. 1. MUST send/receive UTF-8 encoded text 2. MUST send/receive 1 batch at a time 3. SHOULD send data to the specified PIPP end point 4. SHOULD send data securely when specified 5. SHOULD receive data from another PIPP end point 2.2 Data Format The data format defines a batch of function calls using a subset JSON as described in RFC 4627 [RFC4627]. Since JSON is not a standard, the subset used by PIPP is defined explicitly to allow PIPP to be standardized. The definition is taken nearly verbatim from the JSON RFC. The encoding MUST be UTF-8 as described in RFC 3629 [RFC3629]. 2.2.1 JSON Grammar A JSON text is a sequence of tokens. The set of tokens includes three structural characters, strings, and one literal name. A JSON text is a serialized array. JSON-text = array J. Guerin Expires June 6, 2011 [Page 5] INTERNET DRAFT PIPP December 3, 2010 These are the three structural characters: begin-array = ws %x5B ws ; [ left square bracket end-array = ws %x5D ws ; ] right square bracket separator = ws %x2C ws ; , comma Insignificant whitespace is allowed before or after any of the three structural characters. ws = *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ; Carriage return ) The null literal name MUST be lowercase. No other literal names are allowed. null = %x6e.75.6c.6c ; null The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A through F can be upper or lowercase. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C". Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single reverse solidus character may be represented more compactly as \\. To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve- character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) J. Guerin Expires June 6, 2011 [Page 6] INTERNET DRAFT PIPP December 3, 2010 may be represented as "\uD834\uDD1E". string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 2.2.2 Batch of Function Calls A batch MUST be a JSON array of zero or more function calls as the array element. A function call MUST itself be a JSON array with up to two elements. The first element of a function call MUST be either a JSON string or the JSON null value. This is intended to be the function name. The optional second element is the function arguments. The function arguments MUST itself be a JSON array with zero or more JSON string values or JSON null values. argument = null / string arguments = begin-array [ argument *( separator argument ) ] end-array function-name = null / string function-call = begin-array function-name [ separator arguments ] end-array batch = begin-array [ function-call *( separator function-call ) ] end-array J. Guerin Expires June 6, 2011 [Page 7] INTERNET DRAFT PIPP December 3, 2010 Here are some sample batches: Batch Sample [ [ "functionNoArgs" ], [ "functionWithArgs", ["firstArgValue",null,"ThirdArgValue"] ] ] Batch Sample [ [ "functionCall", [ "1" ] ] ] 2.3 Design Considerations 2.3.1 Separation of Concerns PIPP is designed specifically for the task of inter-process communication over the Internet. The communication is limited to function calls allowing applications to give instructions/commands to each other. Data streaming and resource caching are left to other network protocols. Authentication and security concerns are left to the application and are discussed in later sections. 2.3.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 a batch of function calls in return. UTF-8 encoding allows for applications written in various languages to communicate with each other. Only strings, nulls and arrays are defined to allow as many application languages as possible to work with PIPP. Applications are responsible for how they want to deal with nulls, type conversion, named parameters and so forth. Applications enforce how strict they want their interface to be. Not all applications require a secure transport layer, strong data types, or named parameters, so the protocol does not force them to be used. 2.3.3 Anticipation of Change PIPP allows for pier to pier communication between web servers and eventually for client applications as improvements to telecommunications are made. In some cases, persistent J. Guerin Expires June 6, 2011 [Page 8] INTERNET DRAFT PIPP December 3, 2010 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. 3 PIPP Communication This section describes the basics of how applications can use PIPP to communicate with each other. This section illustrates why PIPP is a better alternative to HTTP and other remote procedure call (rpc) style protocols for inter-process communication over the Internet. Later sections describe application architectures with special attention given to the browser. In general, PIPP allows applications to group together batches of function calls as needed to be sent over the Internet. By not requiring a response, PIPP can be used for asynchronous or synchronous communication. This allows Internet communication to be optimized while allowing application developers to design using functions. Internet trips are minimized, and grouping batches together allows for pipelining by the underlying transport layer. Existing rpc protocols require a single function call and result. This leads to more Internet round trips and transferring of state data when compared to PIPP. Moreover, a restful style architecture limits the functions that can be performed on the resources and is very limiting for application development. 3.1 Function Mapping The function name and arguments are mapped to classes, named parameters and so on for execution using a convention defined by an application. For example, the function name "myClass.myMethod" can map to a class and method to call. For named parameters, alternating name/value parameter pairs can be used. 3.2 Modularity All Internet function calls from independent components can be grouped together and sent to their counterparts at the other end point without the other components knowledge. This greatly reduces the complexity of designing large Internet applications to make optimal use of sending information over the Internet. In some cases, an application may not want to group all calls together in a single batch. For example, a critical component can use it's own batch to be processed independently. Yet all batches can be sent at the same time one after the other assuming the connection can stay open long enough to send all of the batches. J. Guerin Expires June 6, 2011 [Page 9] INTERNET DRAFT PIPP December 3, 2010 PIPP allows application designers to easily group calls as an application requires while helping to avoid coupling between components. 3.3 State PIPP allows state to be sent as needed and shared across a batch to enable optimal reuse of state data. For example, if a function needs the token for the current user, then the token is passed as an argument. If the token is needed for other functions in the batch, a "setState" function is defined that accepts a token. This function is called first in the batch allowing the end point to share the state across all subsequent function calls in the batch. The lifetime of the state is limited to the batch, allowing the batch of functions to be processed using load balancing techniques. Moreover, only the state data required to process the functions in the batch needs to be sent. This way large applications are not limited to a single "setState" function to use for all of their batches. Functions to set state information can be created as needed. Sample batch sent to the server with state data shared across the lifetime of the batch [ [ "setRepoortState", [ "token data", "Report options" ] ] [ "getReportHeaderInfo" ] [ "getInvoieReportData" ] ] 3.4 Callback Functions When an application is in control of both end points, then it may already know what functions it can call and send in a batch to the other end point. However, a callback technique can be used for a general purpose library or function. One or more of the parameters to the function will name a call back function to use. The parameters of the callback function are defined by the general purpose library/function, but the actual name of the function to call is the given callback function name argument. Multiple callback functions can be given to process results, handle exceptions, validation failure, etc. For example, to create a general database stored procedure processing function define the function name as "runProc" with arguments of "", "", "". The call back function must take one argument which has the results in a JSON string. J. Guerin Expires June 6, 2011 [Page 10] INTERNET DRAFT PIPP December 3, 2010 Sample batch sent to the server [ [ "setState", [ "token data here" ] ] [ "runProc", [ "getCustomers", null, "displayCustomers" ] ] [ "runProc", [ "getUserInfo", null, "displayUserInfo" ] ] ] Sample batch sent back to the client [ [ "displayCustomers", [ "getCustomers proc results here" ] ] [ "displayUserInfo", [ "getUserInfo proc results here" ] ] ] 4 Browser Design This section describes how to design a browser and links for Internet applications. The Internet contains a vast repository of resources. The browser and the web server are two running processes communicating over the Internet. The browser and web server run application specific code, such as HTML or php. This section describes how HTTP can be used to download resources to the browser while PIPP is used for communication between the browser, application client and application server processes. This section contains references to PIPP connections. This assumes specific PIPP end points will be defined, standardized, and implemented such as PIPP over TCP/IP and PIPP inter-process communication on an OS. 4.1 Browser and the Command Prompt It's useful to compare the browser to a command prompt. At a command prompt, a user can execute a program by typing in a url to a file that is a program or a data file associated with a program. The OS loads the resources from disk and creates a process to run the program. Sometimes the url is actually a script to launch an application and not a direct resource location. In an editor, a user can load resources (e.g. a file) into the program to work with. Similarly, a url is entered into a browser. The browser loads the resource from the Internet to work with. It could be a plain html file, JavaScript code to run in a scripting engine, and so on. The url entered into a browser is just like running a program from the command prompt. A link is specified along with command line arguments to either the resource or code to launch an application. The link may have the browser download and run code such as JavaScript. The link may also first install and/or update a J. Guerin Expires June 6, 2011 [Page 11] INTERNET DRAFT PIPP December 3, 2010 regular desktop application on the machine, and then run the code. In any case, an application is run as a separate process inside the browser for security and stability. The end user is not necessarily aware if this is a process/thread/HTML/JavaScript/etc. The end user wants to go to a browser and enter a link to run an application. Being able to install/update a normal desktop OS application will require extra permission from the user. However, this is not all that different from having a web site which requires a browser plug-in to install. There are several practical cases for the ability to do this. For example, there are large desktop based programs where users want to run a subset of functionality, such as reporting, through a browser. Having this feature in the browser will allow these programs to more easily reuse code and make it available through a browser. Moreover, as improvements are made to so-called sand-boxing, desktop application code will be downloaded and run without requiring an installation just like script code. 4.2 Application Links There is a clear distinction to be made between links to resources and links to applications. Resource links are standard HTTP links used to download resources taking advantage of the caching features of HTTP. Application links are new links used to start an application with arguments similar to command line arguments. Unsecured link = "l:" host [ ":" port ] [ path ] [ " " arguments] Secured link = "sl:" host [ ":" port ] [ path ] [ " " arguments] The goal behind the links is to make them more user friendly. This is why the protocol name is not explicitly in the link. When an application link is processed, a PIPP/TCP connection MUST be established with the application server code located on the host and specified port. The optional path is provided to allow multiple applications on the same host. If a port is not specified, then the default PIPP port 14 is used. A secure link MUST also use a secure transport protocol for the connection such as TLS 1.2 as described in RFC 5246 [RFC5246]. The default PIPP port for a secure connection is 15. The optional arguments are not used to establish the connection and are application specific. After a connection is established, the arguments MUST be passed as the first single string argument as part of a standard batch with a "linkRequest" function call. This way the arguments can easily include spaces and be very long, since they are never sent as part J. Guerin Expires June 6, 2011 [Page 12] INTERNET DRAFT PIPP December 3, 2010 of the string used to establish a connection. If no arguments are specified, then the "linkRequest" function call MUST be made will a null first argument. Additional arguments may be passed to the linkRequest function after the first argument to facilitate bootstrapping. Additional function calls may be included in the batch to also facilitate bootstrapping. Sample application links and resulting batch calls sent to the application server code sl:mywebsite.com start=home city=kihei [ [ "linkRequest", [ "start=home city=kihei" ] ] ] l:mywebsite.com [ [ "linkRequest", [ null ] ] ] 4.3 Browser Application Bootstrapping When an application link is clicked or entered into a browser, the browser establishes a PIPP connection to the application server code on the host. The connection is established with the application server code, so the browser is communicating with the application server using PIPP. The standard batch with the "linkRequest" function call is sent to the application server code. Next, the application server and browser communicate using PIPP to install/load the needed application client code. While the bootstrapping process is specific to a browser/OS, hopefully the Internet community will develop standard browser functions to work cross-platform and across browsers. For example, the application server may want to know what language/time-zone the browser is in to start off the application in the correct language. Also, the application server can look at the arguments given in the linkRequest to determine the version of the application to use. Not all customers/users want to be on the latest version of an application. The arguments may also specify a starting point, for example run the application and open to this invoice/profile/etc. The application defines what starting points to support. The client code can come from a variety of locations on the Internet. For example, if a third party GUI library is used, then the client code for the library can be downloaded from the third party server. This allows for popular libraries to take advantage J. Guerin Expires June 6, 2011 [Page 13] INTERNET DRAFT PIPP December 3, 2010 of HTTP caching for distribution and not require every application to have a copy of the resources to distribute. The HTTP connection to download resources can be unsecured while the PIPP connection between the application client and application server is secured. All resources downloaded can be verified automatically by the browser with a check sum given by the application server to ensure the client code and resources are exactly what the application wants to use. The application server instructs the browser what client code and resources to download. The client code may be optionally installed as a regular OS application by the browser if needed. In any case, even for small client script applications, the client application code is then launched in a separate process running within the browser creating it's own PIPP connection to the application server code and a PIPP connection back to the browser. Once the bootstrapping process is complete, then the PIPP connection between the browser and application server is closed. All applications are run in their own process for security and stability. The client code can be anything the browser/OS supports from small, lightweight, cross-platform HTML/JavaScript code to C#/Java to a fully installed OS specific desktop application. All or part of the client code can be installed/downloaded during the bootstrap process. The client code can download additional resources/code as needed in order to allow the application to start as quickly as possible. Moreover, all resources/code are retrieved using HTTP to take advantage of caching. 4.4 Client Application Interaction A client application is started with an entry point function call and given command line arguments to establish PIPP connections to it's corresponding server code and the browser. The client code may also want to create other PIPP connections to communicate with other Internet web services. This allows web services to be called securely on their own connection separate from the client's connection with it's own server. The client code communicates with the browser to create tabs/windows, update the address bar, and work with the back/forward buttons. The client is centered around the process and not pages/tabs/windows. This way, state information is easily shared across all tabs/windows in the application. However, once a user closes all tabs/windows associated with a client process, then the process exits. The client code instructs the browser to update the address bar text. The browser does not navigate or J. Guerin Expires June 6, 2011 [Page 14] INTERNET DRAFT PIPP December 3, 2010 create a new connection/linkRequest in this case, it just updates the text that's there. This way if the user is at a point where an application link to restart from this point in the program is supported, then the address bar text is updated with the corresponding application link. The user can save the application link to their favorites and so on. The application decides if it want's to support back/forward style navigation. It responds to back/forward requests from the browser and updates the active tab/window accordingly. When a user enters a url/link in the address bar, the browser closes the active tab and replaces it by running the user application/HTTP request to create a new application process. If the closed tab was part of an application, then the client application code is notified of the closed tab. If it's the last open window/tab for an application, then the application process exits. 5 Internet Application Architecture Static HTML page viewing and web sites with no client code continue to use existing development methods and HTTP links. Existing HTTP web applications also use HTTP links and continue to be supported. PIPP Internet applications use application links. A browser supports both HTTP links and application links allowing for both to seamlessly coexist. Web sites are developed using the appropriate methods for the situation. 5.1 Dynamic HTML Internet Application This section describes one way to build a dynamic html Internet application using PIPP. In general, the code and resources are organized the way most desktop applications are developed. The GUI is treated as a translatable resource controlled by the client code. The communication between the client and server is done with PIPP function calls. The server sends commands to the client to build the GUI as needed instead of the server generating the GUI itself. The user interface definition, e.g. HTML, is static and downloaded using HTTP caching. The communication between the client and server is dynamic, and the client code handles the dynamic GUI generation. This makes efficient use of the Internet by not having the dynamic GUI generated by the server and sent down to the client every time an application is run. To treat HTML as a resource, a client-side HTML template system can be used. Another option is to strip the HTML of all script code and leave it to layout the user interface. Code is written J. Guerin Expires June 6, 2011 [Page 15] INTERNET DRAFT PIPP December 3, 2010 to attach functions to listen for HTML events. The HTML is split up into elements instead of pages similar to working with controls in a desktop application. HTML elements may require a unique id to reuse the same element multiple times on a page. In this case, a unique string placeholder such as "$EID$" is used in the HTML resource definition. The client code will replace the "$EID$" with the real unique element id before the element is added to the final HTML document. The process for the client code to dynamically create a HTML document is very similar to the process of a desktop application's form and control loading. First, an instance of an element is created and added to the HTML document with the proper element id. The client code does this by loading the HTML resource for the desired element, replacing the "$EID$" with the actual element id, and updating the inner HTML of the actual element id. Second, the HTML element calls the same process on all elements it contains to load them onto the HTML document passing each element the proper element id to use. Third, the element is initialized as needed similar to a constructor call. The first step in initialization is to call an initialization function for each element it contains. Once the elements it contains are initialized, then the element can finish with it's own initialization. Each element has initialization functions to be called where the actual element id is passed in to work with. This is where the client code sets default values and associates HTML document events with functions. The HTML elements have functions associated with them that other elements and server code call using PIPP. The HTML element functions call functions for elements contained in it and server functions it knows about. This way, code can placed on either the server or client as needed and seamlessly be called. Internet applications can simultaneously run multiple versions of their code. All of the client code and html are put into versioned directories. Each version can be translated as well. Requests for resources are routed to the correct code version/language to use. This way customers/users run the version of an application they want to use and are not forced to use the latest version. 5.2 PIPP over HTTP This section describes how to use PIPP with existing browsers over HTTP. Previous sections discussed a more ideal use of PIPP with new browsers, new PIPP/TCP end points, application links and so on. PIPP can also be used over HTTP. This helps illustrate the need to use PIPP directly over TCP with new browsers and so forth. J. Guerin Expires June 6, 2011 [Page 16] INTERNET DRAFT PIPP December 3, 2010 No matter what underlying network protocol there is, PIPP is used on top of it for Internet application development. In this example, the web site code and resources are organized as described in the previous section where the HTML is again treated as a resource and split up by element components. Java is used for the server code and JavaScript for the client code. HTTP requests and responses are funneled to PIPP end points. Treating HTML as a resource in JavaScript can be accomplished in a several ways. A JavaScript HTML template system can be used. Alternately, the HTML for each element can be stored the same way translatable resource strings are stored. Another option is to create JavaScript functions with the HTML embedded in the function. A pre-processing step can be added to development to allow HTML files to be coded separately. The HTML element resource strings/JavaScript functions are generated from the HTML files. If needed, resources can be dynamically downloaded to the client in parts using common JavaScript resource loading techniques. A Java PIPP endpoint can be created as follows. Create a class to build PIPP batch calls. Create a class to dispatch incoming PIPP batch calls for execution. A simple "classname.methodname" mapping can be used with all arguments to methods defined as a String type. Create a servlet. In the servlet, any uri ending in "/pipp" is assumed to have a HTTP body with PIPP batch calls to process. The servlet sends those calls to the dispatcher for processing. The server code builds up PIPP batch calls to send for the HTTP response. After the servlet dispatches the calls for processing, it sends all of the new PIPP batch calls in response to the client. If any other uri is given to the servlet, then a new HTML page needs to be created from scratch. The uri arguments are mapped to function calls as needed to once again build up PIPP batch calls. A nearly empty HTML page container is sent in response, and the PIPP batch calls are embedded directly into JavaScript code to run on page load. The page container includes all needed JavaScript code/files in the head element. This way the client code can build up the starting HTML page for display from PIPP function calls the same way it builds elements for display as the application runs. A JavaScript PIPP endpoint can be created as follows. Create functions to build up PIPP batch calls. Create a function to dispatch and process incoming PIPP batch calls. Create a function to send PIPP batch calls to the server using "ajax" with "/pipp" as the uri and specify the PIPP dispatch function to process the response. J. Guerin Expires June 6, 2011 [Page 17] INTERNET DRAFT PIPP December 3, 2010 6 Security Considerations 6.1 Protocol The protocol requires the use of UTF-8 allowing for harmless data travel between end points through routers, firewalls and so forth. Since PIPP uses it's own port numbers (14 and 15), those ports will need to be configured for security similar to HTTP/HTTPS. 6.2 Client Code It does not matter if the client code for an Internet application is binary or text based. Once code in any form is downloaded on a client machine to be executed, security precautions are taken. Client code should be run in it's own process. An application does not share memory with other Internet applications or effect the stability of other applications. This way an application has control over it's state data. When client code is not a fully installed desktop application, it should be run in a so-called sandbox with limited permission to the client OS. The permission granted to an Internet application can be adjusted by the browser/OS on a per application basis. Client code and resources can be downloaded from various Internet locations. To ensure the application is using the resources it wants, the resources can be verified with a hash code. If an application accepts and executes user entered scripts/code, then it is up to the application to do so securely. However, most communication with other applications will be through function calls passing data and not executing code from other applications. The function calls to be executed as specified by another application are controlled by an application and can be ignored when they are not properly authenticated. 6.3 Server Code Security needs to be applied on a per function basis. Any security applied in the client code to make for an easy to use application by users needs to be re-checked inside every function that can be called over the Internet to protect against malicious users. For example, an invoice may not be allowed to be modified in the client GUI code, but the server function to save an invoice needs to recheck the given user has permission to modify the invoice. J. Guerin Expires June 6, 2011 [Page 18] INTERNET DRAFT PIPP December 3, 2010 A secure token can be issued after authentication of a user to provide access to server functions. Typically, not all users will be able to perform all functions available in an application. Therefore, all server functions must also validate the user associated with the token has the right to perform the function. This guards against attacks where the application's client code is by-passed. An attack is made by calling server functions directly by an attacker that gains knowledge of a login. To help alleviate having to write code to check for security inside every server function, the name of the function/parameters can include the name of the role required to run the function. This way the role permission can be checked automatically as part of the function mapping process. This is all the security needed when the server function call maps directly to the feature being secured. However, in some cases a direct mapping is not possible which requires additional security checking code inside the server function. Direct Mapping Example A secure, reusable server function to run stored procedures is named "runProc". All stored procedure names are prefixed with the required role needed to run them. In this example, if the user specified in the token does not have the "admin" role, then the stored procedure is not run. [ [ "setState", [ "token data goes here" ] ] [ "runProc", [ "admin_addUser", "joe" ] ] ] Additional Security Check Example In this example, the server function call is prefixed with the role "manager". If the user specified in the token does not have the "manager" role, then the function call is not run. In this application, security is defined for each individual invoice. So in addition to the role check already performed, the server function has to also verify the manager user given in the token has permission to save changes to the given invoice. [ [ "setState", [ "token data goes here" ] ] [ "manager_saveInvoice", [ "invoice data here" ] ] ] 6.4 Authentication Authentication is best handled by each application individually. J. Guerin Expires June 6, 2011 [Page 19] INTERNET DRAFT PIPP December 3, 2010 Frameworks and libraries can be used to help application developers manage their own authentication with password hashing, secure tokens and so on. Sharing the same authentication across applications is a greater security risk. This allows any other application that shares authentication to call any server function of the application. Typically, applications want to restrict what data and functions are available to other applications. This should be enforced explicitly by keeping authentication separate for each application. The following technique can be used to allow applications to securely communicate with each other. Users of an application explicitly input what data other applications are allowed to access by giving a list of the applications and their identity in those applications. The application can then verify the token given to it to allow access to the restricted data. For example, there is a contact list application to manage all of a user's contacts. The user also has an accounting application they use for their business. The user wants to automatically allow the accounting application access to all of their business contacts, but none of their personal contacts. The user goes into the contact list application and explicitly grants access to their business contacts with their user identifier in the accounting application. No password is needed, just the user's identifier. An application link is also needed for the accounting application in order to return the public key to verify a digitally signed token from the accounting application. This is setup once by the user and allows the accounting application to automatically access the business contacts seamlessly. Next the user goes into their accounting application and specifies they want their contacts to come from the contact list application. They enter their user identifier from the contact list application. The accounting application must know the function interface of the contact list application. The contact list application only makes some of it's server functions available to be called by an outside application. For example, outside applications can only read contacts made available by users. The contacts can't be edited. Once the user configures the accounting application and contact list application, then the two applications can communicate with each other seamlessly from their onward. The user logs in to the J. Guerin Expires June 6, 2011 [Page 20] INTERNET DRAFT PIPP December 3, 2010 accounting application. To get the business contacts, the accounting application digitally signs with a private key a token which contains the application list user identifier, contact list user identifier, and a timestamp expiration. Note these are just user identifiers without any password information. They do not even need to be the same identifier used for login. The token is sent along with the needed function calls to get the business contacts to the contact list application. The contact list application validates the token by checking the timestamp and digital signature with the public key for the accounting application. If needed, the contact list program can obtain the latest public key from the accounting application by calling the application link configured by the user. After the token is validated, the contact list application returns the business contacts to the accounting application through a callback function. By keeping authentication separate for each application, users can know what information is being shared between the applications they use. This also gives applications control over what functions and data are available to share with other applications instead of making all of their server functions and data available. This also provides a more detailed audit trail to know what applications are accessing data in case their is abuse. Once the setup is complete, then communication is securely automated between the applications. This means users will not have to re- login or switch between application interfaces whenever one application needs to work with another application. In cases where applications are not configured ahead of time to work with each other, then application links are used to launch other applications. The user switches between the application interfaces in this case. 7 IANA Considerations The use of port 14 is requested to be officially reserved for PIPP, and the use of port 15 is requested to be officially reserved for PIPP over a secure connection. 8 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. J. Guerin Expires June 6, 2011 [Page 21] INTERNET DRAFT PIPP December 3, 2010 [RFC5234] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 8.2 Informative References [RFC4627] D. Crockford, "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC5246] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 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. This lead me to expand the idea into this RFC. 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 EMail: jguerin@shootingsoul.com J. Guerin Expires June 6, 2011 [Page 22]