RE: Comments on CPP/CPA Specification Version 0.95

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

Tony,

Business transaction:  Is your comment on the pattern of the notification
transaction based on the latest version of the Spec. Schema Spec.? If not,
I would appreciate your checking the latest one to be sure that a
business-level response is not required.

I am  hoping that Chris will see your comments and review your response
regarding signatures.  Meanwhile, I think that the philosophy should be
that since signing is optional to begin with, we should keep the triple
signature as a suggestion and not mandate complexity that not everyone will
need. Since XMLDSIG is primarily concerned with creating a signature, I am
not surprised if it does not mention notarization.

If by now, you saw my retraction on the cardinality question, then you know
that I agree with you.  However, I believe that the train has left the
station regarding changes to the DTD and XSD between now and Vienna, so I
have put this on the list to discuss in Vienna.  By the way, there is the
same cardinality question about ds:Signature.  We could discuss limiting
the number of signatures to 3 in the CPA (at least in the Schema).

Regards,
Marty

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

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



Tony Weida <TonyW@EDIFECS.COM> on 04/26/2001 03:04:23 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org
Subject:  RE: Comments on CPP/CPA Specification Version 0.95



Marty et al.,

I generally agree with Marty's suggestions -- thanks!  A few specific
replies follow.  I encourage everyone to review the replies that Marty
called out.

Cheers,
Tony

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, April 26, 2001 11:03 AM
> To: Tony Weida
> Subject: Re: Comments on CPP/CPA Specification Version 0.95
>
>
>
> Tony,
>
> Here are my responses, embedded below.
>
> Everyone, please especially see my replies to Tony's comments on lines
> 1669, 1970, and 1978,  Further discussion may be needed.
>
> Regards,
> Marty
>
> **************************************************************
> ***********************
>
> 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
> **************************************************************
> ***********************
>
>
>
> Tony Weida <TonyW@EDIFECS.COM> on 04/25/2001 10:21:30 PM
>
> To:   ebxml-tp@lists.ebxml.org
> cc:
> Subject:  Comments on CPP/CPA Specification Version 0.95
>
>
>
> The following comments refer to version 0.95 dated 25 April
> 2001 in the
> page
> headings (despite saying 04/19/01 5:32 PM beneath the title).
>
> MWS:  Some Word magic, I guess.  The date of last save in my
> copy is April
> 19.
> Apparently it is updating the date in the header for reasons
> all its own.
>
> As far as I'm
> concerned, they need not be treated as formal public comments
> since I'm a
> member of the TP team.
>
> 226-227: The statement "... Business Transactions, each of which is a
> request Message from one Party and a response Message from the other
> Party."
> seems incorrect.  Considering the transaction patterns, if "response
> message" refers only to  business actions (called responses in the
> patterns), then the Notification pattern does not include any response
> message (but only a receipt acknowledgement signal).  On the
> other hand, if
> "response message" refers to signals as well as actions, then
> some patterns
> have a receipt acknowledgment signal, an acceptance
> acknowledgement signal,
> AND a business action response.  Either way, the number of response
> messages
> is not fixed at one.
>
> MWS:  The business signals defined in BP model do not surface to the
> CPP/CPA.
> Remember the discussion we had at the Boston F2F.  We are
> dealing only with
> the
> response message that passes a business message (except in the
> syncReplyMode
> attribute of DeliveryChannel where we can't avoid mentioning
> the signals).
> I am not inclined to attempt to clarify since that might only confuse.
> The last sentence of the paragraph refers the interested
> parties to the BP
> spec.

TW: In that case, considering the pattern for the Notification transaction,
I believe the statement should read "... and zero or one response message
...".  (Unfortunately, I was not at the Boston F2F.)

> 407-412: Packaging should be included among the child elements of
> CollaborationProtocolProfile.
>
> MWS:  Thank you.
>
> 792: I'd say "The ServiceBinding element identifies a default
> DeliveryChannel element" -- adding the word "default" -- to
> account for
> possible Override elements.
>
> MWS:  OK
>
> 970: I'd say "The value of the syncReplyMode attribute is one of the
> following possible values ..." -- the value itself is not an
> enumeration
> (an
> enumeration is all of the values at once).
>
> MWS:  How about "The syncReplyMode attribute is an
> enumeration comprise of
> the following possible values:

TW: Good -- modulo the missing 'd' at the end of comprise[d].

> 993: Change "a response will contain ..." to "a response
> SHALL contain ..."
>
> MWS: fine.
>
> 1054: This sentence seems misplaced -- I don't see why it
> appears in this
> section.
>
> MWS:  The sentence is intended to point out that synchronous
> replies are
> one property that distinguishes different transports.  I will add this
> point.
>
> 1071: Capitalize SHALL in "... the SendingProtocol element shall ..."
>
> MWS:  More thanks.
>
> 1335: Change "The pair of elements Retries, RetryInterval
> ..." to "The
> trio
> of elements Retries, RetryInterval, and PersistDuration ... "
>
> MWS:  Still more thanks.
>
> 1343: Change "They MUST all be either present or absent." (which is
> vacuously true), to "They MUST either be all present or all absent."
>
> MWS:  OK.
>
> 1413: Typo -- change "retry be deferring" to "retry by deferring"
>
> MWS:  OK
>
> 1431 and 1454: I'd prefer identical examples of a Protocol
> element that
> referencesXML DSIG, to avoid raising questions in readers'
> minds about the
> distinction.  If there is a good reason to keep two different
> examples, I'd
> want to explicitly acknowledge the difference and explain it.
>
> MWS: The first example is the original one;  the value shown
> was simply a
> place holder for what wasnt't spelled out.  I will copy the second one
> into the first.
>
> 1550: Change 'two attributes with REQUIRED Boolean values of
> either "true"
> or "false". ' to 'two REQUIRED attributes with  Boolean
> values of either
> "true" or "false". ' -- relocating the word "required".
>
> MWS:  I agree.
>
> 1622: Re "application/pkcs7-mime." -- shouldn't the period be
> outside the
> quotation mark?
>
> MWS:  Absolutely.
>
> 1627: Change "Both the Encapsulation attribute ..." to "Both the
> Encapsulation element ..."
>
> MWS:  done.
>
> 1669-1670: This requirement can and often will conflict with
> the preceding
> recommendation that "If multiple Comment elements are
> present, each SHOULD
> have a unique xml:lang attribute value."  For example, two
> CPPs may well
> have their own (say) "en-gb" comment.  Various solutions are
> possible --
> perhaps best to discuss them on the next call or in Vienna.
>
> MWS:  I don't understand the reason for SHOULD.  The sentence
> seems to say
> that two comments may not have the same xml:lang attribute
> value.  I am
> inclined to say "each MAY have a different..." Changing SHOULD to MAY
> I believe solves your problem. Does anyone know why it says SHOULD?

TW: I agree with changing MAY to SHOULD and would also relax the reference
to uniqueness, yielding: "If multiple Comment elements are present, some
MAY
have different xml:lang attribute values."

> 1672-1673: Insert the word "upon" in the phrase "... the
> capabilities that
> two Parties must agree to enable them to engage in electronic Business
> ...",
> yielding "... the capabilities that two Parties must agree
> upon to enable
> them to engage in electronic Business ..."
>
> MWS:  Good!
>
> 1759-1760: I'd say "The value of this attribute is one of the
> following
> possible values:" -- again, the value itself is not an enumeration.
>
> MWS:  As above, "This attribute is an enumeration comprised of..."
>
> 1834: Typo -- Change "performace" to "performance"
>
> MWS:  Thanks.
>
> 1852-1853: Rectify "Error! Reference source not found."
>
> MWS:  Hmmm... I wonder what it's supposed to be :-)
>
> 1970: The section heading "ds:Xpath element" does not match
> the section
> content concerning the ds:Algorithm attribute of the
> ds:Transform element.
>
> MWS:  I am going to change the section heading to
> ds:Algorithm element.
> I don't know where the ds:Xpath element heading came from.
> Does anyone
> know if we need to discuss a ds:Xpath element here?
>
> 1978: I don't know about the need or lack thereof for
> notarization, but the
> phrase "It MAY be necessary ..." is liable to be confusing --
> sounds like
> there might be a REQUIREMENT or then again there might not --
> which is it?
>
> MWS:  I don't understand the problem here.  "MAY be
> necessary" means just
> that.  The Parties may or may not need the notary signature.
> Am I missing
> something?  As I understand it, the point of the "notary" is
> that in order
> to protect the second signature, a third signature (the
> notary) is needed.

TW: Perhaps this is outside my expertise -- I was previously under the
impression that two digital signatures were sufficient, and this is the
first I've heard of third-party notarization for cryptographic closure.
(As
far as I've noticed, XML DSIG doesn't mention notarization -- for whatever
that's worth.)  However, if notarization is in fact necessary to "protect"
the second signature, then what is the value of an "unprotected" second
signature?  In other words, why wouldn't the statement then be "It is
REQUIRED that a notary sign over both signatures so as to provide for
cryptographic closure."?

> 2128: Change the comma at the end of the sentence to a period.
>
> MWS:  done.
>
> Appendices C and D: I've not looked at the DTD and XSD carefully, but
> noticed that in each of them the cardinality of PartyInfo is
> one or more,
> whereas the text of the specification correctly mandates exactly "two
> REQUIRED PartyInfo elements, one for each Party to the CPA".
>
> MWS:  Your are correct.  An enterprise may include multiple PartyInfo
> elements in a CPP if it wants to express capabilities represented by
> different divisions (for example) that have unique PartyIds
> and otherwise
> may behave differently.  A CPA has only one PartyInfo element
> per Party.
> This is a shortcoming of defining a combined DTD or XSD for
> CPP and CPA.  A
> normative text statement has to supplement the cardinality in
> the DTD/XSD.
> I don't know of any grammatical solution other than using
> different names
> for the element
> in the DTD or XSD or having completely separate DTD/XSD for
> CPP and CPA.
> The (probably better) solution is to assume that the tool
> builders will
> build this kind of cardinaltiy modification into their tools.

TW: It seems to me that we could change the CollaborationProtocolAgreement
element to require exactly two PartyInfo elements, while leaving the
CollaborationProtocolProfile elements unchanged.  That is, simple redefine
the CollaborationProtocolAgreement element in the DTD as follows (and
equivalently in the XSD):

<!ELEMENT CollaborationProtocolAgreement (CPAType?, Status, Start, End,
ConversationConstraints?, PartyInfo, PartyInfo, ds:Signature*, Comment*)>

I do agree that CPA-specific tools can solve the problem independently of
the DTD/XSD.

> Cheers,
> Tony
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org