TRP v0.98 - Comments

["Kudela, Melanie" <MKudela@uc-council.org>]

Our comments, from UCCNet and UCC, are directed at the implementation of the
standard and at a section-by-section  review of the document:

- we have a requirement for an additional layer which we call the command
layer and which you can read more about in the attached document. However,
there is no way for us to plugin this layer, without breaking the standard.
 <<Architecture 011701.doc>> 
- Is two pass parsing required to parse the message and payload; and if yes,
what are the implications on performance?
- One difficulty that we are having is that there are tags that are not
present in the t&r spec, but are necessary for us to transport and route our
messages correctly. There is no extensibility to allow us to add our tags to
the ebXML t&r message header, manifest, etc. without breaking the standard. 
-Manifest structure will work but is not perfect 
-Requires use of UUID algorithm for message id/MIME identifiers 
-Requires use of MIME structure - both this and the previous point make it
more difficult to involve a SME with out buying tools to implement it.
Cannot simply create an XML document and send it, you must jump through
hoops to create the proper message.

-  of major importance to us at this time. It seems that ebXML and EDIINT
are
alternatives and they don't  fit together. Nowhere in the doc was
EDIINT even mentioned as a transport or in any a partner spec.

- Does anyone have prototype ebXML message transport handlers out there?
(From our experiences with EDIINT vendors, it seems that their products are
just slightly ahead of being prototypes and adoption of EDIINT is rather
limited.) It seems that ebXML is the successor to EDIINT and the two aren't
necessarily compatible.

ebXML Participants (2)
Why are there so few "trading companies" represented? (I count Chrysler and
Kraft) Perhaps they are better represented on other parts of the ebXML
efforts.
Curious especially by the lack of representation by the financials and
software companies that serve the financials. Messaging has been going on
there for 30 years. For example, I would have expected someone like Reuters
or Hogan to be participating.
Introduction (3)
It looks like a SOAP processor is now needed? (I need to read up on SOAP
some more to further understand that implication)
Why no mention of EDIINT anywhere?
This section should show how the T&R stuff fits into the ebXML architecture
as a whole. Where does the message transport service end and something else
begin?
The protocol should be described using a protocol stack. Need to show how
the different services communicate with their peers. Need to show
dependencies between services in stack form. Each service is responsible for
wrapping / unwrapping / processing some of the message.
Our specific interest: are we looking at this from the point of view of
developing it or utilizing it?
Comments in various places say that this is supposed to be a "low-cost,
simple" messaging scheme. Nothing about it seems to be low-cost or simple.
It's not overly baroque, but I wouldn't't say that a low cost hack could
implement it.
System Overview (6)
The "message service overview" and accompanying picture are not consistent.
Missing from the picture are "heading parsing", "security services",
"reliable messaging services".
Missing from the textual description is "authentication, authorization and
repudiation".
These services should be presented as a protocol stack. There are
dependencies and an orderly path that a given message needs to take through
the message handler.
Where is the SOAP processor? What is its role?
Need to show interaction scenarios between the components. (or is that done
elsewhere?)
Packaging Specification (7)
Was the addition of SOAP the significant change made since the last draft?
(think so)
Why only a single header?
Is there a limit to the number of payloads? Is there a practical limit? Can
a potential recipient set /advertise this limit if their implementation has
some sort of limit?
ebXML SOAP Extensions (8)
Judging from the number of comments that I made, this chapter is too long.
I can't make heads or tails of section 8.2 (line 310). It seemingly
contradicts itself in the first sentence. The title is "ebXML SOAP Envelope
Extensions", but then in the body it first says that it does not extend,
then says it does extend. ENGLISH PREFERRED! 
8.2.2 Regarding signatures, is (can be?) the header separately signed? Or
does the signature in the header sign the entire contents? Well, just a bit
confused here because if the signature is part of the header, then the
signature can't sign the header (recursive, no?) Why isn't the signature for
the entire message a separate part?
8.3 Is all of the message header to be in plaintext? Or can it be encrypted?
If mandated to be in plain-text, will it be disclosing any private trading
relationships since it has to, from, service, action, etc. in it? For
example: to:levi's, from: walmart, service: private-label-purchasing,
action:create PO
8.5.4 What is the intent for a single service/action pair with regards to
the handling of multiple payload documents? It seems that there is no way
for packaging of heterogeneous types of payload and sending it all to a
single service unless that service is extremely generic in nature. Is there
any to allow a service/action pair in a manifest entry so that a piece of
payload could be directed to a service different from other pieces?
8.5.1 To and from elements: what are the allowable types of identifiers? How
are they resolved to physical entities? (can we chant "registry"?)
8.5.1 To what kinds of entities are to/from to refer? The business parties
involved in the transactions? The message transport instances that are
sending the messages? How far up/down the chain? How do they correlate to
the physical endpoints that are transporting messages?
8.5.2 CPAId: (later on I found out sort of what a "CPA" is) CPA needs to be
defined.
8.5.3 Conversation ID: it implementers free to choose how they identify and
store ...... and SHOULD provide a facility for mapping.... THEN won't an
implementer need to implement a map to every other implementation that it
converses with? This seems not particularly interoperable.
8.5.4 Service: who assigns service names? Who regulates? How are they
published? Is there some kind of "endpoint capabilities" query?
8.5.4.1 Type attribute: I can't understand these paragraphs. Rewrite.
8.5.7.1 MessageOrderSemantics: how to detect missing messages? Is there a
concept of a "sequence number gap"? (I've implemented numerous systems like
that in the past). What is the receiver to do if a message that makes up a
conversation is missing? Is there a way to request re-transmission?
8.5.7.2 DeliveryReceiptRequested: if it is used to provide a business-level
acknowledgement, then call it that. Don't call it a delivery receipt if it
isn't really a delivery receipt.
8.5.8 Who signs a signed receipt? The message handler that receives the
message, or the end party to which it was addressed?
8.5.8 Sequence numbers within a conversation: if I have multiple, dynamic
conversations outstanding, and I have to maintain a sequence number for
each, my bookkeeping will get somewhat complex.
8.5.8 Sequence reset: incredibly confusing. Rewrite.
8.5.8 Is there a way to request re-transmission of previously received and
acknowledged messages? This is very important in a disaster-recovery
scenario. A backup site may not be 100% in sync with the primary site. In
the past, the first thing that a backup transport would do upon activation
is request retransmission of message that have been sent since a given point
in time to being it up to the current set of messages that had been sent to
it. Of course, when the are multiple senders, this can be very difficult. It
would probably need to poll all of its partners and make sure that it is in
sync with them.
8.5.8 Also this kind of retrieval is useful in problem investigations.
Is there any required "heartbeat" message that is to be sent periodically so
that we know that everyone that we expect to be alive truly is?
8.6 Mult-hop: not entirely sure how this all works. Does each hop create a
new header and re-sign the message? Is an intermediary hop allowed to do
anything but forward the message? What do conversation and sequence number
mean in a multi-hop context? Do they identify the end-to-end conversation or
conversations between the intermediaries? What do to/from mean in a
multi-hop context?
8.7.5 Can things like reliableMessagingMethod change between hops? Or does
what was specified by the originator constrain what the intermediary hops
can do?
8.7 How does non-repudiation work in multi-hop context?
8.7 What are legal responsibilities of intermediaries?
8.7 "via" element: how many hops forward does it apply?
8.7 Signature: what is scope of text included in signature? Who's signature
is it? The "from" party? The message transport system that is sending the
message?
8.12.5 messagerStatus attribute: can there be a value of "accepted" or
"rejected"? Or do we consider "rejected" messages to be received? Where is
"persistDuration" defined?

Reliable messaging (10)
10.2.3 time to live: what does timeToLive mean in a multi-hop context? The
time to make one hop? The time to be received and acknowledged by the
ultimate recipient?
10.2.6 persistDuration: who determines this? Does the sender mandate it? Or
the recipient?
10.3 reliabl e messaging protocol: this looks remarkable like what we
invented one afternoon for UCCnet. I think that there must be more to it,
no?
How does recipient request re-transmission of lost messages? (detected via
sequence number gap)
10.3.1.5 duplicate message handling: Re-sends should be marked as "possible
duplicates".
Security (12)
12.3.1 persistent digital signature: who is the entity signing the message?
How do we correlate vs. the "from" party?

Architecture 011701.doc