W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2003

RE: Proposed resolution for issue 440

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Thu, 6 Nov 2003 09:14:48 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B63384EDA5F@RED-MSG-43.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT