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

Re: Access Control Preliminary Draft

From: -=jack=- <jack@twaxx.twaxx.com>
Date: Mon, 7 Jul 1997 14:32:02 -0700
Message-Id: <9707071432.ZM29942@twaxx.twaxx.com>
To: "'Judith Slein'" <slein@wrc.xerox.com>, Dylan Barrell <dbarrell@opentext.ch>
Cc: jack@twaxx.com, "jradoff@novalink.com" <jradoff@novalink.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
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

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

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?


(This text composed by voice)

Received on Monday, 7 July 1997 17:33:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:15 UTC