- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Sun, 18 Jan 2004 21:53:12 -0500
- To: noah_mendelsohn@us.ibm.com
- Cc: Martin Gudgin <mgudgin@microsoft.com>, xml-dist-app@w3.org
On Jan 15, 2004, at 8:40 PM, noah_mendelsohn@us.ibm.com wrote: > Marc Hadley asks: > >>> I don't recall - do we already have text that >>> captures the other part of the resolution, >>> namely that MTOM doesn't preclude additional >>> parts in the package not reference via >>> miffy:Include ? > > Did we conclude that? Yes, we did. > More specifically, did we conclude that for Miffy > or for the HTTP binding as well? For both. The variability we introduced between XOP and MTOM was related to the cardinality of inclusions: we concluded that in XOP there could be multiple inclusions of the same binary part but that the HTTP binding would restrict it to a single inclusion of any binary part. Both HTTP binding/MTOM and XOP would allow unreferenced attachments but they are outside the SOAP processing model. Marc. > Not surprisingly, I'm fairly strongly > opposed to allowing variability in the content sent by the HTTP > binding. > That said, I may just be repressing memories of a decision that went > counter to my preferences. > > I've just read the review copies of the specs, and regardless of what > our > issue resolutions say (and they should be clear), the current miffy > text > does allow for separate parts. The HTTP binding could probably be read > either way, since it says to make a part for each optimized piece, but > doesn't really say whether that means >only< for each optimized piece. > I > think we should remind ourselves what the resolution is on the http > binding, and clarify the MTOM document either way. I think I can live > with the variability in Miffy/XOP. > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > --- Marc Hadley <marc.hadley at sun.com> Web Products, Technologies and Standards, Sun Microsystems.
Received on Sunday, 18 January 2004 21:55:54 UTC