RE: BIND method response codes, new header?

I'm still looking for a compelling reason to do anything
about this at all.  So far, the only argument is for
"consistency".  Since these are different methods with
different semantics, I find "consistency" arguments less 
compelling than simplicity arguments (i.e. it simpler to
just always return 200 if there are no errors).

So what is the compelling use case for a client knowing
whether the new binding is replacing an old binding or not?

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Thursday, October 10, 2002 11:06 AM
To: Stefan Eissing
Cc: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: Re: BIND method response codes, new header?


Or.... how about....  (get your tomatoes ready...)

A new header, whereby the client can submit
assertions that it wants the server to test.  These tests
need not prevent an operation from occuring, but
they can inform the user of the situation just before
(or after) the operation occured.   It could test for things 
like etags and locks.  And in this case it could test if
a resource existed.

This header would not be bind specific.  And it
need not go in the spec now.  But if we are anticipating 
something like this, we wouldn't need to spend time defining
a new status code now or even debating which one to use.

J.

------------------------------------------
Phone: 914-784-7569