RE: Open Questions on using the Atom Feed Format for search results

["Darrick Brown" <dbrown@xxxxxxxxxxxxxx>]

> On 9/27/05, Darrick Brown <dbrown@xxxxxxxxxxxxxx> wrote:
>> I have a good amount of experience dealing with ambiguous return 
>> values from FTP.  It's horrid.  I'd hate to see Atom in the same
camp.
>
> The spec used to detail many error codes. Most of them ended up
> parroting the HTTP spec word for word. I'd say the bar for
> inclusion is whether there's something that needs saying which
> isn't in RFC2616.

My concern is not the error codes themselves.  I'm concerned with what
error codes get returned when.  I agree that the Atom spec should not
duplicate Section 10 of RFC2616.  However, Atom has new concepts that
HTTP does not.  For example, what error should I expect back from an APP
server if I PUT an updated Entry to a previously existing entry URI that
has since been deleted?  Should I expect "400 Bad Request", "404 Not
Found", or "406 Not Acceptable"?  2616 certainly does not cover this.

Are any other client developers concerned about this or do most everyone
feel that section 4.5 of the APP draft is sufficient?