Re: ebXML PoC feedback to ebXML teams

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

Philippe,

This is great feedback! It would be useful if they could be
numbered when formally submitted so that we can reference
the formal submission rather than have to cut-n-paste
into a database. Maybe a scheme like: TRP-n and RR-n could
be used? 

Also note that I have annotated below where I believe
that TRP has already addressed a specific issue since Tokyo.
I have also added some comments and requested clarification
on a couple of items.

Thanks again for all of the great feedback. You guys are
really doing a *great* service to ebXML in helping us
to craft specs that are proofed through real implementation
experience.

Cheers,

Chris

Philippe DeSmedt wrote:
> 
> 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.

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

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

I recommend that TR&P log this and mark it as Accepted and addressed
in the v0.8 version.

> *       [FN] Need sample TRP messages in appendix for queries

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

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

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

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

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

> *       [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>

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

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

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

> *       [HE/FK] Missing URLs for error reporting.

Comment: this needs clarification.

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

Who ever indicated that it was not? 

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

Of course it can! Note that this mapping is explicit and MAY vary
by message within a given choreography.

> *       [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
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