Re: ebXML PoC comments: structured and updated comment list

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

Thanks Philippe!

This is great stuff.

Cheers,

Chris

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