- From: Dan Brotsky <dbrotsky@adobe.com>
- Date: Thu, 27 Jun 2002 11:23:31 -0700
- To: w3c-dist-auth@w3c.org
I like Lisa's latest proposal.
I have two concern, based on no experience but just reading the text:
1. is it clear that REFRESH on any resource controlled by the lock (not
just the URI in the original request) refreshes the counter?
2. is it clear that server policy is allowed to refresh the lock for its
own reasons?
Perhaps the following wording is true to the original but slightly
clearer on these points?
The timeout counter MUST be restarted if a refresh LOCK request is
successfully executed on any resource controlled by the lock. The
timeout counter SHOULD NOT be restarted as a consequence of any other
client request.
dan
On Thursday, June 27, 2002, at 09:46 AM, Lisa Dusseault wrote:
> I’m not so sure about the wording you suggest. It drops the requirement
> that the lock MUST be refreshed if a refresh LOCk method is
> successful. How about this:
>
>
>
> “The timeout counter MUST be restarted if a refresh LOCK request is
> successful. The timeout counter SHOULD NOT be restarted at any other
> time.”
>
>
>
> Lisa
>
>
>
> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Thursday, June 27, 2002 8:25 AM
> To: Lisa Dusseault
> Cc: Webdav WG (E-mail)
> Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS
>
>
>
> The current wording is difficult to understand. I'd suggest that the
> wording be changed from...
>
> The timeout counter SHOULD NOT be restarted any time an owner of the
> lock sends a method to any member of the lock, including unsupported
> methods, or methods which are unsuccessful. However the lock MUST be
> refreshed if a refresh LOCK method is successfully received.
>
> To simply say...
>
> The timeout counter SHOULD only be restarted if a refresh LOCK method
> is successfully received.
>
> If you like, we can mention that this is a change from 2518.
>
> ------------------------------------------
> Phone: 914-784-7569, ccjason@us.ibm.com
>
Received on Thursday, 27 June 2002 14:24:06 UTC