RE: initial draft of CPP-CPA Specification

[Martin W Sachs <mwsachs@us.ibm.com>]

Stefano,

Thank you very much for your comment set.  If I do not reply to a
particular comment, it means that I agree.  Responses are embedded in this
copy of your comment set.

My replies are embedded in the attached copy of your comments.

To all:  most comments that you supplied so far will be processed AFTER I
complete and distribute the initial draft of the CPA chapter.

Regards,
Marty


(See attached file: response-stefano.html)

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Stefano POGLIANI <stefano.pogliani@sun.com> on 01/17/2001 09:37:58 AM

To:   ebxml-tp@lists.ebxml.org, ebxml-ta-security@lists.ebxml.org
cc:
Subject:  RE: initial draft of CPP-CPA Specification



Please disregard the previous mail since the attachment was poorly
formatted!
============================================================================

==
Attached you will find my comments on the document.
Please do not hesitate to contact me for clarifications on my comments.

Best regards and congratulations for the excellent job!

/Stefano

» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: 15 January 2001 23:11
» To: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
» Subject: initial draft of CPP-CPA Specification
»
»
» I have attached the initial version of the CPP-CPA specification.  As
» previously indicated to the TP team, this copy has the CPP chapter but
not
» the CPA chapter.  Please review the CPP chapter while I am completing the
» CPA chapter.  Please post comments and be prepared to discuss at
» Wednesday's conference call.
»
» Regards,
» Marty
»
» (See attached file: cpa-cpp-spec-0.1-interim.pdf)
»
» ******************************************************************
» *******************
»
» Martin W. Sachs
» IBM T. J. Watson Research Center
» P. O. B. 704
» Yorktown Hts, NY 10598
» 914-784-7287;  IBM tie line 863-7287
» Notes address:  Martin W Sachs/Watson/IBM
» Internet address:  mwsachs @ us.ibm.com
» ******************************************************************
» *******************
»

Comments to the TPA specification V0.1 (January 15, 2001)

Stefano Pogliani, Sun Microsystems

---

• Line 5 (typo)

"..with another business partners" should be changed into "...with another business partner"
• Line 7 and Line 8:

"...between two Partners" should be changed into "...among Partners".

MWS: A CPA among more than two parties is major new function. I do not believe that we can address this in phase 1 (i.e. before May, 2001). I prefer to delete places in the CPP-CPA specification that refer to more than two parties. This applies to all subsequent comments about more than two parties.
 

• Line 9:

"...of the two Partners' TPPs" should be changed into "...of the Partners' TPPs".
• At this point I would add a NOTE:

this NOTE should state that, whilst in principle TPA/CPA are among two OR MORE Partners/Parties, it has been decided that the scope of this specification will concentrate on TWO Partners/Parties.
This note will avoid further confusions, during the remaining part of the doc, about the use of TWO instead of MANY.
• Line 14 and 15:

Shouldn't also "security constraints" be mentioned here ?
• Line 51 (typo)

I think "xxxx" stands for the name of the current document.
• Lines 58 thru 94.

I like very much this section (which is missing from the TA document and which causes a lot of troubles when reading the TA....).
But I would make sure that a pointer to the "OFFICIAL" ebXML Glossary is made.
• Line 64 and 65.

I would change the first sentence as follows : "A business process that is carried out and managed by all the participants".
• Line 76 and 79 (typos)

These empty lines should be removed for consistency with the other items

MWS: I found no way to make the note stand out without the blank lines. Anything else I tried resulted in a bullet point on it, which I do not want.

• Line 83.

"...to carry out a Collaborative Process" should be changed into "...to carry out the Collaborative Processes"

MWS: I disagree. The CPP may refer to more than one collaborative process. Use of "the" is appropriate only when the CPP references exactly one colalborative process.

• Line 84 (typo)

"comma" after "logically" is not required
• Line 88 (typo)

"Collaboration Protocol" should be changed into plural "Collaboration Protocols"

MWS: This sentence is referring to a CPA. I believe that at the moment, the consensus is that a CPA refers to a single collaboration protocol. In any case, the multiple collaboration protocols in a CPA may be best deferred to a phase beyond May.

• Line 93.

It is a little bit difficult to read that "a Service is the representation of a set of services...".
I would say "A Serive is the representation of a set of functionalities..."
• Line 99.

"..the chosen business process" should be changed into "...the chosen Collaborative Process".
• Line 100.

I would modify the sentence "Both parties...systems" with the following:
"The agreed upon CPA can be used to configure the runtime system of each intervening party".
The reason is that the concept of CPA=configuration-file is introduced.

MWS: I do not understand "intervening". Do you mean "interacting"? In any case, I believe your addressing the "2 vs. many" question here.

• Lines 113 thru 116.

I would add to this sentence that it is important that each party knows the other party's ROLE in the Collaborative Process,l not only the Collaborative Process
• Line 119.

I would enclose "within a TPP" in parenthesis since, otherwise, one may not understand if it is the CPP or the TPP to be stored in the repository

MWS: I prefer to eliminate the word "TPP" except perhaps in lines 4-9 since function beyond the CPP and CPA is not in our scope at this time.

• Line 125 and 126.

I would change the part from "This specification..." until "...XML documents." with the following : "This specification defines the XML vocabulary for creating electronic CPPs and CPAs".
• Line 126 and 127.

I would change the part from "In the appendices..." until "...Schema document" with the following : "In the appendices of this specification sample CPP and CPA documents, with their associated DTD and XML Schema files, are provided."
• Paragraph between Line 129 and 135.

I would enforce the idea, here, that the "legal terms", which cannot be easily expressed in any electronic document and that are not directly implied in the configuration of the software to manage the exchange, are intentionally left outside the CPP.
• Paragraph between lines 144 and 150.

The concept is there, but I found it difficult to read. There is too much use of the terms "business process" to qualify both internal and external. I propose this wording:
"A CPA describes all the valid, visible (and, hence, enforceable) interactions between the parties and is independent of the internal processes executed at each Party. Each Party executes its own internal processes (which are, normally, invisible to other parties) and interfaces them with the Collaborative Processes described by the CPA.
The intent of the CPA is to provide a description that can be easily comprehended by humans and yet is precise enough for enforcement by computers."
• Line 153 and 154.

I would change the sentence "The conversation..." until "...the business process" with the following : "The conversation represents a single unit of business as defined by the business process; a new conversation is created each time a new unit of business is started."
• Line 157 to 159.

If accepting the previous comments, the whole sentence "When the business... " until "..unit of business." should be removed.
• Line 160 (typo)

Unuseful empty line
• Line 177 and 178.

I would change the part "...and invoke the application-specific programs" into "... and interface with the Party's back-end processes"
• Line 180 and 182 (typo)

empty lines
• Line 184.
• "...a CPA from two nor..." should be "...a CPA from two CPPs nor ..."
• Line 187 (typo)
• "...these notes server to..." should be "...these notes serve to ..."
• Line 244.

"For a CPA written in terms of roles, ...". I think this sentence is introduced without any explanation of what it really means. I would say something like this:
"In some circumstances, a CPA may be created that refers to abstract roles instead than to physical partners. In this case, it is recommended...."

MWS: Section 7 will be considerably shortened after I complete the CPA chapter. Much of this material relates to information, such as partner contact information, that was in tpaML but will not be in our specification. I will review your comments on section 7 after I edit it and address those comments that relate to whatever remains.

• Bullet between line 256 and 259.

I do not understand what this really means. I think an example would make it clear.
• Note between line 263 and 266.
• Why method names are not sensitive?
• What is the CPA-tool which maps names into quantities?
• Lines 280 thru 286.

I STRONGLY DISAGREE. Why, for once, don't the US convert things to their own convention?

MWS:  This will happen when the US converts to metric.:-)

Outside of joking, I think Internationalization is required here for the following reasons:

• for the social agenda of ebXML. Privileging US means privileging the "rich" and "big" as opposed to the "poor and small"
• technically, if there is the need of ad-hoc conversion in the runtime, the same software cannot run everywhere in the world.


MWS:  I completely agree; however I expect that most items that require internationalization will disappear since the party details no longer appear in the CPP and CPA.
 

• Line 289 and 290.

Again, let's try not to impose any US-based constraint.
• Line 300 thru 304

Again, let's try not to impose and US-based constraint.
Besides, the US format for the date is not so suitable for sorting algorithms...
• Line 307 thru 309

I would add a 3 characters indicator of the time zone (such as GMT, CET, EST, PST etc)
• Line 334

I would change "...and the business-application functions..." into "...and the back-end functions..."

MWS:  I don't think I agree.  I view "business application functions" as the application as described by the BP metamodel.  It is aware of the collaboration and of the back end processes.  I view "back end processes" as functions such as database, ERP, workflow, etc.  Their view is strictly internal to one party.
 

• Line 336 and 337.

I would re-use the first part of section 8.6 since it is, in my opinion, more clear. Thus:
"A Delivery Channel is THE combination of a Transport Layer definition and a Document Exchange definition, with some additional properties to define security and addresses, that describes tha Party's message-receiving characteristics. Several Delivery Channels can be defined in a CPP."
• Paragraph between lines 339 and 344.
• In this paragraph the "fan-out" situation is described. Is it possible for the "Document Exchange Layer" to participate in a "fan-in" situation (from Transport to Collaboration-Protocol Layer) ?


MWS:  I will modify the text to talk about send and receive.
 

• I would modify the sentence "The options...the Transport layer" into the following : "The options selected for the Document Exchange Layer are complementar to those selected for the Transport layer."
• Line 489 thru 513

Sorry to post this comment now (which is late on respect to when you submitted the CPP DTDs...).
I would have thought to the <ROLE> tag as a subtag of the <CollaborationProtocol> tag. In fact, in my understanding, a role has a meanin ONLY in the context of the CollaborationProtocol it refers to.
Besides, the <ServiceBinding> tag (lines 506 to 513) seems to be a duplication of the xlink attribute in the <CollaborationProtocol> tag

MWS:  See recent discussions about this on the TP list.
 

• Line 542.

I would change "A delivery channels is a combination..." into "A Delivery Channel is the combination..."
It is not just "a" combination, but "that well-defined combination" you are describing.

MWS:  A party may define more than one delivery channel.  Each would describe different capabilities.  "the combination" implies that there is only one combination.  "a combination" allows for more than one.
 

• Line 542 and 543.

I would make explicit that the Delivery Channel has some other property:
"A Delivery Channel is the combination of a Transport layer definition and a Document Exchange definition, with some additional properties to define security and addresses, that describes the Party's message-receiving characteristics."

MWS:  security and addresses are inside the transport and document exchange definitions. Therefore, they are implied by the present text. It is not necessary to be so detailed in this brief introductory section.
 

• Line 546.

I think that "The same delivery channel or the same..." should be changed into "The same Document Exchange definition or the same..."

MWS: Thank you for pointing out this typo.
 

• Line 570 thru 572 AND 608 thru 611.

Again, sorry for being late to highlight this comment. Wouldn't it be cleaner if the <ServiceBinding> tag would actually be a <CollaborationProtocol> tag which references (IDREF) the <CollaborationProtocol> tag defined at lines 391-393 ?
The issue is that the "xlink" to the BP definition is present in too many places with the risk of inconsistencies.

MWS:  See more recent discussion on the TP list. The final form is still to be decided.
 

• Line 650 thru 660.

If I understand correctly, the reason for having more than one endpoint is to allow each endpoint to deal with a different purpose. If I understand, the purpose is the same as the "type", i.e. "Login, request, response, error".
• If this is the case, I would add a little sentence with an example


MWS:  A better place for the example is in the HTTP section (8.7.5.1) since the example should be illustrated with real endpoints.
 

• How do I specify a Party where the same endpoint can be used for more than one (but not all) of the above purposes?


MWS:  See lines 659-660.  Leaving out the type attribute on the multipurpose endpoint while including other single-purpose endpoints should probably be sufficient.
 

• Line 668 to 670.

I am not clear if "no encoding" is the same as "encoding with no options".

MWS:  I should clarify the words.  "encoding with no options" is supposed to mean that the transport protocol decides whether and how to encode and the upper level is not given the choice.

If <Transport Encoding> is omitted, would the default apply (no encoding) ?

MWS:  If <TransportEncoding> is omitted, the default is whatever the transport protocol normally does. If the transport protocol does no transformation, that is "no encoding".
 

• Line 673 to 675.

I am not clear on the first sentence of this NOTE.
• What is meant by "business application process"? It is the legacy or the Collaboration Protocol layer?


MWS:  As noted above, "business application process" is the process defined by the BP metamodel.  It is aware of the collaboration.  For legacy processes, it is the transformation layer in BSI.
 

• Which are the "data which determine the encoding requirements" ?


MWS:  One case is binary vs 7-bit ASCII.
 

• I think that a little example would make it more clear
• Line 679 and 680.

<TransportEncoding> is under <Transport>. I never saw <Communication> so far.

MWS:  typo inherited from tpaML.
 

• Line 682 thru 704.

I assume that the <TransportTimeout> structure is managed by the MSH only, am I right ?

MWS:  In the last conference call we agreed to eliminate <TransportTimeout>.  The consensus is that any timeout performed directly by the transport implementation does not need agreement between the parties and the important timeout is the reliable messaging timeout.
 

• Line 727 thru 729.

Does this sentence mean that the "endpoints" defined in the CPP may be dynamically redefined by information exchanged during a Conversation?

MWS:  That is correct.  Some existing B2B protocols do this.  I believe that cXML is one such case.
 

• Line 746

I would rather use a fictitious name instead of a real one.

MWS:  I will fix if Chris agrees :-)  Actually, it will be hard to find a fictitious name that no one will later claim as his/hers.
 

• Line 792 and 793.

I would change "...wil not be used for this CPAs composed from this CPP." into "...will not be used for any CPA composed from this CPP.".
• Line 805.

"...the certificate to be used in this delivery channell by...".
Here we are not talking about Delivery Channels, so I do not understand what "THIS delivery channel" points to.

MWS:  typo.
 

• Line 819 to 821.

The sentence "The protocol, protocol version..." until the full-stop does not read very well for me. There is something missing or a cut/paste problem.

MWS:  It should say "...version, and certificate reference must be supplied. Examples..."
 

• Line 885 and 886.

Saying that "the Document Exchange section of the CCP defines the properties of the messaging service to be used..." implies that this is the only place ("THE properties") where the messaging service characteristics are defined. I do not think that this is what is meant here. In fact there are a couple of considerations:
• By "messaging service", do we mean the same as "Transport" ?


MWS:  No.  An example of "messaging service" is the ebXML Message Service.  We have been trying to eliminate this confusion within TRP.  "Transport" should be used only to refer to what is below ebXML.
 

If not, we should introduce what we mean by "Messaging Service" here.
 
MWS:  It is defined by example in lines 443-444.  I should add a better definition in the first paragraph of the Document Exchange section.
 
If yes, we had other places where we have been defining properties for the Transport.
 
MWS:  I don't believe other changes are needed.  I have tried to be rigorous about limiting "Transport" to HTTP, SMTP, etc.
 
• I would try to qualify here WHICH kind of properties are specified in this place and WHY they are specified here and not elsewhere.


MWS:  This is an introductory paragraph.  All the properties are described in detail immediately after (sections 8.8.1 and following).
 

• Line 907 thru 913

Not being an expert in this domain, I would be happy to understand the difference between the <MessageEncoding> tag here and the <TransportEncoding> tag described at lines 662 and following.

MWS:  I believe this is clear.  Line 908 defines <MessageEncoding>.  <TransportEncoding> is defined in line 663.  I think this is another case of confusion between "Transport" and "Message Service".
 

• Line 926 thru 931.

If the <ReliableMessaging> tag is completely missing, does this mean that a "deliverySemantic=BestEffort" is applied ?

MWS:  This question is open.  One view is that <ReliableMessaging> should be a required tag.  Another view is that the cardinality of <ReliableMessaging> should match the cardinality of RM in the messaging service spec.

• Line 956 thru 964.

I would add a comment on the precedence/overwriting between these timeout parameters (BP based) and the Transport-related timeout parameters

MWS:  As I mentioned above, the transport timeout tags are being eliminated.
 

• Line 1029.

I found two references to the <ServiceBinding> tag: one at line 506 and the other at line 608. None of them, in my understanding, references the <CollaborationProtocol> ID, but they both reference the "xlink" attribute mentioned within the <CollaborationProtocol> tag. This is one of the reasons I proposed changes in some previous bullet.

MWS:  See recent discussion on the listserver.
 

• I did not go through the appendices, trusting that they conform to what has been written in the specification.