[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Recursive Behaviors
I am working on creating some specific examples of how to use this spec and one of the foremost requirements will be SMIME encryption. I don't see how anyone can implement without the ability to encrypt and I don't see how to do encryption without this recursive behavior. It is often not sufficient to encrypt just the payload. In many cases, users will want all information which reveals the content (especially the Manifest) to be encrypted. SMIME must encrypt from boundary to boundary so the entire SOAP envelope will have to be included in order to get the Manifest. This behavior IMO is required by this spec and should be included. I don't think this has to be a long explanation. A one sentence statement to include recursion (encapsulation) should be sufficient. Regards, David Fischer Drummond Group. -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Monday, July 30, 2001 2:32 PM To: 'David Fischer' Cc: ebXML Msg Subject: RE: T2 Recursive Behaviors David I think the process (encapsulation) is a useful one. However I think that this should be a separate spec that describes how to do it - it could be an OASIS TC spec. There are several other useful examples, for example using sequencing to transport very large messages by chopping them into chunks. They are both additional good ideas that can be layered on top of what is already there. David -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Monday, July 23, 2001 7:07 PM To: Burdett, David Cc: ebXML Msg Subject: T2 Recursive Behaviors It seems that there will be no way to avoid occasional recursion within ebXML-MS such as encrypting a message with SMIME and putting the result in a bodypart wrapped by a minimal ebXML header structure. At the receiving end, the bodypart would then be decrypted and the resulting message resubmitted to the ebXML parser (recursive). This behavior would also solve the concern over potential in-route additions to the Manifest (put the old message in a bodypart, create a new set of headers with additions to the Manifest, then once the new message is parsed then the old message should be resubmitted to the parser (recursive)). While none of this behavior is prohibited by the current spec, neither is it specifically allowed. Can we add one sentence somewhere to specifically allow this? Regards, David Fischer Drummond Group. ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC