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]