- From: Jacek Kopecky <jacek.kopecky@systinet.com>
- Date: Fri, 07 Nov 2003 02:47:57 -0800
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
+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