Re: Some feedback on Packaging v0-6

[Christopher Ferris <chris.ferris@east.sun.com>]

Joe,

Thanks for your feedback. Please see below.

Cheers,

Chris

Joe Lapp wrote:
> 
> 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?

Thanks for the feedback, we'll look at adding an example of multi-part
payload. 

In answer to your question, there is a single MIME Body representing the
ebXML payload. It can be MIME multipart/* if there are multiple payload
documents.

> 
> 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.

Content-ID doesn't identify the header. The header is identified by
virtue of the Content-Type of application/vnd.eb+xml.

> 
> 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?

I'll leave this one to Dick. We may need to discuss next week.

> 
> 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.

Good question;-) 

> 
> - Joe

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903