RE: Proposal for SOAP 1.2

 
Forwarding and replying to some of the comments that Anish made to the
rest of you. 

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Wednesday, May 25, 2005 2:12 AM
> To: Yalcinalp, Umit
> Cc: Winkler, Steve; Liu, Kevin
> Subject: Re: Proposal for SOAP 1.2
> 
> I did notice that you have sent out the email to the asynch 
> tf list, but 
> I'm sending these comments to you (and not the async-tf list) as I 
> wasn't sure where you wanted the comments to be sent. You can either 
> respond to me or to the list (don't care either way).

I was given an action item to deliver proposals before the meeting
today. I wanted people to have time to read them and therefore sent the
proposal. I like to deliver on time for my action items. I thought
waiting until 1:00am was a safe bet :-)

I am responding to the list so that people are aware of your comments. 


> 
> Here are my comments:
> 
> 1) given the length of the text (and the fact that most of what is in 
> SOAP 1.2 part 2 HTTP binding is repeated, why not define a 
> new binding 
> as opposed to an extension? Or if it is an extension, then 
> just specify 
> the delta (which may be hard to do, but maybe not -- haven't 
> tried to do 

If you read my accompanying note to the tf, I do not care whether this
is labelled an extension or another binding. It requires a new name, and
well defined semantic. I can go either way whether it is an extension or
a new binding. 

I tried the delta approach. And it is hard. This is why it is easy to
read the document as is and everything is provided in context. Otherwise
it hinders readibility unless you are a SOAP expert and do a constant
diff with the delta :-)

> it).
> 
> 2) as you suggest, if there is/will be a SOAP Request MEP, it will be 
> simplier to compose WSDL in-out using two SOAP Request MEPs.
> 
> 3) the writeup talks about 'sending an acknowledgement' (for example, 
> section 4.1.2.2) -- not clear what that is. I'm assuming that 
> you mean 
> the HTTP-response in the 1st connection.

Yes

> 
> 4) the writeup needs to distinguish between a HTTP response and SOAP 
> response. The original SOAP 1.2 HTTP binding does not do that 
> as it is 
> the same, but in this case it isn't and needs to be clarified.
> 
> 5) it is not clear if soap faults are allowed to be sent back 
> on the 1st 
> connection. I'm assuming that they are not.

Yes. They are not. 

> 
> 6) In section 4.1.2.2, you ask -- What should be the 
> Content-Type header 
> field? I believe for empty entity body the content-* headers 
> should not 
> be present.
> 

I was not sure. Will do the change. 

> 7) There are numerous vestiges left from the SOAP 1.2 spec 
> cut-and-paste 
> that need to be removed/modified.

Can you be specific and point out what they are? I modified everything
that required modifying and I am not sure what I have missed. 

> 
> 8) Suggestion: Why not shorten MultipleHTTPConnectionEnabled to 
> MultipleConnectionEnabled?

Naming is not a fundamental thing. It can be named something else as
long as the group agrees. 

> 
> 9) Section 4 says:
> "Note: This proposal does not define how to support 
> soap-response SOAP 
> MEP. This MEP can be accomodated in an asynchronous manner by 
> sending an 
> empty message to an endpoint and it is supported by WSDL 2.0"
> 
> I don't understand this.

We discussed this topic in the WSDL wg. 

> Couldn't you just say that SOAP-response MEP is not supported by this 
> extension?

I have already omitted the SOAP-response MEP from the writeup so that it
is not in scope. 

> 
> 10) There is one instance of mixing (in section 4.1.2.4) between the 
> stages (requesting/sending etc) as defined for the MEP and the HTTP 
> sending/requesting/responding protocol stages.
> 
> {I know you have requested me to check/expand on this -- 
> don't have the 
> text, but will do so tomorrow}

Thanks. 

> 
> 11) table 17 -- remove 1st row
> 
> 12) table 16, last row says:
> "If the SOAP envelope infoset in the 
> http://www.w3.org/2003/05/soap/mep/OutboundMessage property 
> is null, the 
> entity body is omitted"
> 
> This is possible only in case of soap-response MEP, which 
> this extension 
> does not deal with. Similarly table 16, row 3 needs to be changed.

Ok, will do. Thanks for catching this. 

> 
> 13) table 17 talks about WS-Addressing address parameter, this is not 
> defined.
> 
> 14) table 17 talks only about 2xx, whereas section 3 say it 
> must be only 
> 200 (for success)
> 
> 15) section 2 says: "This extension can only be used in 
> conjunction with 
> WS-Addressing extension" -- specify the extension URI.
> 
> 16) editorial -- introduction para could be rewritten. For example 
> something like:
> 
> The MultipleHTTPConnectionEnabled SOAP1.2 HTTP Binding 
> extension is an 
> extension to the SOAP1.2 HTTP binding [ref]. The purpose of the 
> extension for SOAP 1.2 is {specify the purpose}. The 
> extension changes 
> the SOAP 1.2 HTTP binding, specified in [ref], as described in this 
> document. Specifically, it limits the binding to the SOAP 
> Request-Response MEP and requires that the Request and Response SOAP 
> message be sent over different HTTP connections.
> 
> 17) Section 5 says: "The semantics of using the 
> MultipleHTTPConnectionEnabled extension has been described already in 
> another document."
> 
> Which doc is that?

It is the proposal we jointly have for SOAP 1.1/HTTP binding :-). The
WSDL side does not necessarily change, therefore I did not cut and paste
here. 

> 
> 
> HTH.
> 

I will incorporate changes you suggest and wait for others to respond so
I can do this in one pass. 

> -Anish
> -- 
> 
> 

Thanks, 

--umit

Received on Wednesday, 25 May 2005 16:46:29 UTC