Comments on CPP/CPA Specification Version 0.95

[Tony Weida <TonyW@EDIFECS.COM>]

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

407-412: Packaging should be included among the child elements of
CollaborationProtocolProfile.

792: I'd say "The ServiceBinding element identifies a default
DeliveryChannel element" -- adding the word "default" -- to account for
possible Override elements.

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

993: Change "a response will contain ..." to "a response SHALL contain ..."

1054: This sentence seems misplaced -- I don't see why it appears in this
section.

1071: Capitalize SHALL in "... the SendingProtocol element shall ..."

1335: Change "The pair of elements Retries, RetryInterval  ..." to "The trio
of elements Retries, RetryInterval, and PersistDuration ... "

1343: Change "They MUST all be either present or absent." (which is
vacuously true), to "They MUST either be all present or all absent."

1413: Typo -- change "retry be deferring" to "retry by deferring"

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.

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

1622: Re "application/pkcs7-mime." -- shouldn't the period be outside the
quotation mark?

1627: Change "Both the Encapsulation attribute ..." to "Both the
Encapsulation element ..."

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.

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

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.

1834: Typo -- Change "performace" to "performance"

1852-1853: Rectify "Error! Reference source not found."

1970: The section heading "ds:Xpath element" does not match the section
content concerning the ds:Algorithm attribute of the ds:Transform element.

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?

2128: Change the comma at the end of the sentence to a period.

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

Cheers,
Tony