ebXML PoC feedback to ebXML teams

[Philippe DeSmedt <PDeSmedt@viquity.com>]

All,

Please find below a compilation of the comments from the PoC team that have
come in since the Tokyo meeting. Sorry for the delay in getting these to
you. The comments are in 'raw' form, so as not to alter the intent of the
original writer.

I'd like the team to review these to make sure that they are complete
(apologies to those that I may have missed). They will then be submitted to
the individual ebXML project teams. For TR&P specifically, Dale Moberg is
the contact between the PoC team and the TR&P team. I'll be working with him
to make sure that the comments are addressed, and, where appropriate, taken
into account in the specs. For the other teams, I'd like to hear who the
contact person ought to be, so that I can coordinate with him/her as well.
Thank you.

The comments are labeled with the initials of the submitter:
[CF] Chris Ferris (Sun)
[DB] Dick Brooks (Group 8760)
[DM] Dale Moberg (Sterling Commerce)
[FN] Farrukh Najmi (Sun)
[HE/FK] Hatem ElSebaaly/Frank Kieviet (IPNet)
[KN] Kenji Nagahashi (Fujitsu)
[PDS] Philippe De Smedt (Viquity), as compiled with the PoC team at the
Tokyo meeting
[SH] Scott Hinkelman (IBM)

-Philippe

*	[PDS] the lack of precise specifications for multi-hop messaging
caused some confusion; in particular, acknowledgements cannot currently be
sent back to the original sender using the path (through the hub) that the
original message took, but rather, the acknowledgement is sent back directly
to the sender: the reason is that there is no place in the header to keep
that information; furthermore, there are various interpretations as to what
the acknowledgement should convey, i.e., received at the next hop, or
received at the final destination;
resolution: this has been brough to the attention of the TR&P working group,
which is currently taking on the specifications for multi-hop messaging;
comments:
*	[CF] I believe that the confusion lies in the fact that TR&P had
excluded multi-hop functionality from the RM spec incorporated into the
MS0.21d specification specifically because there was not agreement within
TR&P as to how best to approach the problem. The fact that the POC decided
to include a hub in the demo resulted in the confusion (IMHO). 
In hind sight, we (TR&P) should probably have made it clearer in the spec
that the multi-hop feature was excluded so that it could be further
investigated/revised from the original proposal.
I think that this also points to the issue of having a firm specification
underlying *anything* demoed by the POC. If it isn't in the spec, it
shouldn't be attempted. ("don't try this at home" comes to mind;-) It is my
understanding that Nick intends to take a harder stance on this for any
future POC demos.
*	[PDS] optionality is a problem: some of the fields in the header are
specified as optional (e.g. RefToMsgId (sp?)); optionality greatly decreases
the likelihood of out-of-the-box interoperability;
resolution: this has been brought to the attention of the TR&P woking group;
they will look carefully at all of the fields (current and future) that are
optional;
comments:
*	[CF] I thought that I understood that the issue was more of one
regarding clarifying the distinction between "optional to implement" and
"optional in cardinality or use within an instance". It is also my
understanding that the resolution was to be that we would scour the spec for
cases where there is an "optional" element in the DTD/Schema and reinforce
the language used to make it expressly clear as to the expected/required
handling of an "optional in cardinality within an instance" element in its
absense. In additon, if an element is "optional to implement" such as
SequenceNumber in the RoutingHeader then clarifying language will be added
to the specification as to the expected/required treatment as well.
We (TR&P) will endeavor to minimize the optionality within the
spec/protocol, but reserve the possibility that it be necessary to allow for
elements with cardinality requirements of 0 or more.
*	[SH] On the other email concerning optionality: True optionality can
reduce interoperability. But beware that if it is *truely* optional (not
just per DTD rules) and then made mandatory, garbage may have to be loaded
to satisfy.....
*	[PDS] default values can be a problem: 
resolution: the TR&P group suggested that we look at the latest spec (0.8),
as the number of attributes with optional values has been reduced;
comments:
*	[CF] I think that you meant default values, and yes, I believe that
we have eliminated all by the xmlns and Version attributes as having default
values.
*	[FN] Need sample TRP messages in appendix for queries
*	[FN] Need to replace use of GET on object retrieval with TRP
request/response
*	[FN] Need Ad hoc query mechanism for automated clients
*	[FN] UML diagrams truncated method names
*	[FN] Inconsistent use of Asynch Vs. Async in UML diagrams
*	[FN] Need a single DTD instead of many for RegRep
*	[FN] Using '*' for objectType in getClassifiedObjects is not clear
*	[SH] Section 7.2.2 Content Length:
The explanation is good on the definition of the length, but we either
should drop the one-line example following it or actually put in an example
where a small length can be easily understood.
*	[SH] I generally think we need another pass through the header DTD.
I would suggest that we align less to a structure of human-readability and
more to a flat structure without artificial containment (remove TPAInfo,
MessageData tags for example and put the subtags directly under Header).
Fundamentally, I favor for purposes of infrastructure the XML camp thinking
of *data* not *documents* (documents here indicating considerations leaning
toward human readability).
*	[SH] Make Manifest optional. I'm not in favor of
required-empty-tags.
*	[DB] During the last POC there were a couple of packaging related
issues. Have all the packaging related issues been resolved?
*	[DM] There are still problems when using HTTP, servlets, and some
available APIs. In order to interoperate I had to add an additional header
for the MIME-entity in the HTTP PDU. Also, when processing, I had to ignore
the real MIME-entity header (which sometimes did not even have a
content-type of "multipart/related" !!) in order to find the right MIME body
parts. So the actual bits on the wire, as seen by a sniffer for example,
would not match the ebXML packaging.  
I hope that we can get this issue thoroughly resolved by the next POC. I do
not think it is a problem with the spec as long as we continue to follow the
IETF RFCs on the layout for HTTP.
But there definitely is a problem for implementations that impact
interoperability. It is not a new problem, however. Maybe the bindings
section needs a stronger warning on the problem if it is not there already.
One answer is to reexamine the servlet IO interface and work out a way that
the sharing of the IO between web server and servlet is less subject to
confusion. What happens is that the web server needs to read the MIME
entity's headers and so advances the stream past the headers. If the servlet
then just uses the stream reference, it will miss the real headers (which
are stored on request properties ). It would be nice to make a new
inputstream class that could take the stored header data and prepend it to
the other input stream, resulting in an input stream suitable to feed
directly to a MIME multipart parser.
*	[HE/FK] Content Length (After the boundary string)
We believe that this requirement need to be dropped. We should simply
utilize the boundary string. There is no need for two ways to determine the
length.
*	[HE/FK] Need to specify what are the valid values for TPAID. We used
the following on the POC, but we were not clear what should be used.
<TPAId>
    /requester-DUNS-number/responder-DUNS-number/ItemCreate
</TPAId>
*	[HE/FK] The SMTP Bindings need to take into account the base64
encoding. The example in the documentation is misleading and insufficient.
We also need to indicate the fact that some SMTP gateways enforce some
restrictions on the message size. In fact I believe that these kind of
restrictions should be reflected in the CPP.
*	[HE/FK] Missing URLs for error reporting. 
*	[HE/FK] Routing Header should be optional. 
*	[HE/FK] Clarification on PayLoad in Acks and also when to use
MessageType Acknowledgement vs Normal.
*	[HE/FK] Lack of security. We just wanted to re-emphasize this so
that it will be addressed soon.
*	[HE/FK] HTTPS should be supported. 
*	[HE/FK] HTTP responses are not defined. 
Body of 200 OK? What in case of errors? What kind of errors are allowed,
etc. 
*	[KN] [re: TP] Values of ID type attributes should only be used for
referencing XML element within a CPP/A. Identifier (in the context of ebXML)
for ServiceInterface, etc. could be an URI, which cannot be held in ID type
attribute. These identifiers should be written in the separate XML elements.
*	[KN] [re: TP,TRP] Semantics of each element/attribute should be
specified strictly. For example, CPA DTD has Partyname element and PartyName
attribute. Which is for system use and which is just for human-readable
description? Which identifier is used for ServiceInterface, Action in the
TRP header? etc.
*	[KN] [re: TP,TRP] CPA should have information for sending transport
ack messages. POC implementation used a simple scheme that maps sender DUNS
to URI. Currently this mapping cannot be obtained from CPA.
*	[KN] [re: TP,TRP] Bootstrapping problem in CPA proposal have to be
resolved. POC assumed the CPA proposal/acceptance is a well-known service
and exchanged message between implicitly agreed interfaces. In reality, Its
transport information have to be either predescribed by ebXML specification
or found in the to-be-partner's CPP obtained from registry. Later case
requires the means (and its spec) with which CPA accepter can find which CPP
to use, ex. attatching CPP (or its URL) with the proposed CPA.
*	[FN] I assume the custom CPA proposal/acceptance protocol was just
to fill a hole in the POC flow for Tokyo. IMHO, a general purpose Event
Notification mechanism that is based on a general puprose publish/subscribe
mechanism is a better alternative. Note that I made a proposal for such a
service which articulates the CPA proposal/acceptance scenario as an
example. The proposal can be found at:
http://lists.ebxml.org/archives/ebxml-regrep/200010/msg00033.html
See section 1.3 for CPA proposal/acceptance protocol related example.

_______________________________
Philippe De Smedt
Architect
Viquity Corporation (www.viquity.com)
1161 N. Fair Oaks Avenue
Sunnyvale, CA 94089-2102
(408) 548-9722
(408) 747-5586 (fax)
pdesmedt@viquity.com