2000-0911-ebXML TRP DELIVERY MATRIX

[Dick Brooks <dick@8760.com>]

 The previous attempt to send a MS Word document had problems. Here is an
HTML version of the Delivery Matrix.

 2000-0911-ebXML TRP DELIVERY MATRIX

Title: DELIVERY MATRIX

DELIVERY MATRIX

Draft Version: 0.2

Date: October 22, 2000

Author: ebXML TR&P Group

 

PHASE ONE FUNCTIONAL REQUIREMENTS

 

 

USE CASES

 

The functional requirements specified for phase 1 should be sufficient to support the following user scenarios:

 

1. A party wishing to send unacknowledged messages to another party or set of parties (e.g. send a stock price update every 15 minutes)
2. A party offering a server with services (e.g. RPC's) in which a "client" invokes a service on a server and receives a response (e.g. a stock quote service where a party requests a stock quote for a particular symbol)
3. A party wishing to exchange data with another party. Data is sent from originator to recipient, a transport level positive acknowledgement is issued by the recipients messaging service to the originator indicating a successful transfer.
4. A party wishing to exchange data with another party has agreed to encrypt the payload. The PA specifies the agreements on the encryption keys and algorithms. Data is encrypted by the originator and sent to the message service handler. The message service handler creates the message header and sends the message to the recipient. The receiving message handler hands the message to the To recipient for decryption of the payload.

 

FUNCTIONAL REQUIREMENTS

 

Core Functionality

Functional Requirement	Reference	Comments
4.1.1) documents expressed in either XML or other digital format wrapped in message envelope...	line 110	btdt (been there, done that, have the t-shirt to prove it;-)
4.1.2) multiple document support	line 112	btdt
4.1.3 a) physical or logical address	line 114-116	logical address support
4.1.4) messages transported over variety of protocols (transport neutral)	line 118	normative bindings for HTTPS SMTP & FTP initially, others later (possibly)
4.1.5) messages with globally unique id	line 120	this has been discussed and I believe all are on-board.
4.1.6) reference to previous message	line 121	btdt
4.1.7) message timestamp	line 122	btdt
4.1.13) message manifest	line 132	btdt
4.3.2 serial or parallel delivery	line 166
4.7 motherhood and apple pie	line 234	platform independence is a given

 

Reliability

            note: references are to ebXML TRP Requirements document v0-96

note: Reliable Messaging Features are added to base and are not optional for interoperability

Functional Requirement	Reference	Comments
Delivery “At Most Once”	4.2.1(a)	Algorithm guarantees the same message is never passed more than once to the Receiving Party’s MSH
Report failure to Sending Party	4.2.1(b)	Sending Party’s MSH will report failure (of delivery to Receiving Party’s MSH) to Sending Party if requested; not sure how to do this without timeouts…
MS must support direct connections between MSHs		Doesn’t support multi-node networks (e.g. intermediate pass-through MSH between the Sender MSH and Receiver MSH)
MS does not recognize transport-specific properties (QoS, reliability functions, etc.)		Sending Party just decides “send reliably or not”
Message ordering not specified beyond simple ACK of each message

 

Trading Partner/Discovery

Functional Requirement	Reference	Comments
Include TPA-related message routing Information in message header	See comments	The basic TPA-related routing information is complete at this time.   The Overview and Requirements specification should be updated to cover TPA requirements and connections between the TRP and TP teams.

 

Error Handling

Functional Requirement	Reference	Comments
failure to deliver shall be reported, if the sending party requires it.	section 4.2
inability to send a document may be notified to the party that sent the document	section 4.2
Error messages should be capable of reporting on: a) errors associated with the underlying transport protocol, e.g. HTTP b) errors in the message wrapper, message header or message routing information c) errors with the way documents are wrapped inside their message envelopes d) errors associated with failed attempts at reliable once-only delivery of messages e) errors in the documents that are being transported g) abnormal errors with the services that processed the documents (e.g. the service crashed)	section 4.2

 

Service Interface

Functional Requirement	Reference	Comments
Define a simple, conceptual service interface that maps incoming messages to unique actions within specified application service.	5.2	Sections 5.2.2 though 5.2.5 describe choreography and process that belong in the BP requirements, not the TRP requirements.
Define header elements that support phase 1 mapping.	5.2

 

Transport/Packaging

Functional Requirement	Reference	Comments
Documents, expressed either in XML or other electronic formats, shall be able to be wrapped inside a message envelope for transporting between the parties involved in eCommerce.	section 4.1
Messages may be transported over many network protocols (e.g. HTTP, SMTP, CORBA, 118 JMQ, MQSeries, MSMQ, etc)	section 4.1	Propose limiting scope in phase 1 to HTTP, SMTP, FTP
Servers/systems that support the exchange of documents shall be treated as "black boxes"	section 4.7
The method used to transport documents shall be completely independent of: a) the hardware used by the server/services at each end b) the software or systems architecture of the server/services at each c) the language used for implementation of systems and applications.	section 4.7
3) Support for a service shall be expressible solely in terms of the type and sequence in which documents (and their message envelopes) are to be exchanged	section 4.7
4) The ebXML Transport, Routing and Packaging specifications shall be suitable for implementation on hardware that varies from a very simple device to a large multi-processor/system complex	section 4.7
1) The protocol shall be extensible to support (by use of protocol versioning): c) additional types of data in message headers and message routing information d) new values for codes	section 4.9

 

Security

Functional Requirement	Reference	Comments
Access controls to prevent unauthorized access		when permissable by underlying transport mechanism
Payload documents may be digitally signed as defined in the PA by the From Party		Decided at Dallas F2F 9/2000
Payload can also be encrypted as defined in the PA by the From Party		Decided at Dallas F2F 9/2000
On the wire encryption of message headers possible (SSL, TLS) through transport level security mechanisms as defined in PA		Decided at Dallas F2F 9/2000
Signatures on digitally signed documents may be used by the To Party to:                                                                i.            Verify the authenticity of the From Party                                                              ii.            Provide non-repudiation of origin or receipt ( we are not able to prove sending without modification unless we have some hash and signature over the header).		Decided at Dallas F2F 9/2000

 

 

 

Miscellaneous

Functional Requirement	Reference	Comments

 

PHASE TWO FUNCTIONAL REQUIREMENTS

 

 

USE CASES

The functional requirements specified for phase 2 should be sufficient to support the following user scenarios:

 

1. A third party service bureau operating as a proxy for one or more trading partners (multihop/multinode)
2. Two trading partners engaged in multi-message protocol exchanges where the multiple exchanges are considered an atomic unit or related set (CHRIS FERRIS TO PROVIDE REVISED WORDING)
3. Two trading partners can cryptographically process data (encrypt/sign and decrypt/verify) before/after.
4. Two trading partners engaged in a message exchange may agree to cryptographically sign and verify either the message header, the routing header(s) and/ or the payload. The sending message handler or the originator may perform the signing of the payload. The sending message handler signs the message header.   A routing header may be appended to the message & message by the message service  handler. The routing header may also be signed by the message service handler.  Policy in the PA states which message service handler is responsible for verification of the signature.
5. Communication via multiple intermediaries. Same as Scenario 3 but one of the hops is an intermediary, which forwards the message to the recipient. The Sender wishes to enforce the non-repudiation property of the route. Any intermediate message service handler that appends a routing message must log the routing header information. Signed routing headers and the message headers must be logged at the message handler which passes the message to the “to” party to provide the evidence of non-repudiation.  Real life examples: Sun and Cisco trading through their component net markets. Slam Dunk Networks charge per KB of the transferred message.

 

 

6. Communication via an intermediary using a variety of transports. Same as Scenario 3 but the intermediary forwards the message to the recipient using a different transport (e.g. FTP). The Sender wishes to enforce the non-repudiation property on the route. Real life example: connection to a remote partner in Africa over an unreliable network segment (Intel).

 

 

 

 

 

 

 

FUNCTIONAL REQUIREMENTS

 

Core Functionality

Functional Requirement	Reference	Comments
4.1.9 replyTo	line 126	belongs in TPA, probably phase 1
4.1.8 message lifetime	line 124	belongs in TPA, probably phase1
4.3.1.c intermediary router	line 165
4.5 auditing/audit trails	line 193	this needs some refinement IMHO
4.6.8 message (set) status	line 222	probably belongs in service interface discussion
4.9 extensibility	line 256

 

 

Reliability

 

Functional Requirement	Reference	Comments
MS supports multi-node networks, but each node is just pass-through		Intermediate MSH handler nodes allowed, no processing
Sending MSH can set time-out for message and will report error if MSH-level ACK not received within timeout		Phase 1 just requires error notification if no delivery; this requirements allows setting of a specific timeout period
Scalability		Must scale to large networks
Sequence of related messages can be established and forced for transmission	4.2.1(e)
Sending application may establish a group of unordered messages to be sent reliably

 

 

 

Trading Partner/Discovery

Functional Requirement	Reference	Comments
Identify TPA requirements related to reliable messaging, error reporting, and other new functions; provide definitions.
Update TRP specifications to reflect progress on the TP specification
Identify and define TPA-related information about BP and Transport levels, which is needed in the upper and lower interfaces to the messaging service.		There may or may not be any such information.

 

 

Error Handling

Functional Requirement	Reference	Comments
Error messages should be capable of reporting on: f) errors in the sequence in which messages are exchanged	section 4.2
3) Inquiries should be possible to determine why Message Sets failed, (see Message Set Status Inquiry below).	section 4.2

 

 

 

Service Interface

 

Functional Requirement	Reference	Comments
Define an interface for invoking messaging system semantics, including: send, receive, notify, inquire.
Incorporate error handling, timeouts, etc. into the service interface.
Verify that the header and message format definitions are sufficient for implementing the semantics
Verify that service interface properly supports (and does not contradict) Phase 2 TPA and BP.
behind the services interface.

 

 

Transport/Packaging

Functional Requirement	Reference	Comments
Support for MQSeries, JMq, MSMQ, Corba

 

Security

Functional Requirement	Reference	Comments
Message headers and payload documents may be digitally signed by MSHs		Decided at Dallas F2F 9/2000
Payload can be encrypted by the MSH		Decided at Dallas F2F 9/2000
A single digital signature may be used to sign documents (payloads and message headers) within the same ebXML message		Decided at Dallas F2F 9/2000
A Receiving MSH must be able to:                      i.            Verify the authenticity of the From Party and/or the Sending MSH                    ii.            Provide non-repudiation of origin or receipt (if the message header and/or routing header is signed)		Decided at Dallas F2F 9/2000
An extensible set of credential mechanisms must be supported for authentication of principals(from/to/MSHentities), including username/password and digitally signed messages		Decided at Dallas F2F 9/2000
Ensure that the content of the message has not  been modified during message delivery		Decided at Dallas F2F 9/2000
Whenever possible, a Receiving MSH must be able to identify and authenticate the Sending MSH, and thus prevent an unknown entity from accessing the Receiving MSH from the network		Decided at Dallas F2F 9/2000
A signed routing trail of MSHs through which a message has passed should be indentifiable and analyzable after transmission completes, showing the identity of each MSH. If specified by a PA security policy, each MSH must sign the routing header, and the final MSH must persist the routing trail.		Decided at Dallas F2F 9/2000
Verification  by MSH  or to entity (as specified in the PA, with failure reporting) of                                  i.            credentials for authentication and                                ii.            signatures for data integrity		Decided at Dallas F2F 9/2000
Enforcement of the PA authorization policy, if any, by the Receiving MSH(s)		Decided at Dallas F2F 9/2000
Support of a minimum set of security protocols available in all MSH implementations for interoperability: PGP? S/MIMEv3? S/MIMEv2 (even if an informational RFC? Subset/profile?) [TBD]		Decided at Dallas F2F 9/2000
Provide hash information for each document reference in the manifest, consisting of a domain of computation, type, value and encoding scheme		Decided at Dallas F2F 9/2000

 

 

 

Miscellaneous

Functional Requirement	Reference	Comments
The set of related documents and messages that are contained within a Message Set, shall be: a) globally uniquely identified b) related to one another. 2) Two or more Message Sets that are related to one another should be capable of being linked together by enabling one Message Set to refer to another Message Set's Message Set identifier. 3) A trace or path through the services and parties through which documents have passed should be identifiable and analyzable after the event	section 4.5
1) If a service that accepts messages becomes temporarily unavailable after starting a Message Set it shall be possible to recover from the failure and deliver the message once the service is available	section 4.8
2) If a service that accepts messages is temporarily unavailable before starting a Message Set then it shall be possible to recover from the failure and deliver the message once the service is available	section 4.8
3) If the delivery of a message is considered not possible by the originally intended method, then a) alternative methods of delivering the message may be used if available, and/or b) the end state of the Message Set shall be capable of rollback to a consistent state.	section 4.8

 

PHASE THREE FUNCTIONAL REQUIREMENTS

 

 

USE CASES

 

The functional requirements specified for phase 3 should be sufficient to support the following user scenarios:

1. A publish/subscribe scenario in which a publisher provides a service to subscribers. Information can be sent to interested parties using a distribution list type of processing.
2. Parties offer a quality of service capability so that trading partners can query a server to determine the various options for communicating in a data exchange. For example, a service may offer 15 minute stock quotes for one price and real time stock quotes for another price.
3. Communication via an intermediary. A party wishes to exchange a business message with another party. The sending party has defined a PA and the receiving party has accepted the agreement including a Confidentiality Policy.  The message header and the Payload is encrypted and sent from originator to an intermediary message service which is responsible for routing the request to the appropriate set of business partners defined by the recipient’s organization and documented in the PA.  A positive acknowledgement is issued by the message service as well as the target recipients to the originator indicating a successful transfer. All routing headers have been digitally signed.Real life example: requested by Compaq at a RNIF meeting.

 

 

 

FUNCTIONAL REQUIREMENTS

 

Core Functionality

 

Functional Requirement	Reference	Comments
4.6.5 query if service available	line 216	this probably belongs in service interface, but should be deferred to phase 3
4.6.6query hours of operation	line 218	same comment. Not sure that we should delve into this. Should reconsider requirement
4.6.7 congestion management	line 220	again, this seems related to grey area of functionality
4.6.9 discovery	line 224	this is related to RR and TP work and may be impacted by UDDI discussion. In any event, probably can be deferred to more advanced feature set reserved for phase 3
4.3.1.b multiple recipients	line 162
4.3.3 pub/sub semantics	line 168	this actually sounds like a service built on TR&P MS and begins to enter the grey area but which is application independent and thus should possibly be considered within TR&P scope

 

Reliability

 

Functional Requirement	Reference	Comments
MS supports multi-node networks, and each node can perform processing on the message
Performance		Must deal with performance issues in large networks…?
Sending application may establish a group of ordered messages to be sent reliably

 

 

Trading Partner/Discovery

Functional Requirement	Reference	Comments
Update the TRP specifications with regard to new messaging function that requires TPA-related information in the message header.

 

 

 

Error Handling

Functional Requirement	Reference	Comments
Error messages should be capable of reporting on: h) business failures where the service completed but did not realize its hoped for outcome (e.g. out-of-stock)	section 4.2

 

 

 

Service Interface

 

Functional Requirement	Reference	Comments
Verify that service interface properly supports (and does not contradict) Phase 3 TPA and BP.

 

Transport/Packaging

Functional Requirement	Reference	Comments
1) The protocol shall be extensible to support (by use of protocol versioning): e) new ways and methods of exchanging data	section 4.9

 

Security

Functional Requirement	Reference	Comments
For privacy and confidentiality purposes, all or part of the elements in a message may be encrypted prior to sending
Secure timestamps: Documents or messages may be time stamped securely with a digital signature Secure time stamps may be generated by a trusted third party Timestamps shall be recorded in a location independent way (e.g. UTC)
Digital signatures may be used to bind the documents and message sets in the sequence in which they were used.
Multicast support, allowing encryption and signatures with different keys (distribution lists, publish/subscribe?)
Provide a summary of non-normative ebXML Security Best Practices document, especially suitable for SME
A single digital signature may be used to sign documents (payloads and message headers) located: In multiple messages In a message and somewhere else (for example the content at a URL)

 

 

 

Miscellaneous

Functional Requirement	Reference	Comments
Parameters must be present in every TSLA that: . 1) support Session based and Long Term Transactions 2) enable recovery from failure to receive an anticipated response(s) to a message 3) enable a Receiving Service to inform a sender of a message of the Receiving Service's expected maximum Response Time(s) 4) enable a sender of a message to inform the recipient of a message, of the Response Time(s) that the sender expects 5) enable a sender of a message to discover if a Receiving Service is operational and therfore able to receive messages 6) enable a sender of a message to discover the hours of operation of a Receiving Service The hours of operation is the period of time that the service is available to process the message 7) enable a Receiving Service to indicate to the sender of a message that it is too busy to process a message within expected timeframes. This supports congestion management 8) enable a sender of a message to discover from a Receiving Service the current status of a Message Set. This is Message Set Status Inquiry.  This is particularly relevant if Asynchronous processing is being used 9) enable the Sending and Receiving Parties to discover and agree: a) the document choreographies that can support their processing requirements b) the parameters that control how the parties will use cryptography c) how they will achieve reliable messaging and error handling when required d) the transport protocols to be used 10) TSLAs may be negotiated between two Parties that apply to: a) an individual message b) an individual message set c) all messages associated with one or more services d) all interactions between two parties	section 4.6