RE: Access Control Preliminary Draft

I agree we should make a decision.

The only time I can see it being necessary to disallow access to a resource is if its state is inconsistent due to dependent parts being out of sync (e.g. If an HTML page is edited and a reference to an image added and this image has not yet been posted to the server)

the options for solving this are

1)  The possibility to update a group of resources in an atomic operation
2)  Supporting both types of lock with the ability to lock a collection of resources
3)  The concept of a published version of a resource with the ability to publish the most recent version of a collection of resources in an atomic operation (i.e. the contents could then be posted out of sync and once everything is available the collection is published)

I would vote for supporting both types of lock and supporting locks on a collection of resources.

Cheers
Dylan

----------
From:  -=jack=-[SMTP:jack@twaxx.twaxx.com]
Sent:  Montag, 7. Juli 1997 17:32
To:  'Judith Slein'; Dylan Barrell
Cc:  jack@twaxx.com; jradoff@novalink.com; w3c-dist-auth@w3.org
Subject:  Re: Access Control Preliminary Draft

I think it should be up-to the implementation whether the write lock prevents
people from reading a resource. I can definitely see the requirements for both
types of locks (although I think that the type which allows reading is more
valid in a Web environment) but I think it overkill to require provision of
both
----------------

I think it would be ok to allow the implementation and those doing it to
decide whether or not they want to support either allowing the reading of
resources which are write-locked, or to prevent people from reading a
resource when it's write-locked, but I think we should decide whether or
not we'll choose one or the other of these definitions, or support both.

Perhaps I'm mistaken, but it's my feeling that part of what we're trying
to do is to present the basic landscape of this technological area to the
community at large, and to make reasonable judgments about how to negotiate
this landscape... if this is true, it's my feeling that we should clearly
examine the issue and make a decision.  Either you can read write locked
resources, or you can't, or there's infrastructure to support both, which
may then be applied as necessary and/or desired. For what it's worth, I'm
of the feeling that it's perhaps not necessary to prevent folks from
reading a resource simply because a new revision is currently being created
as there's usually no reason to be concerned or interested until that new
revision is available, although I can imagine cases in which folks might
not want to read a document when they know a new version is being created,
and in this case, they might want to wait.  It would seem that we need to
decide how important this is.  It it's very important that write locks
be able to prevent the accessing of a resource, then we should probably
support it.  If it's also determined that this can be a nuisance (and it's
my contention that it *will* be a nuisance if *all* write locks prevent the
read access of the particular resource) then when it's not necessary in a
given case, we should probably allow it to be optional to facilitate the
proper treatment of resources, or in other words, we should probably support
both.

Are there critical cases in which preventing read access for resources
which are currently write locked is critically important?  If so, what
are these cases?  Is there compelling evidence to state that ALL write
locks should prevent any read access?  If there's need, then we should
probably support both policies, but we should be fairly careful to make
sure there really is reason to support both... any comments?

-=jack=-

(This text composed by voice)


--

Received on Tuesday, 8 July 1997 04:42:35 UTC