Internet Draft Commerce One draft-ietf-trade-xmlmsg-requirements-00.txt January 2000 Expires: July 2000 David Burdett Requirements for XML Messaging Version 1.0 Release 00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the TRADE working group at <ietf-trade@lists.elistx.com >, which may be joined by sending a message with subject "subscribe" to <ietf- trade-request@lists.elistx.com>. Discussions of the TRADE working group are archived at http://www.elistx.com/archives/ietf-trade. Abstract This specification contains requirements for a generic approach to the reliable, resilient, secure, tamper resistant, authenticated exchange of XML or other electronic documents over insecure transport mechanisms. The specification provides the requirements and framework for a set of related specifications on XML Messaging covering: o Requirements for XML Messaging (this paper) o Common XML Message Elements o Document Exchange and Transactions o Reliable Messaging o Secure Messaging o Document Choreography Definitions o Common Document Exchanges o Transport Protocol Supplements Although much work has been carried out on the other parts of the XML Messaging specification described above, they are sill in development David Burdett [Page 1]
Internet Draft XMLMSG/1.0 January 2000 Table of Contents Status of this Memo ................................................1 Abstract ...........................................................1 1. Background .....................................................5 1.1 Structure ...................................................6 1.2 History .....................................................7 1.3 Objectives of Document ......................................7 1.4 Principles and Assumptions ..................................7 1.5 Document Structure ..........................................7 1.6 Terminology .................................................8 2. XML Messaging Definitions and Terminology ......................9 2.1 Documents, Parties, Messages and Document Exchanges .........9 2.1.1 Overview ..............................................9 2.1.2 A Document ...........................................10 2.1.3 Party ................................................10 2.1.4 From, To and Authorizing Parties .....................10 2.1.5 Message ..............................................12 2.1.6 Message Header .......................................12 2.1.7 Message Routing Information ..........................13 2.1.8 Digital Signature ....................................14 2.1.9 Message Envelope .....................................15 2.1.10 Request Message ......................................15 2.1.11 Response Message .....................................15 2.1.12 One Way Message ......................................16 2.1.13 Document Exchange ....................................16 2.1.14 Simple Document Exchange .............................16 2.1.15 Multiple Round Trip Document Exchange ................17 2.1.16 Exchange Message .....................................17 2.1.17 Acknowledgement Message ..............................18 2.1.18 Error Message ........................................18 2.2 Services, Service Types and Transactions ...................19 2.2.1 Overview .............................................19 2.2.2 Service and Service Type .............................19 2.2.3 Sub-Service ..........................................20 2.2.4 Document Choreography ................................21 2.2.5 Transaction ..........................................21 2.3 Lower Level Data Definitions ...............................22 2.3.1 Overview .............................................22 2.3.2 Transaction Identity Data ............................22 2.3.3 Message Identity Data ................................22 2.3.4 Message Manifest .....................................23 2.3.5 Related Transaction Data .............................23 2.3.6 Organization Data ....................................24 2.3.7 Action Data ..........................................24 2.3.8 Status Data ..........................................25 2.3.9 Error Data ...........................................25 2.3.10 Cancel Data ..........................................25 2.4 Miscellaneous Definitions ..................................26 2.4.1 Document Encoding ....................................26 David Burdett [Page 2]
Internet Draft XMLMSG/1.0 January 2000 2.4.2 Audit Trail ..........................................26 2.4.3 Transport Mechanism ..................................27 2.4.4 Identical Elements ...................................27 3. Standard Transactions .........................................28 3.1 Service Availability Inquiry ...............................28 3.2 Transaction Status Inquiry .................................29 3.3 User/Server Authentication .................................29 3.4 Quality of Service Negotiation .............................30 4. Restart, Recovery and Idempotency .............................31 4.1 Idempotency ................................................31 4.2 Recovering from failed Message delivery ....................31 5. Security Considerations .......................................34 5.1 Digital Signatures .........................................34 5.1.1 Determining whether to use digital signatures ........34 5.1.2 Reasons for using Digital Signatures .................35 5.1.3 Reasons to not use Signatures ........................36 5.2 Message Authenticity .......................................36 5.3 Data Privacy ...............................................37 6. XML Messaging Compliance Levels ...............................38 6.1 Data Element Compliance ....................................38 6.2 Message Level Compliance ...................................38 6.3 Document Exchange and Transaction Level Compliance .........38 6.4 Reliable Messaging Compliance ..............................39 6.5 Secure Messaging Compliance ................................39 6.6 Document Choreography Compliance ...........................39 6.7 Transport Protocol Supplement Compliance ...................40 6.8 Common Document Exchange and Transaction Compliance ........40 7. XML Messaging Examples ........................................41 7.1 XML Message Structure ......................................41 7.2 XML Messaging Examples .....................................43 7.2.1 Simple Document Exchange .............................43 7.2.2 Simple Document Exchange with Errors .................45 7.2.3 Canceling a Transaction ..............................47 7.2.4 Transaction with Multiple Document Exchanges .........48 7.2.5 Relating Two Transactions ............................53 8. References ....................................................57 9. Author's Address ..............................................60 David Burdett [Page 3]
Internet Draft XMLMSG/1.0 January 2000 Table of Figures Figure 1 XML Messaging, Message Structure 42 Figure 2 Simple Document Exchange Message Flow 44 Figure 3 Document Exchange with Request Message Errors 46 Figure 4 Document Exchange with Response Message Errors 47 Figure 5 Multiple Document Exchange Transaction 53 David Burdett [Page 4]
Internet Draft XMLMSG/1.0 January 2000 1. Background Many Internet protocols consist of an exchange of documents over the Internet, for example sending a Purchase Order and receiving a Purchase Order Acknowledgement in return. Many of these protocols use or plan to use XML to represent those documents. However irrespective of the way in which documents are represented, there are common requirements that are independent of the purpose of the protocols, the information they are carrying or the processes that create or accept those documents. The XML Messaging specification provides a generic approach to the reliable, resilient, secure, tamper resistant, authenticated exchange of XML or other electronic documents over insecure, unreliable transport mechanisms. More specifically it provides, a series related specifications that cover: o wrapping a document o identifying a document o describing the processing of a document o reporting errors in a document o digitally signing documents to provide tamper resistance and security o exchanging a series of documents to carry out a process or service o authenticating a document so that the intended recipient knows: - who sent and/or authorized the document, and therefore that - the document should be processed and a response returned o providing a record of the success or failure of a process/service o securely relating a series of sub-services together to create a larger, more complex service where the start of one sub-service is dependent on the authorized, successful completion of another o providing an audit-trail of the execution of a set of services that can be used after the event as evidence that those services were carried out o inquiring on the success or failure of a service initiated by sending a document o determining if a failed service can be restarted and then restarting it where possible David Burdett [Page 5]
Internet Draft XMLMSG/1.0 January 2000 o detecting whether or not a system or server is up-and-running and able to accept documents o authenticating a user or server that is providing a service. 1.1 Structure This specification is one of a set of related specifications on XML Messaging covering: o Requirements for XML Messaging (this paper) o Common XML Message Elements [XMLMSG-CME]. This defines the XML elements and attributes used to construct Messages that conform to XML Messaging o Document Exchanges and Transactions [XMLMSG-DET]. This defines standard templates for exchanging documents between parties that can be used to implement transactions that support different types of services and processes. o Reliable Messaging [XMLMSG-RM]. This defines how to exchange messages in a way that is reliable, robust and resilient and results in "guaranteed once-only" message delivery o Secure Messaging [XMLMSG-SM]. This describes how digital signatures and other methods such as [SSL] may be used to ensure the tamper resistance and authenticated exchange of messages o Document Choreography Definitions [XMLMSG-DCD]. This describes how the sequence in which documents are exchanged may be defined, agreed between the parties involved and then used dynamically to determine the way in which a particular type of business service or process is carried out o Common Document Exchanges [XMLMSG-CDE]. This defines a number of Common Document Exchanges that are generally applicable to many situations o Transport Protocol Supplements. These are a set of specifications that describe how Messages that conform to XML Messaging specifications are transported over a various transport protocols such as [HTTP], [SMTP], etc. A compliant XML Messaging specification does not need to implement all the specifications highlighted above. An explanation of the how these relate is contained in section 6 XML Messaging Compliance Levels. Currently only this document is fully defined and published. David Burdett [Page 6]
Internet Draft XMLMSG/1.0 January 2000 1.2 History The ideas in this specification are largely based on the ideas contained within the Internet Open Trading Protocol [IOTP]. IOTP development started in early 1998 and is available as an Informational RFC (currently in RFC Editor Queue) from the IETF. Several implementations of IOTP have been developed. 1.3 Objectives of Document The objectives of this document are to: o define the terminology used by XML Messaging, and o provide the reader with an overall understanding of XML Messaging so that they can better understand the relationships between this and the other XML Messaging Specifications identified above o highlight the requirements that other XML Messaging specifications must cover. It is recommended that this specification is read first. 1.4 Principles and Assumptions The following principles and assumptions have been applied in developing this specification: o [XML] will be used to define any data required to support XML Messaging o XML Messaging shall support the exchanging of documents in any digital format o the data used by XML Messaging will be defined using: - the W3C XML Schema language [XDSL], and - an [XML] Data Type Definition (DTD) o Schema and DTD definitions will be placed in a repository such as those being developed by [XML.org]. 1.5 Document Structure This document contains the following sections: o XML Messaging Definitions and Terminology. This defines the terminology used by XML Messaging David Burdett [Page 7]
Internet Draft XMLMSG/1.0 January 2000 o Standard Transactions. This describes four standard Transactions that are built using XML messaging that are generally applicable: - Service Availability Inquiry - Transaction Status Inquiry - Quality of Service Negotiation - User/Server Authentication o Restart, Recovery and Idempotency. This describes how XML Messaging can be used to ensure the completion of a transaction and provide guaranteed once-only delivery o Security Considerations. This describes some of the considerations around whether or not digital signatures should be used with XML Messaging o XML Messaging Compliance Levels. Compliance with XML Messaging levels. This describes how the different parts of the XML Messaging specification may be used in combination to meet different needs. o XML Messaging Examples. This illustrates the structure of a "Message" and illustrates its use with five example message flows o References. This lists the other documents and standards used by XML Messaging [Note] In several part of the specification "notes" such as this are placed to provide additional background, advice or guidance as an aid to understanding. They are non-normative parts of this specification. [Note End] 1.6 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. David Burdett [Page 8]
Internet Draft XMLMSG/1.0 January 2000 2. XML Messaging Definitions and Terminology This section defines the main terminology used by XML Messaging. It is divided into four parts: o Documents, Parties, Messages and Document Exchanges o Services and Transactions, o Lower Level Data Definitions that are used by the above, and o Miscellaneous Definitions that don't fall into any of the above categories. [Note] Definitions of words or phrases in this section that start with a capital letter (for example Document Exchange) cab usually be found defined elsewhere within this section. [Note End] 2.1 Documents, Parties, Messages and Document Exchanges 2.1.1 Overview This section describes how Parties, such as buyers and suppliers, customers and merchants, can exchange Documents contained in Messages in order to execute Services. All the Documents and other data in a Message are contained within an outermost Message Envelope. A Message can optionally include a Digital Signature so that: o the identity of the party sending the message can be authenticated o any changes to the message can be detected. Services are requested by sending one or more Documents in a Request Message to a Party who then: o processes the Request Message by carrying out a Service and o generates a Response Message to indicate the result. At a minimum a Document Exchange consists of a Request Message and a Response Message although there might be additional Exchange Messages between the Request and the Response Message. Documents may also be sent as in a One Way message. In this case no business or application level response is provided. David Burdett [Page 9]
Internet Draft XMLMSG/1.0 January 2000 The receipt of a Message may be acknowledged by sending a Message Acknowledgement back to the sender of the Message. Error Messages are used to report permanent or transient problems or errors in a Message. More detail is provided below. 2.1.2 A Document A Document is any data that can be represented in a digital form. Examples of Documents include: o a set of XML Elements o an XML Document o an HTML Document o a word processing file o a Adobe Acrobat PDF file o a binary file. 2.1.3 Party A Party is a company, organization, individual or other entity that can generate, receive or authorize Documents and their associated Messages. Examples of a Party include: o a Merchant o a Customer o a Lawyer o a Bank A Party is also used to refer to systems or servers that are carrying out Services or other processes on behalf of a Party. 2.1.4 From, To and Authorizing Parties FROM AND TO PARTIES A Party that sends a Message is the "From" Party. A Party that is the intended recipient of a Message is the "To" Party. Every Message MUST David Burdett [Page 10]
Internet Draft XMLMSG/1.0 January 2000 identify the "From" and the "To" Parties although Parties MAY identify themselves as anonymous. Examples of a "From" Party include: o a buyer that sends a Purchase Order to a supplier o a supplier that sends an Invoice to a buyer. Examples of a "To" Party include: o the customer that receives a bank statement from their bank o the travel agent that receives a booking for a flight ANONYMOUS PARTIES Anonymous parties MAY be used where the identity of the sender of a message is not required for the service associated with the message to be carried out. Examples of anonymous parties include: o an individual that is querying availability of seats on a flight o a company that is searching for the list prices of a product from a number of suppliers. AUTHORIZING PARTIES Messages MAY also contain one or more Authorizing Parties. The Authorizing Parties are Parties that authorize the "To" Party to act upon the Message that is received. The Authorizing Party will frequently be the "From" party but this MAY NOT always be the case. If no Authorizing Parties are present in a Message then the "From" party is the Authorizing Party. Examples of document exchanges where more than the "From" party are required to authorize an action include: o a payment request a consumer makes to a bank to get a refund on a credit card payment. The authorizing parties are: - the consumer that is requesting the refund, and - the merchant that is instructing the bank to make the refund o a transport firm that is being requested by a company to deliver goods that have been ordered from a supplier and payment made to a bank. The authorizing parties are: - the company that is requesting the delivery - the bank that authorizes that payment had been made - the supplier that specifies what goods should be delivered [Note] In the above examples, the consumer/company is sending a message to one party to ask them to carry out a service on behalf of another party where the information that is being David Burdett [Page 11]
Internet Draft XMLMSG/1.0 January 2000 sent is being passed through the consumer/company. Frequently Digital Signatures may be used to protect the information. See section 7.2.4, Transaction with Multiple Document Exchanges for an example of this can be used. [Note End] 2.1.5 Message A Message is data that is sent from one Party to another. A Message MUST consist of: o a Message Header o Message Routing Information o zero or more Digital Signatures, and o zero or more Documents All the data in a Message is contained within a Message Envelope. Examples of a Message include: o a Purchase Order that is sent by a buyer to a supplier o an Invoice that is sent by the supplier back to the buyer o a request to make a payment of $50 sent to a Credit Card acquirer o the authorization received from a Credit Card acquirer as a result of making a payment o Status Data indicating the success or failure of a Service o a multiple document message, e.g. - a design specification for a product including the Microsoft Word document and several JPEG files that illustrate the product's appearance - a batch of Purchase Orders that are being sent at the same time to the same destination [Note] A Message need not contain any documents since the Message Header can contain all the data necessary to indicate the purpose of the Message. [Note End] 2.1.6 Message Header A Message Header contains the additional data that needs to be associated with a Document so that it can be sent to and successfully processed by a Party. The Message Header MUST contain: David Burdett [Page 12]
Internet Draft XMLMSG/1.0 January 2000 o Transaction Identity data to identify the set of Messages that are related to one another through one or more Document Exchanges o Message Identity data to enable the Message to be identified and referenced within the Transaction o Organization Data that describes: - who the Message is From - who the Message is sent To o Action Data to indicate the type of Service that is being sent the message and the intention behind sending it Depending on the purpose of the message, a Message Header MAY also contain: o Status Data that describes the results of carrying out a Service. o a Message Manifest to identify the documents, other than the Message Header and Message Routing Information, that are contained within the same Message Envelope o Related Transaction Data that identifies other Transactions to which this Transaction is related 2.1.7 Message Routing Information The Action Data and Organization Data together identify, logically, the Sender and Recipient of the Message, the type of Service that should process it and the intention behind sending the message. This information is used to determine the [URL] to which the Message should be physically sent. The rules used to determine the URL that is used for this purpose SHALL NOT form part of this specification. The resultant URL MUST then be placed inside the Message Routing Information prior to sending the message to the URL that was determined. The URL to which the Message is sent may not be the final destination of the Message and may be some "hub" process that forwards the Message to yet another location. Each "hop" along the chain of destinations results in another entry in the Message Routing Information. The Message Routing Information may be digitally signed so that the intent of sending the message at the time and in the manner indicated can be authenticated. [Note] Message Routing Information is held separately from other Documents in the Message, such as the Message Header, since: David Burdett [Page 13]
Internet Draft XMLMSG/1.0 January 2000 o it would break any digital signature on those documents as Message Routing Information is extended each time the Message is forwarded to a new URL o it makes it easier to separate the processing logic that determines the logical destination (e.g. the business application) from the physical destination. As a result business applications need not be aware of changes to network designs that result in changes to URLs that to which Messages are sent, o if a particular URL is not accepting Messages for some reason, then an alternative URL may be used without invalidating any signatures (see section 4. Restart, Recovery and Idempotency) The Message Routing Information may also be extended when a Message is routed beyond its apparent ultimate destination by processes that are not made publicly available. [Note End] 2.1.8 Digital Signature A Digital Signature is a cryptographic signature over data contained in a Message, or elsewhere that are addressable via [URI]s, that may permit: - the identity of the sender of the message to be authenticated, and - enables changes in the signed data to be detected The XML Messaging specifications SHALL NOT specify any of the trust relationships or certificate authority issues associated with Digital Signatures. This is the responsibility of the designers of systems that use XML Messaging. Use of Digital Signatures by XML Messaging is OPTIONAL. Digital Signatures within XML Messaging are implemented using the IETF/W3C Digital Signature standard [XMLDSIG]. Examples of the use of Digital Signatures include: o demonstrating that a Request Message to initiate a Service is authorized o proving the authenticity and validity of an assertion contained in a document. For example, "these goods are guaranteed against defect for one year" [Note] Signatures are optional since: o some Messages may not need any security o some Documents might contain their own Signatures that make the need for Signatures at the Message level unnecessary Signatures are not contained in the Message Header since: David Burdett [Page 14]
Internet Draft XMLMSG/1.0 January 2000 o implementations of XML Messaging may require that Signatures sign the Message Header o it makes it easier for Documents to make use of message- level signatures without understanding the structure of a Message Header [Note End] 2.1.9 Message Envelope A Message Envelope is the outermost container for a Message. It MUST be either: o an XML Document with pre-defined XML tags, or o a multi-part MIME message 2.1.10 Request Message A Request Message is a Message sent from one Party to a second Party with the intent that the second Party act upon the data in the Request Message by carrying out a Service. A Request Message MAY also contain: o Status Data that describes the end process state of earlier Document Exchanges on which start of the Service being requested may depend Examples of a Request Messages include: o requesting the processing of a new purchase order o requesting that a previous purchase order is changed o requesting a refund of a payment as a result of a problem o requesting the review of a legal document o requesting information on the services a business provides. 2.1.11 Response Message A Response Message is a Message that is generated by the Party that received a Request Message. It is produced as a result of carrying out the requested Service. It is the last Message in a Document Exchange unless the Message contains errors. Response Messages are sent back to the sender of the Request Message. A Response Message MUST contain: David Burdett [Page 15]
Internet Draft XMLMSG/1.0 January 2000 o a Reference to the immediately preceding Message (e.g. a Request Message) that the Response Message is responding to, and o Status Data that describes the end process state of the Document Exchange. Examples of Response Messages include: o an acknowledgement of receipt of a Purchase Order o an Invoice generated as a result of processing a Purchase Order o a receipt for a payment that was made o an opinion on a legal document that was received o a description of the services provided by a business [Note] There is a distinction between a Response Message and an Error Message (see section 2.1.18) below. [Note End] 2.1.12 One Way Message A One Way Message is a Message sent from one Party to another where a business level or application response to the message is not required. Example uses of One Way Messages include: o a newsletter that contains updated information about a company or group o a Request for Quotation (RFQ) for the provision of a service or product 2.1.13 Document Exchange A Document Exchange is a generic term for either a Simple Document Exchange or a Multiple Round Trip Document Exchange. 2.1.14 Simple Document Exchange A Simple Document Exchange consists of: o a Request Message sent from one party to a second party, and o the Response Message that is returned as a result. Examples of instances of a Simple Document Exchange include: David Burdett [Page 16]
Internet Draft XMLMSG/1.0 January 2000 o a Purchase Order sent by a buyer to a seller and the acknowledgement from the seller of its receipt o a Purchase Order sent by a buyer to a seller and the Invoice that is sent back as a result of fulfilling the order o sending a document for review by a lawyer followed by the legal opinion that is sent back as a result 2.1.15 Multiple Round Trip Document Exchange A Multiple Round Trip Document Exchange consists of: o a Request Message sent from one party to a second party, followed by o a series of Exchange Messages that are exchanged between the two parties until finally o the second party generates and sends a Response Message back to the first party. Examples of Multiple Round Trip Document Exchanges include: o the exchange of messages required to make a payment using payment method protocols such as [SET] or [Mondex] o the exchange of messages required to negotiate an agreement on terms and conditions o the exchange of messages required to send a large document between two locations in several smaller parts. 2.1.16 Exchange Message An Exchange Message is a Message that is sent between one Party and another after the sending of the initial Request Message and before the sending of the final Response Message. An Exchange Message MUST also contain a Reference to the immediately preceding Message that the caused the Exchange Message to be generated. Examples of Exchange Messages include: o intermediate messages that are part of a Payment Protocol o a counter offer to an offer made as part of a negotiation. David Burdett [Page 17]
Internet Draft XMLMSG/1.0 January 2000 2.1.17 Acknowledgement Message The sender of any Message, apart from an Acknowledgement Message, MAY request that receipt of the Message be acknowledged by recipient sending an Acknowledgement Message back to the Party that sent the original Message. The purpose of an Acknowledgment Message is to provide positive confirmation that a Message has been received. Acknowledgement Messages should be sent immediately upon receipt of the Message before the Message is processed and before any business or application level response (i.e. a Response Message or Exchange Message) is sent. Acknowledgement Messages may be digitally signed to help prove their authenticity. [Note] Acknowledgement Messages are particularly useful in an asynchronous exchange of Messages where there may be extended periods of time between the receipt of a Message and the generation of another business or application level Message in response. [Note End] 2.1.18 Error Message An Error Message is a Message that reports on a problem in an earlier Message that prevents the earlier Message from being processed in a normal way. An Error Message MUST also contain Error Data to describe the problem that has been found. Examples of an Error Message include: o an Error Message reporting that an XML document was invalid or did not conform to its XML schema o an Error Message reporting a Transient Error that the Server processing a Message is busy and therefore the original Message should be resent at a later point in time. [Note] Error Messages report abnormal conditions which will require some type of unusual handling that might (or might not) permit recovery from the error. This is distinct from a Response Message that is used when a process completes normally. However even though a process completes "normally" it might not be successful. For example, if a Purchase Order is sent to a supplier, the goods requested might be "out of stock". David Burdett [Page 18]
Internet Draft XMLMSG/1.0 January 2000 This means that the request failed although the request was not in error and no Error Message should be produced. [Note End] 2.2 Services, Service Types and Transactions 2.2.1 Overview A Service is the implementation, by a Party, of a set of processes that conform to a particular Service Type. Each Service Type has associated with it a set of Document types that it can accept as input and a set of Document types that it can produce as output. The same Document type may be sent with different intentions. For example a purchase order might be either sent as either a "new" purchase order or as a "change" purchase order. Sending a Document to a Service with a particular intention will result in an Document Exchange where documents are swapped in a sequence defined according to the rules defined in a Document Choreography. The Document Choreographies and One Way Messages associated with a Service Type fully define that type of Service's interactions with the outside world. The definition of a Service Type may also make use of Sub Services to implements it's functionality. Each Sub-Service is a Service in its own right. So, at the lowest level, all definitions of a Service Type consist of Document Exchanges. The preceding description describes terms that define the rules associated with the sending or receiving of documents by a Service. The actual sending of real documents are called Transactions. More detail is provided below. 2.2.2 Service and Service Type A Service is carried out by a Party as a result of receiving a Request Message containing Documents sent with a particular intention. The behavior of a Service in terms of the Documents it can accept or generate is defined by its Service Type. Service Types may be defined by and be proprietary to an individual Party. However it is more likely that "standard" Service Types will David Burdett [Page 19]
Internet Draft XMLMSG/1.0 January 2000 be defined to meet common requirements, for example, to submit a new Purchase Order or to make a payment. Examples of Service Types include descriptions of: o a Purchasing Service that enables a customer to purchase goods on- line o an Order Processing Service that processes an Order and generates a response as a result o a Payment Service that accepts a payment and provides a receipt o a Fulfillment service that fulfills an order at the request of a Merchant. 2.2.3 Sub-Service A Sub-Service is a Service that is executed at the request of and as part of another Service. Examples of Sub-Services include: o a payment service that occurs as part of a purchase o a tax calculation service that calculates the tax due as part of an order processing service. The Sub-Services in a Service will have dependencies between them. These dependencies MAY be: o Serial. One Sub-Service MUST start only after the completion of another Sub-Service o Alternative. One Sub-Service MAY be executed as an alternative to another o Iterative Loop. A Sub-Service MAY be repeated a variable number of times o Conditional. The execution of a Sub-Service is conditional on the state of another Service. This may be used in conjunction with Serial, Alternative and Iterative Loop dependencies. o Parallel. A Sub-Service MAY execute in Parallel with another Service o Concurrent. A Sub-Service MUST Execute at the same time as another Sub-Service. An example of a simple Service with Sub-Services is a Purchase Service that consists of three Sub-Services: David Burdett [Page 20]
Internet Draft XMLMSG/1.0 January 2000 o an Offer Service that conveys an Offer for sale of goods. This Sub- Service has no dependencies and therefore starts first o a Payment Service that carries out the Payment which has a Serial dependency on the Offer Service o a Delivery Service that delivers the Digital Goods, that has a Serial dependency on the Payment Service 2.2.4 Document Choreography A Document Choreography is a description of the dependencies that control the sequence and choices in which Documents may be exchanged within a Document Exchange. Document Choreographies MUST be either: o Explicit, in that the Document Choreography is contained as data in one of the Messages in a Transaction, or o Implicit, in that the Document Choreography is defined in some other document or specification, for example a protocol specification. An example of a Document Choreography would be a new Purchase Order document choreography where: o a new Purchase Order is sent to a supplier, then o one of the following documents is returned as a result: - a Purchase Order Acknowledgement to indicate that the document has been received and is being processed, or - an Error Document to indicate there was a technical error in the Purchase Order, or - a Cancel Document to indicate that the Purchase Order will not be processed. 2.2.5 Transaction A Transaction is an instance of the execution of a Service with a particular intention. Examples of a Transaction include: o a Purchase Transaction that buys an Company Report for $20. It consists of three Sub-Service instances: - an Offer Service instance to buy the Company Report for $20 - a Payment Service instance that accepts a Payment for $20 using a credit card, and finally - a Delivery Service instance that delivers the Company Report as an HTML web page. o a Buying Service that consists of the following Sub-Services: David Burdett [Page 21]
Internet Draft XMLMSG/1.0 January 2000 - three Price Negotiation Service instances that negotiate the price of a Photocopier - a Purchase Order Service instance that places the order for the Photocopier. 2.3 Lower Level Data Definitions 2.3.1 Overview This sub-section contains definitions of the lower level data elements referenced in the previous two sub-sections. It covers: o Transaction Identity Data o Message Identity Data o Organization Data o Status Data o Action Data o Error Data o Cancel Data 2.3.2 Transaction Identity Data Transaction Identity Data uniquely identifies and describes a Transaction. Examples of the data contained in Transaction Identity Data include: o an identifier that globally uniquely identifies the Transaction (a GUID) o the version number of XML Messaging that is being used o the date/time the Transaction started 2.3.3 Message Identity Data Message Identity Data is data that enables a Message to be uniquely identified and referenced within a Transaction. Examples of the data contained in Message Identity Data include: o a reference that uniquely identifies the Message within a Transaction David Burdett [Page 22]
Internet Draft XMLMSG/1.0 January 2000 o the date/time the message was created o the software that generated the Message 2.3.4 Message Manifest The Message Manifest contains references to the other documents, apart from the Message Routing Information document, that are contained within the same Message Envelope. The purpose of the Message Manifest is to facilitate locating and validating that all required Documents contained within the Message Envelope are present. Examples of the types of documents that might be referenced by a Message Manifest include: o a Purchase Order o a Purchase Order and a picture of the requested goods o a Purchase Order and a digital signature [Note] The Message Manifest does not contain a reference to the Message Routing Information since this information will typically be added after the rest of the documents contained in the Message Envelope have been created and therefore it's reference number will not be known. The reference cannot be added later if the Message Header has been digitally signed since it would break the signature. Finally, there may be benefit in adopting the Message Manifest developed by the IETF/W3C digital signature group [XMLDSIG] as the standard to be used here since essentially they serve the same purpose. [Note End] 2.3.5 Related Transaction Data Related Transaction Data optionally links one Transaction to other related Transactions. The linkage may be either by: o specifying the GUID of the other transactions as specified on that Transactions, Transaction Identity Data or, o using some other reference, outside the scope of XML Messaging by which the transaction may be identified Examples of the use of Related Transaction Data include: David Burdett [Page 23]
Internet Draft XMLMSG/1.0 January 2000 o referring to an earlier transaction where the terms and conditions associated with the transaction were negotiated o raising a request to fix a problem associated with some earlier transaction that had occurred o making a query on the status of another transaction. 2.3.6 Organization Data Organization Data is data that describes and identifies a Party. The purpose of Organization Data is to provide information: o to enable the identity of the Organization to be determined o that allows the Organization to be contacted when and if necessary o to determine who a Message is from and who it is sent to. Examples of information contained within Organization Data include: o Name and Address o Individuals and contacts o Reference numbers, e.g. [DUNS] numbers [Note] The amount of information provided in Organization Data can vary from: o a simple reference number, through o a comprehensive address, for example to describe a Supplier who is selling tangible goods, to o minimal or none, for example if a Consumer is buying a page of digital information for 2 cents. [Note End] 2.3.7 Action Data Action Data indicates the type of Service that is being sent a Message and the intention behind sending it. Examples of information contained within Action Data include: o the identifier of the Service that should process the Message o the intention in sending the Message, for example to request a service o whether or not the Action is for test purposes only. David Burdett [Page 24]
Internet Draft XMLMSG/1.0 January 2000 2.3.8 Status Data Status Data provides information on the current state of a Transaction. It MUST be sufficient, on its own, to indicate success or failure of the Transaction. Examples of the information contained within Status Data include: o a code to indicate success, failure and various other states o a reference to the Request Message that initiated the Transaction o a reference to the Organization Data that carried out the Service [Note] A standard definition of the results of a Transaction enables that information to be used to authorize the start of a later Service within a Document Choreography without providing details of the first Service to the Party that is carrying out the later Service. As a result privacy is improved in that a Party is only provided with the information they need, to carry out a requested service. [Note End] 2.3.9 Error Data Error Data contains data that describes an Error contained in a Message. It MUST contain: o a reference to the Message(s) that are in Error If the error is not a Transient Error then the Error Data MUST also contain: o a reference to the part(s) of the Message that are in Error 2.3.10 Cancel Data Cancel Data sent by one party indicates that to the other Party that the remainder of the transaction will not be carried out. Cancel Data MAY be sent: o by the Party that generated a Request Message to the Party that is acting on the message - to indicate that the requested action should not be completed o by the Party that received a Request Message back to the party that generated the Request Message to indicate that the Request Message was unacceptable in some way and therefore no Response Message will be generated. David Burdett [Page 25]
Internet Draft XMLMSG/1.0 January 2000 [Note] One of the main uses of sending a Message containing Cancel Data is to prevent the sender of a Request Message going into "recovery mode" since no Response Message was received within the expected timeframe (see 4.2 Recovering from failed Message delivery). Also note that: o sending a Message containing Cancel Data will fail if the Response Message has already been sent o it may not be possible (or allowable) to cancel the processing of some Request Messages after they have been sent. [Note End] 2.4 Miscellaneous Definitions This section covers a number of miscellaneous definitions used earlier in this section. It covers: o Document Encoding o Audit Trails o Transport Mechanism o Identical Elements 2.4.1 Document Encoding Some Documents may exist either in their native form or transformed into a directly equivalent form through the use of a Document Encoding. Examples of a Document Encoding include: o [BASE64] encoding o [MIME] encoding. 2.4.2 Audit Trail An Audit Trail is a record of a Transaction that allows the processing carried out by a Transaction to be traced. There are three mechanisms in XML Messaging that support the production of audit trails: o data on each Message Identity Information that references the earlier Message that is being responded to David Burdett [Page 26]
Internet Draft XMLMSG/1.0 January 2000 o Status Data from an earlier Message that shows how the start of one Document Exchange is dependent on an earlier one, and o digital signatures on the above two sets of information to make the audit trail non-refutable. See the XML Messaging Examples below for examples of an audit trail. 2.4.3 Transport Mechanism A Transport Mechanism is a protocol, such as [HTTP] or [SMTP], that is used to physically transport a Message between two Parties. XML Messaging is designed so that any Transport Mechanism may be used. [Note] Although [HTTP] and [SMTP] are two likely transport mechanisms, literally any transport mechanism is possible, including: o sending a Message as a fax o putting the Message on a floppy disk and sending it in the post [Note End] 2.4.4 Identical Elements There are a number of instances where it is necessary to compare XML elements from one Message with elements from another to determine if they are the same. For example the way in which the Messages that belong to the same Transaction are identified is that they have "identical" Transaction Identification Data elements. However some Transport Mechanisms can introduce additional characters into documents which means that a simple character-by-character comparison of elements will not provide reliable results. Therefore, in XML Messaging, identification of identical elements MUST be determined by checking that their [DOM-HASH] values are identical. David Burdett [Page 27]
Internet Draft XMLMSG/1.0 January 2000 3. Standard Transactions The specification for XML Messaging defines four "standard" transactions: o Service Availability Inquiry, that checks whether or not a Service is up-and-running o Transaction Status Inquiry, that checks on the status of a transaction, o User/Server Authentication, that enables one Party to authenticate another, and o Protocol Negotiation, that allows two parties to agree which choreography and documents they will use to carry out a service. The Service Availability and Transaction Status Inquiry transactions MAY be used to assist in re-start and recovery (see section 4). Each of these are described in more detail below. 3.1 Service Availability Inquiry In outline a Service Availability transaction consists of a Simple Document Exchange: o a Service Availability Request document, sent by one Party to another, and o a Service Availability Response document, that is sent in return The Service Availability Response indicates whether or not the Service is available and provides basic information on some of properties of the Service such as scheduled "down time" and anticipated Response Times. Service Availability Requests MAY be signed. System operators can use this to decide whether or not to generate a Service Availability Response. It is RECOMMENDED that a Party that is conducting Transactions with other Parties periodically sends Service Availability Requests to those other Parties to make sure that they are up and running. David Burdett [Page 28]
Internet Draft XMLMSG/1.0 January 2000 3.2 Transaction Status Inquiry The Transaction Status Inquiry consists of a Simple Document Exchange: o a Transaction Status Inquiry Request document, that specifies the globally unique identifier of a Transaction, and o a Transaction Status Inquiry Response document, that indicates the current state of the transaction. The state can include: - Not Known - Not Yet Started - In Progress - Completed Ok - Failed - Canceled - Process Error The Transaction Status Inquiry document also indicates the identifier of the last Message that was received. This is used in recovering from failed message delivery (see section 4.2). Transaction Status Inquiry Request documents MAY be digitally signed. This means that system operators can use this to determine if an inquiry is valid. Transaction Status Inquiry Response documents MAY also be digitally signed. This means that the recipient of the Response Message can check its authenticity. 3.3 User/Server Authentication The User/Server Authentication Transaction enables one Party to authenticate another. It uses the following Document Exchange: o Authentication Request document. This is sent to the Party to be authenticated. It contains: - "challenge data" to which the Party being authenticated should respond, and - the authentication method that should be used, this can vary from providing a simple password, providing a digital signature or using some proprietary authentication protocol o Authentication Response document. This is sent by the Party being authenticated to the Party requesting authentication. It contains the results of the processing the authentication data Authentication Request documents may optionally be digitally signed. This MAY be used by the user/server being authenticated to determine whether or not the Authentication Request is authorized. David Burdett [Page 29]
Internet Draft XMLMSG/1.0 January 2000 3.4 Quality of Service Negotiation The same service may be implemented in a variety of ways and with differing levels or timeliness of response and using different transport protocols. The Quality of Service Negotiation transaction enables two parties to agree which, of the possible alternatives, may be used. Two of the uses of Quality of Service Negotiation are: o to determine the transport protocols that the Service supports o to determine whether the Service will be implemented synchronously or asynchronously o to agree the various "timeouts" used in recovering from failed message delivery (see section 4.2). It consists of the following Document Exchange: o Quality of Service Negotiation Request document. This is sent by the Party that wants to discover information about the Service. It contains a prioritized list that describes: - the protocols supported (e.g. HTTP, SMTP, etc) - whether messages are exchanged synchronously or asynchronously - the preferred time after which "recovery from failed message delivery processing" would start. o Quality of Service Negotiation Response document. This is returned by the Party that received the Request. It contains, for example: - the selected protocol (if any), - the preferred time after which recovery from failed message delivery processing should start, - whether or not the data is exchanged synchronously - the validity of the Service Negotiation Response document - details of any planned outages or non-availability of the Service. A single Quality of Service Negotiation transaction may not result in a successful response. In this case the sender of the original Request Message, may vary the content of the Quality of Service Negotiation Request document in order to find a combination that is acceptable. Implementers may want to cache the results of a Quality of Service Negotiation Response document for later use It is not necessary for a Quality Of Service Negotiation to be carried out before sending messages between two parties. However its use should maximize the probability of any particular transaction completing in a normal way. David Burdett [Page 30]
Internet Draft XMLMSG/1.0 January 2000 4. Restart, Recovery and Idempotency Restart and Recovery in XML Messaging provides a standard approach to recovering from the failure of a Message to get through to its intended recipient. It uses the Service Availability Transaction (see section 3.1) and the Transaction Status Inquiry Transaction (see section 3.2) to determine what the current situation is and therefore what action should be taken to recover. When to start the restart/recovery process will vary depending on the transport protocol and characteristics of the service. The Quality of Service Negotiation transaction (see section 3.4) MAY be used to determine when this should be. The following is an overview. More detail is provided in [XMLMSG-RM]. 4.1 Idempotency Duplicate Messages can be received by a Service for a number of reasons: o the Transport Protocol sometimes causes duplicate Messages to be delivered o the sender of the Message sent the message twice. Either by accident, for example there is a bug in the Sender's software; or by design, for example no response was received to the first message so the message was resent. In XML Messaging restart and recovery, it is assumed that if a Recipient receives an "identical" duplicate message (see section 2.4.4), then: o the duplicate message is not processed o the message that was generated in response to the original message is resent. 4.2 Recovering from failed Message delivery Prior to sending a Message (either a Request Message or an Exchange Message) to another Party the timeframe in which recovery/restart should commence should be negotiated using a Quality of Service Negotiation Transaction (see section 3.4). David Burdett [Page 31]
Internet Draft XMLMSG/1.0 January 2000 Once the Message is sent, the Sender of the Message will only discover a failure in delivery by realizing that the Message expected in response has not been received within the expected time frame. The Message expected in response may be: o an Acknowledgement Message (see 2.1.17 Acknowledgement Message), or o a Message that is a business or application level response to the original Message, this can be: - a Response Message - an Exchange Message - an Error Message, or - a Cancel Message However the Sender does not know why no Message was received in response. The Sender may also not want to re-send their Message without knowing the results of sending the earlier message. They therefore need to find out the current situation so that they can work out what to do to recover. The following approach is RECOMMENDED as a guideline: 1)Carry out a Transaction Status Inquiry for the Transaction 2)If the result of the Inquiry is "Not Known", then re-send the original Message as the Message did not get through on the first try 3)If the result of the Inquiry is "In Progress" then wait a further period of time, as a Message in response should be received in due course once its processing is complete. If no Message in response is received after a period of time then repeat from step 1. 4)If the result of the Inquiry is any other Transaction Status (e.g. "Completed Ok", "Failed", etc.) then the first Message was received and processed but the Message in Response did not get through. In this case re-send the first Message which should result in the re- sending of the previously generated Message in Response. If the Message in Response does not arrive after the expected period of time then repeat from step 1. 5)If no response to the Transaction Status Inquiry is received, then it is possible that either the Transaction Status Inquiry transaction failed, or that the Service that should respond to the Inquiry is not working. In this case carry out a Service Availability Transaction for the Service. 6)If the Service Availability Transaction does not work then in all probability the Service is not working. In this case either: a) wait some period of time and retry the Service Availability Transaction until it does respond. Once the Service Availability Transaction works then repeat from step 1 to determine what recovery action to take, or David Burdett [Page 32]
Internet Draft XMLMSG/1.0 January 2000 b) choose an alternative URL to send the Message to (if one is available) and send the Message to that URL then wait for a response. In this case the failure to send the message to the original destination should be recorded in the Message Routing Information. 7)If, after a number of re-tries, there is still no response from sending a Service Availability Request, and there are no alternative URLs that can be used then carry out whatever action is appropriate such as notify an operator for human intervention and carry out no further recovery actions until requested by the operator. David Burdett [Page 33]
Internet Draft XMLMSG/1.0 January 2000 5. Security Considerations This section considers, from an IETF perspective how XML Messaging addresses security. The section covers: o digital signatures o message authenticity, and o data privacy. 5.1 Digital Signatures The data contained within XML Messages can be digitally signed for the usual reasons such as: o authenticating the identity of the sender of a message, o enables changes in the signed data to be detected, o providing a mechanism to support non-repudiation of a request for or response to the execution of a Service. However, the scope of this specification SHALL be limited to defining how digital signatures can be used by XML Messaging and excludes the trust relationships that use of signatures may apply. 5.1.1 Determining whether to use digital signatures The use of digital signatures within XML Messaging is entirely optional. XML Messaging can work successfully either with or without the use of digital signatures. Ultimately it is up to the Parties involved to decide whether the XML Messages they use will include signatures. For example if a Sender of a Message omits a Digital Signature then the recipient of the Message will need to decide whether carrying out the requested Service without signatures is an acceptable risk. If senders of Request Messages discover that requests without signatures are not being accepted, then they will either: o start using signatures, o find a method of working which does not need signatures, or o accept a lower volume and value of transactions. David Burdett [Page 34]
Internet Draft XMLMSG/1.0 January 2000 5.1.2 Reasons for using Digital Signatures A non-exhaustive list of the reasons why digital signatures might be used are described below. A MERCHANT WANTS TO DEMONSTRATE THAT THEY CAN BE TRUSTED If, for example, a merchant generates an offer to carry out a trade and includes it in an XML Message with a Signature that uses a certificate from a trusted third party, known to the Consumer, then the Consumer can check the signature and certificate and so more reasonably rely on the offer being from the actual organization the merchant claims to be. In this case signatures using asymmetric (PKI) cryptography are likely to be required since the Merchant would not want other organizations to be able to generate an equivalent signature. A MERCHANT WANTS TO GENERATE A RELIABLE RECORD OF A TRANSACTION For example, with appropriate trust hierarchies, digital signatures could be checked by the Consumer to determine: o if a record of a purchase will be accepted by tax authorities as a valid record of a transaction, or o if some warranty, for example from a "Better Business Bureau" or similar was being provided. A PARTY NEEDS TO KNOW THAT A REQUEST MESSAGE IS UNALTERED AND AUTHORISED The data that constitutes a Request Message may have been provided by someone other than the sender of the Message. For example, in [IOTP], details of how much to pay is sent to the Consumer by a Merchant and then forwarded to the Payment Handler that is to accept the payment in a payment request message. If the request is not signed, the Consumer could change the amount due by, for example, removing a digit. If the Payment Handler has no access to the original payment information provided by the Merchant, then, without signatures, the Payment Handler cannot be sure that the data has not been altered. Similarly, if the payment information is not digitally signed, the Payment Handler cannot be sure who is the Merchant that is requesting the payment. A PARTY WANTS TO PROVIDE A NON-REFUTABLE RECORD OF THE COMPLETION STATUS OF A SERVICE If a Response Message is digitally signed, then the recipient of the Response Message can later use the data in the Response Message to David Burdett [Page 35]
Internet Draft XMLMSG/1.0 January 2000 prove that the service was carried out. This could be used, for example, to enable a customer to claim a refund of a purchase if required. 5.1.3 Reasons to not use Signatures A non-exhaustive list of the reasons why digital signatures might not be used follows. A SINGLE PARTY IS CARRYING OUT ALL SERVICES One of the reasons for using digital signatures is so that one Party can determine if data has been changed by an intermediate Party that is forwarding the data. However if the Party that needs to check for authenticity has access to all the necessary data, then it might be possible to compare, for example, the forwarded information with the original. Access to the data necessary could be realized by, for example, one Party carrying out all the different roles on the same system, or where the roles are carried out on different systems but the systems can communicate in some way. THE PROCESSING COST OF THE CRYPTOGRAPHY IS TOO HIGH If a payment is being made of only a few cents, the cost of carrying out all the cryptography associated with generating and checking digital signatures on a request to make the payment or a receipt contained in a payment response might make the whole transaction uneconomic. ANYONE CAN REQUEST THE SERVICE The service that is being requested, for example to inquire on the public list price of a product, may be open to anyone. In this case, there is little benefit in signing the request as it is likely that a response will always be generated. 5.2 Message Authenticity XML Messaging provides two mechanisms by which the authenticity of the Parties involved may be assured: o digital signatures o user/server authentication Digital signatures contained in Messages MAY be checked to ensure that the sender of the document is who they appear to be. David Burdett [Page 36]
Internet Draft XMLMSG/1.0 January 2000 User/server authentication (see section 3.3) may be used to authenticate the sender of or recipient for any message. This can occur either: o before sending a message to authenticate a recipient, or o after receiving a message to authenticate its sender. In addition transport level methods MAY be used to determine the authenticity of messages. For example: o by checking the certificates associated with the use of secure channels such as [SSL/TLS], or o using a communication method (e.g. a telephone line) that is dedicated to the two parties and is thought sufficiently trustworthy. Transport Level authenticity methods SHALL NOT be defined by this specification. A secure transport protocol MAY also remove the need to use digital signatures. 5.3 Data Privacy Privacy of information is provided by sending Messages using a secure channel such as [SSL/TLS]. Use of a secure channel with XML Messaging is OPTIONAL. Any elements within documents that are transmitted using XML Messaging MAY be encrypted. However, the procedure used to encrypt XML elements or documents SHALL NOT be defined within this specification. David Burdett [Page 37]
Internet Draft XMLMSG/1.0 January 2000 6. XML Messaging Compliance Levels The purpose of this section is to indicate the different ways in which the various parts of the XML Messaging Specification may be used together in a compliant way. XML Messaging Specification is split into several parts for a number of reasons: o so that implementers of XML Messaging may select the just the parts of XML Messaging that they need, for example, some implementations may not need to use digital signatures, o to facilitate the development and evolution of individual sections in parallel, o to encourage re-use of the XML Messaging Specifications by other protocol and standard developers. The following examples illustrate ways in which the different parts of XML Messaging may be combined. 6.1 Data Element Compliance Data Element Compliance is the lowest level of compliance which simply requires use of some of the XML element definitions contained in the Common XML Messaging Elements specification [XMLMSG-CME]. The message elements MUST be used with the semantics as defined in the specification. 6.2 Message Level Compliance Message Level Compliance uses all the data elements defined in the Common XML Messaging Elements Specification [XMLMSG-CME] to construct XML Messages that can be sent between two Parties. However use of XML Messages in a Response-Request based Document Exchange is not required. 6.3 Document Exchange and Transaction Level Compliance Document Exchange Compliance exchanges messages in the standard ways defined within Document Exchange and Transactions [XMLMSG-DET]. This uses XML Messages to support Transactions consisting of either: o a Simple Document Exchange David Burdett [Page 38]
Internet Draft XMLMSG/1.0 January 2000 o a Multiple Round Trip Document Exchange, or o a One Way Message This MUST be used with: o Message Level Compliance (see section 6.2), and o a transaction protocol (e.g. HTTP)as defined in the protocol's Transaction Protocol Supplement (see section o). 6.4 Reliable Messaging Compliance Reliable Messaging Compliance uses the processes and procedures defined in Reliable Messaging [XMLMSG-RM] to achieve reliable, robust and resilient message delivery. This MUST be used with Document Exchange and Transaction Compliance (see section 6.3) and MAY be used with any combination of: o Secure Messaging Compliance (see section 6.5), o Document Choreography Compliance (see section 6.6). 6.5 Secure Messaging Compliance Secure Messaging Compliance uses the processes and procedures defined in Secure Messaging [XMLMSG-SM] to ensure the tamper resistant and authenticated exchange of messages. This MUST be used with Document Exchange and Transaction Compliance (see section 6.3) and MAY be used with any combination of: o Reliable Messaging Compliance (see section 6.4), o Document Choreography Compliance (see section 6.6). 6.6 Document Choreography Compliance Document Choreography Compliance uses the processes and procedures defined in Document Choreography Definitions [XMLMSG-DCD] that defines how the sequence in which documents are exchanged may be defined. This MUST be used with Document Exchange and Transaction Compliance (see section 6.3) and MAY be used with any combination of: o Reliable Messaging Compliance (see section 6.4), David Burdett [Page 39]
Internet Draft XMLMSG/1.0 January 2000 o Secure Messaging Compliance (see section 6.5). 6.7 Transport Protocol Supplement Compliance XML Messages may be transported over a variety of transport protocols such as [HTTP] or [SMTP]. How this is done for a particular transport protocol is defined in a Transport Protocol Supplement for the protocol. Transport Protocol Supplement Compliance means that an implementation conforms with the Transport Protocol Supplement specification. 6.8 Common Document Exchange and Transaction Compliance Common Document Exchange Compliance means that an implementation supports one or more of the document exchanges defined as standard. Examples of candidate standard document exchanges/transactions include: o a Transaction Status Inquiry, that allows the current status of any transaction to be discovered, o a Large Message Delivery Transaction, that supports the delivery of large messages/documents by splitting them up into several smaller parts, o a Message Trace Inquiry that enables the sender of a message to discover where the message has been forwarded to, o a Service Functionality Inquiry that enables the functions that a Service supports to be discovered such as Reliable Messaging, Security and Signatures, Transport Protocols supported, Large Message Delivery capability, etc These common document exchanges/transactions MUST be used with Document Exchange and Transaction Compliance (see section 6.3) and MAY be used with any combination of: o Reliable Messaging Compliance (see section 6.4), o Secure Messaging Compliance (see section 6.5), o Document Choreography Compliance (see section 6.6). David Burdett [Page 40]
Internet Draft XMLMSG/1.0 January 2000 7. XML Messaging Examples This section is in two parts: o an illustration of the structure of a Message that conforms to the ideas in this specification, and o a series of examples that illustrate how XML Messaging could be used. The examples provided are: - Simple Document Exchange - Simple Document Exchange with Errors - Canceling a Transaction - Transaction with Multiple Document Exchanges - Relating Two Transactions 7.1 XML Message Structure In outline, an XML Message has the structure shown in the figure below. Note that spaces have been included in the "element" names for ease of reading. <MessageEnvelope ...> o Outer wrapper can be an XML Document or a Multipart MIME message. <MessageHeader ...> o Message Header contains additional data required to send the document(s) successfully. Content depends on whether it is a Request Message, Exchange Message, Response Message or an Error Message. <MessageType ...> o Required in every Message. It indicates the type of the Message. The different types of Message are: Request, Response, Exchange, Acknowledgement, OneWay, Cancel, and Error. <TransactionIdentityData ...> o Required in every Message. It ... identifies a set of related </TransactionIdentityData> Messages. <MessageIdentityData ...> o Required in every Message. It ... identitifies and describes an </MessageIdentityData> individual message within a Transaction <From ...> o Required in every Message. It ... identifies, logically, the sender </From> of the message. The sender may be anonymous. <To ...> o Required in every Message. It ... identifies, logically, the David Burdett [Page 41]
Internet Draft XMLMSG/1.0 January 2000 </To> recipient of the Message. The recipient may be anonymous in which case the recipient is identified at the Transport Protocol level. <AuthorizationData ...> o Optional. Contains information ... that identifies who is </AuthorizationData> authorizing that the recipient of the Message should act on the Message. <ServiceType ... > o Required in every Message. It ... indicates the type of Service to </ServiceType> which the Message is associated. <Intent ... > Required in every Message. It ... indicates the reason why Message </Intent> is being sent to the Service. <Status ... > On Response, Acknowledgement and ... Error Messages it rovides an </Status> indication of the current state of the Document Exchange. On Request Messages it is used to indicate the end state of a preceding Document Exchange. <MessageManifest ...> o Required in every Message that ... contains more than just a Message </MessageManifest> Header and Message Routing Information. Identifies what other documents/signatures were sent with the message. <RelatedTransactionData...> o Optionally links one Transaction ... to some earlier Transaction </RelatedTransactionData> </MessageHeader> <MessageRoutingInfo ...> o Required within every message. ... Maps the logical destination to </MessageRoutingInfo> the physical destination (e.g. a URL). Contains a history of the route taken by the message in order to reach its final destination. <Signatures ...> o Zero or more. A Digital signature ... can sign any data in the Message, </Signatures> the Transaction, or elsewhere, for example on the web. o The actual document(s) that are ... DOCUMENT(S) ... to be sent to a party. Documents may be encoded for transportation for example using [Base64]. </MessageEnvelope> Figure 1 XML Messaging, Message Structure David Burdett [Page 42]
Internet Draft XMLMSG/1.0 January 2000 If the Message Envelope is implemented using multi-part MIME, then the Message Header, Signatures and the "Documents" would each be contained in separate multi-part MIME parts. If the Message Envelope is implemented using an XML-Document, then non-XML "documents" would be wrapped in thin XML wrapper so that they can be uniquely identified by the Message Manifest. 7.2 XML Messaging Examples 7.2.1 Simple Document Exchange At its simplest, a Transaction consists of just one Service that uses just one Simple Document Exchange that consists of: o a Request Message sent from one party to a second party, and o the Response Message that is returned as a result. The figure below provides an example of what these messages could contain and how they could be processed. Party 1 | Party 2 STEP | | 1. Party 1 generates the documents that need to be sent, places them in an XML Message together with a Message Header and (optional) digital signature and sends it to the Party 2. 1 --> 2 Request Message: o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Party 1) - To (Party 2) - Service Type - Intent - Authorization Data - Message Manifest o Message Routing Info o Signature(s) (Optional) o Document(s) 2. Party 2 that received the Request Message carries out the following processes: o checks the "To" data to check the Message intended for them; o checks the Service Type and Intent to make that they can carry out the request; David Burdett [Page 43]
Internet Draft XMLMSG/1.0 January 2000 o if required, checks the "From" data to make sure that the sender is known o checks the Authorization Data (if present) to make sure the action is authorized (note some requests may not need authorization); o checks the Signature, if present, to make sure the data has not changed and the sender can be identified, then o if everything is OK, checks the Document(s) for errors, then o if no errors in the Document(s) then carries out the requested action using the data contained in the Document(s) o once the action is complete, then generates a Response Message and sends it back to Party 1. 1 <-- 2 Response Message: o Message Header: - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Party 2) - To (Party 1) - Service Type - Intent - Message Manifest - Status Data o Message Routing Info o Signature(s) (Optional); o Document(s) 3. Party 1 that has received the Response Message then carries out the following processes: o Checks the Transaction Identity Data and Message Identity Data to make sure the Response Message refers to the Transaction/Request Message that they sent earlier o checks the Signature, if present, to make sure the data has not changed and is the sender of the message can be authenticated o checks the Status Data to determine that the Service was carried out by the anticipated Organization and whether the service succeeded or failed o if everything is OK, then checks the Document(s) for Errors, o if everything is still OK, then carries out whatever processing of the Document(s) is necessary. Figure 2 Simple Document Exchange Message Flow [Note] In the above example the sequence of the processing by the described for Party 1 or Party 2 is indicative of the processing required. Sequences that provide the same result are equally acceptable. David Burdett [Page 44]
Internet Draft XMLMSG/1.0 January 2000 [Note End] 7.2.2 Simple Document Exchange with Errors In the previous example, it was assumed that no errors were found. If errors are found then a slightly different message flow would occur. The example below builds on the previous example in Figure 2 Simple Document Exchange Message Flow. Party 1 | Party 2 STEP | | 1. Party 1 generates the documents that need to be sent, places them in an XML Message together with a Message Header and (optional) digital signature and sends it to the Recipient. 1 --> 2 Request Message: o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Party 1) - To (Party 2) - Service Type - Intent - Message Manifest o Message Routing Info o Signature(s) (Optional) o Document(s) 2. Party 2 that receives the Request Message detects an error and so sends an Error Message back to Party 1. 1 <-- 2 Error Message: o Message Header - Message Type (Error) - Transaction Identity Data - Message Identity Data - From (Party 2) - To (Party 1) - Service Type - Intent - Message Manifest o Message Routing Info o Signature(s) (Optional) o Document(s) - Error Data 3. Party 1 that received the Error Message: o Checks the Transaction Identity Data and Message Identity Data to make sure the Message refers to the Transaction/Request Message that they sent David Burdett [Page 45]
Internet Draft XMLMSG/1.0 January 2000 o checks the Signature, if present, to make sure the data has not changed o determines that there was an Error and takes the appropriate action. Figure 3 Document Exchange with Request Message Errors Errors can also occur in a Response Message. In this case the Message flow would be as below. Party 1 | Party 2 STEP | | 1. Party 1 generates the documents that need to be sent, places them in an XML Message together with a Message Header and (optional) digital signature and sends it to Party 2. 1 --> 2 Request Message: o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Party 1) - To (Party 2) - Service Type - Intent - Message Manifest o Message Routing Info o Signature(s) (Optional) o Document(s) 2. Party 2 that receives the Request Message successfully processes the Request Message and generates and sends a Response Message back to Party 1. 1 <-- 2 Response Message: o Message Header: - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Party 2) - To (Party 1) - Service Type - Intent - Message Manifest - Status Data o Message Routing Info o Signature(s) (Optional); o Document(s) 3. Party 1 that has received the Response Message identifies an error in the some part of the Response Message and David Burdett [Page 46]
Internet Draft XMLMSG/1.0 January 2000 therefore sends an Error Message back to the Sender of the Response Message. 1 --> 2 Error Message: o Message Header - Message Type (Error) - Transaction Identity Data - Message Identity Data - From (Party 1) - To (Party 2) - Service Type - Intent (Error) - Message Manifest o Message Routing Info o Signature(s) (Optional) o Document(s) (Optional) - Error Data 4. Party 2 that received the Error Message: o Checks the Transaction Identity Data and Message Identity Data to make sure the Message refers to a Transaction/Request Message that they are aware of o checks the Signature, if present, to make sure the data has not changed o determines that there was an Error in the Response Message they had sent and takes the appropriate action. Figure 4 Document Exchange with Response Message Errors 7.2.3 Canceling a Transaction Transaction cancellation occurs in a similar way to generating errors. For example if a Recipient of a Request Message wants to cancel a transaction they would do this as illustrated in the figure below. Party 1 | Party 2 STEP | | 1. Party 1 generates the documents that need to be sent, places them in an XML Message together with a Message Header and (optional) digital signature and sends it to Party 2. 1 --> 2 Request Message: o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Party 1) - To (Party 2) - Service Type David Burdett [Page 47]
Internet Draft XMLMSG/1.0 January 2000 - Intent - Message Manifest o Message Routing Info (Optional) o Signature(s) (Optional) o Document(s) 2. Party 2 that received the Request Message checks the message but decides they want to cancel the Transaction for some reason and so sends a Cancel Message back to the Sender of the Request Message. 1 <-- 2 Cancel Message: o Message Header - Message Type (Cancel) - Transaction Identity Data - Message Identity Data - From (Party 2) - To (Party 1) - Service Type - Intent (Cancel) - Message Manifest (Optional) o Message Routing Info (Optional) o Signature(s) (Optional) o Document(s) (Optional) 7.2.4 Transaction with Multiple Document Exchanges Transactions can also consist of multiple Document Exchanges as illustrated in the following example that contains four Document Exchanges that are part of three Services. The Services, the associated Intent and the resultant Document Exchanges are as follows o Service: Supplier Order Processing - Intent: Stock Availability Check Document: Stock Availability Request Document: Stock Availability Response - Intent: New Purchase Order Document: Purchase Order Document: Invoice Document: Payment Brand List o Service: Payment Service - Intent: Make Payment Document: Payment Request Document: Payment Instrument Document: Payment Response o Service: Delivery Goods - Intent: Request Delivery Document: Delivery Request Document: Delivery Response David Burdett [Page 48]
Internet Draft XMLMSG/1.0 January 2000 Note that this example also illustrates how digital signatures can be used to provide an Audit Trail and authorize the execution of each Service. More details are provided below together with explanations on how signatures are used to link each Document Exchange instance together. Buyer Supplier / | Payment Handler STEP | | 1. Buyer generates a Stock Availability Request, digitally signs it, and sends it to the Supplier to check for availability. B --> S Request Message (Stock Availability Request): o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Supplier Order Processing) - Intent (Stock Availability Check) - Authorization Data: Buyer Data ref. to Signature1 - Message Manifest o Message Routing Info o Signatures - Signature1, Signs: Message Header Stock Availability Request o Documents - Stock Availability Request 2. The Supplier checks the Stock Availability Request (see example earlier for what is involved in checking a request) and generates a Stock Availability Response to send back to the Buyer. The response is digitally signed. B <-- S Response Message (Stock Availability Response): o Message Header - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Supplier) - To (Buyer) - Service Type (Supplier Order Processing) - Intent (Stock Availability Check) - Message Manifest - Status Data (Stock Availability Check) o Message Routing Info o Signatures - Signature2, Signs: David Burdett [Page 49]
Internet Draft XMLMSG/1.0 January 2000 Message Header Stock Availability Response Signature1 in Stock Availability Request Message o Document - Stock Availability Response 3. The Buyer checks the Stock Availability Response Message and finds it OK. As a result generates a Purchase Order Document and sends it to the Supplier. The Authorization Data includes Status Data on the Stock Availability, to indicate that the Purchase Order is linked to the earlier Stock Availability Check Document Exchange. B --> S Request Message (Purchase Order): o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Supplier Order Processing) - Intent (New Purchase Order) - Message Manifest - Authorization Data: Buyer Data Status Data (Stock Availability Check) ref. to Signature3 o Message Routing Info o Signatures - Signature3, signs: Message Header Purchase Order Signature2 (on Stock Availability Check Response Message) o Documents - Purchase Order 4. The Supplier checks the Purchase Order Request Message and generates an Invoice, and a list of Payment Brands that the Supplier accepts, signs the documents and sends them back to the Buyer. B <-- S Response Message (Purchase Order Response): o Message Header - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Supplier) - To (Buyer) - Service Type (Supplier Order Processing) - Intent (New Purchase Order) - Message Manifest - Status Data (New Purchase Order) o Message Routing Info David Burdett [Page 50]
Internet Draft XMLMSG/1.0 January 2000 o Signatures - Signature4, signs Message Header Invoice Brand List Signature3 (on Purchase Order Request Message) o Documents - Invoice - Brand List 5. The Buyer checks the Purchase Order Response Message and finds it OK. As a result generates a Payment Request, provides information on the Payment Instrument to use, digitally signs them sends them to the Payment Handler (another Party) that is to accept the payment on behalf of the Supplier. B --> P Request Message (Payment Request): o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Payment Handler) - Service Type (Payment) - Intent (Make Payment) - Message Manifest - Authorization Data Buyer Data Supplier Data Status Data (New Purchase Order) ref. to Signature4 (from Purchase Order Response Message) ref to Signature5 o Message Routing Info o Signatures - Signature4 (copied from Purchase Order Response Message) - Signature5, signs Signature4 (on Purchase Order Response Message) Payment Instrument Payment Request o Documents: - Payment Request (amount to pay, which Brand) - Brand List - Payment Instrument 6. The Payment Handler Checks the Payment Request including the Authorization Data to check that they know the Supplier, and on the Payment Instrument data to check that the Buyer wants to make the payment. Accepts the Payment, generates a Payment Receipt, digitally signs the information and sends it back to the Buyer. David Burdett [Page 51]
Internet Draft XMLMSG/1.0 January 2000 B <-- P Response Message (Payment Response): o Message Header - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Payment Handler) - To (Buyer) - Service Type (Payment) - Intent (Make Payment) - Message Manifest - Status Data (Payment Response) o Message Routing Info o Signatures - Signature6, signs Message Header Payment Receipt Signature4 (on Purchase Order Response Message) Signature5 (on Payment Request Message) o Document: - Payment Receipt 7. The Buyer checks the Payment Response Message and finds it OK. As a result generates a Delivery Request Document and sends it to the Supplier to request delivery of the goods. B --> S Request Message (Delivery Request): o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Supplier Order Processing) - Intent (Make Delivery) - Message Manifest - Authorization Data Payment Handler Data ref to Signature6 ref to Payment Receipt o Message Routing Info o Signatures - Signature6 (copied from Payment Response Message) o Documents - Payment Receipt 8. The Supplier checks the Delivery Request including the Authorization Data to check that payment has been made. Checks that delivery is possible and therefore generates a Delivery Response that confirms how delivery will occur, digitally signs the information and sends the message back to the Buyer. B <-- S Response Message (Delivery Response): o Message Header David Burdett [Page 52]
Internet Draft XMLMSG/1.0 January 2000 - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Supplier) - To (Buyer) - Service Type (Supplier Order Processing) - Intent (Make Delivery) - Message Manifest - Status Data (Delivery Response) o Message Routing Info o Signatures - Signature7, signs: Message Header Delivery Response Signatures6 (on the Delivery Request Message) o Documents - Delivery Response 9. The Buyer checks the Delivery Response Message and finds it OK then logs the information and waits for the physical Delivery of the goods. Figure 5 Multiple Document Exchange Transaction [Note] In the example above, signatures are used, to help provide the audit trail and so that one Party, e.g. the Payment Handler, can check the validity of the Payment Request Message. Alternative approaches that avoid the need for signatures are possible. For example: o the Buyer and Seller use a secure Transport Mechanism such as [HTTPS] to set up a secure channel between them o the Seller authenticates the Buyer (perhaps using a User/Server Authentication Transaction) o the first two Document Exchanges occur over the secure channel. [Note End] 7.2.5 Relating Two Transactions XML Messaging allows two or more transactions to be linked together. This example shows how a purchase transaction can be linked to an earlier contract negotiation transaction. The first example is the contract negotiation transaction. Note that this also illustrates a Multiple Round Trip Document Exchange. Buyer | Supplier STEP | | 1. Buyer generates a draft contract places it in an XML Message together with a Message Header and sends it to the Supplier. David Burdett [Page 53]
Internet Draft XMLMSG/1.0 January 2000 B --> S Request Message: o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Contract Processing) - Intent (New Draft Contract) - Message Manifest o Message Routing Info o Document - Draft Contract 2. The Supplier reviews the Contract, makes revisions and places the revised contract in an Exchange Message and sends it back to the Buyer B <-- S Exchange Message: o Message Header: - Message Type (Exchange) - Transaction Identity Data - Message Identity Data - From (Supplier) - To (Buyer) - Service Type (Contract Processing) - Intent (Contract Amendment) - Message Manifest o Message Routing Info o Document - Revised Contract 3. The Buyer reviews the revised contract, amends it and places it in an XML Message together with a Message Header and sends it to the Supplier. B --> S Exchange Message: o Message Header - Message Type (Exchange) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Contract Processing) - Intent (Contract Amendment) - Message Manifest o Message Routing Info o Document - Revised Contract N-1. The Supplier and Buyer keep on swapping drafts of the contract in Exchange Messages until eventually they agree David Burdett [Page 54]
Internet Draft XMLMSG/1.0 January 2000 and the Supplier sends the final version of the contract, digitally signed, back to the Buyer in a Response Message. B <-- S Response Message: o Message Header: - Message Type (Response) - Transaction Identity Data - Message Identity Data - From (Supplier) - To (Buyer) - Service Type (Contract Processing) - Intent (Final Contract) - Message Manifest - Status Data o Message Routing Info o Signatures - Signature1, signs: Message Header Final Contract o Document - Final Contract N. The Buyer carries out a final check on the contract and stores it for later use. Some time later, the Buyer wants to make a purchase under the terms of the agreed contract. Now suppose that the contract negotiation transaction had an identifier of "ACV-CN-1999/2456@example.com". Then the Purchase Transaction could refer to the Contract Negotiation by referring to the identifier in the Transaction Identity Data of the Purchase Transaction. For example: Buyer | Supplier STEP | | 1. Buyer generates a Purchase Order places it in an XML Message. The Transaction Identity Data refers to the earlier Contract Negotiation transaction. B --> S Request Message (Purchase Order): o Message Header - Message Type (Request) - Transaction Identity Data - Message Identity Data - From (Buyer) - To (Supplier) - Service Type (Supplier Order Processing) - Intent (New Purchase Order) - Message Manifest - Related Transaction Data (refers to "ACV-CN-1999/2456@example.com") o Message Routing Info o Signatures David Burdett [Page 55]
Internet Draft XMLMSG/1.0 January 2000 - Signature1, signs Message Header Purchase Order o Document - Purchase Order 2. Purchase continues ... [Note] Note that the digital signature is being used by the Buyer to bind the Purchase Order to the earlier contract negotiation. [Note End] David Burdett [Page 56]
Internet Draft XMLMSG/1.0 January 2000 8. References This section contains references to related documents identified in this specification. [Base64] Base64 Content-Transfer-Encoding. A method of transporting binary data defined by MIME. See: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N. Borenstein. November 1996. [DOM-HASH] A method for generating hashes of all or part of an XML tree based on the DOM of that tree. See http://www.ietf.org/internet-drafts/draft-ietf-trade- hiroshi-dom-hash-*.txt. [DUNS] The Data Universal Numbering System, the D&B D-U-N-S Number, is a unique nine-digit code that helps identify and link more than 57 million companies worldwide. See http://www.dnb.com/dunsno/list.htm. [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee. January 1997. [HTTPS] Hyper Text Transfer Protocol (secure) transported using The TLS Protocol (see RFC 2246, T. Dierks & C Allen. January 1999. [IOTP] The Internet Open Trading Protocol, David Burdett et al. See RFCxxx. This document is currently in the RFC editor queue. Also see http://www.ietf.org/internet- drafts/draft-ietf-trade-iotp-v1.0-protocol-07.txt. [MIME] Multipurpose Internet Mail Extensions. See RFC822, RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. [MONDEX] A proprietary electronic cash product where cash is stored on a smart card. See http:/www.mondex.com/ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SET] Secure Electronic Transaction. See http://www.setco.org [SMTP] Simple Mail Transfer Protocol, RFC 821, J. Postel, August 1982 [SSL/TLS] SSL is a standard developed by Netscape for encrypting David Burdett [Page 57]
Internet Draft XMLMSG/1.0 January 2000 data over IP networks. See http://home.netscape.com/eng/ssl3/index.html. TLS is the likely successor to SSL being developed by the IETF. See http://www.ietf.org/internet-drafts/draft- ietf-tls-protocol-05.txt [URI] Uniform Resource Identifiers (URI): Generic Syntax. T Berners-Lee, R. Fielding, L. Masinter. IETF RFC 2396. [URL] Universal Resource Locator (URL). R Fielding, IETF RFC 1808 [XDSL] The W3C Schema language specification. See http://www.w3.org/TR/xmlschema-1/ [XML Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- xml-names" [XML.org] A repository designed to hold definitions of XML Documents. See http://www.xml.org. [XML] Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version. [XMLDSIG] XML Signature Core Syntax and Processing. Specifies XML digital signature processing rules and syntax. A W3C Working Draft. See http://www.w3.org/TR/xmldsig-core/. [XMLMSG-CDE] Common Document Exchanges. Defines a number of Common Document Exchanges that are generally applicable to many situations. [XMLMSG-CME] XML Messaging - Common XML Message Elements. Contains definitions of elements and attributes used to construct messages that conform to XML Messaging. To be completed. [XMLMSG-DCD] Document Choreography Definitions. Describes how the sequence in which documents are exchanged may be defined, agreed between the parties involved and then used dynamically to determine the way in which a particular type of business service or process is carried out. [XMLMSG-DET] Document Exchanges and Transactions. Defines standard templates for exchanging documents between parties that can be used to implement transactions that support different types of services and processes. To be completed. [XMLMSG-RM] Reliable Messaging. Defines how to exchange messages in a way that is reliable, robust and resilient and David Burdett [Page 58]
Internet Draft XMLMSG/1.0 January 2000 results in "guaranteed once-only" message delivery. [XMLMSG-SM] Secure Messaging. Describes how digital signatures and other methods such as [SSL] may be used to ensure the tamper resistance and authenticated exchange of messages. David Burdett [Page 59]
Internet Draft XMLMSG/1.0 January 2000 9. Author's Address The author of this document is: David Burdett Commerce One 1600 Riviera Ave, Suite 200 Walnut Creek California 94596 USA Tel: +1 (925) 941 4422 or +1 (650) 623 2888 Email: david.burdett@commerceone.com The author would also like to acknowledge everyone who worked on the development and implementation of [IOTP] on which many of the ideas in this specification are based and the numerous individuals who have reviewed earlier versions of this document and provided their most helpful comments. File Name: draft-ietf-trade-xmlmsg-requirements-00.txt David Burdett [Page 60]
