This XML-based Emergency Data Exchange Language (EDXL) Resource Messaging specification describes a suite of standard messages for data sharing among emergency and other information systems that deal in requesting and providing emergency equipment, supplies, people and teams, This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding.

Status:

This document was last revised or approved by the Emergency Management Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Emergency Management TC web page at http://www.oasis-open.org/committees/emergency/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at http://www.oasis-open.org/committees/emergency/ipr.php

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/emergency/.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “Emergency Data Exchange Language,” “Emergency Data Exchange Language Distribution Element,” “Emergency Data Exchange Language Resource Messaging,” “EDXL,” “EDXL-DE” and “EDXL-RM” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction. 7

1.1 Purpose. 7

1.2 History. 7

1.3 Structure of the EDXL Resource Message. 8

1.4 Terminology. 8

1.5 Normative References. 8

1.6 Non-Normative References. 9

2 Design Principles and Concepts (non-normative) 10

2.1 Requirements for Design. 10

EDXL Resource Messaging Standard Requirements Supplement. Error! Bookmark not defined.

2.2 Example Usage Scenarios. 11

2.2.1 Safecom Explosion. 11

2.2.2 Cedar Fire Incident 11

2.2.3 Hurricane. 11

2.2.4 Pandemic Influenza. 12

3 EDXL Resource Messaging Model (normative) 13

3.1 Abstract Reference Model. 13

3.2 Element Reference Model. 14

3.3 Resource Message Types. 14

3.3.1 Request Resource Message. 18

3.3.1.1 Overview.. 18

3.3.1.2 Element Reference Model 18

3.3.1.3 Message Flow.. 20

3.3.1.4 Message Example. 20

3.3.2 Response to Request Resource Message. 23

3.3.2.1 Overview.. 23

3.3.2.2 Element Reference Model 23

3.3.2.3 Message Flow.. 25

3.3.2.4 Message Example. 25

3.3.3 Requisition Resource Message. 27

3.3.3.1 Overview.. 27

3.3.3.2 Element Reference Model 27

3.3.3.3 Message Flow.. 29

3.3.3.4 Message Example. 30

3.3.4 Commit Resource Message. 32

3.3.4.1 Overview.. 32

3.3.4.2 Element Reference Model 32

3.3.4.3 Message Flow.. 34

3.3.4.4 Message Example. 34

3.3.5 Request Information (RFI) Message. 36

3.3.5.1 Overview.. 36

3.3.5.2 Element Reference Model 36

3.3.5.3 Message Flow.. 38

3.3.5.4 Message Example. 38

3.3.6 Response to Request Information Message. 40

3.3.6.1 Overview.. 40

3.3.6.2 Element Reference Model 40

3.3.6.3 Message Flow.. 42

3.3.6.4 Message Example. 42

3.3.7 Offer Unsolicited Resource Message. 45

3.3.7.1 Overview.. 45

3.3.7.2 Element Reference Model 45

3.3.7.3 Message Flow.. 46

3.3.7.4 Message Example. 47

3.3.8 Release Resource Message. 49

3.3.8.1 Overview.. 49

3.3.8.2 Element Reference Model 49

3.3.8.3 Message Flow.. 52

3.3.8.4 Message Example. 52

3.3.9 Request Return Message. 53

3.3.9.1 Overview.. 53

3.3.9.2 Element Reference Model 54

3.3.9.3 Message Flow.. 55

3.3.9.4 Message Example. 56

3.3.10 Response to Request Return Message. 57

3.3.10.1 Overview.. 57

3.3.10.2 Element Reference Model 57

3.3.10.3 Message Flow.. 59

3.3.10.4 Message Example. 59

3.3.11 Request Quote Message. 60

3.3.11.1 Overview.. 60

3.3.11.2 Element Reference Model 60

3.3.11.3 Message Flow.. 62

3.3.11.4 Message Example. 63

3.3.12 Response to Request Quote Message. 65

3.3.12.1 Overview.. 65

3.3.12.2 Element Reference Model 65

3.3.12.3 Message Flow.. 67

3.3.12.4 Message Example. 67

3.3.13 Request Resource Deployment Status Message. 69

3.3.13.1 Overview.. 69

3.3.13.2 Element Reference Model 69

3.3.13.3 Message Flow.. 71

3.3.13.4 Message Example. 72

3.3.14 Report Resource Deployment Status Message. 73

3.3.14.1 Overview.. 73

3.3.14.2 Element Reference Model 73

3.3.14.3 Message Flow.. 75

3.3.14.4 Message Example. 75

3.3.15 Request Extended Deployment Duration. 77

3.3.15.1 Overview.. 77

3.3.15.2 Element Reference Model 77

3.3.15.3 Message Flow.. 79

3.3.15.4 Message Example. 79

3.3.16 Response to Request Extended Deployment Duration Message. 80

3.3.16.1 Overview.. 80

3.3.16.2 Element Reference Model 80

3.3.16.3 Message Flow.. 82

3.3.16.4 Message Example. 82

4 Data Dictionary. 84

4.1.1 ResourceMessage Element 84

4.1.2 IncidentInformation Element 88

4.1.3 MessageRecall Element 88

4.1.4 Funding Element 89

4.1.5 ResourceInformation Element 90

4.1.6 ResponseInformation Element 90

4.1.7 Resource Element 92

4.1.8 OwnershipInformation Element 95

4.1.9 ResourceStatus Element 97

4.1.10 AssignmentInformation Element 100

4.1.11 AssignmentInstructions Element 103

4.1.12 ScheduleInformation Element 104

Supporting Element Types. 106

4.1.13. 106

4.1.13.1 ContactInformationType. 106

4.1.13.1.1 Radio Element 108

4.1.13.2 LocationType. 109

4.1.13.2.1 Imported Type Definitions. 110

4.1.13.3 ValueListType. 114

5 Distribution of EDXL-RM.. 116

A. XML Schema for the EDXL Resource Messaging.. 117

A.1 Resource Messaging Common Types. 117

A.2 Resource Messaging Reference Schema. 122

A.3 Request Resource Message Schema. 124

A.4 Response To Request Resource Message Schema. 127

A.5 Requisition Resource Message Schema. 130

A.6 Commit Resource Message Schema. 132

A.7 Request For Information (RFI) Message Schema. 135

A.8 Response To Request For Information Message Schema. 137

A.9 Offer Unsolicited Resource Message Schema. 140

A.10 Release Resource Message Schema. 142

A.11 Request Return Message Schema. 145

A.12 Response To Request Return Message Schema. 148

A.13 Request Quote Message Schema. 151

A.14 Response to Request Quote Message Schema. 153

A.15 Request Resource Deployment Status Message Schema. 156

A.16 Report Resource Deployment Status Message Schema. 159

A.17 Request Extended Deployment Duration Message Schema. 162

A.18 Response to Request Extended Deployment Duration Message Schema. 165

B. Acknowledgements. 169

C. Revision History. 170

1 Introduction

1.1 Purpose

As detailed in the EDXL_DE Specification the goal of the EDXL project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL will accomplish this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession jor governmental jurisdiction is involved.

The primary purpose of the Emergency Data Exchange Language Resource Messaging (EDXL_RM). Specification is to provide a set of standard formats for XML emergency messages. These Resource Messages are specifically designed as payloads of Emergency Data Exchange Language Distribution Element- (EDXL_DE)-routed messages. Together EDXL_DE and EDXL_RM are intended to expedite all activities associated with resources needed to respond and adapt to emergency incidents. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs.

The Resource Message is constrained to the set of Resource Message Types contained in this specification. The Resource Message is intended to be the payload or one of the payloads of the Distribution Element which contains it.

1.2 History

Disaster Management (DM) is a communications program in the Department of Homeland Security’s (DHS) Office for Interoperability and Compatibility (OIC) and managed by the Science and Technology (S&T) Directorate. The program was initiated as one of the Presidents e-gov initiatives. DM’s mission is to serve as the program within the Federal Government to help local, tribal, state, and federal public safety and emergency response agencies improve public safety response through more effective and efficient interoperable data sharing. The DHS DM program sponsors a Practitioner Steering Group (PSG) made up of represenations of major emergency response associations.

