RE: Proofread of MTOM draft

"Martin Gudgin" <[email protected]>
Newsgroups gmane.text.xml.distributed
Message-ID <DD35CC66F54D8248B6E04232892B633802292A68@RED-MSG-43.redmond.corp.microsoft.com>
 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: 19 May 2004 05:50
> To: [email protected]
> Subject: Proofread of MTOM draft
> 
> 
> I've just done a quick skim of MTOM, following up on XOP 
> notes of last 
> night.  I did not get to the media-type registration part.  
> Also:  I have 
> >not< had time to proofread the following.  My meeting is 
> about to start, 
> and I want to get this sent out in time for review.   
> Apologies for any 
> errors.
> 
> Most Important
> --------------
> 
> * Section 3.2:  "When sending a SOAP message using the MIME 
> Multipart/Related Serialization, the SOAP message Data Model 
> is serialized 
> as specified in [XOP] 4.1 Creating XOP packages. "  -> "When 
> sending a 
> SOAP message using the MIME Multipart/Related Serialization, the SOAP 
> >envelope Infoset< is serialized as specified in [XOP] 4.1 
> Creating XOP 
> packages. "

+1 

> 
> * Section 4.3.1:  "Generate a binding-dependent SOAP fault"  
> This seems to 
> violate the rule in the SOAP binding framework that a SOAP 
> binding must be 
> capable of sending any legal SOAP envelope infoset.  The bullet as 
> supplied seems to preclude, for example, sending a SOAP message that 
> contains an error report showing a fragment with a 
> xop:Include in it.  I 
> would prefer to leave out this bullet, but I do realize that 
> in so doing 
> we make implementations a bit more complicated, and to handle a quite 
> obscure case.  Still, I don't like the precedent that a SOAP 
> binding can 
> punt on sending any SOAP envelopes that prove inconvenient.  Maybe we 
> debated this earlier and I forgot?
> 

I don't remember the discussion either, but I'm tempted to leave this
one as is for LC.

Gudge
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.