- From: Jacek Kopecky <jacek.kopecky@systinet.com>
- Date: Tue, 11 Nov 2003 16:12:16 -0800
- To: Dale Moberg <dmoberg@cyclonecommerce.com>
- Cc: XMLP Dist App <xml-dist-app@w3.org>
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