RE: Interop issue: how can clients force authentication?

I would like to add to Geoff response about timing. Depending on what type
of authorization credentials the user is attempting to enter there can be
short windows to the client and server as to the half-life of the
credentials. So a "not authorized" would be mandatory from the server as the
credentials have aged beyond their usable window. Any further use of the
credentials should constitute a replay attack.
 
As for the language Dan proposed. There needs to a limit for the number of
times a userid can attempt authentication/authorization, the spec should not
allow "and continues to challenge (401) the client until the client
authenticates as a user who is actually authorized to perform all those
methods on that resource", otherwise it opens the door wide open for the
abuse.
 
IMHO, Dan's comment about clients forcing re-authentication is outside of
the DAV spec is correct. There are a number of topics around distributed
authentication/authorization that need to be addressed and the DAV spec
should work within the framework started by other WGs. 
 
 

- Even if the server comes back and says "yes, you could do that", 
by the time you get around to trying it, it may fail because the 
state on the server has changed, so a client needs to be prepared 
to handle the "not authorized" response in the middle of a stream 
of requests anyway. 

<snip> 

 > In the wonderfully-future-compliant case: the server actually looks at 
> the value of the property specified, and continues to challenge (401) 
> the client until the client authenticates as a user who is actually 
> authorized to perform all those methods on that resource.  At that 
> point the server return 409 because (ha!) DAV:authorized-methods is 
> actually a read-only property. 
> 
> In the currently compliant server case: the server just 
> authenticates/authorizes the user for the PROPPATCH on the resource, 
> and then either sets the (dead) property or refuses the request (403, 
> presumably), because the user is trying to set a property in the DAV: 
> space that's not mentioned in the current version of the spec. :^) 
>