XEP-xxxx: Linked Process Protocol

Abstract: Linked Process is a protocol for distributed computing that facilitates the creation of an Internet-scale, general-purpose compute cloud. Any computing device with an Internet connection can consume and/or provide computing resources in a Linked Process cloud. Resource consumption occurs when a device migrates arbitrary code to another device for execution. Linked Process is applicable where it is necessary for a resource consumer to define the means by which a provider's resources are utilized.
Authors:Marko Rodriguez, Joshua Shinavier
Copyright:© 1999 - 2009 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Track
Version:0.0.1
Last Updated:2009-09-18

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Table of Contents


1. Introduction
2. Requirements
3. Glossary
4. Use Cases
    4.1. Farm Use Cases
       4.1.1. Rules Regarding Farm Presence
       4.1.2. Spawning a Virtual Machine
       4.1.3. Submitting a Job to a Virtual Machine
       4.1.4. Determining the Status of a Virtual Machine Job
       4.1.5. Aborting a Virtual Machine Job
       4.1.6. Managing Virtual Machine Variable Bindings
       4.1.7. Terminating a Virtual Machine
       4.1.8. Discovering Information About a Farm
       4.1.9. General Farm Use Cases
    4.2. Registry Use Cases
       4.2.1. Rules Regarding Registry Presence
       4.2.2. Locating Countrysides with Farms
       4.2.3. Discovering Information About a Registry
5. Error Codes
    5.1. Farm Error Codes
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
10. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud.

Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources) [1]. Linked Process allows a resource consumer to leverage the computing resources offered by a resource provider in anyway deemed appropriate by the resource consumer. This is accomplished by the resource consumer providing/migrating/sending code (i.e. software instructions) to a computer language interpreter maintained by the resource provider. As such, it is up to the resource consumer to define the instructions to be executed by the provider. Given this architecture, resource providing devices in a Linked Process cloud are general-purpose computing sandboxes (i.e. they can be leveraged for computational ends that are defined by a resource consumer).

Linked process is unlike Remote Procedure Call (RPC) and Web Service models, where the means by which resources are consumed are defined apriori by the deployer of the service (in the way of functions/methods that can be remotely executed/invoked). The benefit of this protocol is that computing resources that exist elsewhere on the Internet can be leveraged by code that was not developed/created/inteded by the owner/provider of those resources.

2. Requirements

Linked Process was developed to address the following two distributed computing requirements: Internet-scale and general-purpose. These requirements imply yet more requirements which accompany their description below.

3. Glossary

The introduction discussed the physical devices and the roles that they serve as the hardware infrastructure of a Linked Process cloud. This glossary provides a summary of the entites that yield the software instructure of a Linked Process cloud. The following entities make up the core of the Linked Process protocol [3]. The naming convention used follows a "rural" theme [4].

In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider.

4. Use Cases

Given that Linked Process provides an Internet-scale, general-purpose compute cloud, there are many use cases. Before listing a collection of general use case scenarios, the following subsections will present the possible interactions that can occur in a Linked Process cloud. These interactions are specified with protocol examples. Once the specifics of the protocol are understood, the end of this section will discuss more generalized scenarios in which Linked Process can be useful.

4.1 Farm Use Cases

This is the list of the XMPP stanzas (i.e. packets) that MUST be supported by a farm implementation.

4.1.1 Rules Regarding Farm Presence

The farm specification for <presence/> is built on the specification as defined by the Instant Messaging XMPP specification [7]. What follows is a collection of guidelines regarding the use of <presence/> by a farm.

There are three types of non-subscription-based <presence/> stanzas that a farm produces.

4.1.2 Spawning a Virtual Machine

A <spawn_vm/> element is wrapped by an <iq/> element. The purpose of <spawn_vm/> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindings [9].

Example 1. A successful <spawn_vm/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
  <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascript"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" vm_species="javascript"/>
</iq>

Example 2. An unsuccessful <spawn_vm/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
  <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascr"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
  <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#"/>  
  <error code="503" type="cancel">
    <service_unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <species_not_supported xmlns="http://linkedprocess.org/2009/06/Farm#"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
      'javascr' is not a supported virtual machine species
    </text>  
  </error>   
</iq>

4.1.3 Submitting a Job to a Virtual Machine

A <submit_job/> element is wrapped by an <iq/> element. The purpose of <submit_job/> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <submit_job/> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a job in Linked Process and is assigned a job_id as specified by the <iq/> id attribute value. That is, the staza id of the <submit_job/> is the job's id.

Example 3. A successful <submit_job/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    var temp=0;
    for(i=0; i&lt;10; i++) {
      temp = temp + 1;
    }
    temp;
  </submit_job>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
    10
  <submit_job/>
</iq>

The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <submit_job/>.

Example 4. A successful <submit_job/> request demonstrating the consistency of a virtual machine's state between <submit_job/> requests.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    temp + 1;
  </submit_job>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
    11
  <submit_job/>
</iq>

Example 5. An unsuccessful <submit_job/> request.

<iq from="lp1@linkedprocess.org/villein"
  to="lp2@linkedprocess.org/farm" type="get" id="zzzz">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    bad_variable;
  </submit_job>
</iq>

<iq from="lp2@linkedprocess.org/farm"
  to="lp1@linkedprocess.org/villein" type="error" id="zzzz">
  <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#"/>
  <error code="400" type="modify">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <evaluation_error xmlns="http://linkedprocess.org/2009/06/Farm#"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
      ReferenceError: "bad_variable" is not defined at line number 1
    </text>  
  </error>
</iq>

4.1.4 Determining the Status of a Virtual Machine Job

A <ping_job/> element is wrapped by an <iq/> element. The purpose of <ping_job/> is to determine the status (i.e. progress, state) of a previously submitted <submit_job/> stanza (i.e. job) that has yet to complete.

Example 6. A successful <ping_job/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
  <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" status="in_progress"/>
</iq>

4.1.5 Aborting a Virtual Machine Job

An <abort_job/> element is wrapped by an <iq/> element. The purpose of <abort_job/> is to cancel (i.e. quit, stop, halt) a previously submitted, yet not completed <submit_job/> stanza (i.e. job).

Example 7. A successful <abort_job/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
  <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>

Example 8. An unsuccessful <abort_job/> request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
  <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="zzzz"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
  <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#"/>    
  <error code="404" type="cancel">
    <item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <job_not_found xmlns="http://linkedprocess.org/2009/06/Farm#"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
      Job 'zzzz' was not found in the virtual machine.
    </text>  
  </error> 
</iq>

4.1.6 Managing Virtual Machine Variable Bindings

A <manage_bindings/> element is wrapped by an <iq/> element. The purpose of <manage_bindings/> is to allow a villein to get and set variables in the variable space of a virtual machine. The definition of the "variable space" is up to the implementation of the virtual machine. In general, this is the set of all global variables for the virtual machine.

Example 9. A successful <manage_bindings/> set request.

<iq from="lp1@linkedprocess.org/villein"
  to="lp2@linkedprocess.org/farm" type="set" id="xxxx">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    <binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/>
    <binding name="name" value="marko" datatype="http://www.w3.org/2001/XMLSchema#string"/>
  </manage_bindings>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
	

Example 10. A successful <manage_bindings/> get request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    <binding name="age"/>
    <binding name="name"/>
  </manage_bindings>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    <binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/>
    <binding name="name" value="marko" datatype="http://www.w3.org/2001/XMLSchema#string"/>
  </manage_bindings>
</iq>

After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript

var fact = name + " knows josh and peter";
will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.

Example 11. A successful <manage_bindings/> get request.

<iq from="lp1@linkedprocess.org/villein" 
  to="lp2@linkedprocess.org/farm" type="get" id="zzzz">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    <binding name="fact"/>
  </manage_bindings>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="zzzz">
  <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
    <binding name="fact" value="marko knows josh and peter" 
      datatype="http://www.w3.org/2001/XMLSchema#string"/>
  </manage_bindings>
</iq>

A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.

var x = 1.0;
while(true) {
  x = x + 0.0001;
}
This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.

4.1.7 Terminating a Virtual Machine

A <terminate_vm/> element is wrapped by an <iq/> element. The purpose of a <terminate_vm/> is to shutdown (i.e. quit, exit, halt) the virtual machine. Upon termination, the virtual machine will lose its state and will no longer be able to be communicated with.

Example 12. A successful <terminate_vm/> request.

<iq from="lp1@linkedprocess.org/LoPVillein/EFGH" 
  to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
  <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>

<iq from="lp2@linkedprocess.org/farm" 
  to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
  <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>

4.1.8 Discovering Information About a Farm

A farm uses the XEP-0030 XMPP extension for allowing villeins to discover what features and permissions a farm and its spawned virtual machines support.

The <identity/> of a farm MUST be of category="client" and type="bot". The name attribute is up to the implementation.

The following <feature/>s MUST be supported by a farm:

The http://linkedprocess.org/2009/06/Farm# <feature/> denotes that the XMPP client is in fact a farm.

For presenting permissions, configurations, and statistics, a farm uses the data forms XEP-0004 XMPP extension in its disco#info response. The following list of <field/> variables (var) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machines [12].

Table 1: Fields of the data forms for the disco#info of a farm.

Field Type Option Status Label
farm_password boolean false REQUIRED Denotes whether a password is required to spawn virtual machines.
ip_address list-single false RECOMMENDED The IP address of the device hosting the farm.
vm_species list-single true REQUIRED The virtual machine species supported by the farm.
vm_time_to_live list-single false REQUIRED The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.
job_timeout text-single false REQUIRED The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.
job_queue_capacity text-single false RECOMMENDED The number of jobs which a virtual machine can hold in its queue before it rejects requests to submit additional jobs. A value of -1 means infinite.
max_concurrent_vms text-single false RECOMMENDED The number of concurrent virtual machines which the farm can support before it rejects a request to spawn a new virtual machine. A value of -1 means infinite.
farm_start_time text-single false RECOMMENDED The xs:dateTime at which this farm was started.
read_file list-multi false RECOMMENDED The directories/files that virtual machine's have read access to.
write_file list-multi false RECOMMENDED The directories/files that virtual machine's have write access to.
delete_file list-multi false RECOMMENDED The directories/files that virtual machine's have delete access to.
open_connection boolean false RECOMMENDED Whether a socket connection is allowed by the virtual machine.
listen_for_connection boolean false RECOMMENDED Whether a socket connection can be listened for by the virtual machines.
accept_connection boolean false RECOMMENDED Whether a socket connection can be accepted by the virtual machines.
perform_multicast boolean false RECOMMENDED Whether an IP multicast can be initiated by the virtual machines.

4.1.9 General Farm Use Cases

The previously defined interactions can be used in concert to perform some distributed computing task. A list of general use cases are presented below.

The previous list has a collection of more specific application scenarios that are itemized below. Please note that this list is not intended to be exhaustive and provides points of inspiration for the development of more use cases for Linked Process.

4.2 Registry Use Cases

This is the list of the stanzas that MUST be supported by a registry.

4.2.1 Rules Regarding Registry Presence

A registry makes use of <presence/> stanzas for determining the availability of farms on a countryside. In order to monitor <presence/> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In Instant Messaging, this is handled using this sequence of <presence/> communication.

Example 13. A successful subscription with a registry

<presence from="lp2@linkedprocess.org/farm" 
  to="lp3@linkedprocess.org/registry" type="subscribe"/>
					
<presence to="lp2@linkedprocess.org/farm" 
  from="lp3@linkedprocess.org/registry" type="subscribed"/>
					
<presence to="lp2@linkedprocess.org/farm" 
  from="lp3@linkedprocess.org/registry" type="subscribe"/>
					
<presence from="lp2@linkedprocess.org/farm" 
  to="lp3@linkedprocess.org/registry" type="subscribed"/>

After a subscription pairing has been established, the registry will then monitor all <presence/> stanza emanating from the countryside of the subscribing XMPP client. When a registry receives a <presence type="available"/> stanza from a farm (determined through disco#info), then the registry will add the countryside (the bare JID of the farm) to its index. When the registry receives a <presence type="unavailable"/> stanza from a farm, it will only remove that farm's countryside from its index if no other active farms are available at that countryside. In short, a registry only publishes countrysides (i.e. bare JIDs), not farms (i.e. fully-qualified JIDs). However, the determinant for publishing countrysides is the availability of active farms based off the bare JID countryside.

4.2.2 Locating Countrysides with Farms

A registry uses the XEP-0030 XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a disco#info query. The <item/> elements denote countrysides. For example, <item jid="lanl_countryside@lanl.linkedprocess.org"/> denotes that there is at least one active farm at lanl_countryside@lanl.linkedprocess.org.

Example 14. A successful query for countrysides registered with a registry.

<iq id="xxxx" to="lp3@linkedprocess.org/registry" 
  from="lp1@linkedprocess.org/villein" type="get">
  <query xmlns="http://jabber.org/protocol/disco#items"/>
</iq>

<iq id="xxxx" from="lp3@linkedprocess.org/registry" 
  to="lp1@linkedprocess.org/villein" type="result">
  <query xmlns="http://jabber.org/protocol/disco#items">
    <item jid="lanl_countryside@lanl.linkedprocess.org"/>
    <item jid="fortytwo_countryside@fortytwo.linkedprocess.org"/>
    <item jid="sweden_countryside@fortytwo.linkedprocess.org"/>
  </query>
</iq>

4.2.3 Discovering Information About a Registry

A registry uses the XEP-0030 XMPP extension for allowing villeins to discover what features a registry supports.

The <identity/> of a registry MUST be of category="client" and type="bot". The name attribute is up to the implementation.

The following <feature/>s MUST be supported by a registry:

The http://linkedprocess.org/2009/06/Registry# <feature/> denotes that the XMPP client is in fact a registry.

5. Error Codes

5.1 Farm Error Codes

The error codes associated with the http://linkedprocess.org/2009/06/Farm# namespace are fairly complicated as there are various states that a farm and its virtual machines can be in. The following error codes are summarized in the table below. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to Error Condition Mappings. Implementations SHOULD support both legacy and XMPP error handling.

Table 2: Error codes for http://linkedprocess.org/2009/06/Farm# namespace.

Code Type Condition Specific Element Purpose
400 Modify bad-request malformed_packet all The provided stanza was not properly constructed.
401 Auth not-authorized wrong_farm_password spawn_vm The supplied farm password was incorrect.
409 Cancel conflict internal_error all An error internal to the farm has occurred.
503 Cancel service-unavailable farm_is_busy spawn_vm The farm is out of resources and can not spawn a new virtual machine.
400 Modify bad-request species_not_supported spawn_vm The provided virtual machine species is not supported by the farm.
404 Cancel item-not-found vm_not_found all except spawn_vm The virtual machine id does not point to an existing virtual machine.
503 Cancel service-unavailable vm_is_busy submit_job The virtual machine has too many jobs in its queue and will not accept anymore.
400 Modify bad-request evaluation_error submit_job The supplied job expression threw an error in the virtual machine.
403 Auth forbidden permission_denied submit_job The supplied job expression violated a security permission in the virtual machine.
409 Cancel conflict job_already_exists submit_job The supplied job identifier already exists in the virtual machine.
408 Cancel request-timed-out job_timed_out submit_job The submitted job timeout and is no longer executing.
404 Cancel item-not-found job_not_found ping_job and abort_job The queried job identifier does not point to an existing job.
405 Cancel not-allowed job_aborted submit_job The submitted job was canceled.
400 Modify bad-request unknown_datatype manage_bindings The provided datatype is an unsupported datatype.
400 Modify bad-request invalid_value manage_bindings The provided value can not be converted according to the provided datatype.

This specification does not stipulate values of the XMPP <text/> element associated with the foregoing error conditions.

6. Security Considerations

Linked Process can be a very dangerous protocol if implemented incorrectly. The reason for this is that foreign code is executed on devices that are unaware of the intention or purpose of the code. Thus, if farm and virtual machine implementations do not correctly respect the permissions stated by the farm (as specified in the disco#info of the farm), then it is possible for malicious or poorly written code to destroy the integrity of the executing device (i.e. the resource provider). Moreover, Linked Process devices can be utilized for nefarious purposes.

The following is a list of potentially dangerous behaviors that can be executed if a Linked Process farm and virtual machine is not implemented correctly and/or exposes permission that are too "loose."

It is strongly RECOMMENDED that the implementors of a Linked Process farm and virtual machine have considerable knowledge in the area of software security and operating system engineering.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA)

8. XMPP Registrar Considerations

The following namespaces are defined by Linked Process:

9. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
  xmlns:xs='http://www.w3.org/2001/XMLSchema'
  targetNamespace='http://linkedprocess.org/2006/06/Farm#'
  xmlns='http://linkedprocess.org/2006/06/Farm#'
  elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      Linked Process XEP-XXX: http://www.xmpp.org/extensions/xep-xxx.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='spawn_vm'>
    <xs:complexType>
      <xs:attribute name='vm_species' type='xs:string' use='required'/>
      <xs:attribute name='farm_password' type='xs:string' use='optional'/>
      <xs:attribute name='vm_id' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='submit_job'>
    <xs:complexType>
      <xs:attribute name='vm_id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='ping_job'>
    <xs:complexType>
      <xs:attribute name='vm_id' type='xs:string' use='required'/>
      <xs:attribute name='job_id' type='xs:string' use='optional'/>
      <xs:attribute name='type' use='optional'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='in_progress'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='abort_job'>
    <xs:complexType>
      <xs:attribute name='vm_id' type='xs:string' use='required'/>
      <xs:attribute name='job_id' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='manage_bindings'>
    <xs:complexType>
      <xs:attribute name='vm_id' type='xs:string' use='required'/>
      <xs:element ref='binding'/>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='binding'>
    <xs:complexType>
      <xs:attribute name='name' type='xs:string' use='required'/>
      <xs:attribute name='value' type='xs:string' use='optional'/>
      <xs:attribute name='datatype' type='xs:simpleType' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='terminate_vm'>
    <xs:complexType>
      <xs:attribute name='vm_id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='malformed_packet' type='empty'/>
  <xs:element name='wrong_farm_password' type='empty'/>
  <xs:element name='internal_error' type='empty'/>
  <xs:element name='farm_is_busy' type='empty'/>
  <xs:element name='species_not_supported' type='empty'/>
  <xs:element name='vm_not_found' type='empty'/>
  <xs:element name='vm_is_busy' type='empty'/>
  <xs:element name='evaluation_error' type='empty'/>
  <xs:element name='permission_denied' type='empty'/>
  <xs:element name='job_already_exists' type='empty'/>
  <xs:element name='job_timed_out' type='empty'/>
  <xs:element name='job_not_found' type='empty'/>
  <xs:element name='job_aborted' type='empty'/>
  <xs:element name='unknown_datatype' type='empty'/>
  <xs:element name='invalid_value' type='empty'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

10. Acknowledgements

An acknowledgement of contribution must be given to Peter Neubauer (Neo Technology). Peter contributed to the testing of an implementation of the protocol that was developed in concert with this specification. Through the testing process, many issues were identified, rectified, and incorported into the protocol specification.


Appendices


Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2009-09-18
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0001, XEP-0004, XEP-0030, XEP-0086
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED


Appendix B: Author Information

Marko Rodriguez

Email: marko@markorodriguez.com
JabberID: okrammarko@gmail.com
URI: http://markorodriguez.com

Joshua Shinavier

Email: josh@fortytwo.net
JabberID: parcour@gmail.com
URI: http://fortytwo.net


Appendix C: Legal Notices

Copyright

Linked Process is copyright (c) 2009 by the Los Alamos National Laboratory of the United States Government.

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. Nothing prevents the same device from being a resource consumer in one context and being a resource provider in another.

2. There is a tradeoff between "general-purpose" and "safety." It is important to ensure that the integrity of resource providers are not compomised due to malicious or poorly written code.

3. The term entity is a generic term refering to a software component that is involved in a Linked Process cloud.

4. Given the rural naming convention, the term cloud could have been substituted by the terms nation or world. However, in order to maintain some connection to the terminology of the distributed computing community, the term cloud was opted for instead the more consistent "earthly" term.

5. Note that this is not required as in some cases, it is useful to run multiple farms on a single device. For example, two farms can have different permissions to resources.

6. This quote was taken from the surfdom Wikipedia entry on 06-06-2009.

7. Please refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.

8. This guideline is a SHOULD as opposed to a MUST as there may be cases where a farm instance wishes to divert from the guideline in order to handle known malicious JIDs or to ensure a private farm (or private cloud).

9. This is an important concept to understand. During the life of a virtual machine, the virtual machine has a state that changes as jobs are submitted and bindings are managed. In other words, a virtual machine is not a "one-job" machine.

10. This is an OPTIONAL attribute. Farm passwords are useful for creating private farms in order, for example, to allow "looser" permissions with known villeins. If no password is required (e.g. a public farm), then no farm_password attribute SHOULD be provided.

11. Note that, according to XMPP Core, it is RECOMMENDED that an <iq type="error"/> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <submit_job/>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <submit_job/> stanza in the error response could lead to excessive communication overhead.

12. What is provided is not an exhaustive list as there may be other permissions that are desired that can not be known apriori by the developers of this specification. For example, there may be computing resources such as hardware (e.g. video cards, FPGA components) that can have specialized requirements and parameters. Moreover, particular implementations of a Linked Process farm may have specific permissions that are not general to all implementaitons (e.g. Java-specific permissions). The data forms specification provided here can be extended to support such farm specific resources.


Appendix H: Revision History

Version 0.0.1 (2009-09-18)

First draft.

(psa)

END