idnits 2.17.1 draft-ietf-trade-xmlmsg-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 60 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 60 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2000) is 8867 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SSL' is mentioned on line 2818, but not defined == Missing Reference: 'Note' is mentioned on line 2704, but not defined == Missing Reference: 'Mondex' is mentioned on line 790, but not defined == Missing Reference: 'BASE64' is mentioned on line 1262, but not defined == Unused Reference: 'MONDEX' is defined on line 2749, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 2752, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 2767, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DOM-HASH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DUNS' ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2246 (ref. 'HTTPS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'IOTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MONDEX' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 1808 (ref. 'URL') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XDSL' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-CDE' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-CME' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-DCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-DET' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-RM' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLMSG-SM' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Commerce One 2 draft-ietf-trade-xmlmsg-requirements-00.txt January 2000 3 Expires: July 2000 David Burdett 5 Requirements for XML Messaging 6 Version 1.0 Release 00 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this document is unlimited. Please send comments to 30 the TRADE working group at , which may 31 be joined by sending a message with subject "subscribe" to . 34 Discussions of the TRADE working group are archived at 35 http://www.elistx.com/archives/ietf-trade. 37 Abstract 39 This specification contains requirements for a generic approach to 40 the reliable, resilient, secure, tamper resistant, authenticated 41 exchange of XML or other electronic documents over insecure transport 42 mechanisms. 44 The specification provides the requirements and framework for a set 45 of related specifications on XML Messaging covering: 46 o Requirements for XML Messaging (this paper) 47 o Common XML Message Elements 48 o Document Exchange and Transactions 49 o Reliable Messaging 50 o Secure Messaging 51 o Document Choreography Definitions 52 o Common Document Exchanges 53 o Transport Protocol Supplements 55 Although much work has been carried out on the other parts of the XML 56 Messaging specification described above, they are sill in development 58 Table of Contents 60 Status of this Memo ................................................1 62 Abstract ...........................................................1 64 1. Background .....................................................5 65 1.1 Structure ...................................................6 66 1.2 History .....................................................7 67 1.3 Objectives of Document ......................................7 68 1.4 Principles and Assumptions ..................................7 69 1.5 Document Structure ..........................................7 70 1.6 Terminology .................................................8 72 2. XML Messaging Definitions and Terminology ......................9 73 2.1 Documents, Parties, Messages and Document Exchanges .........9 74 2.1.1 Overview ..............................................9 75 2.1.2 A Document ...........................................10 76 2.1.3 Party ................................................10 77 2.1.4 From, To and Authorizing Parties .....................10 78 2.1.5 Message ..............................................12 79 2.1.6 Message Header .......................................12 80 2.1.7 Message Routing Information ..........................13 81 2.1.8 Digital Signature ....................................14 82 2.1.9 Message Envelope .....................................15 83 2.1.10 Request Message ......................................15 84 2.1.11 Response Message .....................................15 85 2.1.12 One Way Message ......................................16 86 2.1.13 Document Exchange ....................................16 87 2.1.14 Simple Document Exchange .............................16 88 2.1.15 Multiple Round Trip Document Exchange ................17 89 2.1.16 Exchange Message .....................................17 90 2.1.17 Acknowledgement Message ..............................18 91 2.1.18 Error Message ........................................18 92 2.2 Services, Service Types and Transactions ...................19 93 2.2.1 Overview .............................................19 94 2.2.2 Service and Service Type .............................19 95 2.2.3 Sub-Service ..........................................20 96 2.2.4 Document Choreography ................................21 97 2.2.5 Transaction ..........................................21 98 2.3 Lower Level Data Definitions ...............................22 99 2.3.1 Overview .............................................22 100 2.3.2 Transaction Identity Data ............................22 101 2.3.3 Message Identity Data ................................22 102 2.3.4 Message Manifest .....................................23 103 2.3.5 Related Transaction Data .............................23 104 2.3.6 Organization Data ....................................24 105 2.3.7 Action Data ..........................................24 106 2.3.8 Status Data ..........................................25 107 2.3.9 Error Data ...........................................25 108 2.3.10 Cancel Data ..........................................25 109 2.4 Miscellaneous Definitions ..................................26 110 2.4.1 Document Encoding ....................................26 111 2.4.2 Audit Trail ..........................................26 112 2.4.3 Transport Mechanism ..................................27 113 2.4.4 Identical Elements ...................................27 115 3. Standard Transactions .........................................28 116 3.1 Service Availability Inquiry ...............................28 117 3.2 Transaction Status Inquiry .................................29 118 3.3 User/Server Authentication .................................29 119 3.4 Quality of Service Negotiation .............................30 121 4. Restart, Recovery and Idempotency .............................31 122 4.1 Idempotency ................................................31 123 4.2 Recovering from failed Message delivery ....................31 125 5. Security Considerations .......................................34 126 5.1 Digital Signatures .........................................34 127 5.1.1 Determining whether to use digital signatures ........34 128 5.1.2 Reasons for using Digital Signatures .................35 129 5.1.3 Reasons to not use Signatures ........................36 130 5.2 Message Authenticity .......................................36 131 5.3 Data Privacy ...............................................37 133 6. XML Messaging Compliance Levels ...............................38 134 6.1 Data Element Compliance ....................................38 135 6.2 Message Level Compliance ...................................38 136 6.3 Document Exchange and Transaction Level Compliance .........38 137 6.4 Reliable Messaging Compliance ..............................39 138 6.5 Secure Messaging Compliance ................................39 139 6.6 Document Choreography Compliance ...........................39 140 6.7 Transport Protocol Supplement Compliance ...................40 141 6.8 Common Document Exchange and Transaction Compliance ........40 143 7. XML Messaging Examples ........................................41 144 7.1 XML Message Structure ......................................41 145 7.2 XML Messaging Examples .....................................43 146 7.2.1 Simple Document Exchange .............................43 147 7.2.2 Simple Document Exchange with Errors .................45 148 7.2.3 Canceling a Transaction ..............................47 149 7.2.4 Transaction with Multiple Document Exchanges .........48 150 7.2.5 Relating Two Transactions ............................53 152 8. References ....................................................57 154 9. Author's Address ..............................................60 156 Table of Figures 158 Figure 1 XML Messaging, Message Structure 42 159 Figure 2 Simple Document Exchange Message Flow 44 160 Figure 3 Document Exchange with Request Message Errors 46 161 Figure 4 Document Exchange with Response Message Errors 47 162 Figure 5 Multiple Document Exchange Transaction 53 164 1. Background 166 Many Internet protocols consist of an exchange of documents over the 167 Internet, for example sending a Purchase Order and receiving a 168 Purchase Order Acknowledgement in return. 170 Many of these protocols use or plan to use XML to represent those 171 documents. However irrespective of the way in which documents are 172 represented, there are common requirements that are independent of 173 the purpose of the protocols, the information they are carrying or 174 the processes that create or accept those documents. 176 The XML Messaging specification provides a generic approach to the 177 reliable, resilient, secure, tamper resistant, authenticated exchange 178 of XML or other electronic documents over insecure, unreliable 179 transport mechanisms. More specifically it provides, a series related 180 specifications that cover: 182 o wrapping a document 184 o identifying a document 186 o describing the processing of a document 188 o reporting errors in a document 190 o digitally signing documents to provide tamper resistance and 191 security 193 o exchanging a series of documents to carry out a process or service 195 o authenticating a document so that the intended recipient knows: 196 - who sent and/or authorized the document, and therefore that 197 - the document should be processed and a response returned 199 o providing a record of the success or failure of a process/service 201 o securely relating a series of sub-services together to create a 202 larger, more complex service where the start of one sub-service is 203 dependent on the authorized, successful completion of another 205 o providing an audit-trail of the execution of a set of services that 206 can be used after the event as evidence that those services were 207 carried out 209 o inquiring on the success or failure of a service initiated by 210 sending a document 212 o determining if a failed service can be restarted and then restarting 213 it where possible 215 o detecting whether or not a system or server is up-and-running and 216 able to accept documents 218 o authenticating a user or server that is providing a service. 220 1.1 Structure 222 This specification is one of a set of related specifications on XML 223 Messaging covering: 225 o Requirements for XML Messaging (this paper) 227 o Common XML Message Elements [XMLMSG-CME]. This defines the XML 228 elements and attributes used to construct Messages that conform to 229 XML Messaging 231 o Document Exchanges and Transactions [XMLMSG-DET]. This defines 232 standard templates for exchanging documents between parties that can 233 be used to implement transactions that support different types of 234 services and processes. 236 o Reliable Messaging [XMLMSG-RM]. This defines how to exchange 237 messages in a way that is reliable, robust and resilient and results 238 in "guaranteed once-only" message delivery 240 o Secure Messaging [XMLMSG-SM]. This describes how digital signatures 241 and other methods such as [SSL] may be used to ensure the tamper 242 resistance and authenticated exchange of messages 244 o Document Choreography Definitions [XMLMSG-DCD]. This describes how 245 the sequence in which documents are exchanged may be defined, agreed 246 between the parties involved and then used dynamically to determine 247 the way in which a particular type of business service or process is 248 carried out 250 o Common Document Exchanges [XMLMSG-CDE]. This defines a number of 251 Common Document Exchanges that are generally applicable to many 252 situations 254 o Transport Protocol Supplements. These are a set of specifications 255 that describe how Messages that conform to XML Messaging 256 specifications are transported over a various transport protocols 257 such as [HTTP], [SMTP], etc. 259 A compliant XML Messaging specification does not need to implement 260 all the specifications highlighted above. An explanation of the how 261 these relate is contained in section 6 XML Messaging Compliance 262 Levels. 264 Currently only this document is fully defined and published. 266 1.2 History 268 The ideas in this specification are largely based on the ideas 269 contained within the Internet Open Trading Protocol [IOTP]. IOTP 270 development started in early 1998 and is available as an 271 Informational RFC (currently in RFC Editor Queue) from the IETF. 272 Several implementations of IOTP have been developed. 274 1.3 Objectives of Document 276 The objectives of this document are to: 278 o define the terminology used by XML Messaging, and 280 o provide the reader with an overall understanding of XML Messaging so 281 that they can better understand the relationships between this and 282 the other XML Messaging Specifications identified above 284 o highlight the requirements that other XML Messaging specifications 285 must cover. 287 It is recommended that this specification is read first. 289 1.4 Principles and Assumptions 291 The following principles and assumptions have been applied in 292 developing this specification: 294 o [XML] will be used to define any data required to support XML 295 Messaging 297 o XML Messaging shall support the exchanging of documents in any 298 digital format 300 o the data used by XML Messaging will be defined using: 301 - the W3C XML Schema language [XDSL], and 302 - an [XML] Data Type Definition (DTD) 304 o Schema and DTD definitions will be placed in a repository such as 305 those being developed by [XML.org]. 307 1.5 Document Structure 309 This document contains the following sections: 311 o XML Messaging Definitions and Terminology. This defines the 312 terminology used by XML Messaging 314 o Standard Transactions. This describes four standard Transactions 315 that are built using XML messaging that are generally applicable: 316 - Service Availability Inquiry 317 - Transaction Status Inquiry 318 - Quality of Service Negotiation 319 - User/Server Authentication 321 o Restart, Recovery and Idempotency. This describes how XML Messaging 322 can be used to ensure the completion of a transaction and provide 323 guaranteed once-only delivery 325 o Security Considerations. This describes some of the considerations 326 around whether or not digital signatures should be used with XML 327 Messaging 329 o XML Messaging Compliance Levels. Compliance with XML Messaging 330 levels. This describes how the different parts of the XML Messaging 331 specification may be used in combination to meet different needs. 333 o XML Messaging Examples. This illustrates the structure of a 334 "Message" and illustrates its use with five example message flows 336 o References. This lists the other documents and standards used by XML 337 Messaging 339 [Note] In several part of the specification "notes" such as this 340 are placed to provide additional background, advice or 341 guidance as an aid to understanding. They are non-normative 342 parts of this specification. 343 [Note End] 345 1.6 Terminology 347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 349 document are to be interpreted as described in RFC2119. 351 2. XML Messaging Definitions and Terminology 353 This section defines the main terminology used by XML Messaging. It 354 is divided into four parts: 356 o Documents, Parties, Messages and Document Exchanges 358 o Services and Transactions, 360 o Lower Level Data Definitions that are used by the above, and 362 o Miscellaneous Definitions that don't fall into any of the above 363 categories. 365 [Note] Definitions of words or phrases in this section that start 366 with a capital letter (for example Document Exchange) cab 367 usually be found defined elsewhere within this section. 368 [Note End] 370 2.1 Documents, Parties, Messages and Document Exchanges 372 2.1.1 Overview 374 This section describes how Parties, such as buyers and suppliers, 375 customers and merchants, can exchange Documents contained in Messages 376 in order to execute Services. 378 All the Documents and other data in a Message are contained within an 379 outermost Message Envelope. 381 A Message can optionally include a Digital Signature so that: 383 o the identity of the party sending the message can be authenticated 385 o any changes to the message can be detected. 387 Services are requested by sending one or more Documents in a Request 388 Message to a Party who then: 390 o processes the Request Message by carrying out a Service and 392 o generates a Response Message to indicate the result. 394 At a minimum a Document Exchange consists of a Request Message and a 395 Response Message although there might be additional Exchange Messages 396 between the Request and the Response Message. 398 Documents may also be sent as in a One Way message. In this case no 399 business or application level response is provided. 401 The receipt of a Message may be acknowledged by sending a Message 402 Acknowledgement back to the sender of the Message. 404 Error Messages are used to report permanent or transient problems or 405 errors in a Message. 407 More detail is provided below. 409 2.1.2 A Document 411 A Document is any data that can be represented in a digital form. 413 Examples of Documents include: 415 o a set of XML Elements 417 o an XML Document 419 o an HTML Document 421 o a word processing file 423 o a Adobe Acrobat PDF file 425 o a binary file. 427 2.1.3 Party 429 A Party is a company, organization, individual or other entity that 430 can generate, receive or authorize Documents and their associated 431 Messages. 433 Examples of a Party include: 435 o a Merchant 437 o a Customer 439 o a Lawyer 441 o a Bank 443 A Party is also used to refer to systems or servers that are carrying 444 out Services or other processes on behalf of a Party. 446 2.1.4 From, To and Authorizing Parties 448 FROM AND TO PARTIES 450 A Party that sends a Message is the "From" Party. A Party that is the 451 intended recipient of a Message is the "To" Party. Every Message MUST 452 identify the "From" and the "To" Parties although Parties MAY 453 identify themselves as anonymous. 455 Examples of a "From" Party include: 457 o a buyer that sends a Purchase Order to a supplier 459 o a supplier that sends an Invoice to a buyer. 461 Examples of a "To" Party include: 463 o the customer that receives a bank statement from their bank 465 o the travel agent that receives a booking for a flight 467 ANONYMOUS PARTIES 469 Anonymous parties MAY be used where the identity of the sender of a 470 message is not required for the service associated with the message 471 to be carried out. Examples of anonymous parties include: 473 o an individual that is querying availability of seats on a flight 475 o a company that is searching for the list prices of a product from a 476 number of suppliers. 478 AUTHORIZING PARTIES 480 Messages MAY also contain one or more Authorizing Parties. The 481 Authorizing Parties are Parties that authorize the "To" Party to act 482 upon the Message that is received. 484 The Authorizing Party will frequently be the "From" party but this 485 MAY NOT always be the case. If no Authorizing Parties are present in 486 a Message then the "From" party is the Authorizing Party. 488 Examples of document exchanges where more than the "From" party are 489 required to authorize an action include: 491 o a payment request a consumer makes to a bank to get a refund on a 492 credit card payment. The authorizing parties are: 493 - the consumer that is requesting the refund, and 494 - the merchant that is instructing the bank to make the refund 496 o a transport firm that is being requested by a company to deliver 497 goods that have been ordered from a supplier and payment made to a 498 bank. The authorizing parties are: 499 - the company that is requesting the delivery 500 - the bank that authorizes that payment had been made 501 - the supplier that specifies what goods should be delivered 503 [Note] In the above examples, the consumer/company is sending a 504 message to one party to ask them to carry out a service on 505 behalf of another party where the information that is being 506 sent is being passed through the consumer/company. 507 Frequently Digital Signatures may be used to protect the 508 information. See section 7.2.4, Transaction with Multiple 509 Document Exchanges for an example of this can be used. 510 [Note End] 512 2.1.5 Message 514 A Message is data that is sent from one Party to another. A Message 515 MUST consist of: 517 o a Message Header 519 o Message Routing Information 521 o zero or more Digital Signatures, and 523 o zero or more Documents 525 All the data in a Message is contained within a Message Envelope. 527 Examples of a Message include: 529 o a Purchase Order that is sent by a buyer to a supplier 531 o an Invoice that is sent by the supplier back to the buyer 533 o a request to make a payment of $50 sent to a Credit Card acquirer 535 o the authorization received from a Credit Card acquirer as a result 536 of making a payment 538 o Status Data indicating the success or failure of a Service 540 o a multiple document message, e.g. 541 - a design specification for a product including the Microsoft Word 542 document and several JPEG files that illustrate the product's 543 appearance 544 - a batch of Purchase Orders that are being sent at the same time to 545 the same destination 547 [Note] A Message need not contain any documents since the Message 548 Header can contain all the data necessary to indicate the 549 purpose of the Message. 550 [Note End] 552 2.1.6 Message Header 554 A Message Header contains the additional data that needs to be 555 associated with a Document so that it can be sent to and successfully 556 processed by a Party. The Message Header MUST contain: 558 o Transaction Identity data to identify the set of Messages that are 559 related to one another through one or more Document Exchanges 561 o Message Identity data to enable the Message to be identified and 562 referenced within the Transaction 564 o Organization Data that describes: 565 - who the Message is From 566 - who the Message is sent To 568 o Action Data to indicate the type of Service that is being sent the 569 message and the intention behind sending it 571 Depending on the purpose of the message, a Message Header MAY also 572 contain: 574 o Status Data that describes the results of carrying out a Service. 576 o a Message Manifest to identify the documents, other than the Message 577 Header and Message Routing Information, that are contained within 578 the same Message Envelope 580 o Related Transaction Data that identifies other Transactions to which 581 this Transaction is related 583 2.1.7 Message Routing Information 585 The Action Data and Organization Data together identify, logically, 586 the Sender and Recipient of the Message, the type of Service that 587 should process it and the intention behind sending the message. 589 This information is used to determine the [URL] to which the Message 590 should be physically sent. The rules used to determine the URL that 591 is used for this purpose SHALL NOT form part of this specification. 593 The resultant URL MUST then be placed inside the Message Routing 594 Information prior to sending the message to the URL that was 595 determined. 597 The URL to which the Message is sent may not be the final destination 598 of the Message and may be some "hub" process that forwards the 599 Message to yet another location. Each "hop" along the chain of 600 destinations results in another entry in the Message Routing 601 Information. 603 The Message Routing Information may be digitally signed so that the 604 intent of sending the message at the time and in the manner indicated 605 can be authenticated. 607 [Note] Message Routing Information is held separately from other 608 Documents in the Message, such as the Message Header, 609 since: 611 o it would break any digital signature on those documents 612 as Message Routing Information is extended each time the 613 Message is forwarded to a new URL 614 o it makes it easier to separate the processing logic that 615 determines the logical destination (e.g. the business 616 application) from the physical destination. As a result 617 business applications need not be aware of changes to 618 network designs that result in changes to URLs that to 619 which Messages are sent, 620 o if a particular URL is not accepting Messages for some 621 reason, then an alternative URL may be used without 622 invalidating any signatures (see section 4. Restart, 623 Recovery and Idempotency) 625 The Message Routing Information may also be extended when a 626 Message is routed beyond its apparent ultimate destination 627 by processes that are not made publicly available. 628 [Note End] 630 2.1.8 Digital Signature 632 A Digital Signature is a cryptographic signature over data contained 633 in a Message, or elsewhere that are addressable via [URI]s, that may 634 permit: 635 - the identity of the sender of the message to be authenticated, and 636 - enables changes in the signed data to be detected 638 The XML Messaging specifications SHALL NOT specify any of the trust 639 relationships or certificate authority issues associated with Digital 640 Signatures. This is the responsibility of the designers of systems 641 that use XML Messaging. 643 Use of Digital Signatures by XML Messaging is OPTIONAL. 645 Digital Signatures within XML Messaging are implemented using the 646 IETF/W3C Digital Signature standard [XMLDSIG]. 648 Examples of the use of Digital Signatures include: 650 o demonstrating that a Request Message to initiate a Service is 651 authorized 653 o proving the authenticity and validity of an assertion contained in a 654 document. For example, "these goods are guaranteed against defect 655 for one year" 657 [Note] Signatures are optional since: 658 o some Messages may not need any security 659 o some Documents might contain their own Signatures that 660 make the need for Signatures at the Message level 661 unnecessary 663 Signatures are not contained in the Message Header since: 665 o implementations of XML Messaging may require that 666 Signatures sign the Message Header 667 o it makes it easier for Documents to make use of message- 668 level signatures without understanding the structure of a 669 Message Header 670 [Note End] 672 2.1.9 Message Envelope 674 A Message Envelope is the outermost container for a Message. It MUST 675 be either: 677 o an XML Document with pre-defined XML tags, or 679 o a multi-part MIME message 681 2.1.10 Request Message 683 A Request Message is a Message sent from one Party to a second Party 684 with the intent that the second Party act upon the data in the 685 Request Message by carrying out a Service. 687 A Request Message MAY also contain: 689 o Status Data that describes the end process state of earlier Document 690 Exchanges on which start of the Service being requested may depend 692 Examples of a Request Messages include: 694 o requesting the processing of a new purchase order 696 o requesting that a previous purchase order is changed 698 o requesting a refund of a payment as a result of a problem 700 o requesting the review of a legal document 702 o requesting information on the services a business provides. 704 2.1.11 Response Message 706 A Response Message is a Message that is generated by the Party that 707 received a Request Message. It is produced as a result of carrying 708 out the requested Service. It is the last Message in a Document 709 Exchange unless the Message contains errors. 711 Response Messages are sent back to the sender of the Request Message. 713 A Response Message MUST contain: 715 o a Reference to the immediately preceding Message (e.g. a Request 716 Message) that the Response Message is responding to, and 718 o Status Data that describes the end process state of the Document 719 Exchange. 721 Examples of Response Messages include: 723 o an acknowledgement of receipt of a Purchase Order 725 o an Invoice generated as a result of processing a Purchase Order 727 o a receipt for a payment that was made 729 o an opinion on a legal document that was received 731 o a description of the services provided by a business 733 [Note] There is a distinction between a Response Message and an 734 Error Message (see section 2.1.18) below. 735 [Note End] 737 2.1.12 One Way Message 739 A One Way Message is a Message sent from one Party to another where a 740 business level or application response to the message is not 741 required. 743 Example uses of One Way Messages include: 745 o a newsletter that contains updated information about a company or 746 group 748 o a Request for Quotation (RFQ) for the provision of a service or 749 product 751 2.1.13 Document Exchange 753 A Document Exchange is a generic term for either a Simple Document 754 Exchange or a Multiple Round Trip Document Exchange. 756 2.1.14 Simple Document Exchange 758 A Simple Document Exchange consists of: 760 o a Request Message sent from one party to a second party, and 762 o the Response Message that is returned as a result. 764 Examples of instances of a Simple Document Exchange include: 766 o a Purchase Order sent by a buyer to a seller and the acknowledgement 767 from the seller of its receipt 769 o a Purchase Order sent by a buyer to a seller and the Invoice that is 770 sent back as a result of fulfilling the order 772 o sending a document for review by a lawyer followed by the legal 773 opinion that is sent back as a result 775 2.1.15 Multiple Round Trip Document Exchange 777 A Multiple Round Trip Document Exchange consists of: 779 o a Request Message sent from one party to a second party, followed by 781 o a series of Exchange Messages that are exchanged between the two 782 parties until finally 784 o the second party generates and sends a Response Message back to the 785 first party. 787 Examples of Multiple Round Trip Document Exchanges include: 789 o the exchange of messages required to make a payment using payment 790 method protocols such as [SET] or [Mondex] 792 o the exchange of messages required to negotiate an agreement on terms 793 and conditions 795 o the exchange of messages required to send a large document between 796 two locations in several smaller parts. 798 2.1.16 Exchange Message 800 An Exchange Message is a Message that is sent between one Party and 801 another after the sending of the initial Request Message and before 802 the sending of the final Response Message. 804 An Exchange Message MUST also contain a Reference to the immediately 805 preceding Message that the caused the Exchange Message to be 806 generated. 808 Examples of Exchange Messages include: 810 o intermediate messages that are part of a Payment Protocol 812 o a counter offer to an offer made as part of a negotiation. 814 2.1.17 Acknowledgement Message 816 The sender of any Message, apart from an Acknowledgement Message, MAY 817 request that receipt of the Message be acknowledged by recipient 818 sending an Acknowledgement Message back to the Party that sent the 819 original Message. 821 The purpose of an Acknowledgment Message is to provide positive 822 confirmation that a Message has been received. 824 Acknowledgement Messages should be sent immediately upon receipt of 825 the Message before the Message is processed and before any business 826 or application level response (i.e. a Response Message or Exchange 827 Message) is sent. 829 Acknowledgement Messages may be digitally signed to help prove their 830 authenticity. 832 [Note] Acknowledgement Messages are particularly useful in an 833 asynchronous exchange of Messages where there may be 834 extended periods of time between the receipt of a Message 835 and the generation of another business or application level 836 Message in response. 837 [Note End] 839 2.1.18 Error Message 841 An Error Message is a Message that reports on a problem in an earlier 842 Message that prevents the earlier Message from being processed in a 843 normal way. 845 An Error Message MUST also contain Error Data to describe the problem 846 that has been found. 848 Examples of an Error Message include: 850 o an Error Message reporting that an XML document was invalid or did 851 not conform to its XML schema 853 o an Error Message reporting a Transient Error that the Server 854 processing a Message is busy and therefore the original Message 855 should be resent at a later point in time. 857 [Note] Error Messages report abnormal conditions which will 858 require some type of unusual handling that might (or might 859 not) permit recovery from the error. This is distinct from 860 a Response Message that is used when a process completes 861 normally. 863 However even though a process completes "normally" it might 864 not be successful. For example, if a Purchase Order is sent 865 to a supplier, the goods requested might be "out of stock". 867 This means that the request failed although the request was 868 not in error and no Error Message should be produced. 869 [Note End] 871 2.2 Services, Service Types and Transactions 873 2.2.1 Overview 875 A Service is the implementation, by a Party, of a set of processes 876 that conform to a particular Service Type. 878 Each Service Type has associated with it a set of Document types that 879 it can accept as input and a set of Document types that it can 880 produce as output. 882 The same Document type may be sent with different intentions. For 883 example a purchase order might be either sent as either a "new" 884 purchase order or as a "change" purchase order. 886 Sending a Document to a Service with a particular intention will 887 result in an Document Exchange where documents are swapped in a 888 sequence defined according to the rules defined in a Document 889 Choreography. 891 The Document Choreographies and One Way Messages associated with a 892 Service Type fully define that type of Service's interactions with 893 the outside world. 895 The definition of a Service Type may also make use of Sub Services to 896 implements it's functionality. Each Sub-Service is a Service in its 897 own right. So, at the lowest level, all definitions of a Service Type 898 consist of Document Exchanges. 900 The preceding description describes terms that define the rules 901 associated with the sending or receiving of documents by a Service. 902 The actual sending of real documents are called Transactions. 904 More detail is provided below. 906 2.2.2 Service and Service Type 908 A Service is carried out by a Party as a result of receiving a 909 Request Message containing Documents sent with a particular 910 intention. 912 The behavior of a Service in terms of the Documents it can accept or 913 generate is defined by its Service Type. 915 Service Types may be defined by and be proprietary to an individual 916 Party. However it is more likely that "standard" Service Types will 917 be defined to meet common requirements, for example, to submit a new 918 Purchase Order or to make a payment. 920 Examples of Service Types include descriptions of: 922 o a Purchasing Service that enables a customer to purchase goods on- 923 line 925 o an Order Processing Service that processes an Order and generates a 926 response as a result 928 o a Payment Service that accepts a payment and provides a receipt 930 o a Fulfillment service that fulfills an order at the request of a 931 Merchant. 933 2.2.3 Sub-Service 935 A Sub-Service is a Service that is executed at the request of and as 936 part of another Service. 938 Examples of Sub-Services include: 940 o a payment service that occurs as part of a purchase 942 o a tax calculation service that calculates the tax due as part of an 943 order processing service. 945 The Sub-Services in a Service will have dependencies between them. 946 These dependencies MAY be: 948 o Serial. One Sub-Service MUST start only after the completion of 949 another Sub-Service 951 o Alternative. One Sub-Service MAY be executed as an alternative to 952 another 954 o Iterative Loop. A Sub-Service MAY be repeated a variable number of 955 times 957 o Conditional. The execution of a Sub-Service is conditional on the 958 state of another Service. This may be used in conjunction with 959 Serial, Alternative and Iterative Loop dependencies. 961 o Parallel. A Sub-Service MAY execute in Parallel with another Service 963 o Concurrent. A Sub-Service MUST Execute at the same time as another 964 Sub-Service. 966 An example of a simple Service with Sub-Services is a Purchase 967 Service that consists of three Sub-Services: 969 o an Offer Service that conveys an Offer for sale of goods. This Sub- 970 Service has no dependencies and therefore starts first 972 o a Payment Service that carries out the Payment which has a Serial 973 dependency on the Offer Service 975 o a Delivery Service that delivers the Digital Goods, that has a 976 Serial dependency on the Payment Service 978 2.2.4 Document Choreography 980 A Document Choreography is a description of the dependencies that 981 control the sequence and choices in which Documents may be exchanged 982 within a Document Exchange. 984 Document Choreographies MUST be either: 986 o Explicit, in that the Document Choreography is contained as data in 987 one of the Messages in a Transaction, or 989 o Implicit, in that the Document Choreography is defined in some other 990 document or specification, for example a protocol specification. 992 An example of a Document Choreography would be a new Purchase Order 993 document choreography where: 995 o a new Purchase Order is sent to a supplier, then 997 o one of the following documents is returned as a result: 998 - a Purchase Order Acknowledgement to indicate that the document has 999 been received and is being processed, or 1000 - an Error Document to indicate there was a technical error in the 1001 Purchase Order, or 1002 - a Cancel Document to indicate that the Purchase Order will not be 1003 processed. 1005 2.2.5 Transaction 1007 A Transaction is an instance of the execution of a Service with a 1008 particular intention. 1010 Examples of a Transaction include: 1012 o a Purchase Transaction that buys an Company Report for $20. It 1013 consists of three Sub-Service instances: 1014 - an Offer Service instance to buy the Company Report for $20 1015 - a Payment Service instance that accepts a Payment for $20 using a 1016 credit card, and finally 1017 - a Delivery Service instance that delivers the Company Report as an 1018 HTML web page. 1020 o a Buying Service that consists of the following Sub-Services: 1022 - three Price Negotiation Service instances that negotiate the price 1023 of a Photocopier 1024 - a Purchase Order Service instance that places the order for the 1025 Photocopier. 1027 2.3 Lower Level Data Definitions 1029 2.3.1 Overview 1031 This sub-section contains definitions of the lower level data 1032 elements referenced in the previous two sub-sections. It covers: 1034 o Transaction Identity Data 1036 o Message Identity Data 1038 o Organization Data 1040 o Status Data 1042 o Action Data 1044 o Error Data 1046 o Cancel Data 1048 2.3.2 Transaction Identity Data 1050 Transaction Identity Data uniquely identifies and describes a 1051 Transaction. 1053 Examples of the data contained in Transaction Identity Data include: 1055 o an identifier that globally uniquely identifies the Transaction (a 1056 GUID) 1058 o the version number of XML Messaging that is being used 1060 o the date/time the Transaction started 1062 2.3.3 Message Identity Data 1064 Message Identity Data is data that enables a Message to be uniquely 1065 identified and referenced within a Transaction. 1067 Examples of the data contained in Message Identity Data include: 1069 o a reference that uniquely identifies the Message within a 1070 Transaction 1072 o the date/time the message was created 1074 o the software that generated the Message 1076 2.3.4 Message Manifest 1078 The Message Manifest contains references to the other documents, 1079 apart from the Message Routing Information document, that are 1080 contained within the same Message Envelope. 1082 The purpose of the Message Manifest is to facilitate locating and 1083 validating that all required Documents contained within the Message 1084 Envelope are present. 1086 Examples of the types of documents that might be referenced by a 1087 Message Manifest include: 1089 o a Purchase Order 1091 o a Purchase Order and a picture of the requested goods 1093 o a Purchase Order and a digital signature 1095 [Note] The Message Manifest does not contain a reference to the 1096 Message Routing Information since this information will 1097 typically be added after the rest of the documents 1098 contained in the Message Envelope have been created and 1099 therefore it's reference number will not be known. 1101 The reference cannot be added later if the Message Header 1102 has been digitally signed since it would break the 1103 signature. 1105 Finally, there may be benefit in adopting the Message 1106 Manifest developed by the IETF/W3C digital signature group 1107 [XMLDSIG] as the standard to be used here since essentially 1108 they serve the same purpose. 1109 [Note End] 1111 2.3.5 Related Transaction Data 1113 Related Transaction Data optionally links one Transaction to other 1114 related Transactions. The linkage may be either by: 1116 o specifying the GUID of the other transactions as specified on that 1117 Transactions, Transaction Identity Data or, 1119 o using some other reference, outside the scope of XML Messaging by 1120 which the transaction may be identified 1122 Examples of the use of Related Transaction Data include: 1124 o referring to an earlier transaction where the terms and conditions 1125 associated with the transaction were negotiated 1127 o raising a request to fix a problem associated with some earlier 1128 transaction that had occurred 1130 o making a query on the status of another transaction. 1132 2.3.6 Organization Data 1134 Organization Data is data that describes and identifies a Party. 1136 The purpose of Organization Data is to provide information: 1138 o to enable the identity of the Organization to be determined 1140 o that allows the Organization to be contacted when and if necessary 1142 o to determine who a Message is from and who it is sent to. 1144 Examples of information contained within Organization Data include: 1146 o Name and Address 1148 o Individuals and contacts 1150 o Reference numbers, e.g. [DUNS] numbers 1152 [Note] The amount of information provided in Organization Data can 1153 vary from: 1154 o a simple reference number, through 1155 o a comprehensive address, for example to describe a 1156 Supplier who is selling tangible goods, to 1157 o minimal or none, for example if a Consumer is buying a 1158 page of digital information for 2 cents. 1159 [Note End] 1161 2.3.7 Action Data 1163 Action Data indicates the type of Service that is being sent a 1164 Message and the intention behind sending it. 1166 Examples of information contained within Action Data include: 1168 o the identifier of the Service that should process the Message 1170 o the intention in sending the Message, for example to request a 1171 service 1173 o whether or not the Action is for test purposes only. 1175 2.3.8 Status Data 1177 Status Data provides information on the current state of a 1178 Transaction. It MUST be sufficient, on its own, to indicate success 1179 or failure of the Transaction. 1181 Examples of the information contained within Status Data include: 1183 o a code to indicate success, failure and various other states 1185 o a reference to the Request Message that initiated the Transaction 1187 o a reference to the Organization Data that carried out the Service 1189 [Note] A standard definition of the results of a Transaction 1190 enables that information to be used to authorize the start 1191 of a later Service within a Document Choreography without 1192 providing details of the first Service to the Party that is 1193 carrying out the later Service. 1195 As a result privacy is improved in that a Party is only 1196 provided with the information they need, to carry out a 1197 requested service. 1198 [Note End] 1200 2.3.9 Error Data 1202 Error Data contains data that describes an Error contained in a 1203 Message. It MUST contain: 1205 o a reference to the Message(s) that are in Error 1207 If the error is not a Transient Error then the Error Data MUST also 1208 contain: 1210 o a reference to the part(s) of the Message that are in Error 1212 2.3.10 Cancel Data 1214 Cancel Data sent by one party indicates that to the other Party that 1215 the remainder of the transaction will not be carried out. Cancel Data 1216 MAY be sent: 1218 o by the Party that generated a Request Message to the Party that is 1219 acting on the message - to indicate that the requested action should 1220 not be completed 1222 o by the Party that received a Request Message back to the party that 1223 generated the Request Message to indicate that the Request Message 1224 was unacceptable in some way and therefore no Response Message will 1225 be generated. 1227 [Note] One of the main uses of sending a Message containing Cancel 1228 Data is to prevent the sender of a Request Message going 1229 into "recovery mode" since no Response Message was received 1230 within the expected timeframe (see 4.2 Recovering from 1231 failed Message delivery). 1233 Also note that: 1234 o sending a Message containing Cancel Data will fail if the 1235 Response Message has already been sent 1236 o it may not be possible (or allowable) to cancel the 1237 processing of some Request Messages after they have been 1238 sent. 1239 [Note End] 1241 2.4 Miscellaneous Definitions 1243 This section covers a number of miscellaneous definitions used 1244 earlier in this section. It covers: 1246 o Document Encoding 1248 o Audit Trails 1250 o Transport Mechanism 1252 o Identical Elements 1254 2.4.1 Document Encoding 1256 Some Documents may exist either in their native form or transformed 1257 into a directly equivalent form through the use of a Document 1258 Encoding. 1260 Examples of a Document Encoding include: 1262 o [BASE64] encoding 1264 o [MIME] encoding. 1266 2.4.2 Audit Trail 1268 An Audit Trail is a record of a Transaction that allows the 1269 processing carried out by a Transaction to be traced. 1271 There are three mechanisms in XML Messaging that support the 1272 production of audit trails: 1274 o data on each Message Identity Information that references the 1275 earlier Message that is being responded to 1277 o Status Data from an earlier Message that shows how the start of one 1278 Document Exchange is dependent on an earlier one, and 1280 o digital signatures on the above two sets of information to make the 1281 audit trail non-refutable. 1283 See the XML Messaging Examples below for examples of an audit trail. 1285 2.4.3 Transport Mechanism 1287 A Transport Mechanism is a protocol, such as [HTTP] or [SMTP], that 1288 is used to physically transport a Message between two Parties. 1290 XML Messaging is designed so that any Transport Mechanism may be 1291 used. 1293 [Note] Although [HTTP] and [SMTP] are two likely transport 1294 mechanisms, literally any transport mechanism is possible, 1295 including: 1296 o sending a Message as a fax 1297 o putting the Message on a floppy disk and sending it in 1298 the post 1299 [Note End] 1301 2.4.4 Identical Elements 1303 There are a number of instances where it is necessary to compare XML 1304 elements from one Message with elements from another to determine if 1305 they are the same. For example the way in which the Messages that 1306 belong to the same Transaction are identified is that they have 1307 "identical" Transaction Identification Data elements. 1309 However some Transport Mechanisms can introduce additional characters 1310 into documents which means that a simple character-by-character 1311 comparison of elements will not provide reliable results. 1313 Therefore, in XML Messaging, identification of identical elements 1314 MUST be determined by checking that their [DOM-HASH] values are 1315 identical. 1317 3. Standard Transactions 1319 The specification for XML Messaging defines four "standard" 1320 transactions: 1322 o Service Availability Inquiry, that checks whether or not a Service 1323 is up-and-running 1325 o Transaction Status Inquiry, that checks on the status of a 1326 transaction, 1328 o User/Server Authentication, that enables one Party to authenticate 1329 another, and 1331 o Protocol Negotiation, that allows two parties to agree which 1332 choreography and documents they will use to carry out a service. 1334 The Service Availability and Transaction Status Inquiry transactions 1335 MAY be used to assist in re-start and recovery (see section 4). 1337 Each of these are described in more detail below. 1339 3.1 Service Availability Inquiry 1341 In outline a Service Availability transaction consists of a Simple 1342 Document Exchange: 1344 o a Service Availability Request document, sent by one Party to 1345 another, and 1347 o a Service Availability Response document, that is sent in return 1349 The Service Availability Response indicates whether or not the 1350 Service is available and provides basic information on some of 1351 properties of the Service such as scheduled "down time" and 1352 anticipated Response Times. 1354 Service Availability Requests MAY be signed. System operators can use 1355 this to decide whether or not to generate a Service Availability 1356 Response. 1358 It is RECOMMENDED that a Party that is conducting Transactions with 1359 other Parties periodically sends Service Availability Requests to 1360 those other Parties to make sure that they are up and running. 1362 3.2 Transaction Status Inquiry 1364 The Transaction Status Inquiry consists of a Simple Document 1365 Exchange: 1367 o a Transaction Status Inquiry Request document, that specifies the 1368 globally unique identifier of a Transaction, and 1370 o a Transaction Status Inquiry Response document, that indicates the 1371 current state of the transaction. The state can include: 1372 - Not Known 1373 - Not Yet Started 1374 - In Progress 1375 - Completed Ok 1376 - Failed 1377 - Canceled 1378 - Process Error 1380 The Transaction Status Inquiry document also indicates the identifier 1381 of the last Message that was received. This is used in recovering 1382 from failed message delivery (see section 4.2). 1384 Transaction Status Inquiry Request documents MAY be digitally signed. 1385 This means that system operators can use this to determine if an 1386 inquiry is valid. 1388 Transaction Status Inquiry Response documents MAY also be digitally 1389 signed. This means that the recipient of the Response Message can 1390 check its authenticity. 1392 3.3 User/Server Authentication 1394 The User/Server Authentication Transaction enables one Party to 1395 authenticate another. It uses the following Document Exchange: 1397 o Authentication Request document. This is sent to the Party to be 1398 authenticated. It contains: 1399 - "challenge data" to which the Party being authenticated should 1400 respond, and 1401 - the authentication method that should be used, this can vary from 1402 providing a simple password, providing a digital signature or 1403 using some proprietary authentication protocol 1405 o Authentication Response document. This is sent by the Party being 1406 authenticated to the Party requesting authentication. It contains 1407 the results of the processing the authentication data 1409 Authentication Request documents may optionally be digitally signed. 1410 This MAY be used by the user/server being authenticated to determine 1411 whether or not the Authentication Request is authorized. 1413 3.4 Quality of Service Negotiation 1415 The same service may be implemented in a variety of ways and with 1416 differing levels or timeliness of response and using different 1417 transport protocols. The Quality of Service Negotiation transaction 1418 enables two parties to agree which, of the possible alternatives, may 1419 be used. 1421 Two of the uses of Quality of Service Negotiation are: 1423 o to determine the transport protocols that the Service supports 1425 o to determine whether the Service will be implemented synchronously 1426 or asynchronously 1428 o to agree the various "timeouts" used in recovering from failed 1429 message delivery (see section 4.2). 1431 It consists of the following Document Exchange: 1433 o Quality of Service Negotiation Request document. This is sent by the 1434 Party that wants to discover information about the Service. It 1435 contains a prioritized list that describes: 1436 - the protocols supported (e.g. HTTP, SMTP, etc) - 1437 whether messages are exchanged synchronously or asynchronously 1438 - the preferred time after which "recovery from failed message 1439 delivery processing" would start. 1441 o Quality of Service Negotiation Response document. This is returned 1442 by the Party that received the Request. It contains, for example: 1443 - the selected protocol (if any), 1444 - the preferred time after which recovery from failed message 1445 delivery processing should start, 1446 - whether or not the data is exchanged synchronously 1447 - the validity of the Service Negotiation Response document 1448 - details of any planned outages or non-availability of the Service. 1450 A single Quality of Service Negotiation transaction may not result in 1451 a successful response. In this case the sender of the original 1452 Request Message, may vary the content of the Quality of Service 1453 Negotiation Request document in order to find a combination that is 1454 acceptable. 1456 Implementers may want to cache the results of a Quality of Service 1457 Negotiation Response document for later use 1459 It is not necessary for a Quality Of Service Negotiation to be 1460 carried out before sending messages between two parties. However its 1461 use should maximize the probability of any particular transaction 1462 completing in a normal way. 1464 4. Restart, Recovery and Idempotency 1466 Restart and Recovery in XML Messaging provides a standard approach to 1467 recovering from the failure of a Message to get through to its 1468 intended recipient. 1470 It uses the Service Availability Transaction (see section 3.1) and 1471 the Transaction Status Inquiry Transaction (see section 3.2) to 1472 determine what the current situation is and therefore what action 1473 should be taken to recover. 1475 When to start the restart/recovery process will vary depending on the 1476 transport protocol and characteristics of the service. The Quality of 1477 Service Negotiation transaction (see section 3.4) MAY be used to 1478 determine when this should be. 1480 The following is an overview. More detail is provided in [XMLMSG-RM]. 1482 4.1 Idempotency 1484 Duplicate Messages can be received by a Service for a number of 1485 reasons: 1487 o the Transport Protocol sometimes causes duplicate Messages to be 1488 delivered 1490 o the sender of the Message sent the message twice. Either by 1491 accident, for example there is a bug in the Sender's software; or by 1492 design, for example no response was received to the first message so 1493 the message was resent. 1495 In XML Messaging restart and recovery, it is assumed that if a 1496 Recipient receives an "identical" duplicate message (see section 1497 2.4.4), then: 1499 o the duplicate message is not processed 1501 o the message that was generated in response to the original message 1502 is resent. 1504 4.2 Recovering from failed Message delivery 1506 Prior to sending a Message (either a Request Message or an Exchange 1507 Message) to another Party the timeframe in which recovery/restart 1508 should commence should be negotiated using a Quality of Service 1509 Negotiation Transaction (see section 3.4). 1511 Once the Message is sent, the Sender of the Message will only 1512 discover a failure in delivery by realizing that the Message expected 1513 in response has not been received within the expected time frame. 1515 The Message expected in response may be: 1517 o an Acknowledgement Message (see 2.1.17 Acknowledgement Message), or 1519 o a Message that is a business or application level response to the 1520 original Message, this can be: 1521 - a Response Message 1522 - an Exchange Message 1523 - an Error Message, or 1524 - a Cancel Message 1526 However the Sender does not know why no Message was received in 1527 response. The Sender may also not want to re-send their Message 1528 without knowing the results of sending the earlier message. They 1529 therefore need to find out the current situation so that they can 1530 work out what to do to recover. 1532 The following approach is RECOMMENDED as a guideline: 1534 1)Carry out a Transaction Status Inquiry for the Transaction 1536 2)If the result of the Inquiry is "Not Known", then re-send the 1537 original Message as the Message did not get through on the first try 1539 3)If the result of the Inquiry is "In Progress" then wait a further 1540 period of time, as a Message in response should be received in due 1541 course once its processing is complete. If no Message in response is 1542 received after a period of time then repeat from step 1. 1544 4)If the result of the Inquiry is any other Transaction Status (e.g. 1545 "Completed Ok", "Failed", etc.) then the first Message was received 1546 and processed but the Message in Response did not get through. In 1547 this case re-send the first Message which should result in the re- 1548 sending of the previously generated Message in Response. If the 1549 Message in Response does not arrive after the expected period of time 1550 then repeat from step 1. 1552 5)If no response to the Transaction Status Inquiry is received, then it 1553 is possible that either the Transaction Status Inquiry transaction 1554 failed, or that the Service that should respond to the Inquiry is not 1555 working. In this case carry out a Service Availability Transaction 1556 for the Service. 1558 6)If the Service Availability Transaction does not work then in all 1559 probability the Service is not working. In this case either: 1561 a) wait some period of time and retry the Service Availability 1562 Transaction until it does respond. Once the Service Availability 1563 Transaction works then repeat from step 1 to determine what 1564 recovery action to take, or 1566 b) choose an alternative URL to send the Message to (if one is 1567 available) and send the Message to that URL then wait for a 1568 response. In this case the failure to send the message to the 1569 original destination should be recorded in the Message Routing 1570 Information. 1572 7)If, after a number of re-tries, there is still no response from 1573 sending a Service Availability Request, and there are no alternative 1574 URLs that can be used then carry out whatever action is appropriate 1575 such as notify an operator for human intervention and carry out no 1576 further recovery actions until requested by the operator. 1578 5. Security Considerations 1580 This section considers, from an IETF perspective how XML Messaging 1581 addresses security. The section covers: 1583 o digital signatures 1585 o message authenticity, and 1587 o data privacy. 1589 5.1 Digital Signatures 1591 The data contained within XML Messages can be digitally signed for 1592 the usual reasons such as: 1594 o authenticating the identity of the sender of a message, 1596 o enables changes in the signed data to be detected, 1598 o providing a mechanism to support non-repudiation of a request for or 1599 response to the execution of a Service. 1601 However, the scope of this specification SHALL be limited to defining 1602 how digital signatures can be used by XML Messaging and excludes the 1603 trust relationships that use of signatures may apply. 1605 5.1.1 Determining whether to use digital signatures 1607 The use of digital signatures within XML Messaging is entirely 1608 optional. XML Messaging can work successfully either with or without 1609 the use of digital signatures. 1611 Ultimately it is up to the Parties involved to decide whether the XML 1612 Messages they use will include signatures. For example if a Sender of 1613 a Message omits a Digital Signature then the recipient of the Message 1614 will need to decide whether carrying out the requested Service 1615 without signatures is an acceptable risk. If senders of Request 1616 Messages discover that requests without signatures are not being 1617 accepted, then they will either: 1619 o start using signatures, 1621 o find a method of working which does not need signatures, or 1623 o accept a lower volume and value of transactions. 1625 5.1.2 Reasons for using Digital Signatures 1627 A non-exhaustive list of the reasons why digital signatures might be 1628 used are described below. 1630 A MERCHANT WANTS TO DEMONSTRATE THAT THEY CAN BE TRUSTED 1632 If, for example, a merchant generates an offer to carry out a trade 1633 and includes it in an XML Message with a Signature that uses a 1634 certificate from a trusted third party, known to the Consumer, then 1635 the Consumer can check the signature and certificate and so more 1636 reasonably rely on the offer being from the actual organization the 1637 merchant claims to be. 1639 In this case signatures using asymmetric (PKI) cryptography are 1640 likely to be required since the Merchant would not want other 1641 organizations to be able to generate an equivalent signature. 1643 A MERCHANT WANTS TO GENERATE A RELIABLE RECORD OF A TRANSACTION 1645 For example, with appropriate trust hierarchies, digital signatures 1646 could be checked by the Consumer to determine: 1648 o if a record of a purchase will be accepted by tax authorities as a 1649 valid record of a transaction, or 1651 o if some warranty, for example from a "Better Business Bureau" or 1652 similar was being provided. 1654 A PARTY NEEDS TO KNOW THAT A REQUEST MESSAGE IS UNALTERED AND 1655 AUTHORISED 1657 The data that constitutes a Request Message may have been provided by 1658 someone other than the sender of the Message. For example, in [IOTP], 1659 details of how much to pay is sent to the Consumer by a Merchant and 1660 then forwarded to the Payment Handler that is to accept the payment 1661 in a payment request message. 1663 If the request is not signed, the Consumer could change the amount 1664 due by, for example, removing a digit. 1666 If the Payment Handler has no access to the original payment 1667 information provided by the Merchant, then, without signatures, the 1668 Payment Handler cannot be sure that the data has not been altered. 1670 Similarly, if the payment information is not digitally signed, the 1671 Payment Handler cannot be sure who is the Merchant that is requesting 1672 the payment. 1674 A PARTY WANTS TO PROVIDE A NON-REFUTABLE RECORD OF THE COMPLETION 1675 STATUS OF A SERVICE 1677 If a Response Message is digitally signed, then the recipient of the 1678 Response Message can later use the data in the Response Message to 1679 prove that the service was carried out. This could be used, for 1680 example, to enable a customer to claim a refund of a purchase if 1681 required. 1683 5.1.3 Reasons to not use Signatures 1685 A non-exhaustive list of the reasons why digital signatures might not 1686 be used follows. 1688 A SINGLE PARTY IS CARRYING OUT ALL SERVICES 1690 One of the reasons for using digital signatures is so that one Party 1691 can determine if data has been changed by an intermediate Party that 1692 is forwarding the data. 1694 However if the Party that needs to check for authenticity has access 1695 to all the necessary data, then it might be possible to compare, for 1696 example, the forwarded information with the original. 1698 Access to the data necessary could be realized by, for example, one 1699 Party carrying out all the different roles on the same system, or 1700 where the roles are carried out on different systems but the systems 1701 can communicate in some way. 1703 THE PROCESSING COST OF THE CRYPTOGRAPHY IS TOO HIGH 1705 If a payment is being made of only a few cents, the cost of carrying 1706 out all the cryptography associated with generating and checking 1707 digital signatures on a request to make the payment or a receipt 1708 contained in a payment response might make the whole transaction 1709 uneconomic. 1711 ANYONE CAN REQUEST THE SERVICE 1713 The service that is being requested, for example to inquire on the 1714 public list price of a product, may be open to anyone. In this case, 1715 there is little benefit in signing the request as it is likely that a 1716 response will always be generated. 1718 5.2 Message Authenticity 1720 XML Messaging provides two mechanisms by which the authenticity of 1721 the Parties involved may be assured: 1723 o digital signatures 1725 o user/server authentication 1727 Digital signatures contained in Messages MAY be checked to ensure 1728 that the sender of the document is who they appear to be. 1730 User/server authentication (see section 3.3) may be used to 1731 authenticate the sender of or recipient for any message. This can 1732 occur either: 1734 o before sending a message to authenticate a recipient, or 1736 o after receiving a message to authenticate its sender. 1738 In addition transport level methods MAY be used to determine the 1739 authenticity of messages. For example: 1741 o by checking the certificates associated with the use of secure 1742 channels such as [SSL/TLS], or 1744 o using a communication method (e.g. a telephone line) that is 1745 dedicated to the two parties and is thought sufficiently 1746 trustworthy. 1748 Transport Level authenticity methods SHALL NOT be defined by this 1749 specification. A secure transport protocol MAY also remove the need 1750 to use digital signatures. 1752 5.3 Data Privacy 1754 Privacy of information is provided by sending Messages using a secure 1755 channel such as [SSL/TLS]. Use of a secure channel with XML Messaging 1756 is OPTIONAL. 1758 Any elements within documents that are transmitted using XML 1759 Messaging MAY be encrypted. However, the procedure used to encrypt 1760 XML elements or documents SHALL NOT be defined within this 1761 specification. 1763 6. XML Messaging Compliance Levels 1765 The purpose of this section is to indicate the different ways in 1766 which the various parts of the XML Messaging Specification may be 1767 used together in a compliant way. 1769 XML Messaging Specification is split into several parts for a number 1770 of reasons: 1772 o so that implementers of XML Messaging may select the just the parts 1773 of XML Messaging that they need, for example, some implementations 1774 may not need to use digital signatures, 1776 o to facilitate the development and evolution of individual sections 1777 in parallel, 1779 o to encourage re-use of the XML Messaging Specifications by other 1780 protocol and standard developers. 1782 The following examples illustrate ways in which the different parts 1783 of XML Messaging may be combined. 1785 6.1 Data Element Compliance 1787 Data Element Compliance is the lowest level of compliance which 1788 simply requires use of some of the XML element definitions contained 1789 in the Common XML Messaging Elements specification [XMLMSG-CME]. The 1790 message elements MUST be used with the semantics as defined in the 1791 specification. 1793 6.2 Message Level Compliance 1795 Message Level Compliance uses all the data elements defined in the 1796 Common XML Messaging Elements Specification [XMLMSG-CME] to construct 1797 XML Messages that can be sent between two Parties. However use of XML 1798 Messages in a Response-Request based Document Exchange is not 1799 required. 1801 6.3 Document Exchange and Transaction Level Compliance 1803 Document Exchange Compliance exchanges messages in the standard ways 1804 defined within Document Exchange and Transactions [XMLMSG-DET]. This 1805 uses XML Messages to support Transactions consisting of either: 1807 o a Simple Document Exchange 1808 o a Multiple Round Trip Document Exchange, or 1810 o a One Way Message 1812 This MUST be used with: 1814 o Message Level Compliance (see section 6.2), and 1816 o a transaction protocol (e.g. HTTP)as defined in the protocol's 1817 Transaction Protocol Supplement (see section o). 1819 6.4 Reliable Messaging Compliance 1821 Reliable Messaging Compliance uses the processes and procedures 1822 defined in Reliable Messaging [XMLMSG-RM] to achieve reliable, robust 1823 and resilient message delivery. 1825 This MUST be used with Document Exchange and Transaction Compliance 1826 (see section 6.3) and MAY be used with any combination of: 1828 o Secure Messaging Compliance (see section 6.5), 1830 o Document Choreography Compliance (see section 6.6). 1832 6.5 Secure Messaging Compliance 1834 Secure Messaging Compliance uses the processes and procedures defined 1835 in Secure Messaging [XMLMSG-SM] to ensure the tamper resistant and 1836 authenticated exchange of messages. 1838 This MUST be used with Document Exchange and Transaction Compliance 1839 (see section 6.3) and MAY be used with any combination of: 1841 o Reliable Messaging Compliance (see section 6.4), 1843 o Document Choreography Compliance (see section 6.6). 1845 6.6 Document Choreography Compliance 1847 Document Choreography Compliance uses the processes and procedures 1848 defined in Document Choreography Definitions [XMLMSG-DCD] that 1849 defines how the sequence in which documents are exchanged may be 1850 defined. 1852 This MUST be used with Document Exchange and Transaction Compliance 1853 (see section 6.3) and MAY be used with any combination of: 1855 o Reliable Messaging Compliance (see section 6.4), 1856 o Secure Messaging Compliance (see section 6.5). 1858 6.7 Transport Protocol Supplement Compliance 1860 XML Messages may be transported over a variety of transport protocols 1861 such as [HTTP] or [SMTP]. How this is done for a particular transport 1862 protocol is defined in a Transport Protocol Supplement for the 1863 protocol. 1865 Transport Protocol Supplement Compliance means that an implementation 1866 conforms with the Transport Protocol Supplement specification. 1868 6.8 Common Document Exchange and Transaction Compliance 1870 Common Document Exchange Compliance means that an implementation 1871 supports one or more of the document exchanges defined as standard. 1873 Examples of candidate standard document exchanges/transactions 1874 include: 1876 o a Transaction Status Inquiry, that allows the current status of any 1877 transaction to be discovered, 1879 o a Large Message Delivery Transaction, that supports the delivery of 1880 large messages/documents by splitting them up into several smaller 1881 parts, 1883 o a Message Trace Inquiry that enables the sender of a message to 1884 discover where the message has been forwarded to, 1886 o a Service Functionality Inquiry that enables the functions that a 1887 Service supports to be discovered such as Reliable Messaging, 1888 Security and Signatures, Transport Protocols supported, Large 1889 Message Delivery capability, etc 1891 These common document exchanges/transactions MUST be used with 1892 Document Exchange and Transaction Compliance (see section 6.3) and 1893 MAY be used with any combination of: 1895 o Reliable Messaging Compliance (see section 6.4), 1897 o Secure Messaging Compliance (see section 6.5), 1899 o Document Choreography Compliance (see section 6.6). 1901 7. XML Messaging Examples 1903 This section is in two parts: 1905 o an illustration of the structure of a Message that conforms to the 1906 ideas in this specification, and 1908 o a series of examples that illustrate how XML Messaging could be 1909 used. The examples provided are: 1910 - Simple Document Exchange 1911 - Simple Document Exchange with Errors 1912 - Canceling a Transaction 1913 - Transaction with Multiple Document Exchanges 1914 - Relating Two Transactions 1916 7.1 XML Message Structure 1918 In outline, an XML Message has the structure shown in the figure 1919 below. Note that spaces have been included in the "element" names for 1920 ease of reading. 1922 o Outer wrapper can be an XML 1923 Document or a Multipart MIME 1924 message. 1925 o Message Header contains 1926 additional data required to send 1927 the document(s) successfully. 1928 Content depends on whether it is 1929 a Request Message, Exchange 1930 Message, Response Message or an 1931 Error Message. 1932 o Required in every Message. It 1933 indicates the type of the 1934 Message. The different types of 1935 Message are: Request, Response, 1936 Exchange, Acknowledgement, 1937 OneWay, Cancel, and Error. 1938 o Required in every Message. It 1939 ... identifies a set of related 1940 Messages. 1941 o Required in every Message. It 1942 ... identitifies and describes an 1943 individual message within a 1944 Transaction 1945 o Required in every Message. It 1946 ... identifies, logically, the sender 1947 of the message. The sender may be 1948 anonymous. 1949 o Required in every Message. It 1950 ... identifies, logically, the 1952 recipient of the Message. The 1953 recipient may be anonymous in 1954 which case the recipient is 1955 identified at the Transport 1956 Protocol level. 1957 o Optional. Contains information 1958 ... that identifies who is 1959 authorizing that the recipient of 1960 the Message should act on the 1961 Message. 1962 o Required in every Message. It 1963 ... indicates the type of Service to 1964 which the Message is associated. 1965 Required in every Message. It 1966 ... indicates the reason why Message 1967 is being sent to the Service. 1968 On Response, Acknowledgement and 1969 ... Error Messages it rovides an 1970 indication of the current state 1971 of the Document Exchange. On 1972 Request Messages it is used to 1973 indicate the end state of a 1974 preceding Document Exchange. 1975 o Required in every Message that 1976 ... contains more than just a Message 1977 Header and Message Routing 1978 Information. Identifies what 1979 other documents/signatures were 1980 sent with the message. 1981 o Optionally links one Transaction 1982 ... to some earlier Transaction 1983 1984 1985 o Required within every message. 1986 ... Maps the logical destination to 1987 the physical destination (e.g. a 1988 URL). Contains a history of the 1989 route taken by the message in 1990 order to reach its final 1991 destination. 1992 o Zero or more. A Digital signature 1993 ... can sign any data in the Message, 1994 the Transaction, or elsewhere, 1995 for example on the web. 1996 o The actual document(s) that are 1997 ... DOCUMENT(S) ... to be sent to a party. Documents 1998 may be encoded for transportation 1999 for example using [Base64]. 2000 2002 Figure 1 XML Messaging, Message Structure 2004 If the Message Envelope is implemented using multi-part MIME, then 2005 the Message Header, Signatures and the "Documents" would each be 2006 contained in separate multi-part MIME parts. 2008 If the Message Envelope is implemented using an XML-Document, then 2009 non-XML "documents" would be wrapped in thin XML wrapper so that they 2010 can be uniquely identified by the Message Manifest. 2012 7.2 XML Messaging Examples 2014 7.2.1 Simple Document Exchange 2016 At its simplest, a Transaction consists of just one Service that uses 2017 just one Simple Document Exchange that consists of: 2019 o a Request Message sent from one party to a second party, and 2021 o the Response Message that is returned as a result. 2023 The figure below provides an example of what these messages could 2024 contain and how they could be processed. 2026 Party 1 2027 | Party 2 2028 STEP | | 2029 1. Party 1 generates the documents that need to be sent, 2030 places them in an XML Message together with a Message 2031 Header and (optional) digital signature and sends it to 2032 the Party 2. 2034 1 --> 2 Request Message: 2035 o Message Header 2036 - Message Type (Request) 2037 - Transaction Identity Data 2038 - Message Identity Data 2039 - From (Party 1) 2040 - To (Party 2) 2041 - Service Type 2042 - Intent 2043 - Authorization Data 2044 - Message Manifest 2045 o Message Routing Info 2046 o Signature(s) (Optional) 2047 o Document(s) 2049 2. Party 2 that received the Request Message carries out the 2050 following processes: 2051 o checks the "To" data to check the Message intended for 2052 them; 2053 o checks the Service Type and Intent to make that they 2054 can carry out the request; 2056 o if required, checks the "From" data to make sure that 2057 the sender is known 2058 o checks the Authorization Data (if present) to make sure 2059 the action is authorized (note some requests may not 2060 need authorization); 2061 o checks the Signature, if present, to make sure the data 2062 has not changed and the sender can be identified, then 2063 o if everything is OK, checks the Document(s) for errors, 2064 then 2065 o if no errors in the Document(s) then carries out the 2066 requested action using the data contained in the 2067 Document(s) 2068 o once the action is complete, then generates a Response 2069 Message and sends it back to Party 1. 2071 1 <-- 2 Response Message: 2072 o Message Header: 2073 - Message Type (Response) 2074 - Transaction Identity Data 2075 - Message Identity Data 2076 - From (Party 2) 2077 - To (Party 1) 2078 - Service Type 2079 - Intent 2080 - Message Manifest 2081 - Status Data 2082 o Message Routing Info 2083 o Signature(s) (Optional); 2084 o Document(s) 2086 3. Party 1 that has received the Response Message then 2087 carries out the following processes: 2088 o Checks the Transaction Identity Data and Message 2089 Identity Data to make sure the Response Message refers 2090 to the Transaction/Request Message that they sent 2091 earlier 2092 o checks the Signature, if present, to make sure the data 2093 has not changed and is the sender of the message can be 2094 authenticated 2095 o checks the Status Data to determine that the Service 2096 was carried out by the anticipated Organization and 2097 whether the service succeeded or failed 2098 o if everything is OK, then checks the Document(s) for 2099 Errors, 2100 o if everything is still OK, then carries out whatever 2101 processing of the Document(s) is necessary. 2103 Figure 2 Simple Document Exchange Message Flow 2105 [Note] In the above example the sequence of the processing by the 2106 described for Party 1 or Party 2 is indicative of the 2107 processing required. Sequences that provide the same result 2108 are equally acceptable. 2110 [Note End] 2112 7.2.2 Simple Document Exchange with Errors 2114 In the previous example, it was assumed that no errors were found. If 2115 errors are found then a slightly different message flow would occur. 2116 The example below builds on the previous example in Figure 2 Simple 2117 Document Exchange Message Flow. 2119 Party 1 2120 | Party 2 2121 STEP | | 2122 1. Party 1 generates the documents that need to be sent, 2123 places them in an XML Message together with a Message 2124 Header and (optional) digital signature and sends it to 2125 the Recipient. 2127 1 --> 2 Request Message: 2128 o Message Header 2129 - Message Type (Request) 2130 - Transaction Identity Data 2131 - Message Identity Data 2132 - From (Party 1) 2133 - To (Party 2) 2134 - Service Type 2135 - Intent 2136 - Message Manifest 2137 o Message Routing Info 2138 o Signature(s) (Optional) 2139 o Document(s) 2141 2. Party 2 that receives the Request Message detects an error 2142 and so sends an Error Message back to Party 1. 2144 1 <-- 2 Error Message: 2145 o Message Header 2146 - Message Type (Error) 2147 - Transaction Identity Data 2148 - Message Identity Data 2149 - From (Party 2) 2150 - To (Party 1) 2151 - Service Type 2152 - Intent 2153 - Message Manifest 2154 o Message Routing Info 2155 o Signature(s) (Optional) 2156 o Document(s) 2157 - Error Data 2159 3. Party 1 that received the Error Message: 2160 o Checks the Transaction Identity Data and Message 2161 Identity Data to make sure the Message refers to the 2162 Transaction/Request Message that they sent 2164 o checks the Signature, if present, to make sure the data 2165 has not changed 2166 o determines that there was an Error and takes the 2167 appropriate action. 2169 Figure 3 Document Exchange with Request Message Errors 2171 Errors can also occur in a Response Message. In this case the Message 2172 flow would be as below. 2174 Party 1 2175 | Party 2 2176 STEP | | 2177 1. Party 1 generates the documents that need to be sent, 2178 places them in an XML Message together with a Message 2179 Header and (optional) digital signature and sends it to 2180 Party 2. 2182 1 --> 2 Request Message: 2183 o Message Header 2184 - Message Type (Request) 2185 - Transaction Identity Data 2186 - Message Identity Data 2187 - From (Party 1) 2188 - To (Party 2) 2189 - Service Type 2190 - Intent 2191 - Message Manifest 2192 o Message Routing Info 2193 o Signature(s) (Optional) 2194 o Document(s) 2196 2. Party 2 that receives the Request Message successfully 2197 processes the Request Message and generates and sends a 2198 Response Message back to Party 1. 2200 1 <-- 2 Response Message: 2201 o Message Header: 2202 - Message Type (Response) 2203 - Transaction Identity Data 2204 - Message Identity Data 2205 - From (Party 2) 2206 - To (Party 1) 2207 - Service Type 2208 - Intent 2209 - Message Manifest 2210 - Status Data 2211 o Message Routing Info 2212 o Signature(s) (Optional); 2213 o Document(s) 2215 3. Party 1 that has received the Response Message identifies 2216 an error in the some part of the Response Message and 2217 therefore sends an Error Message back to the Sender of the 2218 Response Message. 2220 1 --> 2 Error Message: 2221 o Message Header 2222 - Message Type (Error) 2223 - Transaction Identity Data 2224 - Message Identity Data 2225 - From (Party 1) 2226 - To (Party 2) 2227 - Service Type 2228 - Intent (Error) 2229 - Message Manifest 2230 o Message Routing Info 2231 o Signature(s) (Optional) 2232 o Document(s) (Optional) 2233 - Error Data 2235 4. Party 2 that received the Error Message: 2236 o Checks the Transaction Identity Data and Message 2237 Identity Data to make sure the Message refers to a 2238 Transaction/Request Message that they are aware of 2239 o checks the Signature, if present, to make sure the data 2240 has not changed 2241 o determines that there was an Error in the Response 2242 Message they had sent and takes the appropriate action. 2244 Figure 4 Document Exchange with Response Message Errors 2246 7.2.3 Canceling a Transaction 2248 Transaction cancellation occurs in a similar way to generating 2249 errors. For example if a Recipient of a Request Message wants to 2250 cancel a transaction they would do this as illustrated in the figure 2251 below. 2253 Party 1 2254 | Party 2 2255 STEP | | 2256 1. Party 1 generates the documents that need to be sent, 2257 places them in an XML Message together with a Message 2258 Header and (optional) digital signature and sends it to 2259 Party 2. 2261 1 --> 2 Request Message: 2262 o Message Header 2263 - Message Type (Request) 2264 - Transaction Identity Data 2265 - Message Identity Data 2266 - From (Party 1) 2267 - To (Party 2) 2268 - Service Type 2269 - Intent 2270 - Message Manifest 2271 o Message Routing Info (Optional) 2272 o Signature(s) (Optional) 2273 o Document(s) 2275 2. Party 2 that received the Request Message checks the 2276 message but decides they want to cancel the Transaction 2277 for some reason and so sends a Cancel Message back to the 2278 Sender of the Request Message. 2280 1 <-- 2 Cancel Message: 2281 o Message Header 2282 - Message Type (Cancel) 2283 - Transaction Identity Data 2284 - Message Identity Data 2285 - From (Party 2) 2286 - To (Party 1) 2287 - Service Type 2288 - Intent (Cancel) 2289 - Message Manifest (Optional) 2290 o Message Routing Info (Optional) 2291 o Signature(s) (Optional) 2292 o Document(s) (Optional) 2294 7.2.4 Transaction with Multiple Document Exchanges 2296 Transactions can also consist of multiple Document Exchanges as 2297 illustrated in the following example that contains four Document 2298 Exchanges that are part of three Services. The Services, the 2299 associated Intent and the resultant Document Exchanges are as follows 2301 o Service: Supplier Order Processing 2302 - Intent: Stock Availability Check 2303 Document: Stock Availability Request 2304 Document: Stock Availability Response 2305 - Intent: New Purchase Order 2306 Document: Purchase Order 2307 Document: Invoice 2308 Document: Payment Brand List 2310 o Service: Payment Service 2311 - Intent: Make Payment 2312 Document: Payment Request 2313 Document: Payment Instrument 2314 Document: Payment Response 2316 o Service: Delivery Goods 2317 - Intent: Request Delivery 2318 Document: Delivery Request 2319 Document: Delivery Response 2321 Note that this example also illustrates how digital signatures can be 2322 used to provide an Audit Trail and authorize the execution of each 2323 Service. 2325 More details are provided below together with explanations on how 2326 signatures are used to link each Document Exchange instance together. 2328 Buyer Supplier / 2329 | Payment Handler 2330 STEP | | 2331 1. Buyer generates a Stock Availability Request, digitally 2332 signs it, and sends it to the Supplier to check for 2333 availability. 2335 B --> S Request Message (Stock Availability Request): 2336 o Message Header 2337 - Message Type (Request) 2338 - Transaction Identity Data 2339 - Message Identity Data 2340 - From (Buyer) 2341 - To (Supplier) 2342 - Service Type (Supplier Order Processing) 2343 - Intent (Stock Availability Check) 2344 - Authorization Data: 2345 Buyer Data 2346 ref. to Signature1 2347 - Message Manifest 2348 o Message Routing Info 2349 o Signatures 2350 - Signature1, Signs: 2351 Message Header 2352 Stock Availability Request 2353 o Documents 2354 - Stock Availability Request 2356 2. The Supplier checks the Stock Availability Request (see 2357 example earlier for what is involved in checking a 2358 request) and generates a Stock Availability Response to 2359 send back to the Buyer. The response is digitally signed. 2361 B <-- S Response Message (Stock Availability Response): 2362 o Message Header 2363 - Message Type (Response) 2364 - Transaction Identity Data 2365 - Message Identity Data 2366 - From (Supplier) 2367 - To (Buyer) 2368 - Service Type (Supplier Order Processing) 2369 - Intent (Stock Availability Check) 2370 - Message Manifest 2371 - Status Data (Stock Availability Check) 2372 o Message Routing Info 2373 o Signatures 2374 - Signature2, Signs: 2376 Message Header 2377 Stock Availability Response 2378 Signature1 in Stock Availability Request Message 2379 o Document 2380 - Stock Availability Response 2382 3. The Buyer checks the Stock Availability Response Message 2383 and finds it OK. As a result generates a Purchase Order 2384 Document and sends it to the Supplier. The Authorization 2385 Data includes Status Data on the Stock Availability, to 2386 indicate that the Purchase Order is linked to the earlier 2387 Stock Availability Check Document Exchange. 2389 B --> S Request Message (Purchase Order): 2390 o Message Header 2391 - Message Type (Request) 2392 - Transaction Identity Data 2393 - Message Identity Data 2394 - From (Buyer) 2395 - To (Supplier) 2396 - Service Type (Supplier Order Processing) 2397 - Intent (New Purchase Order) 2398 - Message Manifest 2399 - Authorization Data: 2400 Buyer Data 2401 Status Data (Stock Availability Check) 2402 ref. to Signature3 2403 o Message Routing Info 2404 o Signatures 2405 - Signature3, signs: 2406 Message Header 2407 Purchase Order 2408 Signature2 (on Stock Availability Check Response 2409 Message) 2410 o Documents 2411 - Purchase Order 2413 4. The Supplier checks the Purchase Order Request Message and 2414 generates an Invoice, and a list of Payment Brands that 2415 the Supplier accepts, signs the documents and sends them 2416 back to the Buyer. 2418 B <-- S Response Message (Purchase Order Response): 2419 o Message Header 2420 - Message Type (Response) 2421 - Transaction Identity Data 2422 - Message Identity Data 2423 - From (Supplier) 2424 - To (Buyer) 2425 - Service Type (Supplier Order Processing) 2426 - Intent (New Purchase Order) 2427 - Message Manifest 2428 - Status Data (New Purchase Order) 2429 o Message Routing Info 2430 o Signatures 2431 - Signature4, signs 2432 Message Header 2433 Invoice 2434 Brand List 2435 Signature3 (on Purchase Order Request Message) 2436 o Documents 2437 - Invoice 2438 - Brand List 2440 5. The Buyer checks the Purchase Order Response Message and 2441 finds it OK. As a result generates a Payment Request, 2442 provides information on the Payment Instrument to use, 2443 digitally signs them sends them to the Payment Handler 2444 (another Party) that is to accept the payment on behalf of 2445 the Supplier. 2447 B --> P Request Message (Payment Request): 2448 o Message Header 2449 - Message Type (Request) 2450 - Transaction Identity Data 2451 - Message Identity Data 2452 - From (Buyer) 2453 - To (Payment Handler) 2454 - Service Type (Payment) 2455 - Intent (Make Payment) 2456 - Message Manifest 2457 - Authorization Data 2458 Buyer Data 2459 Supplier Data 2460 Status Data (New Purchase Order) 2461 ref. to Signature4 (from Purchase Order Response 2462 Message) 2463 ref to Signature5 2464 o Message Routing Info 2465 o Signatures 2466 - Signature4 (copied from Purchase Order Response 2467 Message) 2468 - Signature5, signs 2469 Signature4 (on Purchase Order Response Message) 2470 Payment Instrument 2471 Payment Request 2472 o Documents: 2473 - Payment Request (amount to pay, which Brand) 2474 - Brand List 2475 - Payment Instrument 2477 6. The Payment Handler Checks the Payment Request including 2478 the Authorization Data to check that they know the 2479 Supplier, and on the Payment Instrument data to check that 2480 the Buyer wants to make the payment. Accepts the Payment, 2481 generates a Payment Receipt, digitally signs the 2482 information and sends it back to the Buyer. 2484 B <-- P Response Message (Payment Response): 2485 o Message Header 2486 - Message Type (Response) 2487 - Transaction Identity Data 2488 - Message Identity Data 2489 - From (Payment Handler) 2490 - To (Buyer) 2491 - Service Type (Payment) 2492 - Intent (Make Payment) 2493 - Message Manifest 2494 - Status Data (Payment Response) 2495 o Message Routing Info 2496 o Signatures 2497 - Signature6, signs 2498 Message Header 2499 Payment Receipt 2500 Signature4 (on Purchase Order Response Message) 2501 Signature5 (on Payment Request Message) 2502 o Document: 2503 - Payment Receipt 2505 7. The Buyer checks the Payment Response Message and finds it 2506 OK. As a result generates a Delivery Request Document and 2507 sends it to the Supplier to request delivery of the goods. 2509 B --> S Request Message (Delivery Request): 2510 o Message Header 2511 - Message Type (Request) 2512 - Transaction Identity Data 2513 - Message Identity Data 2514 - From (Buyer) 2515 - To (Supplier) 2516 - Service Type (Supplier Order Processing) 2517 - Intent (Make Delivery) 2518 - Message Manifest 2519 - Authorization Data 2520 Payment Handler Data 2521 ref to Signature6 2522 ref to Payment Receipt 2523 o Message Routing Info 2524 o Signatures 2525 - Signature6 (copied from Payment Response Message) 2526 o Documents 2527 - Payment Receipt 2529 8. The Supplier checks the Delivery Request including the 2530 Authorization Data to check that payment has been made. 2531 Checks that delivery is possible and therefore generates a 2532 Delivery Response that confirms how delivery will occur, 2533 digitally signs the information and sends the message back 2534 to the Buyer. 2536 B <-- S Response Message (Delivery Response): 2537 o Message Header 2538 - Message Type (Response) 2539 - Transaction Identity Data 2540 - Message Identity Data 2541 - From (Supplier) 2542 - To (Buyer) 2543 - Service Type (Supplier Order Processing) 2544 - Intent (Make Delivery) 2545 - Message Manifest 2546 - Status Data (Delivery Response) 2547 o Message Routing Info 2548 o Signatures 2549 - Signature7, signs: 2550 Message Header 2551 Delivery Response 2552 Signatures6 (on the Delivery Request Message) 2553 o Documents 2554 - Delivery Response 2556 9. The Buyer checks the Delivery Response Message and finds 2557 it OK then logs the information and waits for the physical 2558 Delivery of the goods. 2560 Figure 5 Multiple Document Exchange Transaction 2562 [Note] In the example above, signatures are used, to help provide 2563 the audit trail and so that one Party, e.g. the Payment 2564 Handler, can check the validity of the Payment Request 2565 Message. Alternative approaches that avoid the need for 2566 signatures are possible. For example: 2567 o the Buyer and Seller use a secure Transport Mechanism 2568 such as [HTTPS] to set up a secure channel between them 2569 o the Seller authenticates the Buyer (perhaps using a 2570 User/Server Authentication Transaction) 2571 o the first two Document Exchanges occur over the secure 2572 channel. 2573 [Note End] 2575 7.2.5 Relating Two Transactions 2577 XML Messaging allows two or more transactions to be linked together. 2578 This example shows how a purchase transaction can be linked to an 2579 earlier contract negotiation transaction. 2581 The first example is the contract negotiation transaction. Note that 2582 this also illustrates a Multiple Round Trip Document Exchange. 2584 Buyer 2585 | Supplier 2586 STEP | | 2587 1. Buyer generates a draft contract places it in an XML 2588 Message together with a Message Header and sends it to the 2589 Supplier. 2591 B --> S Request Message: 2592 o Message Header 2593 - Message Type (Request) 2594 - Transaction Identity Data 2595 - Message Identity Data 2596 - From (Buyer) 2597 - To (Supplier) 2598 - Service Type (Contract Processing) 2599 - Intent (New Draft Contract) 2600 - Message Manifest 2601 o Message Routing Info 2602 o Document 2603 - Draft Contract 2605 2. The Supplier reviews the Contract, makes revisions and 2606 places the revised contract in an Exchange Message and 2607 sends it back to the Buyer 2609 B <-- S Exchange Message: 2610 o Message Header: 2611 - Message Type (Exchange) 2612 - Transaction Identity Data 2613 - Message Identity Data 2614 - From (Supplier) 2615 - To (Buyer) 2616 - Service Type (Contract Processing) 2617 - Intent (Contract Amendment) 2618 - Message Manifest 2619 o Message Routing Info 2620 o Document 2621 - Revised Contract 2623 3. The Buyer reviews the revised contract, amends it and 2624 places it in an XML Message together with a Message Header 2625 and sends it to the Supplier. 2627 B --> S Exchange Message: 2628 o Message Header 2629 - Message Type (Exchange) 2630 - Transaction Identity Data 2631 - Message Identity Data 2632 - From (Buyer) 2633 - To (Supplier) 2634 - Service Type (Contract Processing) 2635 - Intent (Contract Amendment) 2636 - Message Manifest 2637 o Message Routing Info 2638 o Document 2639 - Revised Contract 2641 N-1. The Supplier and Buyer keep on swapping drafts of the 2642 contract in Exchange Messages until eventually they agree 2643 and the Supplier sends the final version of the contract, 2644 digitally signed, back to the Buyer in a Response Message. 2646 B <-- S Response Message: 2647 o Message Header: 2648 - Message Type (Response) 2649 - Transaction Identity Data 2650 - Message Identity Data 2651 - From (Supplier) 2652 - To (Buyer) 2653 - Service Type (Contract Processing) 2654 - Intent (Final Contract) 2655 - Message Manifest 2656 - Status Data 2657 o Message Routing Info 2658 o Signatures 2659 - Signature1, signs: 2660 Message Header 2661 Final Contract 2662 o Document 2663 - Final Contract 2665 N. The Buyer carries out a final check on the contract and 2666 stores it for later use. 2668 Some time later, the Buyer wants to make a purchase under the terms 2669 of the agreed contract. Now suppose that the contract negotiation 2670 transaction had an identifier of "ACV-CN-1999/2456@example.com". Then 2671 the Purchase Transaction could refer to the Contract Negotiation by 2672 referring to the identifier in the Transaction Identity Data of the 2673 Purchase Transaction. For example: 2675 Buyer 2676 | Supplier 2677 STEP | | 2678 1. Buyer generates a Purchase Order places it in an XML 2679 Message. The Transaction Identity Data refers to the 2680 earlier Contract Negotiation transaction. 2682 B --> S Request Message (Purchase Order): 2683 o Message Header 2684 - Message Type (Request) 2685 - Transaction Identity Data 2686 - Message Identity Data 2687 - From (Buyer) 2688 - To (Supplier) 2689 - Service Type (Supplier Order Processing) 2690 - Intent (New Purchase Order) 2691 - Message Manifest 2692 - Related Transaction Data (refers to 2693 "ACV-CN-1999/2456@example.com") 2694 o Message Routing Info 2695 o Signatures 2696 - Signature1, signs 2697 Message Header 2698 Purchase Order 2699 o Document 2700 - Purchase Order 2702 2. Purchase continues ... 2704 [Note] Note that the digital signature is being used by the Buyer 2705 to bind the Purchase Order to the earlier contract 2706 negotiation. 2707 [Note End] 2709 8. References 2711 This section contains references to related documents identified in 2712 this specification. 2714 [Base64] Base64 Content-Transfer-Encoding. A method of 2715 transporting binary data defined by MIME. See: RFC 2716 2045: Multipurpose Internet Mail Extensions (MIME) Part 2717 One: Format of Internet Message Bodies. N. Freed & N. 2718 Borenstein. November 1996. 2720 [DOM-HASH] A method for generating hashes of all or part of an XML 2721 tree based on the DOM of that tree. See 2722 http://www.ietf.org/internet-drafts/draft-ietf-trade- 2723 hiroshi-dom-hash-*.txt. 2725 [DUNS] The Data Universal Numbering System, the D&B D-U-N-S 2726 Number, is a unique nine-digit code that helps 2727 identify and link more than 57 million companies 2728 worldwide. See http://www.dnb.com/dunsno/list.htm. 2730 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 2731 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 2732 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and 2733 RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 2734 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 2735 Lee. January 1997. 2737 [HTTPS] Hyper Text Transfer Protocol (secure) transported using 2738 The TLS Protocol (see RFC 2246, T. Dierks & C Allen. 2739 January 1999. 2741 [IOTP] The Internet Open Trading Protocol, David Burdett et 2742 al. See RFCxxx. This document is currently in the RFC 2743 editor queue. Also see http://www.ietf.org/internet- 2744 drafts/draft-ietf-trade-iotp-v1.0-protocol-07.txt. 2746 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 2747 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 2749 [MONDEX] A proprietary electronic cash product where cash is 2750 stored on a smart card. See http:/www.mondex.com/ 2752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2753 Requirement Levels", BCP 14, RFC 2119, March 1997. 2755 [SET] Secure Electronic Transaction. See http://www.setco.org 2757 [SMTP] Simple Mail Transfer Protocol, RFC 821, J. Postel, 2758 August 1982 2760 [SSL/TLS] SSL is a standard developed by Netscape for encrypting 2761 data over IP networks. See 2762 http://home.netscape.com/eng/ssl3/index.html. TLS is 2763 the likely successor to SSL being developed by the 2764 IETF. See http://www.ietf.org/internet-drafts/draft- 2765 ietf-tls-protocol-05.txt 2767 [URI] Uniform Resource Identifiers (URI): Generic Syntax. T 2768 Berners-Lee, R. Fielding, L. Masinter. IETF RFC 2396. 2770 [URL] Universal Resource Locator (URL). R Fielding, IETF RFC 2771 1808 2773 [XDSL] The W3C Schema language specification. See 2774 http://www.w3.org/TR/xmlschema-1/ 2776 [XML Recommendation for Namespaces in XML, World Wide Web 2777 Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- 2778 xml-names" 2780 [XML.org] A repository designed to hold definitions of XML 2781 Documents. See http://www.xml.org. 2783 [XML] Extensible Mark Up Language. A W3C recommendation. See 2784 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 2785 February 1998 version. 2787 [XMLDSIG] XML Signature Core Syntax and Processing. Specifies XML 2788 digital signature processing rules and syntax. A W3C 2789 Working Draft. See http://www.w3.org/TR/xmldsig-core/. 2791 [XMLMSG-CDE] Common Document Exchanges. Defines a number of Common 2792 Document Exchanges that are generally applicable to 2793 many situations. 2795 [XMLMSG-CME] XML Messaging - Common XML Message Elements. Contains 2796 definitions of elements and attributes used to 2797 construct messages that conform to XML Messaging. To be 2798 completed. 2800 [XMLMSG-DCD] Document Choreography Definitions. Describes how the 2801 sequence in which documents are exchanged may be 2802 defined, agreed between the parties involved and then 2803 used dynamically to determine the way in which a 2804 particular type of business service or process is 2805 carried out. 2807 [XMLMSG-DET] Document Exchanges and Transactions. Defines standard 2808 templates for exchanging documents between parties that 2809 can be used to implement transactions that support 2810 different types of services and processes. To be 2811 completed. 2813 [XMLMSG-RM] Reliable Messaging. Defines how to exchange messages in 2814 a way that is reliable, robust and resilient and 2815 results in "guaranteed once-only" message delivery. 2817 [XMLMSG-SM] Secure Messaging. Describes how digital signatures and 2818 other methods such as [SSL] may be used to ensure the 2819 tamper resistance and authenticated exchange of 2820 messages. 2822 9. Author's Address 2824 The author of this document is: 2826 David Burdett 2827 Commerce One 2828 1600 Riviera Ave, Suite 200 2829 Walnut Creek 2830 California 94596 2831 USA 2833 Tel: +1 (925) 941 4422 or +1 (650) 623 2888 2835 Email: david.burdett@commerceone.com 2837 The author would also like to acknowledge everyone who worked on the 2838 development and implementation of [IOTP] on which many of the ideas 2839 in this specification are based and the numerous individuals who have 2840 reviewed earlier versions of this document and provided their most 2841 helpful comments. 2843 File Name: draft-ietf-trade-xmlmsg-requirements-00.txt