- From: David Fallside <fallside@us.ibm.com>
- Date: Thu, 6 Jun 2002 15:06:57 -0700
- To: xmlp-comments@w3.org, ylafon@w3.org
- Cc: frystyk@microsoft.com, "Christopher Ferris" <chris.ferris@sun.com>, "David Orchard" <david.orchard@bea.com>, distobj@acm.org, highland.m.mountain@intel.com, "Marc Hadley" <marc.hadley@sun.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
Yves, pls capture the following issue in the LC issues list. I believe that it stems from an earlier action item that did not make it into the spec in time. It was submitted by Henrik, at the end of our GETF work. ========================================= From [2], this should be added to section 7.4.1.2 [4]: Table 11 refers to some but not all of the existing HTTP/1.1 status codes (see RFC 2616). In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see RFC 2817 for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in RFC 2616, section 6.1.1. The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. [2] http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0107.html [4] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindwa itstate ========================================= ............................................ David C. Fallside, IBM Ext Ph: 530.477.7169 Int Ph: 544.9665 fallside@us.ibm.com
Received on Thursday, 6 June 2002 18:08:12 UTC