The OASIS Energy Interoperation (EI) Version 1.0 technical specification defines EI services and operations, XML, service and operation payloads and service operation interaction patterns. EI payloads can be exchanged using WSDL-based SOAP messages or using other transport protocols. For interoperability, any use of other networking technologies should be profiled and standardized. This version of this specification specifies standardized exchange of EI messages using the AS4 profile of the OASIS ebMS 3.0 OASIS Standard.

Status:

This document was last revised or approved by the OASIS Energy Interoperation TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this Work Product to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee’s web page at http://www.oasis-open.org/committees/energyinterop/.

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

Citation format:

When referencing this Work Product the following citation format should be used:

[TPB-EI]

Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0. 01 October 2012. OASIS Committee Specification 01.
http://docs.oasis-open.org/energyinterop/tpb-ei/v1.0/cs01/tpb-ei-v1.0-cs01.html.

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 name "OASIS" is a trademark 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/policies-guidelines/trademark for above guidance.

Table of Contents

1 Introduction................................................................................................................................ 5

1.1 Terminology......................................................................................................................... 5

1.2 Normative References.......................................................................................................... 5

1.3 Non-Normative References................................................................................................... 5

2 ebMS 3.0 Transport Protocol Bindings......................................................................................... 7

2.1 Introduction......................................................................................................................... 7

2.1.1 ebMS 3.0 and AS4........................................................................................................ 7

2.1.2 Rationale of EI Transport Bindings for ebMS 3.0............................................................. 7

2.2 EI Transport Bindings for ebXML Messaging 3.0 .................................................................. 8

2.2.1 Relation of EI Transport to the AS4 Profile .................................................................... 8

2.2.1.1 EI Extensions to AS4 Profile ....................................................................................................................... 8

2.2.1.2 EI Restrictions on AS4 Profile .................................................................................................................... 8

2.2.2 Mapping of EI Service Model ........................................................................................ 8

2.2.2.1 Exchange Patterns........................................................................................................................................ 8

2.2.2.2 Push and Pull ................................................................................................................................................ 9

2.2.2.3 UserMessage Header.................................................................................................................................. 9

3 Conformance............................................................................................................................ 11

3.1 EI Conformance Profiles for ebMS 3 Transport Protocol Binding.......................................... 11

3.1.1 EI ebMS 3.0 ebHandler Conformance ......................................................................... 11

3.1.2 EI ebMS 3.0 Light Client Conformance ........................................................................ 11

3.1.3 EI ebMS 3.0 Minimal Client Conformance .................................................................... 11

Appendix A Acknowledgments....................................................................................................... 12

Appendix B Sample EI ebMS 3.0 Message..................................................................................... 14

Appendix B.1 EI Message with Uncompressed Payload.............................................................. 14

Appendix C Revision History.......................................................................................................... 16

1 Introduction

The OASIS Energy Interoperation (EI) Version 1.0 technical specification [EnergyInterop] defines EI Services and Operations, XML, Service and Operation payloads and Service operation interaction patterns. Energy Interoperation payloads can be exchanged using WSDL-based SOAP messages. For interoperability, any use of networking technologies should be profiled and standardized. This specification specifies and intends to increase interoperability of non-WSDL transport bindings for EI.

This version of this specification contains transport protocol bindings for Energy Interoperation messages based on the AS4 profile [AS4-Profile] of the ebMS 3.0 OASIS Standard [ebMS3CORE], defined in chapter 2 of this document. Future versions of this specification MAY define Energy Interoperation profiles for message transport protocols other than ebMS as separate chapters and related conformance clauses.

1.1 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 [RFC2119].

1.2 Normative References

[AS4-Profile] AS4 Profile of ebMS 3.0 Version 1.0. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.odt

[ebMS3CORE] OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features, 1 October 2007, OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pd f

[EnergyInterop] Energy Interoperation Version 1.0. Latest version.
http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html

[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.

[SOAP12] SOAP Version 1.2 Part 1: Messaging Framework. W3C Recommendation. 27 April 2007. http://www.w3.org/TR/soap12-part1/

[SOAPATTACH] SOAP Messages with Attachments, W3C Note. 11 December 2000. http://www.w3.org/TR/SOAP-attachments

[WSS11] Web Services Security: SOAP Message Security 1.1. OASIS Standard incorporating Approved Errata. 1 November 2006, http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf

1.3 Non-Normative References

[ebBP] ebXML Business Process Specification Schema Technical Specification v2.0.4. OASIS Standard, December 2006.
http://docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.pdf

[ebCorePartyId] OASIS ebCore Party Id Type Technical Specification Version 1.0.
OASIS Committee Specification, 28 September 2010. http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.odt

[GLN] GS1 Global Location Number (GLN).
http://www.gs1.org/barcodes/technical/idkeys/gln

[GS1-AS4] AS4: Web Services for B2B. GS1 eTG White Paper. Issue 1, Approved, July 2011.
http://www.gs1.org/docs/ecom/AS4_-_A_new_tools_for_the_B2B_toolbox.pdf

[RFC4130] MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2). IETF RFC, July 2005. http://tools.ietf.org/rfc/rfc4130.txt

2 ebMS 3.0 Transport Protocol Bindings

2.1 Introduction

The OASIS Energy Interoperation (EI) Version 1.0 technical specification [EnergyInterop] defines EI services and operations, XML, service and operation payloads and service operation interaction patterns. EI payloads can be exchanged using WSDL-based SOAP messages, but can be exchanged using other message transport protocols. This chapter defines transport protocol bindings for ebXML Messaging Version 3.0, a Web Services standard for B2B [ebMS3CORE].

2.1.1 ebMS 3.0 and AS4

Web Services technology is horizontal technology and is intended to support a broad range of applications. The OASIS ebXML Messaging Services Version 3.0: Part 1, Core Specification OASIS Standard [ebMS3CORE] is a more specialized protocol that uses Web Services for B2B document exchange. It composes many Web Services standards into a single comprehensive specification for the secure and reliable exchange of documents using Web Services. It also defines additional features not present in Web Services standards that are relevant for B2B exchanges.

The AS4 profile [AS4-Profile] was designed to be a light-weight profile of ebMS 3.0 that simplifies and increases interoperability of ebMS 3.0 by reducing the numerous options and comprehensive alternatives offered in the ebMS 3.0 Core Specification. It is not just a conformance profile for ebMS 3.0 but defines additional features not present in ebMS 3.0 or other Web Services standards to address EDIINT requirements. These requirements are addressed in message transport protocols such as AS2 [RFC4130], which are widely used in the energy industry. AS4 is discussed in the context of EDIINT and compared to AS2 in [GS1-AS4].

2.1.2 Rationale of EI Transport Bindings for ebMS 3.0

For Energy Interoperation, transport bindings to ebMS 3.0 and AS4 have the following benefits:

· Energy Interoperation is about B2B data exchange. The ebMS 3.0 OASIS Standard and AS4 profile standardize B2B data exchange for Web Services, leveraging Web Services standards like SOAP 1.2 [SOAP12], SOAP with attachments [SOAPATTACH] and Web Services Security 1.1 [WSS11] to support B2B exchange.

· Message headers are declared out of scope for EI ([EnergyInterop], section 6.5) but are useful to support operational exchange of EI payloads. Standardized support for message header elements is provided by ebMS 3.0 for common headers that provide identification of message sender and recipient parties, expressing party roles in the exchange, express the purpose of the message (as an action invoked on a service), identify the message and related messages, express the applicable business agreement, any message properties and associate message payloads. The ebMS 3.0 eb3:Messaging SOAP header extension is an evolution of a similar structure in the ebMS 2.0 standard, which has been used for B2B data exchange in various sectors, including energy trade.

· Support is provided for EDIINT requirements (as supported in AS2, [RFC4130]) including functionality not commonly supported in Web Services such as Non-Repudiation of Receipt (NRR).

· Support is provided for functionality not available in either Web Services or AS2, in particular “client only” endpoints that only need occasional network connectivity.

· Support for “light-weight” reliable messaging.

· Payload compression allows EI ebMS 3.0 messages to be small in size and therefore is more suited to low-bandwidth networks.

2.2 EI Transport Bindings for ebXML Messaging 3.0

The specification of the EI Transport Bindings for ebXML Messaging 3.0 covers the following aspects:

· A mapping of the EI Service Model to ebMS 3.0 processing modes. These processing modes constrain the content of the eb3:Messaging/eb3:UserMessage structure in EI ebMS 3.0 SOAP message headers.

· A specification of this binding as a variant of the AS4 profile [AS4-Profile].

· Definition of two conformance profiles, representative for two anticipated application scenarios.

2.2.1 Relation of EI Transport to the AS4 Profile

This transport binding is aligned as closely as possible to the AS4 profile [AS4-Profile], as this profile defines a subset that implementations of ebMS 3.0 are most likely to implement. This allows this EI transport binding to be defined succinctly as a reference to AS4 and a listing of extensions and restrictions to AS4.

2.2.1.1 EI Extensions to AS4 Profile

The AS4 profile is a profile for EDI document exchange. AS4 requires support for the One Way Message Exchange Pattern (MEP), in both push and pull MEP bindings. It allows implementation to also support Two Way message exchanges.

Energy Operation is based on service-orientation concepts and includes request/response interactions. The ebMS 3.0 Two Way MEP is well suited to service-oriented exchanges. Support for the Two Way MEP is REQUIRED in this EI ebMS 3.0 transport binding, using the following MEP Bindings:

· Push-and-Push.

· Push-and-Pull.

· Pull-and-Push.

· Push-and-Pull.

Support for Two Way MEPs implies that response messages based on these EI Transport Bindings include the eb3:RefToMessageId element, the value of which identifies the preceding message to which the message is a response.

Note that all four MEP Bindings are asynchronous bindings: the business request and response messages are exchanged using separate HTTP connections.

2.2.1.2 EI Restrictions on AS4 Profile

The AS4 profile allows arbitrary values for many SOAP header extension elements. This profile limits the values of several of these elements as specified in section 2.2.2 .

2.2.2 Mapping of EI Service Model

The Energy Interoperation specification [EnergyInterop] defines a number of energy interoperation services and associated payload schemes. To exchange messages containing payloads conforming to these payload schemes, this specification constrains aspects of the processing modes.

2.2.2.1 Exchange Patterns

Both EI and ebMS 3.0 have a concept of message exchange patterns and distinguish between message that are logically exchanged as message pairs or as individual messages. The following table maps EI patterns to ebMS 3.0 MEPs.

EbMS 3.0 MEP	EI Patterns
One Way Message Exchange Pattern	Distribute
Two Way Message Exchange Pattern	Create – Created Cancel – Canceled Request – Reply

EbMS 3.0 MEP

EI Patterns

One Way Message Exchange Pattern

Distribute

Two Way Message Exchange Pattern

Create – Created

Cancel – Canceled

Request – Reply

2.2.2.2 Push and Pull

Both EI and ebMS 3.0 distinguish between “push” and “pull”. However, whereas the EI concept is a business level concept, the ebMS 3.0 concept of pulling is at the message level and provides a binding to a message exchange pattern. Subject to processing mode configuration, pull mode allows a message to be sent, not by initiating an HTTP connection to the receiver MSH, but using the HTTP back-channel of a connection initiated in response to a secure eb3:PullRequest signal message. The ebMS 3.0 distinction of push and pull MEP bindings is orthogonal to the EI concept of push and pull exchanges.

2.2.2.3 UserMessage Header

The ebMS 3.0 eb3:Messaging SOAP header extension contains metadata that allows an MSH to route ebMS 3.0 messages using only information contained in the SOAP header. This EI transport binding defines the following REQUIRED mapping of the model of EI service metadata defined in chapter 6 of [EnergyInterop] to the values of some of these headers.

EI	EbMS 3.0
Service	/eb3:Messaging/eb3:UserMessage/eb3:CollaborationInfo/eb3:Service
Operation	/eb3:Messaging/eb3:UserMessage/eb3:CollaborationInfo/eb3:Action
Response	/eb3:Messaging/eb3:UserMessage/eb3:CollaborationInfo/eb3:Action
Service Consumer Role (Request Message)	/eb3:Messaging/eb3:UserMessage/eb3:PartyInfo/eb3:From/eb3:Role
Service Consumer Role (Response Message)	/eb3:Messaging/eb3:UserMessage/eb3:PartyInfo/eb3:To/eb3:Role
Service Provider Role (Request Message)	/eb3:Messaging/eb3:UserMessage/eb3:PartyInfo/eb3:To/eb3:Role
Service Provider Role (Response Message)	/eb3:Messaging/eb3:UserMessage/eb3:PartyInfo/eb3:From/eb3:Role

The eb3:Messaging structure is present in both initiating and responding messages. In the initiating message, the eb3:Action MUST be the value of the EI Operation in the initiating message and in the responding message it MUST be set to the value of the EI Response.

For the value of Service Consumer Role and Service Provider roles, the values defined in [EnergyInterop] MUST be used.

· If the qualified roles defined in the service interaction diagrams are more specific than the values in the service definition tables, the more specific values from the diagrams MUST be used. All values MUST be normalized to UpperCamelCase. For example, the value to use for the Service Provider Role in the EiRegisterParty service is RegistrarParty.

· In the EiDelivery service, the Service Provider Role MUST be identified as CounterParty. This ensures roles are party roles are distinct in any exchange.

Note that the mapping of the values of Service Consumer Role and Service Provider Role to the eb3:From and eb3:To message header elements is reversed for the response leg of a Two Way message exchange.

In ebMS 3.0 these extension header element values are configured by message processing modes, which provide configuration information to the MSH. This transport binding therefore also constrains the allowed values of processing mode parameters.

3 Conformance

This version of this specification provides conformance profiles for the EI ebMS 3.0 transport binding defined in chapter 2 .

3.1 EI Conformance Profiles for ebMS 3 Transport Protocol Binding

An implementation is not conformant with the EI ebMS 3.0 Transport Protocol Binding if it fails to satisfy one or more of the MUST or REQUIRED level requirements defined in chapter 2 .

An implementation of the EI ebMS 3.0 Transport Protocol Binding MUST conform to “General Conformance Requirements” (section 15.1.1 in [EnergyInterop]) and to one of the following:

· Full Conformance with Alternate Interoperation to Energy Interoperation (15.1.4).

· Conformance with Alternate Interoperation to Energy Interoperation (15.1.5).

· Full Conformance or Conformance with Alternate Interoperation to a Named Profile (15.1.6.3).

In addition to this, it MUST conform to either

· EI ebMS 3.0 ebHandler Conformance (defined in section 3.1.1 below)

· EI ebMS 3.0 Light Client Conformance (defined in section 3.1.2 below)

· EI ebMS 3.0 Minimal Client Conformance (defined in section 3.1.3 below).

3.1.1 EI ebMS 3.0 ebHandler Conformance

An implementation conforms with the EI ebMS 3.0 Transport Protocol Binding ebHandler Conformance Clause if it conforms to the AS4 ebHandler Conformance Clause defined in section 6.1 of [AS4-Profile], extended as per 2.2.1.1 and restricted as per 2.2.1.2 .

3.1.2 EI ebMS 3.0 Light Client Conformance

An implementation conforms with the EI ebMS 3.0 Transport Protocol Binding Light Client Conformance Clause if it conforms to the AS4 Light Client Conformance Clause defined in section 6.2 of [AS4-Profile], extended as per 2.2.1.1 and restricted as per 2.2.1.2 .

3.1.3 EI ebMS 3.0 Minimal Client Conformance

An implementation conforms with the EI ebMS 3.0 Transport Protocol Binding Minimal Client Conformance Clause if it conforms to the AS4 Minimal Client Conformance Clause defined in section 6.3 of [AS4-Profile], extended as per 2.2.1.1 and restricted as per 2.2.1.2 .

Appendix A Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

· Aanesen, Mr. Hans, Individual

· Bartell, Bruce, Southern California Edison

· Bennett, Timothy, Drummond Group Inc.

· Besaw, Mr. Carl, Southern California Edison

· Bienert, Rolf, OpenADR Alliance, Inc.

· Cazalet, Edward, Individual

· Considine, Toby, University of North Carolina at Chapel Hill

· Cox, William, Individual

· Davis, Mr. Phil, Schneider Electric Industries SAS

· Dinges, Ms. Sharon, Trane

· Drummond, Rik, Drummond Group Inc.

· Eder, Ernst, LonMark International

· Eijk, Mr. Pim van der, Sonnenglanz Consulting

· Ferrentino, Thomas, Individual

· Gemmill, Craig, Tridium, Inc.

· Ghatikar, Girish, Lawrence Berkeley National Laboratory

· Gray, Dr. Gerald, Electric Power Research Institute (EPRI)

· Hardin, Dave,EnerNOC

· Hendry, Anne, Individual

· Holmberg, David, NIST

· Horst, Mr. Gale, Electric Power Research Institute (EPRI)

· Johnson, Mr. John, Calm Energy, Inc.

· Kiliccote, Ms. Sila, Lawrence Berkeley National Laboratory

· Koch, Ed, Akuacom Inc.

· Lackey, Larry, TIBCO Software Inc.

