OGF Community: Below are details for GFD #183-189 (except #187 and also 182, which are not published yet). Thanks to everyone who worked on their production, and thanks to the OGF for public comments. All OGF documents (including a few that are open for public comment!) may be found here: http://www.ogf.org/gf/docs/ * GFD-I.189 "Relying Party Defined Namespace Constraints Policies in a Policy Bridge PKI Environment." D. Groep, J. Jensen, via CAOPS-WG. 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. * GFD-R-P.188 "WS-Iterator 1.0." M. Morgan, via OGSA-Naming-WG 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 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 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. * GFD-R-P.186 "Data Management API within the GridRPC." Y. Caniou, E. Caron, G. Le Mahec, H. Nakada, via GRIDRPC-WG 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 middle- ware. 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 users, components of a GridRPC platform and storage resources 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. All functions in the API have been thought to be called by each part in a GridRPC platform (client, agent and server) if needed. * GFD-R-P.185 "Open Cloud Computing Interface - RESTful HTTP Rendering." T. Metsch, A. Edmonds, via OCCI-WG. 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. * GFD-R-P.184 "Open Cloud Computing Interface - Infrastructure." T. Metsch, A. Edmonds, via OCCI-WG. 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. * GFD-R-P.183 "Open Cloud Computing Interface - Core." T. Metsch, A. Edmonds, R. Nyren, A. Papaspyrou, via OCCI-WG. 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. With best wishes for a productive OGF32 in Salt Lake City, Greg Newby, OGF Editor Dr. Gregory Newby, Director of the Arctic Region Supercomputing Center Univ of Alaska Fairbanks-909 Koyukuk Dr-PO Box 756020-Fairbanks-AK 99775-6020 e: newby AT arsc.edu v: 907-450-8663 f: 907-450-8603 w: www.arsc.edu/~newby