ebXML PoC comments: structured and updated comment list

[Philippe DeSmedt <PDeSmedt@viquity.com>]

All,

Per Chris Ferris's suggestion, I've categorized and numbered the PoC
comments, so that they can be more easily tracked. [[TRP-n]] denotes a
TRP-related comment; [[RR-n]] is reg/rep-related, [[SEC-n]]
security-related, and [[TP-n]] TPA (CPA)-related (some comments fall in more
than one category). We have PoC reps to the TRP (Dale Moberg) and RR teams
(Farrukh Najmi). We need volunteers to convey the SEC and TP comments to
those teams as well. For the PoC feedback effort to be successful, we need
to cover all of the affected teams. All you'll need to do is to make sure
that the issues are addressed in the respective working groups (and raise
hell if they aren't). Thanks for volunteering!

I've also added some new comments from Jacques Durand [[TRP-22]] and
[[TRP-23]], and some comments that Chris had on the original list. Other
than that, the comments are still in 'raw' form, as before.

-Philippe

Here goes:

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)
[JD] Jacques Durand (Savvion)
[KN] Kenji Nagahashi (Fujitsu)
[PDS] Philippe De Smedt (Viquity), as compiled with the PoC team at the
Tokyo meeting
[SH] Scott Hinkelman (IBM)


[[TRP-1]]
*	[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.

[CF](new comment): 
I'm going to suggest that we (TR&P) log this and mark it as 'Accepted'. The
next revision of the spec will include explicit handling of multi-hop and
acks. David Burdett and I are currently drafting this section. Keep an eye
on the tr&p list for details...


[[TRP-2]]
*	[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.....


[[TRP-3]]
*	[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.

[CF] (new comment):
I recommend that TR&P log this and mark it as Accepted and addressed in the
v0.8 version.


[[TRP-4]][[RR-0]]
*	[FN] Need sample TRP messages in appendix for queries

[CF] (new comment):
Comment: TRP has agreed to include (externally to the spec, but referenced
by it and published on the ebxml.org site) more concrete examples including
a multipart payload example. Or, is this intended to be for RegRep team???


[[RR-1]]
*	[FN] Need to replace use of GET on object retrieval with TRP
request/response

[[RR-2]]
*	[FN] Need Ad hoc query mechanism for automated clients

[[RR-3]]
*	[FN] UML diagrams truncated method names

[[RR-4]]
*	[FN] Inconsistent use of Asynch Vs. Async in UML diagrams

[[RR-5]]
*	[FN] Need a single DTD instead of many for RegRep

[[RR-6]]
*	[FN] Using '*' for objectType in getClassifiedObjects is not clear

[[TRP-5]]
*	[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.

[CF] (new comment):
Content-Length header has been eliminated in all MIME bodyparts except in
the HTTP PDU:
http://lists.ebxml.org/archives/ebxml-transport/200012/msg00067.html



[[TRP-6]]
*	[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).

[[TRP-7]]
*	[SH] Make Manifest optional. I'm not in favor of
required-empty-tags.

[[TRP-8]]
*	[DB] During the last POC there were a couple of packaging related
issues. Have all the packaging related issues been resolved?

[[TRP-9]]
*	[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.

[[TRP-10]]
*	[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.

[CF] (new comment):
Content-Length header has been eliminated in all MIME bodyparts except in
the HTTP PDU:
http://lists.ebxml.org/archives/ebxml-transport/200012/msg00067.html



[[TRP-11]][[RR-7]]
*	[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>

[CF] (new comment):
Comment: The TPAId (now CPAId) scheme is undefined. However, it is intended
that a CPA be registered in the RegRep. Hence, a URI scheme for identifying
a CPA registered with the RegRep is needed (RegRep team needs to specify).
It would also be useful if *access* to the CPA via this URI scheme were
possible (HTTP/S?)


[[TRP-12]]
*	[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.

[CF] (new comment):
Comment: It would help the TR&P team greatly if specific recommendations
could be offered as to how we should modify the specification to address
this. Given that the bindings are contributed, possibly you would volunteer
to draft the SMTP binding section/appendix??? (pretty please;-)


[[TRP-13]]
*	[HE/FK] Missing URLs for error reporting. 

[CF] (new comment):
Comment: this needs clarification.


[[TRP-14]]
*	[HE/FK] Routing Header should be optional. 

[[TRP-15]]
*	[HE/FK] Clarification on PayLoad in Acks and also when to use
MessageType Acknowledgement vs Normal.

[[TRP-16]][[SEC-1]]
*	[HE/FK] Lack of security. We just wanted to re-emphasize this so
that it will be addressed soon.

[[TRP-17]][[SEC-2]]
*	[HE/FK] HTTPS should be supported. 

[CF] (new comment):
Comment:Who ever indicated that it was not? 


[[TRP-18]]
*	[HE/FK] HTTP responses are not defined. 
Body of 200 OK? What in case of errors? What kind of errors are allowed,
etc. 

[[TP-1]]
*	[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.

[[TRP-19]][[TP-2]]
*	[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.

[[TRP-20]][[TP-3]]
*	[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.

[CF] (new comment):
Comment:Of course it can! Note that this mapping is explicit and MAY vary
by message within a given choreography.


[[TRP-21]][[TP-4]]
*	[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.

[[TP-5]][[RR-7]]
*	[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.

NEW:

[[TRP-22]]
*	[JD] RefToMessageId: (V 0.21d, 7.9.3.3)
"For Normal and Error msgs, RefToMessageId is an optional reference to an
earlier ebXML message." We had lots of late minute problems because of
divergent interpretations of this statement. A "seller" decided to rely on
it to sequence messages in a conversation, while the "buyer" was ignoring
it.
We believe it is better to remove any "optional" mention here. This is a
transport-level attribute that is fully justified for Ack and Error types.
In the same way as MessageId is a MSH-level concept (generated by MSH), so
should be the RefToMessageId. Like for MessageId, the spec should not even
suggest any use of it at application level. (even if an implementation
allows for it)
If there is a need for an app to relate messages to each other, a
higher-level ID, the ConversationId, should be used. Any more detailed,
app-specific message linking could as well rely on some payload attributem
and stay out of the Header scope.

[[TRP-23]]
*	[JD] Modifications to Message Spec V0.8, 2.4.4: Delivery
Notification Message (DNM).
It is not clear what the DNM purpose is. Is that for applications? for MSH?
If it is to be processed (interpreted) by MSH: The Delivery Notification
Message seems an overkill to implement RM over multi-hops, given the
intermediate Acks. This may hurt performance, and generate
confusion/overhead. Normally, if the intermediate Acks are as "reliable" as
in point-to-point RM, this should be enough to guarantee end-to-end RM,
provided each intermediate Hub is RM-enabled. And in that case, a failure
along the way is really relevant to a contract between the Hub and the
Receiver(the sender has fulfilled its contract) Now, if we really favor an
end-to-end RM check (i.e. between the From_Party and the To_Party)
(personally I favor it) then it should be done in a similar way, (that is,
same ack mechanism) regardless whether the messages goes directly (a) from
sender to receiver, or (b) through multi hops. But in this current proposed
spec, in (a) the end-to-end delivery notification is represented by an Ack
type, while in (b), it is a Normal type (the DNM). The bottom line here is
we must decide whether RM is between <From_Party and the To_Party> (in that
case, we have to question the meaning of intermediate Acks) or between
<nodeX:From_Party and nodeY:To_Party> (in which case an end-to-end ack as
DNM seems superfluous).


_______________________________
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