[ebxml-cppa] comment set 2 on CPPA 1.11

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

Following are my comments on sections 8.4.22.2 through section 10 plus a
few earlier ones.

I have done this review at home and was unable to obtain a printout of the
PDF file before leaving the office, so I am still working with the DOC
file. To aid in interpreting line numbers, I have included the displacement
from the closest preceding section number for each comment.

8.3

703 (+14):  Please delete the sentence beginning on this line ("The value
of the cppid attribute SHOULD be changed...). It is left over from the
former definition of cppid.

8.4.22.5

1963 (+0):  The actor attribute section needs a bit more explanation.  Does
this attribute control where the acknowledgment is to come from?

8.4.23

2015 (+42): Please explain how the CPP/CPA indicates that the communication
is synchronous and refer to that section (I couldn't find it). If this is
not a CPA matter, then it still needs some explanation.

8.4.23.1

2038 (+1):  Change "referred to by a DeliveryChannel element" to "referred
to by the IDREF-type attribute of a DeliveryChannel element".

8.4.24

2052 (+3): Please add an AccessAuthentication element to the example in
8.4.23.

8.4.26

2086 (+19): Basic Authentication uses userid and password.  It would be
useful to have a non-normative note that states that the values of userid
and password are configured through means outside of this specification.

8.4.28

2108 (+7): Regarding my comment to line 1486(PDF) in the previous comment
set, here is the note on compatibility between SSL and TLS and reference to
TLS that I was asking for. However I am still suggesting that we specify
TLS in section 8.4.13.3 and reference 8.4.28 for the compaitiblity
discussion. Note:  The reference section already includes the TLS reference
[RFC2246] but it needs to be cited where TLS is mentioned.

8.4.29

2114 (+4):  Replace SSL by TLS.

8.4.31

2130 (+0):  The description of the EncryptionAlgorithm element is split
between 8.4.31 and 8.4.49.  It would be better to put the whole discussion
in 8.4.31 and refer to it from 8.4.49.  The only discussion that  should be
in 8.4.49 is anything that is specific to Sender Digital Envelope and is
not relevant to TransportClientSecurity.

   NOTE:  I would agree to treating the above comment as a post-V2 issue if
   is too complex to implement now.

2135 (+5): Please either change TransportSecurityProtocol to "transport
security protocol" or add "element" after it. I believe that the first
alternative is the correct one.

2145 (+15):  We need to explain how a cipher suite is specified.  Is it a
specific element or attribute that needs to be discussed?  Is it already in
the schema?

8.4.33.2

2191(+9)-2192(+10):  Please add the word "element" after all the element
names in this sentence.

8.4.35

2209 (+4)-2210(+5):  Please specify TLS in these places.

8.4.37.1

2239 (+11):  Please change "URIs exchanged" to "URIs".

8.4.37.2

2258(+9), 2261(+15), and 2266(+20):  Please indent these notes.

8.4.38

2374(+47):  If both ebXMLReceiverBinding and ebXMLSenderBinding are
omitted, it is an error that a parser presumably won't catch. We should
state that a CPP and CPA composition should check for this error.

   NOTE:  There are other places where all child elements of an element
   have minOccurs=0. Perhaps we should state a general rule that
   composition tools much check for the case where all are omitted. This
   could be in a new section discussing such matters that could directly
   follow the document conventions section. Alternatively, we could simply
   state the rule where needed. My comments below mention other places but
   I don't know if I caught them all.

8.4.39

2387(+0):  All child elements of ebXMLSenderBinding element have
minOccurs=0. We should state that a CPP and CPA composition too should
check for this error.

8.4.40

2413(+4): We should state what reliable messaging semantics is implied by
the presence of the ReliableMessaging element. Is it always onceAndOnlyOnce
or does it depend on the child elements?

8.4.40.2

2445(+6): Please change MessageOrder to MessageOrderSemantics.

2452(+13): Please change "must" to MUST.

8.4.41

2454(+0) Comments on PersistDuration

   PersistDuration applies to, and only to, reliable messaging.  Therefore,
   it should be a child element of the ReliableMessaging element.

   Since the PersistDuration has cardinality 0 or 1, we need tighter rules
   on its use besides the rule that it must appear if MessageOrder is
   "guaranteed". In particular, we need to state what happens to duplicate
   elimination if the PersistDuration element is omitted.  Possibilities
   are:
      Duplicate elimination takes place but the value of PersistDuration is
      a local matter.
      There is no duplicate elimination and the delivery semantics become
      atLeastOnce, which is not really reliable messaging.

   The short term answer to the above has to be consistent with ebMS 2.0.
   If necessary, a post-V2 issue should be started.

8.4.45

2501(+3): Regarding "and so on",  we should either give the complete
enumeration here or refer to it (cross reference, if it should be somewhere
else in this spec, or a reference to an external spec).

2503(+5): I don't understand "values in either case".   Should it be "any
of these values"?

8.4.45.1

2513(+2): Please add a reference to the ITU-T recommendation.

2514(+3): Please replace "Appendix D" by "Appendix D of X.208" so that it
is clear that the mentioned appendices are not in this spec.

8.4.49

2560(+0): Please see my comment above, to 8.4.31, about combing the
discussion of EncryptionAlgorithm in one place.  If it is decide to leave
that rewrite to post-V2, then please add a cross reference to 8.4.31 here.

2568(+8): Can oid, w3c, and enumeratedType all be included at the same
time? If so, we need rules for the case where they are inconsistent.  If
only one SHALL be included, please so state. Also, we need discussion of
the case where all are omitted.

8.4.49.1

2571(+2):  Please change "may" to "might be" or "is". I believe that "is"
is correct.

8.4.49.4

2592(+0): Please change enumeratedTypeAttribute to enumeratedType attribute

8.4.52

2635(+10):  Please see my comment to line 2387 above.

8.7

2888(+11)-2892(+15): Please put all element names in this paragraph in bold
italics.

9.2

2986(+12):  Please delete the sentence beginning on this line ("The value
of the cpaid attribute...").  It is left over from the former definition of
cpaid.

3006(+32): Plese make "Signature" bold italics.

9.4.1

3028(+1): Please state the XML Schema data type for the values of these
elements.

10 (References)

Please add a reference for ITU-T (see comment to line 2513).

Regards,
Marty