- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Thu, 6 Nov 2003 09:14:48 -0800
- To: "Dale Moberg" <dmoberg@cyclonecommerce.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Dale, I'm afraid I don't understand any of the below. Why could MTOM multipart/related packages not be transmitted over HTTP? Or SMTP? All we are saying in PASWA/MTOM is that for the multipart/related 'package' that contains the SOAP envelope every other MIME part in that 'package' MUST be referenced by EXACTLY one xbinc:Include in that envelope. Gudge > -----Original Message----- > From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] > Sent: 06 November 2003 16:17 > To: Martin Gudgin; Xml-Dist-App@W3. Org > Subject: RE: Proposed resolution for issue 440 > > > Even the HTTP flavor of MIME syntax allows any MIME entity to > be packaged up with other bodyparts. Prohibiting this > compositional functionality is in flagrant violation of MIME rules. > > Even if we were to think of MTOM as akin to an encapsulation > (such as the MIME within BER of CMS), no prohibition on > combination with encapsulted MIME has any precedent in open > internet standards. > > Possibly since MTOM uses multipart/related, it would be > possible to say, that for this multipart/related usage, that > every bodypart in the MTOM multipart/related is referenced by > exactly one xbinc:include. > > Assertions going that restriction would, however, violate > well-entreched older internet/web technology. No good > technical reason has been given for going that far. IMO > arbitrary disruptions to established open standards is > generally a good thing to avoid, even when seeking the "one > ring to rule them all." > > If the prohibition on combining with other parts is adopted, > SOAP MTOM should not be used in either SMTP, HTTP or HTTPS > MIME transfer situations IMO. > > You cannot build an applicability profile of a "CAN be > combined with any X" by saying "MUST NOT combined with any X > other than these." So this is not a profiling of a standard, > but a violation of a standard. I don't think you should go > there. As indicated above, the infoset preoccupation does not > even require this convention. > > Dale Moberg > > > The above pertains IMO to what Gudge stated here: > > "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 Thursday, 6 November 2003 12:14:51 UTC