Re: Proposed resolution for issue 440

noah_mendelsohn@us.ibm.com wrote:

> Anish Karamarkar writes:

s/Karamarkar/Karmarkar
;)

> 
> 
>>>We have already accepted use case UC6 [2]
> 
> 
> I'm not being fascetious here, but MTOM is a layered system, and we need 
> to be clear on the layers to which our use cases apply.  At the highest 
> level, we clearly meet this use case already.  I suspect that those who 
> proposed it also want it to apply to the particular serialization we are 
> recommending, but we should probably say so. 
> 

My understanding of the use case was that it did apply to the MIME 
serialization that is part of MTOM.

> FWIW:  for exactly the reasons Gudge has raised, I have some concerns 
> about our having approved UC-6.  The concerns are not strong enough for me 
> personally to request that we reopen the question if we have a "status 
> quo" decision, but I am sympathetic to the downsides of having to do 
> reference counting at intermediaries.  Depending on how implementations 
> work, this could require intermediaries to do a much more careful parse 
> than would otherwise be necessary.  Without this, I could go into a 
> well-formedness check on headers not targeted at me, at least in many 
> cases.  With this, I will almost surely have to check them for 
> xbinc:includes so I can count 'em up.  Seems like complexity to me.  If 
> there is a compelling need for the use case, fair enough.  If it's on the 
> 20 side of 80/20, I have some doubts.  Thank you!
> 

IMHO, there is a compelling need not to have to duplicate the same 
binary data in multiple MIME parts. This results in unnecessary message 
bloat.

If we wanted to reduce the complexity on the receiver side wrt to ref 
counting, it could be done by defining a SOAP header that includes the 
the ref counts

Comments?

-Anish
-- 
> Noah
> 
> [2] http://www.w3.org/2000/xp/Group/3/10/wd/soap-os-ucr.html

Received on Friday, 7 November 2003 23:39:25 UTC