RE: Proposed resolution for issue 440

"Martin Gudgin" <[email protected]>
Newsgroups gmane.text.xml.distributed
Message-ID <DD35CC66F54D8248B6E04232892B63384EDA5F@RED-MSG-43.redmond.corp.microsoft.com>
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:[email protected]] 
> 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
> "
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.