Some feedback on Packaging v0-6

[Joe Lapp <jlapp@webMethods.com>]

1)  My understanding is that the plan is to allow multiple application
payloads to occur as multiple MIME parts, but the Packaging spec seems to
imply that they must all occur within a single MIME part.  The diagram
shows one part, the text refers to this one part, and at one point the text
even refers to the packaging of payloads within this part by saying that
such packaging is application-dependent.  All ebXML messages would use no
more than two MIME parts.  If this isn't what is intended, we might want to
clarify the spec, since we want even dummies like me to be able to read and
implement the thing, right?

2)  The spec doesn’t directly state whether the header MIME part must occur
as the first MIME part.  Although it does appear this way in the
illustration, it’s not clear whether the illustration is just intended to
exemplify an ebXML message.  Since the Content-ID identifies the header,
strictly speaking, the header need not be first.  However, there may be
efficiency concerns that would warrant requiring it to be first.

3)  Section 4.5.4 "Optional Support for Signed Headers" says that headers
may be signed, but does not make any statement about whether they can be
encrypted.  Section 4.6.4 "Optional Support for Signed and Encrypted
Payloads" says that payloads may be signed and encrypted.  Presumably
because encryption was not mentioned in 4.5.4, headers may not be
encrypted.  However, logically speaking, the spec does not preclude headers
from being encrypted.  Will ebXML allow headers to be encrypted?  My
understanding is that the answers to these questions will appear in the
"Messaging Security and Signature Specification."  But it appears to me
packaging spec is already providing a partial answer and is claiming that
these answers are within its scope.  Should we clarify this verbage?
Remove it?  Leave it?
 
4)  Section 4.7 "Message Digest Calculation" defines the portion of an
ebXML message that is to be used in the digest.  Where does the digest
itself go?  Seems like that would be a packaging issue, rather than an
issue for the security spec.  Maybe we should resolve this issue when we
tackle the security spec, updating the Packaging spec accordingly then.

- Joe