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

RE: Proposed resolution for issue 440

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 6 Nov 2003 18:34:38 -0500
To: "Martin Gudgin" <mgudgin@microsoft.com>
Cc: "Marc Hadley" <Marc.Hadley@Sun.COM>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Message-ID: <OFE30A805F.A9A50511-ON85256DD6.00816781@lotus.com>

I think I side with Gudge in this discussion.  Marc, perhaps the following 
example will clarify the concern.  Let's say we adopt Gudge's rule of 
1-to-1 between xbinc:Include and parts in the "related" group.  What's the 
rule for intermediaries?  Simple:  the content is logically in the 
Infoset.  Let's assume a header with MTOM content is not removed at the 
intermediary.  If you go out over a non-MTOM binding, you send the 
characters (or whatever your binding does.)  If you go over an MTOM 
binding, then you MAY continue to carry the binary as a part (or MAY fail 
to optimize on the 2nd hop.)  The two bindings MAY conspire to optimize 
the copying of bytes from the inbound stream to the outbound.  Now, let's 
assume the header is removed:  the rule is very clear, even if the 
outbound binding is MTOM, there clearly MUST NOT be a part corresponding 
to the received binary.  So with Gudge's rule, the SOAP processing model 
tells you exactly what to do.

Now consider what happens if we allow parts not referenced by the SOAP 
envelope into the "related" package.  How do we know what do do with them 
at intermediaries?  How do we know whether to sign them with a dsig? Etc., 

I have mixed feelings about whether to allow multiple xbinc:Includes to 
reference a single part, but can easily live with our decision of 
yesterday to say "only one reference per part".  I quite strongly feel 
that Gudge is right that the value of MTOM/PASWA is that most all 
semantically interesting message content is logically in the envelope 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Thursday, 6 November 2003 18:35:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC