[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Preliminary draft for appendix on how to use theMessagingService with a CPA
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC