We put off items 16, 50, & 97 because of backward compatibility. Since that is no longer an issue, I would like to propose the following section addition. Regards, David Fischer Drummond Group ------------------------------------ 1 2 Encapsulation Some implementations may require that ebXML messages be Encapsulated into the payload of another ebXML message in a recursive fashion. This might be needed for encrypting a message where the headers need to be included in the encryption with the payloads. This might be useful when an intermediary node needs to add a payload to an existing message without disturbing a signature. This might also be used to break very large messages, or messages with large numbers of payloads, into smaller pieces for transmission (how this is done is outside the scope of this specification). These examples highlight some possible uses for Encapsulation but do not encompass all possible uses. When the Encapsulation process is applied, the MSH shall put the original message with the normal Multipart/Related content-type, as the payload of another ebXML message. If required, this Multipart/Related MIME structure may be encrypted using an approved encryption process (XMLEncryption, S/MIME, etc.). A minimal set of headers shall be constructed, or copied from the original message, for this message with: · a Service element set to uri:www.oasis-open.org/messageService/ · a n Action element set to Encapsulate These settings are NOT REQUIRED if the Receiving MSH can understand other settings and correctly process the Encapsulated message. When the Receiving MSH parses this message, the Encapsulated payload should be reprocessed as a new message, after decryption as necessary.