RE: [i95, i22] - Proposal for clarifying use of SOAPAction

From RFC 2817, I found 

3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]

Cheers,
Dave

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Henrik Frystyk Nielsen
> Sent: Friday, April 27, 2001 8:25 AM
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: [i95, i22] - Proposal for clarifying use of SOAPAction
> 
> 
> 
> >I think I'd prefer to see some generic name for a 425 like 
> >error code eg. (Header Required by Context Missing) in this 
> >case the context is SOAP. If there is no existing HTTP error 
> >code that can be leveraged to indicate the absense of a 
> >required SOAPAction header then maybe we need to ask for one 
> >to be assigned - but i think it would need to be justified on 
> >the basis of more general utility to the sorts of things 
> >layered above HTTP. 
> 
> Other than the generic status code classes, status codes are actually
> fairly specific and indeed intended as such. The intent of 
> this code is
> not to say that any old header field is missing - it is specifically
> that this request needs a SOAPAction header field. Most other 
> 4xx status
> codes react to specific header fields as well.
> 
> >It seems a little awkward to me from a spec. maintenance POV 
> >that a change to the spec. of the SOAP/HTTP binding cascades a 
> >change in the HTTP spec. It probably also sets a bad precident 
> >for other protocols layered over HTTP to request/require 
> >error/status codes to suit their one specific purposes.
> 
> It is not a change to the HTTP spec - HTTP provides an extensibility
> hook that anybody including us can use. Examples of other specs that
> defines status codes are
> 
> 	http://www.normos.org/ietf/rfc/rfc2817.txt
> 	http://www.normos.org/ietf/rfc/rfc2774.txt
> 	http://www.normos.org/ietf/rfc/rfc2518.txt
> 
> Btw, 2817 uses 426 so that seems to indicate that 425 is already taken
> but I can't find it anywhere. 
> 
> Henrik
>

Received on Monday, 30 April 2001 14:23:41 UTC