proposed response to XMLP response to issue #390

Following the telcon last week, here is the proposed response to the XMLP 
WG

<proposed response>
The WSAWG is not satisfied with the XMLP WG's response[2] to issue #390[1]
and would like to request the XMLP WG to reopen issue #390.

We believe that this issue involves a matter of perspective. 

A message that is either MIME multipart/related, or application/dime, when 
viewed 
from the outside clearly has a different semantic from dereferencing a URI 
to retrieve 
a resource representation and simply selecting a MIME part or DIME record 
and 
processing its contents. 

However, when viewed from the inside (from the perspective of processing 
the SOAP message part) the processing of a SOAP message that contains 
a URI reference should not be dependent upon whether the "resource" is 
packaged locally in a MIME or DIME part of the messsage or retrieved from 
the Web. 

We are of the opinion that dereferencing that URI to retrieve a 
representation 
of the resource identified by that URI should be a function of the 
binding.

We believe that the following use case has not been considered in the 
intro to 
the SOAP1.2-AF spec: 

      A SOAP message that contains URI references to resources that 
      are behind a firewall needs to be sent outside that firewall. 

       A valid approach to solving this problem would be to retrieve the 
       representations and "cache" them with the message that references 
them 
       in a multipart/related or application/dime package. 
       The processer that receives the message can establish a URIResolver 
with 
       the MIME or DIME package as its context. This URIResolver can be 
interposed 
       on any requests to dereference a URI by the SOAP application. If 
the URI is contained 
       in the MIME or DIME package, then the part/record that has that URI 
as its identifier is 
       returned, otherwise, the request is dispatched to the Web. In 
either case, the result is the same. 
       The SOAP application does not, and need not, know the details of 
how the representation 
       was dereferenced. It just dereferences the URI and receives a 
representation of the 
       identified resource. 

      The same SOAP application running behind the firewall might not have 
the representation 
       packaged with the SOAP message, but its processing is identical. 

In the context of this use case, the MIME or DIME packaging can be thought 
of as a portable 
cache for the retrieved representation. In many if not most cases, we 
believe that the use of "attachments" 
is an optimization of processing that might just as effectively be 
performed by dereferencing URIs on the 
Web. 

Consider the encoding of an HTML page that includes <IMG src="..."/> tags 
being sent in an email. 
Typically, the images can be marshalled into a multipart/related package 
along with the HTML 
such that the receiving MUA can view the HTML page along with the images 
that it references. 
The MUA that receives the message can view the HTML page as if it were "on 
the Web"... the fact that 
the images had been marshalled is irrelevant as it should be and does not 
change the processing of
the HTML, nor does it change the URI's of the images within the HTML 
markup.

We understand that the XMLP WG is undertaking an effort to provide a 
concrete binding(s) for the
abstract Attachment feature, we would ask that the XMLP WG take this issue 
into consideration
when it does so.
</proposed response> 

Comments? 

[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390 
[2] http://lists.w3.org/Archives/Public/xmlp-comments/2002Oct/0046.html 


Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624