Re: [ebxml-cppa] Preliminary draft for appendix on how to use theMessagingService with a CPA

[Arvola Chan <arvola@tibco.com>]

Marty:

Thank you very much for your feedback. Please see my responses inline.

-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Thursday, December 13, 2001 5:30 AM
Subject: Re: [ebxml-cppa] Preliminary draft for appendix on how to use the
MessagingService with a CPA



Arvola,

This draft is excellent.  As I mentioned previously, I believe that the
correct place for it is in the MSG specification, with a reference to it
from the CPPA specification.  The text is clearly a set of suggestions on
how to design an MSH.  I have the following comments (caveat:  I have
reviewed the text but not checked the details of the table).

Correspondence table:  This is fine as a normative statement.  An
introductory paragraph would be helpful.

<ac>
I will add an introductory section in the next version of the document.
</ac>

Text, general:  RFC 2119 words should be capitalized.

<ac>
Agreed.
</ac>

In the following, numbers refer to numbered paragraphs in the draft.

PACKAGING AN OUTBOUND EBXML MESSAGE

9.  This should be persistDuration, not timeToLive.  Per recent
discussions, time to live relates to late arrival of the message and not to
how long a reliable message must be kept in persistent store.

<ac>
In the context of constructing an outbound message, it is necessary to
include a TimeToLive element (under the MessageData element) if the message
is being sent reliably. The PersistDuration comes into play on the
receiver's side. At the time it makes a persistent copy of the message, it
needs to specify when the message is eligible for gabage collection.
</ac>

10. Isn't duplicateElimination required with reliableMessaging?  Without
duplicateElimination the RM semantics are atLeastOnce and message ordering
cannot be used.  Does the MSG team intend to allow atLeastOnce?

<ac>
The Messaging TC has decided to decouple the duplicate elimination behavior
from the retry if no Ack is received behavior. Both onceAndOnlyOnce and
atLeastOnce behaviors are supported. Please see section 7.6 in the 1.091
draft.
</ac>

12. Typo:  change "if the requested signature" to "if the requested
acknowledgment".

<ac>
Agreed.
</ac>

UNPACKAGING AN OUTBOUND EBXML MESSAGE

13. See comment above (9) on time to live.

<ac>
I am simply restating the last paragraph in section 7.4.6 PersistDuration in
ebMS draft version 1.091:

The timestamp for a reliably sent message (found in the message heaer), plus
its PersistDuration (found in the CPA), must be greater than its TimeToLive
(found in the message header).
</ac>

16.  In the CPPA spec, V 1.0, Digital Envelope only specifies that RSA
Digital Envelope Encryption is to be used.  If the intent is to broaden the
use of that element, this must be reflected in a revision of that
subsection of the CPPA specification.  Also, unless the following has
already been done, some words should be added either here or elsewhere in
the MSG spec, defining and explaining digital envelope.  If the intent was
not to alter the use of Digital Envelope, then these words should be
changed to discussing identifying the sender's public key from the
appropriate certificate reference in the delivery channel definition.

<ac>
The intent is not to alter the use of Digital Envelope. As in the use of
S/MIME, I am assuming that the payload is encrypted using some symmetric
key. The symmetric key is itself encrypted using a public key provided by
the receiver. The latter is recorded in the DigitalEnvelope element
associated with the DeliveryChannel for the receiver. When the receiver
receives the message, it must use the private key that corresponds to the
public key to recover the symmetric encryption key. All I am trying to say
is that the CPP/A spec does not stipulate how a MSH manages its private
keys.
</ac>

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



Arvola Chan <arvola@tibco.com> on 12/05/2001 08:33:14 PM

To:    ebxml-cppa@lists.oasis-open.org
cc:
Subject:    [ebxml-cppa] Preliminary draft for appendix on how to use the
       Messaging Service with a CPA




Attached please find a Word document along with the message  header and
CPPA schemas. Suggestions on how to turn this into the normative  appendix
we plan to put into the 1.1 spec are most appreciated.

Thanks,
-Arvola