OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: 2000-0911-ebXML TRP DELIVERY MATRIX



 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.

 

 

  1. 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:

  1. Documents or messages may be time stamped securely with a digital signature
  2. Secure time stamps may be generated by a trusted third party
  3. 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:

  1. In multiple messages
  2. 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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC