+1 Here's why I think your proposal is right for both questions (apparently as opposed to Marc and possibly others): 1) The MIME multipart/related envelope is created as an optimization of an infoset of a SOAP envelope. There's no way for unreferenced parts to appear in there. For adding possible other attachments, this multipart/related envelope should be viewed as the SOAP message, and that can be embedded as the root part of an other multipart/related envelope which can contain as many unreferenced parts as it wishes. 2) Because there are different possible semantics of the multiple includes of one attachment (reference, copy), I agree these can be handled by the layer above, which also has better knowledge of which attachments are actually multiplied. This restriction doesn't restrict the xbinc:Include element itself, it's just that we use it in one way. Best regards, Jacek Kopecky Systinet Corporation http://www.systinet.com/ On Wed, 2003-11-05 at 09:48, Martin Gudgin wrote: > On the call today we discussed issue 440[1] which asks > > 1. whether MTOM packages can contain MIME body parts that are NOT > referenced by an xbinc:Include element > 2. whether a MIME body oart can be referenced by multiple > xbinc:Include elements > > I took an action to propose a resolution to this issue, so here it is. > > Proposed resolution: > > Each MIME body part (except the root) MUST be referenced by exactly one > xbinc:Include element. Intermediaries are required to respect this rule. > > Rationale: > > Allowing MIME parts that are unreferenced breaks the infoset model. > Ensuring MIME parts are referenced exactly once simplifies > implementations. > > Cheers > > Gudge > > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440 >Received on Friday, 7 November 2003 05:48:07 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:12:00 UTC