RE: T2 Recursive Behaviors

[David Fischer <david@drummondgroup.com>]

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