Re: Issue #12 proposed resolution

Mark,

Please see my comments/responses below.

Cheers,

Chris

Mark Baker wrote:
> 
> Hi Chris,
> 
> Two issues for you.
> 
> > As agreed on the call, I have removed reference to 201, 203, 205 and
> > 206. I have also changed the SHALL to a MAY in regards to 405 and
> > I have modified 500 to reflect its use for cases other than those described
> > in section 6.3.2 (4xx Client).
> 
> Issue 1;
> 
> I'm quite curious to hear why the references to those other response
> codes were removed.  Is it because you felt that only these response codes
> needed an additional explanation in the context of their use with SOAP?

The WG took the position (mostly) that only those status codes that
had SOAP-specific meaning would be mentioned. 

> If so, I can buy that, but I'd suggest that 202, 405, and 415 don't need
> that explanation (no biggie though).

Actually, in the context of the SOAP/HTTP "default" binding, I think that
they do.

> 
> It's good that there's no mention in your proposal of disallowing other
> status codes, but as with 3xx, I'd suggest that explicitly stating that
> fact would be useful to implementors.  That's my main concern here really -
> that developers don't assume that other status codes can't be used.

I think that's where we're at now, trying to figure out if we say
this explicitly, or leave it to the imagination of the reader. I favor
explicitly saying something, as I believe does Stuart and others.

My thinking is that most readers of the SOAP spec will NOT have read the
HTTP RFC. Providing them with a hint/guidance is useful IMO.

> 
> Issue 2;
> 
> In my original proposal[1], I had a footnote;
> 
> "(*) I would normally suggest that using the specific 5xx or 4xx status
> codes (rather than 400 and 500) should be used, but as SOAP is trying to
> be application-protocol neutral, I can understand its desire not to."
> 
> I believe it's still important for SOAP developers that they *not* be
> forced into specifying an HTTP response code.  I therefore think it's
> important that a default response code be defined for each type of SOAP
> fault.  I was imagining that the code would look something like this;
> 
>    SoapFault f = new SoapFault( SoapFault.CLIENT_FAULT, "you did \
>      something wrong" );
>    // f.statusCode initialized to 400 above, but hidden from developer
>    soapConnection.setResponse( f );
> 
> and that this could be used by the majority of developers, and would
> return a 400 (client fault) status code.  Alternately, developers
> requiring specifying more fine grained response codes could do this;
> 
>    SoapFault f = new SoapFault( 405, "don't know how to do that" );
>    soapConnection.setResponse( f );
> 
> In [1], I'm suggesting what that *default* fault response codes should
> be.  Obviously the default for a good SOAP response should be 200, but
> using a mechanism similar to what's above, developers should be able to
> specify more fine grained 2xx response codes.

I understand where you're coming from, but my thinking is that if you
have (as I do) any expectation of interoperability, you need to say what
is required so that an implementation can know what to expect. 

> 
>  [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0017.html
> 
> MB

Received on Friday, 28 September 2001 14:06:54 UTC