Re: Proofread of MTOM draft

[email protected] wrote:

> 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. "

Oops, the Data Model is still there :-(.

> 
> * 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?

There is still the first bullet to recover from the "error" in a 
graceful way.

> Editorial or minor
> ------------------
> 
> * Section 1.2: "The implementation of the abstract feature as a binding 
> feature for an HTTP binding is intended to enhance the SOAP HTTP binding 
> described in [SOAP Part 2] 7. SOAP HTTP Binding or an updated version of 
> it. "  This wording seems clumsy, but I don't have time to propose 
> alternative.

How about:
"The implementation of the Abstract Transmission Optimization Feature 
for the SOAP 1.2 HTTP binding is intended ..."

> * Section 1.2: "the specification described herein fulfills these 
> requirements" maybe should be "the specification described herein fulfills 
> 
>>those< requirements"?

Yes.

> 
> 
> * Section 2.3.4:  "The choice of whether to implement such cooperation, 
> and if so the means used, is at the discretion of the binding 
> specification(s) and/or the implementation of the bindings. properties." 
> Remove trailing word "properties".

OK.

> * Section 2.3.4: "Other bindings may be capable of optimization, but may 
> or may not choose to or succeed in optimizing the same portions (if any) 
> that were optimized in the inbound message."  Grammar.  Parses as 
> "bindings...may or may not choose to...optimizing".   Suggest "Other 
> bindings may be capable of optimization, but may or may not >choose to 
> optimize< the same portions (if any) that were optimized in the inbound 
> message. "

OK.

> * Section 3.3, 2nd para:  "incorrectly" is spelled incorrectly

OK.

> * Section 4.3:  "the XOP Infoset build" -> "the XOP Infoset built"

OK.

> * Section 4.3.1.1 (2nd bullet  in first list):  "extracted binary parts 
> MUST NOT be referenced with more than one xop:Include in the SOAP message 
> part. " -> "extracted binary parts MUST NOT be referenced >by<more than 
> one xop:Include in the SOAP message part. "  Not important, but saying 
> "reference with" seems a bit clumsy.

OK.

Hervé.

> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
>