W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

Re: Issue #12 proposed resolution

From: christopher ferris <chris.ferris@Sun.COM>
Date: Fri, 28 Sep 2001 14:06:53 -0400
Message-ID: <3BB4BC3D.85AAA1F3@Sun.COM>
To: Mark Baker <distobj@acm.org>
CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

Please see my comments/responses below.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC