W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 12 Aug 2001 22:26:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103DED832@SUS-MA1IT01>
To: w3c-dist-auth@w3c.org
I'd just delete the paragraph in 9.8 that states:

   The timeout counter SHOULD 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.

The last sentence is redundant, since it is already specified in the
LOCK semantics.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Saturday, August 11, 2001 7:51 PM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org
Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS




Hey Geoff...

Could you make an explicit proposal as to how the spec should change?

BTW... I don't care if the server choses to do this or not.  I doubt
refreshing the lock creates a functional problem since I doubt a client
would be written to wait for a time out and choke if it didn't unlock the
resource.  OTOH, I don't see the point in encouraging servers to refresh
the lock either.   If a server developer/administrator discovers a reason
that this refreshing policy is good, they can use it, but we don't need to
encourage it since it might be pointless and costly.

 So my recommendation would be to silent on this... or perhaps somehow
express flexibility.

Anyway, perhaps you could suggest what change to 2518 you'd like... :-)

J.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
Received on Sunday, 12 August 2001 22:17:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT