URNs in the OGF namespace take the form
urn:ogf::.

This document describes the procedure how to register subnamespace identifiers () in the urn:ogf: namespace.

This document describes the Distributed Resource Management Application API Version 2 (DRMAA). It defines a generalized API to Distributed Resource Management (DRM) systems in order to facilitate the development of portable application programs and high-level libraries.

The intended audience for this specification are DRMAA language binding designers, DRM system vendors, high-level API designers and meta-scheduler architects. End users are expected to rely on product-specific documentation for the DRMAA API implementation in their particular programming language.

This document defines the mapping from DFDL 1.0 Infoset to W3C XDM, and from W3C XDM to DFDL 1.0 infoset.

This document specifies a Information System Navigator API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Information System Navigator API is motivated by a number of Use Cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from these Use Cases, as specified in GFD.71. It allows users to find additional information about services to that available via the SAGA Service Discovery API.

This document describes Web Services Agreement Negotiation Specification (WS-Agreement Negotiation), a Web Services protocol for negotiating a valid agreement offer between two parties, such as between a service provider and consumer. A valid agreement offer may then be input to create an agreement using WS-Agreement (specified in GFD.107). WS-Agreement Negotiation can also be used to renegotiate an existing agreement that needs to be modified. Thus, WS-Agreement Negotiation provides an additional layer when creating agreements with WS-Agreement. WS-Agreement Negotiation provides an additional layer when creating agreements with WS-Agreement is using an extensible XML language for specifying the nature of the agreement offers, and agreement templates to facilitate discovery of compatible agreement parties and ease the process of creating valid agreement offers. Agreement templates conforming to the WS-Agreement specification including a negotiation context and a set of negotiation constraints are used for the negotiation. The specification consists of all schemas required for the negotiation and the necessary port types.

All information for creating, managing and monitoring an agreement, based on a valid negotiated agreement offer is not described in this specification but in the specification of WS-Agreement.

This document, part of a document series, produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

This document, part of a document series, produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

This document, part of a document series, produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.

The Production Grid Infrastructure (PGI) working group works on a well-defined set of standard profiles, and additional standard specifications if needed, for job and data management that are aligned with a Grid security and information model that addresses the needs of production Grid infrastructures. These needs have been identified in various international endeavors and are in many cases based on lessons learned obtained from the numerous activities in the Grid Interoperation Now (GIN) community group. Therefore, PGI can be considered as a spin-off activity of the GIN group in order to feed back any experience of using early versions of open standards in Grid production setups to improve the standards wherever possible. This particular document is a survey of common use cases provided by different stakeholders of PGI profiles or standard specifications. Such stakeholders include production Grid and e-science infrastructures as well as technology providers. The goal of this document is to have a foundation for a set of important requirements to be addressed by the PGI set of profiles and/or specifications.

The Production Grid Infrastructure Working Group (PGI-WG) is elaborating documents permitting to improve interoperability of Production Grids.

The purpose of this ‘Glossary of Acronyms and Terms’ is to provide an expansion of acronyms and an unambiguous definition of terms used in the context of a Production Grid.

It is based on the ‘OGSA® Glossary of terms’ GFD.120, the ‘GLUE Specification v. 2.0’ GFD.147 and the PGI ‘Vocabulary’ Wiki page.

The root terms are ‘Data processing’, ‘Administrative domain’, ‘Trust’ and ‘Federation’.

It provides a minimum background information about Grids, but does NOT attempt to justify the definitions or the context in which they may be used. The reader is referred to external documents for further explanation where necessary.

A number of grid services aggregate data together in lists or maps as part of their inherent function. Consider RNS (the Resource Namespace Specification) which provides the means of mapping human readable names to resource endpoints. Also consider a grid queue or cluster management system that might both group together target or backend BESs (Basic Execution Services) as well as provide mechanisms for querying or manipulating lists of queued jobs. Numerous other examples exist. In both of these cases, it is unreasonable and inefficient to expect communication where the entire content of such a group is transferred in a single SOAP document. At the same time, given the potentially large and diverse spectrum of likely uses for which iteration might be ideal, a generic form of iteration is desirable – one for which iterable content is extensible.

A number of iteration service specifications exist already; in particular WS-Enumeration provides similar functionality. Unfortunately, WS-Enumeration [WS-Enumeration] is based off of an entirely different model of web service endpoint interaction then that of WSRF. While WSRF has adopted a notion of the “implied� target resource as identified by WS-Addressing [WS-Addressing] information included in the request message's SOAP headers, WS-Enumeration uses a more service oriented, “token-in-the-soap-body� protocol. As such, in cases where grid service design is heavily influenced by and modeled after a WSRF pattern, WS-Enumeration is confusing and ungainly. In those cases, WS-Iterator provides the same functionality in a way that is more consistent with intended WSRF practices. For a more detailed description of why the existing WS-Enumeration specification is not suited to this task of WSRF-based iteration, please reference.

The Network Services Framework describes a framework to support the request and management of Network Services; it allows an application or network provider to request Network Services from other network providers. This framework incorporates the interface, agent and associated services. The Network Service Interface (NSI) is defined to be the set of protocols and parameters that are used between a software agent requesting a Network Service and the software agent providing that Network Service. This document and its partner Network Service recommendations make up the complete NSI specification.

This document specifies a Message API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Message API is motivated by a number of use cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from these use cases, as specified in GFD.71). The API provides a wide set of communication pattern, and targets widely distributed, loosely coupled, heterogeneous applications.

The topology descriptions used at Internet2 are provided in an XML format for use in the Dynamic Circuit Network suite. The topology descriptions developed by the University of Amsterdam is the Network De- scription Language.

In August and September 2009 Jeroen van der Ham worked at Internet2 on the translation of topology descriptions. This report describes some of the findings in creating this translation.

The SAGA Core API (or short, SAGA API) has been implemented by a vari- ety of groups, in different languages. As the SAGA API specification itself is language neutral (it specifies the API in SIDL), it is difficult to define interop- erability between these implementations, in the conventional sense. That is left to later experience reports addressing specific language bindings.

This report rather will show that (a) the SAGA API can be mapped to various programming languages, without loosing any functionality, and (b) that these implementations can provide the required semantics for a wide variety of grid (and non-grid) backends. We consider those properties as necessary and sufficient to promote the proposed SAGA API specification (P-REC) to full recommendation status (REC).

This document specifies an Advert API extension to the Simple API for Grid Applications (SAGA), a high level, application-oriented API for grid application development. This Advert API is motivated by a number of use cases collected by the OGF SAGA Research Group in GFD.70, and by requirements derived from these use cases, as specified in GFD.71). It allows to persistently store application specific meta data in a name space hierarchy, along with serialized saga::object instances.

This document defines the detailed specifications and implementation requirements for the Inter-Domain Controller Protocol (IDCP). This document level of detail is intended to be sufficient to support independent implementation efforts.

This specification is provided to the OGF NSI Working Group as an informational document. The objective of this submission is to provide another example of a currently deployed protocol in this area, in case it is helpful to the ongoing NSI standardization efforts.

This protocol development work began as part of the DICE Control Plane Working Group. DICE is a collaboration amongst DANTE (GEANT), Internet2, CANARIE, ESnet, USLHCnet, and others. This protocol has been implemented and is currently deployed by ESnet, Internet2, GEANT AutoBAHN, USLHCnet, and others.

The IDCP defines a protocol and associated message formats that enable the dynamic provision of network resources across multiple administrative domains. The IDC architecture supports dynamic networking, the concept by which network resources (i.e. bandwidth, VLAN number, etc) are requested by end-users, automatically provisioned by software, and released when they are no longer needed. This is in contrast with the more traditional “static� networking where network configurations are manually made by network operators and usually stay in place for long periods of time.

The IDC protocol defines messages for reserving network resources, signaling resource provisioning, and gathering information about previously requested resources. These messages are defined in a SOAP [SOAP] web service format. This document and others relating to the IDCP are maintained at the IDCP Control Plane web site: www.controlplane.net.

In their 2002 book, “Distributed Systems: Principles and Paradigms�, Andrew Tannenbaum and Martin van Steen describe in great detail the properties, function, and benefit of naming schemes in distributed systems. Specifically, they describe a typical three-layer naming scheme whereby human readable names map to location-independent names or identifiers, which in turn map to location-dependent addresses. This three-tiered approach is instrumental in providing both usability for clients, as well as many of the classic distributed systems “transparencies� like fault and location transparency. WS-Naming provides the mapping between location-independent names (in the form of EndpointIdentifiers) and location- dependent addresses (i.e., WS-Addressing EPRs). In this specification we describe the Resource Namespace Service (RNS), a grid port type that allows clients to manipulate and retrieve mappings from human-readable strings to WS-Addressing Endpoint Reference Types1, thus providing the higher level mapping described by Tannenbaum and van Steen.

This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of dense binary and legacy data formats in a vendor-neutral declarative manner. DFDL is an extension to the XML Schema Description Language (XSDL).

In their 2002 book, “Distributed Systems: Principles and Paradigms�, Andrew Tannenbaum and Martin van Steen describe in great detail the properties, function, and benefit of naming schemes in distributed systems. Specifically, they describe a typical three-layer naming scheme whereby human readable names map to location-independent names or identifiers, which in turn map to location-dependent addresses. This three-tiered approach is instrumental in providing both usability for clients, as well as many of the classic distributed systems “transparencies� like fault and location transparency. WS-Naming provides the mapping between location-independent names (in the form of EndpointIdentifiers) and location-dependent addresses (i.e., WS-Addressing EPRs). In this specification we describe the Resource Namespace Service (RNS), a grid port type that allows clients to manipulate and retrieve mappings from human-readable strings to WS-Addressing Endpoint Reference Types , thus providing the higher level mapping described by Tannenbaum and van Steen.

This document describe experience gained while implementing the SMOA Computing Service, a component which development was steered by the following OGF specifications:
* GFD 108 - OGSA® Basic Execution Service Version 1.0
* GFD.114 - HPC Basic Profile, Version 1.0
* GFD.135 - HPC File Staging Profile, Version 1.0
In addition to comments on those specifications, this document presents possible extension to the Basic Execution Service: a separate interface for managing Advance Reservations based on the BES-Factory port.

The NML-WG goal is to define a schema for describing topologies of hybrid networks. This schema is in first instance intended for:
* lightpath provisioning applications to exchange topology information intra and inter domain;
* reporting performance metrics.

This document constitutes Deliverable 1 of the working group. It provides a detailed overview of the framework in which the working group operates, detailing the already existing topology schemas and providing the basis for the integration of the various projects.

This document is part of the Open Cloud Computing Interface (OCCI) specification document series. The OCCI document series describes what each OCCI compatible interface needs to provide. The overall OCCI specification itself is setup modular to be extensbible and includes the following parts:
* The OCCI Core and Models
* The OCCI Infrastructure Models
* OCCI XHTML5 rendering
* OCCI HTTP Header rendering

Each of these parts is described in a separate document so the overall specification comes in the form of a document series. Whereas this document describes the OCCI Core and Models.

This document is part of the Open Cloud Computing Interface (OCCI) specification document series. The OCCI document series describes what each OCCI compatible interface needs to provide. The overall OCCI specification itself is setup modular to be extensbible and includes the following parts:
* The OCCI Core and Models
* The OCCI Infrastructure Models
* OCCI XHTML5 rendering
* OCCI HTTP Header rendering

Each of these parts is described in a separate document so the overall specification comes in the form of a document series. Where as this document describes the OCCI HTTP header rendering. It can be seen as the machine interface for OCCI.

This document is part of the Open Cloud Computing Interface (OCCI) specification document series. The OCCI document series describes what each OCCI compatible interface needs to provide. The overall OCCI specification itself is setup modular to be extensbible and includes the following parts:
* The OCCI Core and Models
* The OCCI Infrastructure Models
* OCCI XHTML5 rendering
* OCCI HTTP Header rendering

Each of these parts is described in a separate document so the overall specification comes in the form of a document series. Where as this document describes the OCCI Infrastructure models.

This document is part of the Open Cloud Computing Interface (OCCI) specification document series. The OCCI document series describes what each OCCI compatible interface needs to provide. The overall OCCI specification itself is setup modular to be extensbible and includes the following parts:
* The OCCI Core and Models
* The OCCI Infrastructure Models
* OCCI XHTML5 rendering
* OCCI HTTP Header rendering

Each of these parts is described in a separate document so the overall specification comes in the form of a document series. Where as this document describes the OCCI XHTML5 rendering.This can be used as a User Interface rendering for OCCI.

This document follows the document produced by the GridRPC-WG on GridRPC Model and API for End-User applications]. This new document aims to complete the GridRPC API with Data Management mecha- nisms and API.

This document is not intended to provide features and capabilities for building data management middleware. Its goal is to complete the GridRPC set of functions and definitions to allow users to manipulate their data. The motivation for this document is to provide explicit functions to manipulate the exchange of data between a GridRPC platform and a client since (1) the size of the data used in Grid applications may be large and useless data transfers must be avoided; (2) data are not always stored on the client side but may be made available either on a storage resource or within the GridRPC platform. Nonetheless, all functions in the API have been thought to be called by each part in a GridRPC platform (client, agent and server) if needed.

The Database Access and Integration Services Working Group (DAIS-WG) has submitted three specifications to the Open Grid Forum (OGF) recommendation track [WS-DAI, WS-DAIR, WS-DAIX]. These specifications define a basic set of interfaces, properties and patterns for service-based access to data. The core WS-DAI specification outlines a set of generic interfaces and properties that are common to most types of data access. These may then be extended to access specific types of data. For instance, the WS-DAIR and WS-DAIX specifications extend the base specification to provide access to relational and XML types of data respectively.

This document outlines and motivates a further extension to the WS-DAI family of specifications to provide access to RDF(S) data. This will define a standard mechanism for accessing RDF(S) data in a manner consistent with the framework defined by the WS-DAI core specification. The main outcome of this work will be two specifications that provide complementary ways for accessing RDF(S) data: by using the W3C defined SPARQL query language or through the use of ontological primitives.

This document motivates this work by presenting an overview of the role of RDF(S) in a grid context with several motivational use cases.

This document is an informal description of Use Cases and requirements for the OOCI Cloud API. Created by the Open Cloud Computing Interface working group. This document records the needs of IaaS Cloud computing managers and administrators in the form of Use Cases. The Use Cases serve as the primary guide for the development of API requirements. The document is the first deliverable to demonstrate and validate the features of the Open Cloud Computing Interface.

This document describes the implementation experiences of independent implementations of WS-Agreement along with an overview of the projects that have implemented WS-Agreement so far. It also presents the features of WS-Agreement used by 8 of the implementations. Finally, the document contains information on set-up and results of an experiment where two independent implementations of WS-Agreement were used to mutually exchange templates describing jobs and create agreements.

The Data Access and Integration Services (DAIS) Working Group have defined three proposed recommendations within the Open Grid Forum (OGF). The OGF process and requirements document [GFD.152] states that two independent interoperable implementations are required for a proposed recommendation to become a full OGF recommendation. This OGF experimental document reports on interoperability testing of two implementations of WS-DAIR (GFD.76) – one from the OGSA-DAI group at The University of Edinburgh and the other based on AMGA from KISTI. In addition, as the WS-DAIR proposed recommendation is an extension to WS-DAI (GFD.74), the testing process has encompassed both the WS-DAIR and WS-DAI proposed recommendations. The tests documented in this OGF experimental document establish that it is indeed possible to obtain client-based interoperability for these two implementations. However, as a result of this interoperation process a number of changes are recommended for the WS-DAI and WS-DAIR documents before they gain full recommendation status.

It is important to note that this document establishes a set of interoperability requirements between two or more implementations of the WS-DAI specifications, taking into account the criteria established in GFD.77. This document is not intended to establish a validation process to test the compliance of any particular implementation to any of the (proposed) DAIS recommendations.

This document describes a multi-server based namespace data management system for Resource Namespace Service (RNS), which is introduced in GFD 101. In this system, RNS can be accessed through a master node, which provides the standard interfaces and functions defined in GFD 101. When the master node receives the RNS request, it will dispatch the request to one of the slave nodes based on load balancing policy. Every slave node stores a copy of the namespace data and responses to the read request, such as list and query functions, while only one slave node responses to the write request, such as add, update and remove functions. There is a data synchronization process to keep the data consistence on all the slave nodes. In this method, even though one or more slave servers failed, the RNS can also provide stable service. This multi-server based namespace data management system can improve the availability and scalability of RNS.

This document describes experience in building an INFOD system from the specification document (GFD.110). It also includes changes that should be included in a new version of an INFOD specification.

Relying Party Defined Namespace Constraints (RPDNC) are limitations on the subject namespace issued by X.509 certification authorities (CAs) that are defined and enforced by the end-point at the relying party side. As grid authentication based on X.509 credentials provides the subject DN as a handle that identifies the authenticated entity, the capability to ensure subject name uniqueness is of critical importance in ensuring overall integrity of the authentication system.

This document described the rationale and use cases for relying party defined name space constraints, and lists the set of desired features a policy language expressing such constraints should have.

This document is a result of the work of OGF RISGE-RG. It presents collection of use cases that covers various existing approaches in defining remote access interfaces to sophisticated laboratory equipment. One of the important aspect covered by these examples is an exploitation of Grid technologies for conducting and monitoring measurement tasks and experiments on complex remote scientific equipment.

A few groups have developed independent implementations of the Storage Resource Management (SRM) interface specification v2.2. This document describes those implementations and experiences in interoperability testing. Issues that were identified during the implementations of the specification and the production deplopyments of the implementations in various projects help develop more robust specification in the next version.

This document provides a complete description of the VOMS AC format, both syntax and semantics. It also describes the related extensions that must be used in a proxy certificate to make it fully VOMS-compliant.

This document defines the types of OGF documents and the development and review processes for each type. This document obsoletes GFD-C.1 and replaces it as the description of OGF community practice surrounding the document series. The process reflects several years of experience with OGF document publication, and borrows heavily from the Internet Engineering Task Force Request for Comments document process.

Prior Public Comments:
http://forge.gridforum.org/sf/discussion/do/listTopics/projects.ggf-editor/discussion.cp_ogf_document_process

Grids use X.509 certificates for authentication and authorization. These certificates are issued to subscribers that comprise a virtual organization, and are typically issued by Certification Authorities operated by real institutions. In order to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies or procedures, these Certification Authorities (CAs) should be externally audited periodically. The International Grid Trust Federation (IGTF) has, based on templates established by OGF, established such sets of operational policies and procedures. This document provides an audit checklist which describes auditing items to be considered by CAs accredited by the IGTF to be compliant with the ‘Classic’ Authentication Profile, and provides the acceptable evidence for the verification of these items. Detailed processes of auditing are also described in this document which is intended as guidelines for auditing Grid CAs,

Web-based online communities such as blogs, forums and scientific communities have become important places for people to seek and share expertise. Search engines such as Google, Yahoo!, Live etc. are not yet capable to address queries that require deep semantic understanding of the query or the document. Instead, it may be preferable to find and ask someone who has related expertise or experience on a topic. Web-based online communities are the places people often seek advice or help. Before an analysis of search capabilities for these communities can be done, we need to gather the data (questions and answers, social support or discussion, comments or advice, content rating, social relations, and so forth) that describe the communities. There is no universal standard data structure for the outline of user participation in these communities. Also, as these communities rarely interoperate, each typically only has access to its own social data and cannot benefit from other communities’ data. Extracting, aggregating and analyzing data from these communities for finding experts on a single framework is a challenging task. In this document, we present a Grid-enabled framework of expertise search (GREFES) engine, which utilizes online communities as sources for experts on various topics. We suggest an open data structure called SNML (Social Network Markup Language) to outline user participation in online communities. The architecture addresses major challenges in crawling of community data and query processing by utilizing the computational power and high bandwidth inherently available in the Grid. Our framework supports open APIs for third party providers or developers to build new solutions in order to get more user feedback to improve the system.

The Open Grid Services Architecture Data Movement Interface (OGSA-DMI) specification defines a standardized mechanism for moving data from a source to a destination. By abstracting this data transfer, the client complexity for moving data within a grid is greatly reduced. OGSA-DMI defines two port types for initiating, scheduling and managing data transfers from a given source to a specified destination. The source and destination are described through Data End Point References (DEPRs), a specialized form of a WS-Address.

The Open Grid Services Architecture Data Movement Interface Functional Specification 1.0 defines the abstract methods and attributes of the Data Transfer Factory (DTF) and the Data Transfer Instance (DTI) port types.

This document defines the normative WSDL interface for a plain (non-WSRF-based) Web Service rendering of the Functional Specification.

This document describes the requirements for construction and operation of grid systems. This document does not say “Grid Systems must satisfy these requirements�. It says “These requirements shall be considered when someone designs / constructs / operates on Grid Systems�.

This document describes the representation of the DRMAA 1.0 API in the Python programming language. It is based on the DRMAA 1.0 IDL recommendation (GFD-R-P.130), and maps the DRMAA IDL interface definition to specific Python language constructs.

This document specifies the syntax and semantics of the proposed Parameter Sweep extension to the Job Submission Description Language (JSDL) 1.0.

The syntax and semantics defined in this document provide an alternative to explicitly submitting thousands of individual JSDL job submissions of the same base job template, but, each with a different parameter set.

This document describes the experiences of interoperability testing of independent implementations of the OGSA WSRF Basic Profile 1.0 [OGSA-WSRFBP], and the specifications that it incorporates by reference, namely Web Services Addressing 1.0 - Core [WS-Addressing], Web Services Resource Properties 1.2 [WS-ResourceProperties], Web Services Resource Lifetime 1.2 [WS-Resource Lifetime], Web Service Base Faults 1.2 [WS-Base Faults], and Web Services Base Notification 1.3 [WS-BaseNotification].

Many problems were encountered during the tests, largely related to schema errors, platform/tooling incapability, and specification issues. Despite this the tests proved in so much as they identified two issues in the OGSA WSRF Basic Profile and the WS-BaseNotifiation specifications. Solutions were proposed and were agreed by all implementers and original Profile authors.

This document reports about experiences made with running OGSA ByteIO working group interoperability test scenarios based on the ByteIO OGSA® WSRF Basic Profile Rendering 1.0 of the ByteIO Specification 1.0 as implemented by the four groups participating in the OGSA ByteIO Interoperability Fiesta. The four groups represented different implementation environments: Genesis II by the University of Virginia (UVa), UNICORE by Forschungszentrum Jülich, OGSA-DAI by EPCC, the University of Edinburgh (EPCC), and a clean-room implementation by Fujitsu Labs of Europe (FLE).

This document also remarks on the special considerations made to implement the OGSA ByteIO specifications on different Web Services and XML stacks. The main difficulties arise because of the way that different Web Services and XML tooling interprets particular elements. These arose not in the implementation of the ByteIO specification itself, but in the associated implementation required for the interoperability experiments.

This document describes and evaluates approaches and solutions for firewall issues, such as application level gateways, host based firewalls, VPN style gateways etc., which are currently available to solve some of the problems Grid applications may face when dealing with firewalls located between the source and the destination of their communication paths.

This is an OGF informational document outlining the need for, and some possible approaches to developing, a Professional Grid Certification Program. It is aimed at the stakeholders who might be interested in developing such a certification programme, including potential employers of certified Grid professionals as well as the certification and training industries and middleware and technology providers.
The document outlines a possible structure of a Certification Program along with some options for how to develop and sustain such an effort. Finally, some possible future directions are outlined in the Future work section.

The development of e-Infrastructure, of which grid computing is a fundamental element, will have major economic and social benefits. Online and financial businesses already successfully use grid computing technologies, for instance. New research methods and technologies generate large data sets that need to be shared in order to ensure continued social and scientific research and innovation. Distributed computing can provide an environment for coping with these large data sets and for sharing data across regions. An investment in educating people in grid computing and e-Science, then, is an investment that will strengthen our economies and societies. In order to deliver e-Infrastructure education internationally, we must develop a policy framework that will ensure shared responsibility and equivalent training in the field. This document introduces the current challenges for grid and e-Science education and training and presents opportunities and existing structures for education and training, as a starting point for further work. It then proposes strategies and policies to provide a supportive framework for
e-Infrastructure education and training.

This document is a call to action, identifying issues and proposing a strategy in order to support and make progress in grid and e-Science education and training. Inevitably, it is neither complete nor definitive. The intention is that it will seed much greater efforts to further develop the understanding of requirements, to better characterise challenges and to propose specific strategies, curricula and collaborative efforts for international adoption. The ET-CG is already fostering other more specific work and documents that form elements of that development.

This document shows how specifications, that have been developed within and external to the Open Grid Forum, can be used to enable desktop access to distributed computing resources. Increasingly, Independent Software Vendors (ISVs) are developing applications that have two components – a graphical client that resides on the client and a compute intensive server compo-nent that can run on a ‘back-end’ compute cluster. Integrating these two components within net-works which frequently have firewalls and NATs, across different operating systems and software environments, provides many challenges. A standards based interface to this environment would provide ISVs with a solid foundation upon which to build their own applications.
We identify and describe a set of standards and specification that have been developed to facili-tate access to distributed computing resources. We illustrate how these specifications could en-able access to distributed computing resources through five scenarios. These range from simple job submission to a compute cluster where the client and the cluster have a common file system, to a client that stages files to and from the compute cluster while having bi-directional interaction between the application running on the compute cluster and the remote client.
By illustrating how these specifications can be applied to these scenarios we identify require-ments for both the middleware providers and the ISVs – recognizing that we are providing advice rather than rigid prescriptive solutions. Finally, we identify some open issues for discussion and feedback by the community relating to resource selection and security.

This document presents a specification for an authorization credential retrieval protocol based on the use of the Security Assertion Markup Language (SAML) and protocol as a format for requesting and retrieving attribute assertions.

This document provides a protocol for an authorization component to access an external credential validation service (CVS) prior to calling a policy decision point (PDP). The protocol is a profile of a SAML attribute assertion carried by WS-Trust.

This document describes the implementation and interoperability experiences of independent implementations of the Job Submission Description Language (JSDL) 1.0.

Grids in their current form of deployment and implementation have not been as successful as hoped in engendering distributed applications. Amongst other reasons, the level of detail that needs to be controlled for the successful development and deployment of applications remains too high. We argue that there is a need for higher levels of abstractions for current Grids. By introducing the relevant terminology, we try to understand Grids and Clouds as systems; we find this leads to a natural role for the concept of Affinity, and argue that this is a missing element in current Grids. Providing these affinities and higher-level abstractions is consistent with the common concepts of Clouds. Thus this paper establishes how Clouds can be viewed as a logical and next higher-level abstraction from Grids.

This document defines the Advanced Filter extension – an alternative to the Basic Filter element described in the HPC Basic Profile 1.0 specification. The Basic Filter provides only an 'on' or 'off' approach to returning information about the activities or resources operating within the Basic Execution Service container. The Advanced Filter extension provides more flexibility to the client in returning information from an HPC Basic Profile complaint endpoint.