· Lepeuple, Mr. Benoit, LonMark International

· McParland, Mr. Chuck, Lawrence Berkeley National Laboratory

· Old, Mr. Robert, Siemens AG

· Phillips, Joshua, ISO/RTO Council (IRC)

· Piette, Ms. Mary Ann, Lawrence Berkeley National Laboratory

· Pratt, Donna, ISO/RTO Council (IRC)

· Rajasekhar, Mr. Ruchi, Midwest Independent Transmission System Operator, Inc.

· Roberts, Jeremy, LonMark International

· Snowdon, Dr. Jane, IBM

· Songkakul, Dr. Pornsak, Siemens AG

· Thomas, Chuck, Electric Power Research Institute (EPRI)

· Thompson, Mr. Jake, EnerNOC

· Wakefield, Matt, Electric Power Research Institute (EPRI)

· Wallace, Mr. Evan, NIST

· Watson, Dave, Lawrence Berkeley National Laboratory

· Zink, Brian, New York Independent System Operator

Appendix B Sample EI ebMS 3.0 Message

Appendix B.1 EI Message with Uncompressed Payload

The following non-normative example contains a simplified example of the SOAP 1.2 envelope of an ebMS 3.0 message that conforms to the EI ebMS 3.0 transport protocol binding.

This example identifies Sender and Receiver using GS1 Global Location Numbers [GLN] encoded using the OASIS ebCore Party Id Type [ebCorePartyId] notation.

<S12:Envelope xmlns:S12="http://www.w3.org/2003/05/soap-envelope"

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

xmlns:eb3="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >

<S12:Header>

<wsse:Security S12:mustUnderStand="true">

</wsse:Security>

<eb3:Messaging S12:mustUnderstand="true"

id="_5cb44655-5720-4cf4-a772-19cd480b0ad4" >

<eb3:UserMessage >

<eb3:MessageInfo>

<eb3:Timestamp>2011-11-12T10:49:28.886Z</eb3:Timestamp>

<eb3:MessageId>872129933@gln123456789.example.com</eb3:MessageId>

</eb3:MessageInfo>

<eb3:PartyInfo>

<eb3:From>

<eb3:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>123456789</eb3:PartyId>

<eb3:Role>Party</eb3:Role>

</eb3:From>

<eb3:To>

<eb3:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>192837465</eb3:PartyId>

<eb3:Role>CounterParty</eb3:Role>

</eb3:To>

</eb3:PartyInfo>

<eb3:CollaborationInfo>

<eb3:Service>EiQuote</eb3:Service>

<eb3:Action>EiCreateQuote</eb3:Action>

<eb3:ConversationId>ecae53d4-7473-45a6-ad70-61970dd7c4b0</eb3:ConversationId>

</eb3:CollaborationInfo>

<eb3:PayloadInfo>

<eb3:PartInfo href="#_f8aa8b55-b31c-4364-94d0-3615ca65aa40" />

</eb3:PayloadInfo>

</eb3:UserMessage>

</eb3:Messaging>

</S12:Header>

<S12:Body wsu:Id="_f8aa8b55-b31c-4364-94d0-3615ca65aa40">

<eipyld:eiCreateQuote

xmlns:eipyld="http://docs.oasis-open.org/ns/energyinterop/201110/payloads"

xmlns:ei="http://docs.oasis-open.org/ns/energyinterop/201110"

xmlns:emix="http://docs.oasis-open.org/ns/emix/2011/06"

xmlns:ical="urn:ietf:params:xml:ns:icalendar-2.0"

<ei:publisherPartyID>...</ei:publisherPartyID>

<ei:subscriberPartyID></ei:subscriberPartyID>

<ei:eiQuote>

<ei:quoteID></ei:quoteID>

</ei:eiQuote>

</eipyld:eiCreateQuote>

</S12:Body>

</S12:Envelope>

Appendix C Revision History

Revision	Date	Editor	Changes Made
WD 01	11/07/11	Pim van der Eijk	First draft for discussion
WD 02	04/02/12	Pim van der Eijk	Minor updates for newer versions of energy interop specification and of AS4 profile
WD 03	04/11/12	Pim van der Eijk	Removed placeholder appendix A Fixed a few typos
WD 04	04/27/12	Pim van der Eijk	Now using AS2 instead of the underlying IETF EDIINT requirements document. Added an Acknowledgments section. Changed AS4 reference to the (authoritative) ODT format.