I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how to carry multiple, related EDI documents in MIME using the multipart/related content-type and how to calculate message integrity codes over such related documents. Section 2.3: a) Reference to MIC computation in EDIINT compression should be to Section 4, not Section 2 of RFC 5402. b) For clarity, may want to replace the text "When a digital signature is applied to the multipart/related envelope, the MIC is calculated on the entire multipart/related envelope, including the MIME header and all attached documents." with: "When a digital signature is applied to the multipart/related envelope, the MIC is calculated on the entire multipart/related envelope, including the multipart/related MIME header and all attached documents." c) Similarly, (as the sender performs the MIC calculation before encrypting) I would suggest replacing: "For an encrypted but unsigned and uncompressed message, the MIC is calculated on the decrypted multipart/related envelope, including header and all attached documents." with: "For an encrypted but unsigned and uncompressed message, the MIC is calculated on the unencrypted multipart/related envelope, including the multipart/related header and all attached documents." d) I don't understand: "or an unsigned and unencrypted message, the MIC is calculated over the data inside the multipart/related boundaries prior to Content- Transfer-Encoding. However, unsigned and unencrypted messages SHOULD not be sent due to lack of security.": Why do the MIC-calculation on the internal data only? Why not use the same algorithm (i.e. include the outermost multipart/related MIME header?). Also, should not canonicalization be carried out in this case? Section 3: - May be useful to use micalg SHA-256 (I realize this is an example, but generally we'd like to move in this direction and so examples should encourage it)? Section 4: - May be worthwhile to reference to S/MIME (RFC 5751) for Security considerations in general for signed multipart/related messages. -- Magnus