The DM Practitioner Steering Group (PSG) governance was formalized following publication of the EDXL Distribution element. It plays a key role in the direction, prioritization, definition, and execution, and of the DHS-DM program. The group is comprised of representatives of major emergency response associations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the DM program.

The PSG specified messaging standards-based systems interoperatility as the #1 priority for the DHS Disaster Management program. The EDXL Resource Messaging Specification effort was identified as the top priority standard by this group following the EDXL-DE. The requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) in a Standards Working Group (SWG). That group developed a draft specification which was submitted to the OASIS Emergency Management Technical Committee to begin work on this EDXL-RM specification.

The process remained the same as with the EDXL_DE specification with the exception that the Technical Committee requested that the initial candidate specification submitted by the expert group be recast as a formal Requirements Document according to a template that the Technical Committee provided to the expert group. The candidate specification was then resubmitted along with this requested requirements document.

1.3 Structure of the EDXL Resource Message

The EDXL Resource Message specification applies to 16 separate specific message types related to the major communication purposes involved in the allocation of resources pertaining to preparation for, response to and remediation of emergency incidents.

The non-normative abstract reference model diagram in Figure 1 in Section 3.1 shows the abstract structural relationships of the main components:

· Resource Message: The overall Type of EDXL Payload;

· Message: The specific message, primarily of Request or Response general types, but with signficant other subtypes;

· Party: Organizations and Individuals connected with the message;

· Resource: the actual referrent of the message, which can be equipment, material substances such as water, people with certain skills, etc;

· Schedule: Temporal information such as when requested, when needed, when arrived, etc., associated with the message;

· Assignment: Instructions relative to the displosition of Resource or Resources referred to in the message usually related to geospatial and jurisdictional information.

The Element Reference Model in Figure 2 in Section 3.2 gives a more concrete view of the structure common to all Resource Messages.

Table 1 in Section 3.3 provides a Resource Message Type Summary of the 16 specific types of Resource Message.

Figure 3 in Section 3.3 illustrates the three primary types of behavior which Resource Messages enable :

· Discovery;

· Ordering; and

· Deployment.

Table 1: in Section 3.3 provides a Resource Message Type – Element Matrix where each row represents a specific message element grouped by functional categories and each column represents a specific message type. Thus one can determine whether any combination of message element and message type is Required, Conditional, or Optional.

Each specific message type is fully described in Sections 3.3.1 through 3.3.16

1.4 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 Error! Reference source not found..

1.5 Normative References

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC3066] H. Alvestrand, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc3066.txt, IETF RFC 3066, January 2001.

[WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic System 1984, http://earth-info.nga.mil/GandG/tr8350_2.html, NGA Technical Report TR8350.2, January 2000.

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, February 2004.

[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, January 1999.

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

1.6 Non-Normative References

[EDXL GFR] EDXL General Functional Requirements, http://www.oasis-open.org/committees/download.php/10031/EDXL%20General%20Functional%20Requirements.doc, November 2004

[EDXL-DE IG] EDXL Distribution Element Implementer's Guide, http://www.oasis-open.org/committees/download.php/14120/EDXL_Implementer%27sGuide.doc, August 2005

[EDXL-RM SRS] EDXL Resource Messaging Standard Requirements Supplement, workgroup http://www.oasis-open.org/committees/download.php/14981/EDXLRqmtsSupplement101905.doc, October 19, 2005

[EDXL-RM SF] EDXL Resource Messaging Standard Format for Resource Messaging (candidate specification) http://www.oasis-open.org/committees/download.php/13690/EDXL_ResourceDraft07152005.doc, July 15, 2005

2 Design Principles and Concepts (non-normative)

Below are some of the guiding principles of the Resource Message:

Provide a standard message format for the Resource Message
Provide separate specific formats for the discrete, distinct Resource Message Types
Enable dissemination of messages based on geographic delivery area
Use and re-use of data content and models developed by other initiatives
Business process-driven specific messaging needs across emergency professions
Supporting everyday events and incident preparedness, as well as disasters
Facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services

2.1 Requirements for Design

The initial requirements submitted to the Technical Committee by the EDXL Standards Working Group described in Section 1.2 can be reviewed :

EDXL Resource Messaging Standard Requirements Supplement, workgroup

http://www.oasis-open.org/committees/download.php/14981/EDXLRqmtsSupplement101905.doc, October 19, 2005

In summary, the EDXL Resource Messaging specification should

1. Define a detailed message formet structure for the following specific EDXL Resource Message Types: (Note that requirements that are self-evident from Message Type names are not separately listed)

a. RequestResource

b. Response to Request Resource

c. Requisition Resource

d. Commit Resource

e. Request Information (RFI)

f. Response to Request Information

g. Offer Unsolicited Resource

h. ReleaseResource

i. Request Return

j. Response to Request Return

k. Request Quote

l. Response to Request Quote

m. Request Resource Deployment Status

n. Report Resource Deployment Status

o. Request Extended Deployment Duration

p. Response to Request Extended Deployment Duration

2. Explicitly specify use of EDXL_DE as the routing mechanism for the EDXL Resource Message

3. Provide the ability to specify a desired geographic Resource delivery area, provide for notice of Resource demobilization and the ability to communicate information to provide for returning Resource

4. Provide ability to accept or decline a Response to Request Resource that indicates requested Resource is available or to accept or decline an Offer of Unsolicited Resource

5. Provide the ability to cancel any Resource Message (actual method is Message Recall)

6. Provide the ability to reference specific incidents in Resource Message

7. Provide unique identifier for each message as well as the ability to reference previous messages, including but not limited to originating message in a given sequence

8. Provide the ability to specify Date and Time of Resource Message, referenced messages, scheduling information, assignment information and specific instructions

9. Provide the ability to report Disposition of referenced Resource Message(s)

10. Provide the ability to specify contact information of individuals responsible for Resource Message(s) and/or Resource(s)

11. Provide the ability to specify funding information for Resources

12. Provide the ability to reference external lists for Resource Message content

13. Provide the ability to fully describe Resource(s)

14. Provide the ability to specify Special Requirements such as protective equipment or specific skill credentials, e.g. certifications, licenses

15. Provide the ability to specify Resource Information for purposes beyond identification and qualification such as scheduling and assignment.

2.2 Example Usage Scenarios

Note: The following examples of use scenarios were used as a basis for design and review of the EDXL Resource Messaging Specification. These scenarios are non-normative and not intended to be exhaustive or to reflect actual practices.

2.2.1 Safecom Explosion

This scenario follows the detection of a noxious aerosol substance leak at a demical plant that produces toxic materials, including evacuations, requests for hazmat teams and the evolution of the incident into an explosion that destroys the leak sit and an adjacent building with casualties requiring emergency healthcare teams, full incident command establishment, responses of various kinds and clean up

Full use case available: http://www.oasis-open.org/committees/download.php/14410/EDXL_use_example_SafecomExplosion%20060805.doc

2.2.2 Cedar Fire Incident

This is an actual use case that follows the events of the “Cedar” fire incident inlate October and November 2003 in San Diego County, California. Operation Center (EOC) has been activated, and requests the agencies to be on alert. This follows the lack of radio interoperability and poor coordination of mutual aid in the area due to several other fires during the period and previously

Full use case available: http://www.oasis-open.org/committees/download.php/14411/EDXL_use_example_Fire061005.doc

2.2.3 Hurricane

This scenario modeled a category 5 hurricance several months prior to the start of the 2005 hurricane season in earnest, and follows many different kinds of resource requests and evolving situations as a widespread incident with mass casualties and damage occurs.

Full use case available: http://www.oasis-open.org/committees/download.php/14412/EDXL_use_example_Hurricane061005.doc

2.2.4 Pandemic Influenza

This scenario models an Influenza Pandemic outbreak at Phase 6 (Increased and pre-sustained transmission in general population) as determined by the State Health Agency/Public Health Department. It includes such activities as requesting medical facilities to take stock and determine what resources are readily available and on hand (inventory of available supplies). It includes a wide range of resource messages such as requests for vaccines and anti-.virals.

Full use case available: http://www.oasis-open.org/committees/download.php/14411/EDXL_use_example_Influenza_06152005%20LaniGrahmRev.doc

3 EDXL Resource Messaging Model (Non-normative)

3.1 Abstract Reference Model

Figure 1 below shows the Resource Messaging Abstract Reference Model (RM-ARM). The purpose of the RM-ARM is to highlight the high-level structure of the RM framework and the relationships between the main entities.

The Resource Message contains either one of two major message categories: a Request or a Response message; or a minor message category type, a Report message;.These two major and one minor message categories form the underlying framework for all messages. The Resource Message also contains information on the Party (person or organisation) that plays a significant Role in the message transaction. Funding information can also be specified.

Figure 1: Resource Messaging – Abstract Reference Model

The core of any message is the Resource. A Resource contains information about its Identity, Description and its Status. A Resource owner can also be identified.

A Resource may also have a schedule which includes Temporal and Spatial details. For example, the expected arrival time and place for a specific resource. There are a number of types for Schedules.

A Resource may also have information about its Assignment including the identified Incident and Instructions related to the incident assignment.

3.2 Element Reference Model

Figure 2 below shows the EDXL–RM Element Reference Model (ERM). The purpose of the ERM is to highlight the low-level structure of the RM framework and the relationships between the main entities and their elements.

It is important to note that the ERM should not be used as an implementation model as the exact semantics and structure is captured in the subsequent sections on the Resource Message Types.

Figure 2: Resource Messaging – Element Reference Model

The RM-ERM shows the element-level details for the main entities in the RM. The semantics for each of the elements is defined in Section Error! Reference source not found..

3.3 Resource Message Types

The general RM framework is based on a Request/Response model. Most of the Request messages expect a Response, and in some cases, messages are used to notify others of changes or offers of resources.

This two-way communication is characterised by two classes of primary actors. The Resource Consumer is an actor that needs or requires resources to undertake response to an incident. The Resource Supplier is an owner, or distributor, or manager of resources that can meet the needs of Resource Consumers. There may be more than one actor of each class for a given sequence of message exchanges, and there may also be other classes of actors besides these two primary types.

There are 16 resource messages defined in this specification, which are summarized in Table 2 below.

Table 2: Resource Message Type Summary

Message Type	Description	Message Sender
Request Resource	Message used to request needed resources from one or many recipients, possibly spawning multiple responses. [RequestResource]	Resource Consumer
Response to Request Resource	Message used as the response to a “Request Resource”. Allows sender to list resource(s) which they feel represent suitable match with a resource request. [ResponseToRequestResource]	Resource Supplier
Requisition Resource	Message used to “order” specific resource, or to confirm specific resource to be “ordered” relating to one or more responses to a “Request Resource”. RequisitionResource]	Resource Consumer
Commit Resource	Message used to agree or commit specific resource in response to a Resource Request or Requisition, or to a "Request Return”. [CommitResource]	Resource Supplier
Request Information (RFI)	Message used to ask resource questions or provide general description of situation and general resources needs. [RequestInformation]	Resource Consumer
Response to Request Information	Message used as the response to an RFI message providing general information or to list resource that may meet the specified need. [ResponseToRequestInformation]	Resource Supplier
Offer Unsolicited Resource	Message used to offer available resources (that have not been requested) to assist with an emergency response. [OfferUnsolicitedResource]	Resource Supplier
Release Resource	Message used at the incident to “release” (demobilize) resource back to its original Supplier. [ReleaseResource]	Resource Consumer
Request Return	Message used to request release (demobilize) of resources back to its original point of assignment or to another location / assignment ("I want my stuff back"). [RequestReturn]	Resource Supplier
Response to Request Return	Message used as the response to a "Request Return" indicating whether the resource may be released, with relevant time-line information. [ResponseToRequestReturn]	Resource Consumer
Request Quote	Message used to request a price quote from a seller or supplier. [RequestQuote]	Resource Consumer
Response to Request Quote	Message used as the response to a “Request Quote”. Allows sender to list resource(s) which they feel represent suitable match with the request, with pricing information. [ResponseToRequestQuote]	Resource Supplier
Request Resource Deployment Status	Message used to request current “status” of resource. [RequestResourceDeploymentStatus]	Both