RE: Proposed resolution for issue 440

Dale, I do believe that SOAP headers (or the body, for that matter) may
use URIs freely, including cid: schemed URIs. 

I agree with Gudge that we shouldn't allow multiple references to one
MIME part and non-referenced MIME parts in one part because what we
should start from is the data from which the on-the-wire bits are
created, and that data I believe to be exactly one SOAP Envelope
information item with children. 

We are optimizing the transmission of that envelope, and we may or may
not choose to do various optimizations. One of these is transmitting
binary data optimally in binary form (as opposed to base64 or other
forms). If this is the only thing we choose to do, there will never be
non-referenced or multi-referenced MIME parts so we can as well
explicitly say so.

We can choose additional optimizations like folding multiple instances
of the same piece of binary data, but as this can be done on a higher
layer (Representation header being one example of how this can be done)
I'd choose to reject this optimization from the on-the-wire level as IMO
it makes implementation simpler.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Tue, 2003-11-11 at 10:09, Dale Moberg wrote:
> Hi Jacek,
> 
> One question about your comment here.
> 
> I have assumed that SOAP header blocks are free to make use of URLs in
> referencing external chunks of data.
> Anyway, I do not see how SOAP prohibits header blocks with that pattern.
> 
> If so, for those header block patterns, SOAP processing would go beyond
> (in some sense) what is "in the infoset" of the SOAP envelope. Or did I
> miss a constraint somewhere?
> 
> If that is the case, and URLs are allowed, the CID: scheme URLs are also
> allowed, it seems to me. The use case is that some SOAP node participant
> is unable to allow access via URLs using other schemes (because
> firewall/NAT/what-have-you) blocks it.
> 
> In that case, the multipart/related for MTOM has to be embedded inside
> of some other multipart. That seems complicated to me though it is easy
> enough to "make it work".
> 
> As a non big-guy representative, I am interested in your view on this
> situation. To me it seems wise to ease up on the restriction that the
> MTOM envelope has only MTOM parts in it...
> 
> 
> 
> Dale Moberg
> 
>

Received on Tuesday, 11 November 2003 19:12:30 UTC