Re: TRP v0.98 - Comments

[christopher ferris <chris.ferris@east.sun.com>]

Melanie,

Thanks for the very thorough review!
Please see my comments/responses below.

Cheers,

Chris

"Kudela, Melanie" wrote:
> 
> 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>>

I see the command layer as being the substance of the message payload,
consequently, it is a payload object that is identified in the Manifest
and held in a separate MIME body part than the SOAP Message.

Alternatively, you *could* also carry the command object as a SOAP
extension header as a sibling of the ebXML SOAP extension headers.
That would not be breaking the specification IMO.

What else did you have in mind? How would that alternative violate the 
spec? I'd be glad to help you work through this.

> - Is two pass parsing required to parse the message and payload; and if yes,
> what are the implications on performance?

When you say two pass parsing, I'm not sure that I follow. Are you
asking
if it is necessary to separately parse the header and any payload
objects,
you *could* do it that way. Performance is going to be more a function
of
the implementation than anything else IMHO. 

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

I disagree with this assertion. The Manifest is extensible as is the
TraceHeader. In addition, because ebXML TR&P is based on SOAP, you are
also free to add namespace qualified SOAP header extension elements
from your or other schemata and be in complete conformance with the
specification..

> -Manifest structure will work but is not perfect

The Manifest is extensible as follows:
	- foriegn namespace qualified element content MAY be added
	to the Manifest and Reference elements. 

> -Requires use of UUID algorithm for message id/MIME identifiers

Actually, you can use any URI as long as there is a
Content-Location MIME header with that corresponding URI
in the payload MIME body part(s). This is discussed in the
SOAP Messages with Attachments specification as well as in 
RFC 2557. 

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

Here I must disagree. MIME parsers are readily available for free
(JavaMail for one and I am quite sure there are others as well). 
The Apache SOAP implementation, and quite likely many if not
all of the 37 odd SOAP implementations, will support most of the
necessary
functionality upon which to build a successful and conformant
ebXML Message Service. 

I firmly believe that there will soon be ebXML "toolkits" available,
possibly at no charge. This, like many other things will become a
commodity
component.

> 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?

Yes, there were a number of POC participants (vendors) with prototype 
implementations. There are also a few more since then.

> (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)

Technically, you wouldn't need a SOAP processor, but it would certainly
make things easier as most of the gory details would be handled for
you by the SOAP Processor.

> Why no mention of EDIINT anywhere?

When we did our requirements gathering, we researched EDIINT.
Why do you feel that it should be more prominently
mentioned in the specification.

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

That would be suggesting an implementation. I don't think we want to
go there.

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

Others may disagree. I've written one (a hack at present) in less than
two weeks. Most of the components needed are available for free (MIME
parser,
SOAP Processor, web servers/servlet engines, XML Parsers, XSL 
transform engines...)

Mostly, I think that there will be a few reasonable implementations
out there that are either free or very inexpensive and everyone
else will simply use them.

> 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?

There is no limit, but there may be a practical limit. "Advertising"
is not addressed by the TR&P spec, but more appropriately by
either the CPP/CPA spec (trading partner team) or by the BP
specification to which the CPP/CPA refers.

> 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!

Point taken. 

> 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?

An XML Signature can sign anything, including the document in which it
is
a child element. An XML Signature can exclude itself from the digesting
process. In short, the Signature element can sign:
	- the whole message (Message Package) (except the Signature element
itself)
	- the SOAP message (the SOAP-ENV:Envelope document and all its
	descendants (except the Signature element and its descendants)
	- selected element content in the SOAP-ENV:Envelope
`	- the payload object(s) 
	- stuff on the web
	- any combination of stuff.

(XML Signature is really pretty powerful stuff;-) The section on
Security
describes how to sign the Message Package (header and payload). An
implementation
and/or use case is free to determine what will be signed.

Note also that a Signature could also be added to the message as 
payload if it is generated by the application. This can be either as
S/MIME or as a solo XML Signature document or as an XML document
that contains an XML Signature element.

> 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

When the W3C finishes its work on XML Encryption and releases
it as a Recommendation, then the TR&P spec will be revised to accomodate
use of XML Encryption for persistent confidentiality of selected
content in the ebXML SOAP Message. 

For now, nonpersistent confidentiality is available via use of
transport layer security mechanisms such as SSL and IPSEC, both of which
provide for encryption on the wire.

Persistent confidentiality of the payload can be provided by utilization
of S/MIME
or PGP/MIME encryption of the payload object(s). The TR&P spec
doesn't define a standard for this because the payload is outside
the scope of the specification.

> 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?

This is a good point, and was discussed quite a bit when we were
first developing the header elements. Some of us advocated that
the service/action should be applied to each item referenced
in the Manifest rather than to the message as a whole. Others
favored the approach that had a single service/action in the message.
They out numbered those of us in the minority on this issue.

> 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"?)

Any type you choose may be used. Obviously, both parties need to
agree and understand the means by which the PartyId is
to be interpreted.

> 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?

All good questions. Typically, it would be the business parties
involved, but in theory, it could be anything.

> 8.5.2 CPAId: (later on I found out sort of what a "CPA" is) CPA needs to be
> defined.

See the CPP/CPA specification also being developed at ebXML by the
trading partner team.

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

No, the conversation id is just that, an identifier. A code
that distinguishes one conversation from another. A conversation
is an instance of a choreography that is either defined
or referenced by a collaboration protocol agreement (CPA).
e.g. If you and I agreed to exchange messages using the
process defined by RosettaNet PIP3A4, then a conversation would
be one instance of a PIP3A4 exchange (one PO, one confirmation, etc.)

The mapping refers to the fact that the scheme that I use
to create and maintain conversational state may be very different
than yours. If I start the conversation, then I get to choose the
key (ConversationId) that I use to refer back to that state
when you respond to my message. You as the recipient would
probably want to create and maintain conversational state
as well, but since we're using my key, you need to:
	a) recognize that this is a new conversation
	b) create your own instance of conversational state (which
	may result in assignment of a very different key value)
	c) map the two keys so that my key (ConversationId)
	can resolve to your state in your system.

Basically, this is a hash table that maps my key to your state.

> 8.5.4 Service: who assigns service names? Who regulates? How are they
> published? Is there some kind of "endpoint capabilities" query?

I think that you need to read up on the CPP/CPA. That will answer
many of your questions. As to who regulates Service and Action
values, these are not necessarily regulated, although an organization
such as UCCNet might wish to standardize on these and publish
a regulated set of service and actions for its business processes.
However, it can also be the case the the name of the service is
determined by the deployer of that service. The means that she
communicates this to her partners is via the CPP, or, she could
publish the service in a registry such as UDDI.

> 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?

No, but if the message is sent reliably, then it will be resent if
it is not acknowledged in the time allowed.

> 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?

Again, a good question. That is determined by whose private key is used
and typically, this will be spelled out in the CPA.

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

Possibly, but I think that it actually is no different than if
I have to maintain a sequence number for each party. The reason
that it is scoped to a conversation is that as you have cited
previously, I can have multiple outstanding conversations
that may be quite unrelated. I wouldn't ever want to impose a
restriction
that I have to hold up processing of conversations which do not
have gaps in sequence while I wait for the gap to be filled.

This allows conversations to be run in their own thread, independently
from other conversations which allows for greater (IMHO) scalability.

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

Good point, but no, we have no provision for this, mostly because
we never got around to addressing the issue. The mechanism for
requesting
this sort of thing IS in place (the Message Service Handler Services),
but we haven't gotten around to defining the service. 

Note that this also imposes quite a different set of persistence
requirements on an implementation. That would certainly make it more
complicated and (probably) expensive... Hopefully, we will get to
this and the other issues we still have on our plate (our "phase III"
deliverables mostly) in whatever forum/standards body the ebXML
specifications
are transitioned to for their stewardship.

> 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?

Please see section on Message Service Handler Services. There are
Ping/Pong and Status services defined.

> 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?

All great questions. In short, we do not define what an intermediary
does
or can/cannot do and especially how it does that. As long as they
conform to
the spec, that is clearly their perview.

> 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?

Yes, please see the Via element.

> 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?

One.

> 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?

A message can be multiply signed. The first Signature MUST be the
one generated by the original sender (From).

> 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?

In the CPA.

> 
> 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?

TTL is the time to live for the message, regardless of how many
hops it takes to get to its ultimate destination.

> 10.2.6 persistDuration: who determines this? Does the sender mandate it? Or
> the recipient?

It is something that the parties agree.

> 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?

No. It is pretty simple.

> 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".

That is an optimization that could be explored. The problem is that it
would change the header which, if signed, would invalidate the
signature.

> Security (12)
> 12.3.1 persistent digital signature: who is the entity signing the message?
> How do we correlate vs. the "from" party?

That is determined by the CPA and typically something that the
parties work out between them.

> 
>   ------------------------------------------------------------------------
>                               Name: Architecture 011701.doc
>    Architecture 011701.doc    Type: Winword File (application/msword)
>                           Encoding: BASE64
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard