Subject: Re: Yet another ACL Strawman
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Date: Tue, 30 Dec 2003 00:24:37 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> What if the client is accessing two servers -- one which does not support
> ACL?

Well, then, presumably he has no choice but to use PERMISSIONS on that
server.  But he wouldn't be using PERMISSIONS and ACL simultaneously on
the same server.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 17:38:59 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> Well, you saw an explanation about how that can be done in Timo's message.

Yes -- I'm pretty sure now I misunderstood what you meant.

> But there aren't any such protocols!  And once you go down that path, then
> you get into the obvious question of why IMAP is even in the ACL business.

LDAP, atleast, has been used for group management.  Certainly a directory
makes more sense to store this information in than a mail store.

> > I'd also call it a disadvantage that now a server that wants to implement
> > ACL has to implement another orthogonal scheme which is similar to ACL in
> > complexity.
>
> No, PERMISSIONS is much smaller.
[snip]

Ok, we were talking about two entirely different PERMISSIONS
descriptions.  Now I have a clear(er) picture of yours.

I'm going to think this over now.

> A user who normally manipulates access control would typically use either
> PERMISSIONS or ACL, but would not use both.  Or, put another way, anyone
> who does use both deserves to lose as punishment for his foolishness.

What if the client is accessing two servers -- one which does not support
ACL?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 14:34:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> But here we're not talking about ACL2 -- we're talking about the upgrade
> path from ACL to ACL2.  We're currently *in* a world where there are
> deployments with different groups with different rights on a folder, and
> that needs to be dealt with.  If that means we need to have both UNION and
> MOST-SPECIFIC, that's fine with me.

Well, you saw an explanation about how that can be done in Timo's message.

> I don't think that it is reasonable to expect the IMAP server to be even
> capable of manipulating groups -- leave that to protocols that have been
> designed for that sort of thing.

But there aren't any such protocols!  And once you go down that path, then
you get into the obvious question of why IMAP is even in the ACL business.

> I'd also call it a disadvantage that now a server that wants to implement
> ACL has to implement another orthogonal scheme which is similar to ACL in
> complexity.

No, PERMISSIONS is much smaller.

Think of there being only four identifiers (in the RFC 2086 sense): owner,
group, world, and anonymous.

The anonymous user is stuck in anonymous.

Otherwise, if your userid is in the owner list, then you get owner rights.
Otherwise, if your userid is a member of a group that is in the group
 list, then you get group rights.
Otherwise, you get world rights.

There are tools to manager the owner list, group list, and membership
within a group.  Some of these tools may be restricted to admins.

> Clients then have to interpret both of these unrelated
> schemes to figure out what is going on.

No.  Not normally, anyway.

A client would not normally be using the ACL commands if the user is not
someone who normally manipulates ACLs for that mailbox (the "owner" in the
PERMISSIONS world).

A user who normally manipulates access control would typically use either
PERMISSIONS or ACL, but would not use both.  Or, put another way, anyone
who does use both deserves to lose as punishment for his foolishness.

The missing piece of the equation is "how does a non-owner" know whether
or not he can do something?  *That* is done in one of two ways: either by
trying it to see if it works, *OR* by doing an access control CHECK
operation.

The access control check operation ("can I do t to such-and-such mailbox")
is something that is common to both PERMISSIONS and ACL.  Fortunately,
access control check is less complicated than trying to represent
PERMISSIONS in ACL or ACL in PERMISSIONS, since access control check is
merely a binary "yes or no" to the question "will such-and-such win?".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Mark Crispin <[email-masked]>, [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: Re: Yet another ACL Strawman
Date: Tue, 30 Dec 2003 00:07:25 +0200
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

--Apple-Mail-7--60835413
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Dec 29, 2003, at 11:24 PM, Rob Siemborski wrote:

> On Mon, 29 Dec 2003, Mark Crispin wrote:
>
>> And it seems that the problem is brought about *not* by most-specific
>> between user vs. group vs. world identifiers, but rather by 
>> most-specific
>> between groups with different rights.  That's a design wart in ACL2 
>> that
>> bears looking into.
>
> But here we're not talking about ACL2 -- we're talking about the 
> upgrade
> path from ACL to ACL2.  We're currently *in* a world where there are
> deployments with different groups with different rights on a folder, 
> and
> that needs to be dealt with.  If that means we need to have both UNION 
> and
> MOST-SPECIFIC, that's fine with me.

I'm not sure if you really understood what Mark said.. It anyway sounds 
to me like a quite workable solution. You'd have MOST-SPECIFIC 
behaviour but if there's multiple groups, you'd get union of them. 
Wouldn't that make it possible to quite easily convert old ACLs to 
ACL2? You can keep your old groups, only problems are if you have 
combined user, group and world rights. Then you'd have to do something 
like:

user + world: merge world rights directly to user
user + group(s): merge group rights directly to user
group(s) + world: create a new "world" group and give world rights to 
world group

Other combinations would work the same way as they did with ACL.

--Apple-Mail-7--60835413
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-7--60835413--

Date: Mon, 29 Dec 2003 16:24:46 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> And it seems that the problem is brought about *not* by most-specific
> between user vs. group vs. world identifiers, but rather by most-specific
> between groups with different rights.  That's a design wart in ACL2 that
> bears looking into.

But here we're not talking about ACL2 -- we're talking about the upgrade
path from ACL to ACL2.  We're currently *in* a world where there are
deployments with different groups with different rights on a folder, and
that needs to be dealt with.  If that means we need to have both UNION and
MOST-SPECIFIC, that's fine with me.

The proposal was more or less an attempt to try an alternative/minimal
approach.  It seems that in order to keep everyone happy feature-wise we
are better off (however bad it is) with ACL2 and some sort of
way to announce how identifiers interact.

> Perhaps matters would be easier if you discuss how you implement groups in
> RFC 2086.  As I read RFC 2086, it's a complete crapshoot how groups work
> in ACL, so a client really has no idea what a "group" is.

In our implementation, group management isn't done internally, instead we
pull group membership from one of any number of sources (UNIX groups, AFS
ptserver, LDAP, etc).  This tends to work well since it ensures that group
management is located in a single place for any given enterprise, and
many applications can share the same groups.

I don't think that it is reasonable to expect the IMAP server to be even
capable of manipulating groups -- leave that to protocols that have been
designed for that sort of thing.

> No.  I mean that PERMISSIONS is a separate layer.  If you have PERMISSIONS
> access, you get it.  ACLs are only consulted if you don't have PERMISSIONS
> access.  The implication of this is that the use of ACLs requires denial
> of all permissions (setting PERMISSIONS rights to none).

Ok -- I understand what you are saying now.

> The disadvantage of this is that a PERMISSIONS only client won't show
> anything reasonable with server mailboxes that use ACL.  I consider this
> to be a small price to pay to gain the simplicity.

I'd also call it a disadvantage that now a server that wants to implement
ACL has to implement another orthogonal scheme which is similar to ACL in
complexity.  Clients then have to interpret both of these unrelated
schemes to figure out what is going on.  This is far from ideal from a
management perspective.

This is far worse than even the complicated scheme using regular
expressions that the most recent ACL2 thread came up with.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 13:09:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> Which has a similar problem for ongoing manageability (I want to remove a
> user from my admins group -- now I have to go through and fix ALL of these
> folders? You've got to be kidding me!).  And having an admins group *is*
> used in practice.

Uh, excuse me.

I did say something about the need to be able to manage the membership of
a group.

And it seems that the problem is brought about *not* by most-specific
between user vs. group vs. world identifiers, but rather by most-specific
between groups with different rights.  That's a design wart in ACL2 that
bears looking into.

Perhaps matters would be easier if you discuss how you implement groups in
RFC 2086.  As I read RFC 2086, it's a complete crapshoot how groups work
in ACL, so a client really has no idea what a "group" is.

> > Who said anything about limiting PERMISSIONS to only one user?  I
> > certainly never thought that "owner" equated to a single user; rather,
> > owner equates to one or more users with owner rights.
> The most recent strawman linked it to a single user identifier in the ACL
> realm.

That's not my strawman, and a single user identifier is not good enough.

> Unless you're saying my position is that "PERMISSIONS is a strict subset
> of ACL" which I *do* think is a good thing, because it ensures that
> servers that implement ACL can implement PERMISSIONS as well (as
> PERMISSIONS exists to enable servers that cannot implement ACL to still
> have a rights management scheme).

I think that your making PERMISSIONS a strict subset of ACL is what is
causing the confusion.  See next paragraph.

> > If necessary, I'd be ameniable to a compromise in which use of ACL
> > requires that all PERMISSIONS be denied.  That's been done before.
> I'm not sure what you mean here.  Do you mean an ACL server refuses to
> support any PERMISSIONS commands, or something else?

No.  I mean that PERMISSIONS is a separate layer.  If you have PERMISSIONS
access, you get it.  ACLs are only consulted if you don't have PERMISSIONS
access.  The implication of this is that the use of ACLs requires denial
of all permissions (setting PERMISSIONS rights to none).

The disadvantage of this is that a PERMISSIONS only client won't show
anything reasonable with server mailboxes that use ACL.  I consider this
to be a small price to pay to gain the simplicity.

> No, I'm worried that the complexity of multiple users/groups will just
> make PERMISSIONS "ACL with less bits" which is more or less useless, since
> the "less bits" problem can be equally well solved with adequately defined
> tied rights.

A PERMISSIONS model which does less than the most limited access controls
of the 1960s is also more or less useless.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 14:59:33 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> On Mon, 29 Dec 2003, Rob Siemborski wrote:
> > For example, let's say I have three groups: g1, g2, and g3.
> > g1: u1, u2 ("readers")
> > g2: u2, u3 ("writers")
> > g3: u3, u4 ("baddies")
> > And an ACL(1) on a folder of:
> > g1: rls
> > g2: wipcda
> > g3: -rlswipcda
>
> Is a group of specifically restricted users (with a large set of negative
> rights that denies world access) really in deployment today?  Does CMU use
> it?

While I was using negative rights in the example, a similar problem exists
with positive rights:

g1: u1, u2 ("readers")
g2: u2, u3 ("writers")
g3: u1, u3, u4 ("admins")
And an ACL(1) on a folder of:
g1: rls
g2: wipcd
g3: a

Results in a most-specific acl of:

g1: rls
g2: lwipcd
g3: la
u1: rlsa
u3: lwipcda

Which has a similar problem for ongoing manageability (I want to remove a
user from my admins group -- now I have to go through and fix ALL of these
folders? You've got to be kidding me!).  And having an admins group *is*
used in practice.

I can't see anyone who uses groups heavily to want to upgrade from ACL to
ACL2 if it meant that their ACLs would be destroyed in a
non-backwards-compatible manner.

> > If a PERMISSIONS server can support any number of groups, then you haven't
> > created something "lightweight" you've reinvented ACL2 with only two (or
> > three?) bits, and only one user arguments about PERMISSIONS as we're
> > currently having about ACL2, only with far fewer features in the protocol.
>
> If you feel that ACL was over-engineered, I won't dispute that.

Actually -- I feel it was under-engineered, given the problems it has with
identifiers and the delete right.

> > If its somehow ok to limit PERMISSIONS to only one user, it should also be
> > OK to limit PERMISSIONS to no groups.
>
> Who said anything about limiting PERMISSIONS to only one user?  I
> certainly never thought that "owner" equated to a single user; rather,
> owner equates to one or more users with owner rights.

The most recent strawman linked it to a single user identifier in the ACL
realm.

> I am dismayed by the notion that the capabilities of PERMISSIONS are to be
> dictated by ACL.  Among other things, this opens the door to charges that
> PERMISSIONS was deliberately sabotaged.  I certainly feel that way when
> you tell me what I can or can not have in PERMISSIONS.

I don't think that PERMISSIONS is being sabotaged -- rather, I think we
are conceding one sort of complexity (two rights management schemes) for
reducing complexity in ACL (communicating a server's capability).

Unless you're saying my position is that "PERMISSIONS is a strict subset
of ACL" which I *do* think is a good thing, because it ensures that
servers that implement ACL can implement PERMISSIONS as well (as
PERMISSIONS exists to enable servers that cannot implement ACL to still
have a rights management scheme).

> If necessary, I'd be ameniable to a compromise in which use of ACL
> requires that all PERMISSIONS be denied.  That's been done before.

I'm not sure what you mean here.  Do you mean an ACL server refuses to
support any PERMISSIONS commands, or something else?

> > We certainly don't need to
> > make the situation even worse by intrducing two extensions to do the same
> > thing, except that one has fewer bits than the other.
>
> Are you worried that PERMISSIONS would be good enough that nobody would
> implement ACL?

No, I'm worried that the complexity of multiple users/groups will just
make PERMISSIONS "ACL with less bits" which is more or less useless, since
the "less bits" problem can be equally well solved with adequately defined
tied rights.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 11:45:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> For example, let's say I have three groups: g1, g2, and g3.
> g1: u1, u2 ("readers")
> g2: u2, u3 ("writers")
> g3: u3, u4 ("baddies")
> And an ACL(1) on a folder of:
> g1: rls
> g2: wipcda
> g3: -rlswipcda

Is a group of specifically restricted users (with a large set of negative
rights that denies world access) really in deployment today?  Does CMU use
it?

RFC 2086 is very vague about groups.  I don't see how you can hope to have
something that's interoperable across all clients with RFC 2086.

We put restricted users on restricted servers.

> If a PERMISSIONS server can support any number of groups, then you haven't
> created something "lightweight" you've reinvented ACL2 with only two (or
> three?) bits, and only one user arguments about PERMISSIONS as we're
> currently having about ACL2, only with far fewer features in the protocol.

If you feel that ACL was over-engineered, I won't dispute that.

> If its somehow ok to limit PERMISSIONS to only one user, it should also be
> OK to limit PERMISSIONS to no groups.

Who said anything about limiting PERMISSIONS to only one user?  I
certainly never thought that "owner" equated to a single user; rather,
owner equates to one or more users with owner rights.

I am dismayed by the notion that the capabilities of PERMISSIONS are to be
dictated by ACL.  Among other things, this opens the door to charges that
PERMISSIONS was deliberately sabotaged.  I certainly feel that way when
you tell me what I can or can not have in PERMISSIONS.

> If groups are necessary in a "lightweight" system, then this particular
> strawman has basicly already lost, since that's the level of complexity
> that is causing all sorts of trouble in ACL2.

I disagree.  PERMISSIONS should split the access control problem into two
separate mechanisms, one of which is more featureful and the other of
which is more likely to be universally implemented.

It isn't as if this hasn't been done before, and successfully.  The
problem seems to come in when access control lists are proposed to be the
only solution to the access control problem, and then everybody gets
sidetracked on how ACLs are to be subsetted.

If necessary, I'd be ameniable to a compromise in which use of ACL
requires that all PERMISSIONS be denied.  That's been done before.

> We certainly don't need to
> make the situation even worse by intrducing two extensions to do the same
> thing, except that one has fewer bits than the other.

Are you worried that PERMISSIONS would be good enough that nobody would
implement ACL?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 12:50:48 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Wed, 24 Dec 2003, Mark Crispin wrote:

> > >  . I contend that MOST-SPECIFIC should be the *only* access calculation
> > >    rule
> > This makes it very hard or even impossible for a server to upgrade from
> > ACL (using UNION).  To do so, you would need to calculate the rights at a
> > given moment in time, and then re-advertise them.
>
> I don't think that's really the case.  The server should be able to
> calculate the ACL2 equivalent of ACL rights fairly easily.  Backwards
> calculation will be harder to do reversibly, but the point is that we're
> not trying to make that be perfect.

Sure, you can calculate the rights quickly at any instant of time, but
this fails if an organization has a long-standing use of union ACLs, and
has allocated their groups accordingly.  *Especially* if they manage them
for other purposes.

For example, let's say I have three groups: g1, g2, and g3.

Their contents:

g1: u1, u2 ("readers")
g2: u2, u3 ("writers")
g3: u3, u4 ("baddies")

And an ACL(1) on a folder of:

g1: rls
g2: wipcda
g3: -rlswipcda

In ACL(2)/MOST-SPECIFIC [disregarind the d right], the server would
upgrade this to:

g1: rls
g2: wipcda
u2: rlswipcda
u3: ''

If you apply this across many folders, this can create a sudden management
nightmare, since every user can suddenly have their own acl on every
folder, destroying a standing group management policy (and effectively
rendering the groups, which were designed with UNION style rights in
mind, entirely useless).

No, If ACL2 is to be adopted by current ACL sites, it needs to support
*atleast* the current semantics.

> > > 4) The design of the lightweight mechanism should not preclude a server
> > > implementation being able to support both lightweight and ACL2.
> > I would hope that any server implementing ACL2 would be able to trivially
> > implement any sort of "lightweight" system.
>
> The difficulty would be expressing more complex ACL2 patterns in
> lightweight.  My answer is not to try to make it perfect.

I offered a simple, unambiguous method to express this: an all-or-nothing
approach.

> > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> > > will be left up to the server implementation.
> > I think some rights are inherently tied though -- you wouldn't want a
> > server that uses 'r' as a READ-WRITE right.
>
> Yes, of course.  My point is that implementations should have latitude of
> how they interpret lightweight WRITE in the context of "s", "t", and "w".

This worries me somewhat, but I don't see any immediate problems with it
from either a PERMISSIONS-only server (no concept of acl bits) or an
ACL/PERMISSIONS shared server (you can always find out the real story by
looking at the ACL).

> > However, I fear that the use of groups in a "lightweight" system will just
> > recreate the current ACL2 situation -- loads of complexity to deal with
> > the fact that the lightweight system may not be able to handle more than
> > one group.
>
> I don't think that there's a problem.  A server, whether ACL2 or
> lightweight, has the freedom to decide how many groups it supports; and
> that number can be 1.

If a PERMISSIONS server can support any number of groups, then you haven't
created something "lightweight" you've reinvented ACL2 with only two (or
three?) bits, and only one user arguments about PERMISSIONS as we're
currently having about ACL2, only with far fewer features in the protocol.

If its somehow ok to limit PERMISSIONS to only one user, it should also be
OK to limit PERMISSIONS to no groups.

If groups are necessary in a "lightweight" system, then this particular
strawman has basicly already lost, since that's the level of complexity
that is causing all sorts of trouble in ACL2.  We certainly don't need to
make the situation even worse by intrducing two extensions to do the same
thing, except that one has fewer bits than the other.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Sun, 28 Dec 2003 15:14:41 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Shall we meet in Seoul?
Sender: [email-masked]

Who is going to be able to make it to Seoul? Do we have items about 
which we need to meet? Would a multicast session make a difference?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sun, 28 Dec 2003 15:12:12 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: IMAP URL update?
Sender: [email-masked]

On the LEMONADE list, Alexey mentioned that some folks had been 
talking about an update to the IMAP URL spec (RFC 2192) which would, 
perhaps among other things, add syntax to allow byte ranges for 
partial messages. Is anyone currently working on that or planning to 
work on it? I would like to refer to it in a document I am working on 
for LEMONADE.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 24 Dec 2003 14:38:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Sat, 20 Dec 2003, Rob Siemborski wrote:
> > Also, just as eliminating the need to support non-ACL access control
> > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> > compatibility.
> I'm not convinced that this "simplifies" ACL2 much, other than eliminating
> the need to tie the 'd' right.

If we have PERMISSIONS as a separate entity from ACL2, we can eliminate
tied rights in ACL2.  That is, a server that implements ACL2 must
implement all ACL2 rights as discreet entities.  Given that ACL2 is "all
or not at all", it can be made much simpler; and given that PERMISSIONS
exists as a lighter-weight model, it's alright that ACL2 be "all or not
all all".

> >  . I contend that MOST-SPECIFIC should be the *only* access calculation
> >    rule
> This makes it very hard or even impossible for a server to upgrade from
> ACL (using UNION).  To do so, you would need to calculate the rights at a
> given moment in time, and then re-advertise them.

I don't think that's really the case.  The server should be able to
calculate the ACL2 equivalent of ACL rights fairly easily.  Backwards
calculation will be harder to do reversibly, but the point is that we're
not trying to make that be perfect.

> > 4) The design of the lightweight mechanism should not preclude a server
> > implementation being able to support both lightweight and ACL2.
> I would hope that any server implementing ACL2 would be able to trivially
> implement any sort of "lightweight" system.

The difficulty would be expressing more complex ACL2 patterns in
lightweight.  My answer is not to try to make it perfect.

> > 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> > will be left up to the server implementation.
> I think some rights are inherently tied though -- you wouldn't want a
> server that uses 'r' as a READ-WRITE right.

Yes, of course.  My point is that implementations should have latitude of
how they interpret lightweight WRITE in the context of "s", "t", and "w".

> However, I fear that the use of groups in a "lightweight" system will just
> recreate the current ACL2 situation -- loads of complexity to deal with
> the fact that the lightweight system may not be able to handle more than
> one group.

I don't think that there's a problem.  A server, whether ACL2 or
lightweight, has the freedom to decide how many groups it supports; and
that number can be 1.

Of greater concern is that some lightweight implementations may wish to
support multiple groups, but have all groups have the same rights.  I
don't think that we really need to address this as long as the server
announces the result of any changes.

> If I change the group with the lightweight interface -- what happens in
> the ACL/ACL2 representation?  What if the ACL contains multiple groups?
> What does the lightweight system report?

I would do an end run around all of this and say that *any* lightweight
changes immediately resets all ACL2 settings to reflect the lightweight
setting.  If you don't want this to happen to your acls, then don't use a
lightweight interface to manipulate them ("doctor, it hurts when I do
this"/"so don't do it!").

If you just access ACL2 settings through lightweight, then you'll get a
"reasonable approximation".

The presumption here is that a user will be lightweight or ACL2, but not
both except for an upgrade of a lightweight user to an ACL2 user.

So, we concentrate our attention on making upgrade be correct, but we
don't worry too much about downgrade.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Sat, 20 Dec 2003 12:07:23 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Wed, 10 Dec 2003, Mark Crispin wrote:

> I agree with the desire to "do the minimum required to fix ACL".  I don't
> think that it's quite as small as you'd like.  In particular I don't think
> that a "fix" to ACL would leave UNION as the only access calculation rule.

I'm willing to discuss this, the initial proposal didn't address it at
all, really.

> Also, just as eliminating the need to support non-ACL access control
> models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> compatibility.

I'm not convinced that this "simplifies" ACL2 much, other than eliminating
the need to tie the 'd' right.

> 1) We all agree that RFC 2086 is broken.  ACL is dead, long live ACL2 and
> PERMISSIONS.

I think we all agree that 2086 is broken now, or we wouldn't be talking
about ACL2.

> 2) ACL2 will not attempt to be compatible with RFC 2086.  It should be a
> redesign, and do what's right:
>  . I contend that MOST-SPECIFIC should be the *only* access calculation
>    rule, on the grounds that it makes ACLs easier for clients and users to
>    understand, and allows the removal of negative rights from the
>    specification.

This makes it very hard or even impossible for a server to upgrade from
ACL (using UNION).  To do so, you would need to calculate the rights at a
given moment in time, and then re-advertise them.  If we needs
MOST-SPECIFIC semantics in ACL2 for adoption, then we have to deal with
having two rulesets -- not one.

>  . no "t" right.  Redefine "d" instead.

As long as we have tied rights, I don't think this is a serious concern.

> 3) ACL2 will not attempt to support any other existing access control
> models either [this is my big concession]; this is unnecessary since there
> will be a separate lightweight access control mechanism [this is your big
> concession].

Ok.

> 4) The design of the lightweight mechanism should not preclude a server
> implementation being able to support both lightweight and ACL2.

I would hope that any server implementing ACL2 would be able to trivially
implement any sort of "lightweight" system.

> Conceivably, a server might be able to support ACL too.

This is very desirable, but as long as a direct upgrade of existing
ACLs could be made, it isn't a showstopper.

> 5) There should be some guidelines for mappings right from one to the
> other, but it should be understood from the onset that the mapping is
> focused on:
>  . users who use one form exclusively
>  . users upgrading from lightweight (or ACL) to ACL2
> In particular, a downgrade *will* be lossy.  Life is tough.

I *think* the original proposal accepted this.  (i.e. in PERMISSIONS+ACL2
there was a loss of information if you only looked at the PERMISSIONS
data [no groups + tied rights], likewise with ACL+ACL2 [the d right was
lossy].

> 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> will be left up to the server implementation.

I think some rights are inherently tied though -- you wouldn't want a
server that uses 'r' as a READ-WRITE right.

> 7) Lightweight will have read/write/list rights.  It will also have
> groups.  Details to be determined.  What you proposed was too minimal.

I'm fine with r/w/l rights in the lightweight system.

However, I fear that the use of groups in a "lightweight" system will just
recreate the current ACL2 situation -- loads of complexity to deal with
the fact that the lightweight system may not be able to handle more than
one group.

If I change the group with the lightweight interface -- what happens in
the ACL/ACL2 representation?  What if the ACL contains multiple groups?
What does the lightweight system report?

I think there are far too many questions if we do this, and if this is
necessary, going to a PERMISSIONS+ACL2 system gains us nothing, and loses
a LOT in on interoperability and complexity of the spec.  I'd rather
see ACL2 as it is now (modulo the recent round of comments) than see
this system.

The main benefit of the PERMISSIONS proposal is that it holds PERMISSIONS
as a subset (owner, anyone) of the ACL -- there's no complicated mapping
between the identifiers in the two systems for a server that implements
both.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 10 Dec 2003 19:34:15 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Rob -

I've meant to answer your message, but I've kept on putting it off.

I observed some time ago that the issue isn't about ACL (access control
lists) but rather about access control.

Your proposal is a variation of something that I suggested quite some time
ago, which is to have a lightweight form of access control (which you call
PERMISSIONS), and ACL as a heavyweight form.  A server could support both,
so there would need to be some set of mapping and conflict resolution
rules.  At the time, this was opposed on the grounds that for many people,
lightweight would be good enough and it would preclude the widespread
deployment of ACL.

I am willing to revisit the issue.  However, I think that the people who
want a lightweight form should define what is in (and more importantly,
what is absent from!!) the lightweight form.

I agree with the desire to "do the minimum required to fix ACL".  I don't
think that it's quite as small as you'd like.  In particular I don't think
that a "fix" to ACL would leave UNION as the only access calculation rule.

Also, just as eliminating the need to support non-ACL access control
models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
compatibility.

With this in mind, here's what I would consider a good alterative to the
current ACL2 document:

1) We all agree that RFC 2086 is broken.  ACL is dead, long live ACL2 and
PERMISSIONS.

2) ACL2 will not attempt to be compatible with RFC 2086.  It should be a
redesign, and do what's right:
 . I contend that MOST-SPECIFIC should be the *only* access calculation
   rule, on the grounds that it makes ACLs easier for clients and users to
   understand, and allows the removal of negative rights from the
   specification.
 . no "t" right.  Redefine "d" instead.
 . etc. etc.

3) ACL2 will not attempt to support any other existing access control
models either [this is my big concession]; this is unnecessary since there
will be a separate lightweight access control mechanism [this is your big
concession].

4) The design of the lightweight mechanism should not preclude a server
implementation being able to support both lightweight and ACL2.
Conceivably, a server might be able to support ACL too.

5) There should be some guidelines for mappings right from one to the
other, but it should be understood from the onset that the mapping is
focused on:
 . users who use one form exclusively
 . users upgrading from lightweight (or ACL) to ACL2
In particular, a downgrade *will* be lossy.  Life is tough.

6) Precise mapping details, such as the lightweight mapping of "s" or "t",
will be left up to the server implementation.

7) Lightweight will have read/write/list rights.  It will also have
groups.  Details to be determined.  What you proposed was too minimal.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 10 Dec 2003 17:19:37 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

I realize I probably originally posted this at a bad time, directly after
everyone was returning from the IETF meeting... But are there further
comments/compliments/flames?

Is this something we are interested in pursuing or are we too far down our
current path already?

-Rob

On Fri, 14 Nov 2003, Rob Siemborski wrote:

>
> After the IMAPext meeting I spoke with some people and got to thinking if
> there was a way we could come up with a way to do IMAP sharing that will
> satisfy both the enterprise people who need detailed ACL support, and those
> who feel the need to implement permissions with limited backend support
> (e.g. UNIX file permissions).  Ideally, such a mechanism would be simple to
> implement and not have complexity problems getting past the IESG.
>
> I'd like to propose the following as a strawman INSTEAD of the
> current ACL2 draft (or whatever ACL2 became after the last round of
> comments):
>
> Create an ACL+ capability that does the following:
>
>   * Can only be advertised if ACL is advertised
>   * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE)
> bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2)
>
> There may be other changes from ACL2 that I missed here, but the general
> goal is "do the minimum required to fix ACL".  This may imply changing how
> the namespace of identifiers are treated as well (e.g. user=foo,
> group=bar), but I'd really like to keep the changes as minimal as possible
> here if we can.
>
> Create a new PERMISSIONS capability that works along the lines of the
> following:
>
>   * Define four bits you can set on a mailbox: owner read/write and
> anyone read/write.  Have a command other than the ACL manipulation
> commands that can manipulate/report these.
>
> If a server advertises *both* PERMISSIONS and ACL, then it must also
> advertise ACL+.  Also, the PERMISSIONS bits are tied as follows to ACL
> bits for the *owner* of a mailbox and for the "anyone" identifier (in the
> ACL):
>
> On a mailbox that can contain messages:
>   read: lr
>   write: wite
>
> (I'm not sure how to tie 's' -- maybe Mark can answer that).
>
> On a mailbox that can contain mailboxes:
>   read: l
>   write: cx
>
> "Dual-use" mailboxes get the union of the applicable above sets of bits.
>
> Identifiers in the ACL that correspond to entities other than the
> owner and 'anyone' are not advertised through the permissions extension.
>
> Note that in a ACL+PERMISSIONS system, the rights advertised through the
> PERMISSIONS extension are exactly the rights that match the owner's identifier
> and the "anyone" identifier.  Negative rights are not advertised through,
> the PERMISSIONS system.  When resolving actual rights, the ACL must be fully
> calculated (i.e. the PERMISSIONS interface is just an alternate way to get
> to *some* of the functionality of ACL).
>
> Note also that this does not tie 'a' or 'p' to anything,
> I would expect the PERMISSIONS extension to honor 'a', and I would expect
> 'p' to only be manipulatable through the ACL extension, though perhaps that
> isn't quite the right thing.
>
> If a server implements *only* PERMISSIONS and does not implement ACL, then it
> should keep the semantics that would be provided by the ACL bits as
> defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner).
> However, in this case, the bits advertised through PERMISSIONS *are*
> authoritative.
>
> I think that this setup is significantly simpler than having to bend over
> backwards to force ACLs onto unix filesystem semantics just to allow simple
> folder sharing, and it still allows enterprise servers to continue to
> support the flexibility provided by the ACL extension.
>
> I've intentionally left some things open here: specifically interaction
> with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire.
> I have also left open the question of interpreting the ACL (rather, I left
> it as it was in 2086).  The syntax question, at least, could be worked out when
> a formal draft was issued.
>
> I will note that this does not provide for groups to be used through the
> PERMISSIONS mechanism.  However, it seems to me that the large demand
> is "share folders globally", and this provides for that.
>
> This would also provide a simple standard mapping for "read" and "write"
> acls to mailboxes, which sees to also have been in demand.
>
> Comments?
>
> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems Programmer
> PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
> -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
> w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
> ------END GEEK CODE BLOCK-----
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'IMAP Extension for Conditional STORE  operation' to Proposed Standard 
Date: Mon, 08 Dec 2003 14:02:48 -0500
Sender: [email-masked]

The IESG has approved following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-05.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol Extension 
Working Group. 

The IESG contact persons are Ned Freed and Ted Hardie.

Technical Summary

    Often, multiple IMAP clients need to coordinate changes to a common
    IMAP mailbox.  Examples include different clients for the same user,
    and multiple users accessing shared mailboxes. These clients
    need a mechanism to synchronize state changes for messages within the
    mailbox. They must be able to guarantee that only one client can 
change
    message state (e.g., message flags or annotations) at any time.  An
    example of such an application is use of an IMAP mailbox as a message
    queue with multiple dequeueing clients.

    The Conditional Store facility provides a protected update mechanism 
    for message state information that can detect and resolve conflicts 
    between multiple writing mail clients.
  
Working Group Summary
 
    This document is a product of the imapext working group.
 
Protocol Quality
 
    Ned Freed reviewed the specification for the IESG.

To: IETF-Announce: ;
From: [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-02.txt
Date: Fri, 05 Dec 2003 15:28:53 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IMAP Extension for SASL Initial Client Response
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-imap-sasl-initial-response-02.txt
	Pages		: 8
	Date		: 2003-12-5
	
To date, the Internet Message Access Protocol (IMAP) has used a
Simple Authentication and Security Layer (SASL) profile which always
required at least one complete round trip for an authentication, as
it did not support an initial client response argument.  This
additional round trip at the beginning of the session is
undesirable, especially when round trip costs are high.

This document defines an extension to IMAP which allows clients and
servers to avoid this round trip by allowing an initial client
response argument to the IMAP AUTHENTICATE command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-siemborski-imap-sasl-initial-response-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-imap-sasl-initial-response-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-14.txt
Date: Thu, 04 Dec 2003 15:38:23 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-14.txt
	Pages		: 19
	Date		: 2003-12-4
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-sort-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-sort-14.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-sort-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-05.txt
Date: Mon, 01 Dec 2003 15:29:16 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-05.txt
	Pages		: 16
	Date		: 2003-12-1
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time.  An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

This document defines an extension to IMAP (RFC 3501).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-condstore-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 30 Dec 2003 00:24:37 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> What if the client is accessing two servers -- one which does not support
> ACL?

Well, then, presumably he has no choice but to use PERMISSIONS on that
server.  But he wouldn't be using PERMISSIONS and ACL simultaneously on
the same server.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 17:38:59 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> Well, you saw an explanation about how that can be done in Timo's message.

Yes -- I'm pretty sure now I misunderstood what you meant.

> But there aren't any such protocols!  And once you go down that path, then
> you get into the obvious question of why IMAP is even in the ACL business.

LDAP, atleast, has been used for group management.  Certainly a directory
makes more sense to store this information in than a mail store.

> > I'd also call it a disadvantage that now a server that wants to implement
> > ACL has to implement another orthogonal scheme which is similar to ACL in
> > complexity.
>
> No, PERMISSIONS is much smaller.
[snip]

Ok, we were talking about two entirely different PERMISSIONS
descriptions.  Now I have a clear(er) picture of yours.

I'm going to think this over now.

> A user who normally manipulates access control would typically use either
> PERMISSIONS or ACL, but would not use both.  Or, put another way, anyone
> who does use both deserves to lose as punishment for his foolishness.

What if the client is accessing two servers -- one which does not support
ACL?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 14:34:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> But here we're not talking about ACL2 -- we're talking about the upgrade
> path from ACL to ACL2.  We're currently *in* a world where there are
> deployments with different groups with different rights on a folder, and
> that needs to be dealt with.  If that means we need to have both UNION and
> MOST-SPECIFIC, that's fine with me.

Well, you saw an explanation about how that can be done in Timo's message.

> I don't think that it is reasonable to expect the IMAP server to be even
> capable of manipulating groups -- leave that to protocols that have been
> designed for that sort of thing.

But there aren't any such protocols!  And once you go down that path, then
you get into the obvious question of why IMAP is even in the ACL business.

> I'd also call it a disadvantage that now a server that wants to implement
> ACL has to implement another orthogonal scheme which is similar to ACL in
> complexity.

No, PERMISSIONS is much smaller.

Think of there being only four identifiers (in the RFC 2086 sense): owner,
group, world, and anonymous.

The anonymous user is stuck in anonymous.

Otherwise, if your userid is in the owner list, then you get owner rights.
Otherwise, if your userid is a member of a group that is in the group
 list, then you get group rights.
Otherwise, you get world rights.

There are tools to manager the owner list, group list, and membership
within a group.  Some of these tools may be restricted to admins.

> Clients then have to interpret both of these unrelated
> schemes to figure out what is going on.

No.  Not normally, anyway.

A client would not normally be using the ACL commands if the user is not
someone who normally manipulates ACLs for that mailbox (the "owner" in the
PERMISSIONS world).

A user who normally manipulates access control would typically use either
PERMISSIONS or ACL, but would not use both.  Or, put another way, anyone
who does use both deserves to lose as punishment for his foolishness.

The missing piece of the equation is "how does a non-owner" know whether
or not he can do something?  *That* is done in one of two ways: either by
trying it to see if it works, *OR* by doing an access control CHECK
operation.

The access control check operation ("can I do t to such-and-such mailbox")
is something that is common to both PERMISSIONS and ACL.  Fortunately,
access control check is less complicated than trying to represent
PERMISSIONS in ACL or ACL in PERMISSIONS, since access control check is
merely a binary "yes or no" to the question "will such-and-such win?".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Cc: Mark Crispin <[email-masked]>, [email-masked]
From: Timo Sirainen <[email-masked]>
Subject: Re: Yet another ACL Strawman
Date: Tue, 30 Dec 2003 00:07:25 +0200
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

--Apple-Mail-7--60835413
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Dec 29, 2003, at 11:24 PM, Rob Siemborski wrote:

> On Mon, 29 Dec 2003, Mark Crispin wrote:
>
>> And it seems that the problem is brought about *not* by most-specific
>> between user vs. group vs. world identifiers, but rather by 
>> most-specific
>> between groups with different rights.  That's a design wart in ACL2 
>> that
>> bears looking into.
>
> But here we're not talking about ACL2 -- we're talking about the 
> upgrade
> path from ACL to ACL2.  We're currently *in* a world where there are
> deployments with different groups with different rights on a folder, 
> and
> that needs to be dealt with.  If that means we need to have both UNION 
> and
> MOST-SPECIFIC, that's fine with me.

I'm not sure if you really understood what Mark said.. It anyway sounds 
to me like a quite workable solution. You'd have MOST-SPECIFIC 
behaviour but if there's multiple groups, you'd get union of them. 
Wouldn't that make it possible to quite easily convert old ACLs to 
ACL2? You can keep your old groups, only problems are if you have 
combined user, group and world rights. Then you'd have to do something 
like:

user + world: merge world rights directly to user
user + group(s): merge group rights directly to user
group(s) + world: create a new "world" group and give world rights to 
world group

Other combinations would work the same way as they did with ACL.

--Apple-Mail-7--60835413
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-7--60835413--

Date: Mon, 29 Dec 2003 16:24:46 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> And it seems that the problem is brought about *not* by most-specific
> between user vs. group vs. world identifiers, but rather by most-specific
> between groups with different rights.  That's a design wart in ACL2 that
> bears looking into.

But here we're not talking about ACL2 -- we're talking about the upgrade
path from ACL to ACL2.  We're currently *in* a world where there are
deployments with different groups with different rights on a folder, and
that needs to be dealt with.  If that means we need to have both UNION and
MOST-SPECIFIC, that's fine with me.

The proposal was more or less an attempt to try an alternative/minimal
approach.  It seems that in order to keep everyone happy feature-wise we
are better off (however bad it is) with ACL2 and some sort of
way to announce how identifiers interact.

> Perhaps matters would be easier if you discuss how you implement groups in
> RFC 2086.  As I read RFC 2086, it's a complete crapshoot how groups work
> in ACL, so a client really has no idea what a "group" is.

In our implementation, group management isn't done internally, instead we
pull group membership from one of any number of sources (UNIX groups, AFS
ptserver, LDAP, etc).  This tends to work well since it ensures that group
management is located in a single place for any given enterprise, and
many applications can share the same groups.

I don't think that it is reasonable to expect the IMAP server to be even
capable of manipulating groups -- leave that to protocols that have been
designed for that sort of thing.

> No.  I mean that PERMISSIONS is a separate layer.  If you have PERMISSIONS
> access, you get it.  ACLs are only consulted if you don't have PERMISSIONS
> access.  The implication of this is that the use of ACLs requires denial
> of all permissions (setting PERMISSIONS rights to none).

Ok -- I understand what you are saying now.

> The disadvantage of this is that a PERMISSIONS only client won't show
> anything reasonable with server mailboxes that use ACL.  I consider this
> to be a small price to pay to gain the simplicity.

I'd also call it a disadvantage that now a server that wants to implement
ACL has to implement another orthogonal scheme which is similar to ACL in
complexity.  Clients then have to interpret both of these unrelated
schemes to figure out what is going on.  This is far from ideal from a
management perspective.

This is far worse than even the complicated scheme using regular
expressions that the most recent ACL2 thread came up with.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 13:09:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> Which has a similar problem for ongoing manageability (I want to remove a
> user from my admins group -- now I have to go through and fix ALL of these
> folders? You've got to be kidding me!).  And having an admins group *is*
> used in practice.

Uh, excuse me.

I did say something about the need to be able to manage the membership of
a group.

And it seems that the problem is brought about *not* by most-specific
between user vs. group vs. world identifiers, but rather by most-specific
between groups with different rights.  That's a design wart in ACL2 that
bears looking into.

Perhaps matters would be easier if you discuss how you implement groups in
RFC 2086.  As I read RFC 2086, it's a complete crapshoot how groups work
in ACL, so a client really has no idea what a "group" is.

> > Who said anything about limiting PERMISSIONS to only one user?  I
> > certainly never thought that "owner" equated to a single user; rather,
> > owner equates to one or more users with owner rights.
> The most recent strawman linked it to a single user identifier in the ACL
> realm.

That's not my strawman, and a single user identifier is not good enough.

> Unless you're saying my position is that "PERMISSIONS is a strict subset
> of ACL" which I *do* think is a good thing, because it ensures that
> servers that implement ACL can implement PERMISSIONS as well (as
> PERMISSIONS exists to enable servers that cannot implement ACL to still
> have a rights management scheme).

I think that your making PERMISSIONS a strict subset of ACL is what is
causing the confusion.  See next paragraph.

> > If necessary, I'd be ameniable to a compromise in which use of ACL
> > requires that all PERMISSIONS be denied.  That's been done before.
> I'm not sure what you mean here.  Do you mean an ACL server refuses to
> support any PERMISSIONS commands, or something else?

No.  I mean that PERMISSIONS is a separate layer.  If you have PERMISSIONS
access, you get it.  ACLs are only consulted if you don't have PERMISSIONS
access.  The implication of this is that the use of ACLs requires denial
of all permissions (setting PERMISSIONS rights to none).

The disadvantage of this is that a PERMISSIONS only client won't show
anything reasonable with server mailboxes that use ACL.  I consider this
to be a small price to pay to gain the simplicity.

> No, I'm worried that the complexity of multiple users/groups will just
> make PERMISSIONS "ACL with less bits" which is more or less useless, since
> the "less bits" problem can be equally well solved with adequately defined
> tied rights.

A PERMISSIONS model which does less than the most limited access controls
of the 1960s is also more or less useless.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 14:59:33 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Mark Crispin wrote:

> On Mon, 29 Dec 2003, Rob Siemborski wrote:
> > For example, let's say I have three groups: g1, g2, and g3.
> > g1: u1, u2 ("readers")
> > g2: u2, u3 ("writers")
> > g3: u3, u4 ("baddies")
> > And an ACL(1) on a folder of:
> > g1: rls
> > g2: wipcda
> > g3: -rlswipcda
>
> Is a group of specifically restricted users (with a large set of negative
> rights that denies world access) really in deployment today?  Does CMU use
> it?

While I was using negative rights in the example, a similar problem exists
with positive rights:

g1: u1, u2 ("readers")
g2: u2, u3 ("writers")
g3: u1, u3, u4 ("admins")
And an ACL(1) on a folder of:
g1: rls
g2: wipcd
g3: a

Results in a most-specific acl of:

g1: rls
g2: lwipcd
g3: la
u1: rlsa
u3: lwipcda

Which has a similar problem for ongoing manageability (I want to remove a
user from my admins group -- now I have to go through and fix ALL of these
folders? You've got to be kidding me!).  And having an admins group *is*
used in practice.

I can't see anyone who uses groups heavily to want to upgrade from ACL to
ACL2 if it meant that their ACLs would be destroyed in a
non-backwards-compatible manner.

> > If a PERMISSIONS server can support any number of groups, then you haven't
> > created something "lightweight" you've reinvented ACL2 with only two (or
> > three?) bits, and only one user arguments about PERMISSIONS as we're
> > currently having about ACL2, only with far fewer features in the protocol.
>
> If you feel that ACL was over-engineered, I won't dispute that.

Actually -- I feel it was under-engineered, given the problems it has with
identifiers and the delete right.

> > If its somehow ok to limit PERMISSIONS to only one user, it should also be
> > OK to limit PERMISSIONS to no groups.
>
> Who said anything about limiting PERMISSIONS to only one user?  I
> certainly never thought that "owner" equated to a single user; rather,
> owner equates to one or more users with owner rights.

The most recent strawman linked it to a single user identifier in the ACL
realm.

> I am dismayed by the notion that the capabilities of PERMISSIONS are to be
> dictated by ACL.  Among other things, this opens the door to charges that
> PERMISSIONS was deliberately sabotaged.  I certainly feel that way when
> you tell me what I can or can not have in PERMISSIONS.

I don't think that PERMISSIONS is being sabotaged -- rather, I think we
are conceding one sort of complexity (two rights management schemes) for
reducing complexity in ACL (communicating a server's capability).

Unless you're saying my position is that "PERMISSIONS is a strict subset
of ACL" which I *do* think is a good thing, because it ensures that
servers that implement ACL can implement PERMISSIONS as well (as
PERMISSIONS exists to enable servers that cannot implement ACL to still
have a rights management scheme).

> If necessary, I'd be ameniable to a compromise in which use of ACL
> requires that all PERMISSIONS be denied.  That's been done before.

I'm not sure what you mean here.  Do you mean an ACL server refuses to
support any PERMISSIONS commands, or something else?

> > We certainly don't need to
> > make the situation even worse by intrducing two extensions to do the same
> > thing, except that one has fewer bits than the other.
>
> Are you worried that PERMISSIONS would be good enough that nobody would
> implement ACL?

No, I'm worried that the complexity of multiple users/groups will just
make PERMISSIONS "ACL with less bits" which is more or less useless, since
the "less bits" problem can be equally well solved with adequately defined
tied rights.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 29 Dec 2003 11:45:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Mon, 29 Dec 2003, Rob Siemborski wrote:
> For example, let's say I have three groups: g1, g2, and g3.
> g1: u1, u2 ("readers")
> g2: u2, u3 ("writers")
> g3: u3, u4 ("baddies")
> And an ACL(1) on a folder of:
> g1: rls
> g2: wipcda
> g3: -rlswipcda

Is a group of specifically restricted users (with a large set of negative
rights that denies world access) really in deployment today?  Does CMU use
it?

RFC 2086 is very vague about groups.  I don't see how you can hope to have
something that's interoperable across all clients with RFC 2086.

We put restricted users on restricted servers.

> If a PERMISSIONS server can support any number of groups, then you haven't
> created something "lightweight" you've reinvented ACL2 with only two (or
> three?) bits, and only one user arguments about PERMISSIONS as we're
> currently having about ACL2, only with far fewer features in the protocol.

If you feel that ACL was over-engineered, I won't dispute that.

> If its somehow ok to limit PERMISSIONS to only one user, it should also be
> OK to limit PERMISSIONS to no groups.

Who said anything about limiting PERMISSIONS to only one user?  I
certainly never thought that "owner" equated to a single user; rather,
owner equates to one or more users with owner rights.

I am dismayed by the notion that the capabilities of PERMISSIONS are to be
dictated by ACL.  Among other things, this opens the door to charges that
PERMISSIONS was deliberately sabotaged.  I certainly feel that way when
you tell me what I can or can not have in PERMISSIONS.

> If groups are necessary in a "lightweight" system, then this particular
> strawman has basicly already lost, since that's the level of complexity
> that is causing all sorts of trouble in ACL2.

I disagree.  PERMISSIONS should split the access control problem into two
separate mechanisms, one of which is more featureful and the other of
which is more likely to be universally implemented.

It isn't as if this hasn't been done before, and successfully.  The
problem seems to come in when access control lists are proposed to be the
only solution to the access control problem, and then everybody gets
sidetracked on how ACLs are to be subsetted.

If necessary, I'd be ameniable to a compromise in which use of ACL
requires that all PERMISSIONS be denied.  That's been done before.

> We certainly don't need to
> make the situation even worse by intrducing two extensions to do the same
> thing, except that one has fewer bits than the other.

Are you worried that PERMISSIONS would be good enough that nobody would
implement ACL?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 29 Dec 2003 12:50:48 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Wed, 24 Dec 2003, Mark Crispin wrote:

> > >  . I contend that MOST-SPECIFIC should be the *only* access calculation
> > >    rule
> > This makes it very hard or even impossible for a server to upgrade from
> > ACL (using UNION).  To do so, you would need to calculate the rights at a
> > given moment in time, and then re-advertise them.
>
> I don't think that's really the case.  The server should be able to
> calculate the ACL2 equivalent of ACL rights fairly easily.  Backwards
> calculation will be harder to do reversibly, but the point is that we're
> not trying to make that be perfect.

Sure, you can calculate the rights quickly at any instant of time, but
this fails if an organization has a long-standing use of union ACLs, and
has allocated their groups accordingly.  *Especially* if they manage them
for other purposes.

For example, let's say I have three groups: g1, g2, and g3.

Their contents:

g1: u1, u2 ("readers")
g2: u2, u3 ("writers")
g3: u3, u4 ("baddies")

And an ACL(1) on a folder of:

g1: rls
g2: wipcda
g3: -rlswipcda

In ACL(2)/MOST-SPECIFIC [disregarind the d right], the server would
upgrade this to:

g1: rls
g2: wipcda
u2: rlswipcda
u3: ''

If you apply this across many folders, this can create a sudden management
nightmare, since every user can suddenly have their own acl on every
folder, destroying a standing group management policy (and effectively
rendering the groups, which were designed with UNION style rights in
mind, entirely useless).

No, If ACL2 is to be adopted by current ACL sites, it needs to support
*atleast* the current semantics.

> > > 4) The design of the lightweight mechanism should not preclude a server
> > > implementation being able to support both lightweight and ACL2.
> > I would hope that any server implementing ACL2 would be able to trivially
> > implement any sort of "lightweight" system.
>
> The difficulty would be expressing more complex ACL2 patterns in
> lightweight.  My answer is not to try to make it perfect.

I offered a simple, unambiguous method to express this: an all-or-nothing
approach.

> > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> > > will be left up to the server implementation.
> > I think some rights are inherently tied though -- you wouldn't want a
> > server that uses 'r' as a READ-WRITE right.
>
> Yes, of course.  My point is that implementations should have latitude of
> how they interpret lightweight WRITE in the context of "s", "t", and "w".

This worries me somewhat, but I don't see any immediate problems with it
from either a PERMISSIONS-only server (no concept of acl bits) or an
ACL/PERMISSIONS shared server (you can always find out the real story by
looking at the ACL).

> > However, I fear that the use of groups in a "lightweight" system will just
> > recreate the current ACL2 situation -- loads of complexity to deal with
> > the fact that the lightweight system may not be able to handle more than
> > one group.
>
> I don't think that there's a problem.  A server, whether ACL2 or
> lightweight, has the freedom to decide how many groups it supports; and
> that number can be 1.

If a PERMISSIONS server can support any number of groups, then you haven't
created something "lightweight" you've reinvented ACL2 with only two (or
three?) bits, and only one user arguments about PERMISSIONS as we're
currently having about ACL2, only with far fewer features in the protocol.

If its somehow ok to limit PERMISSIONS to only one user, it should also be
OK to limit PERMISSIONS to no groups.

If groups are necessary in a "lightweight" system, then this particular
strawman has basicly already lost, since that's the level of complexity
that is causing all sorts of trouble in ACL2.  We certainly don't need to
make the situation even worse by intrducing two extensions to do the same
thing, except that one has fewer bits than the other.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Sun, 28 Dec 2003 15:14:41 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Shall we meet in Seoul?
Sender: [email-masked]

Who is going to be able to make it to Seoul? Do we have items about 
which we need to meet? Would a multicast session make a difference?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sun, 28 Dec 2003 15:12:12 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: IMAP URL update?
Sender: [email-masked]

On the LEMONADE list, Alexey mentioned that some folks had been 
talking about an update to the IMAP URL spec (RFC 2192) which would, 
perhaps among other things, add syntax to allow byte ranges for 
partial messages. Is anyone currently working on that or planning to 
work on it? I would like to refer to it in a document I am working on 
for LEMONADE.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 24 Dec 2003 14:38:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Sat, 20 Dec 2003, Rob Siemborski wrote:
> > Also, just as eliminating the need to support non-ACL access control
> > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> > compatibility.
> I'm not convinced that this "simplifies" ACL2 much, other than eliminating
> the need to tie the 'd' right.

If we have PERMISSIONS as a separate entity from ACL2, we can eliminate
tied rights in ACL2.  That is, a server that implements ACL2 must
implement all ACL2 rights as discreet entities.  Given that ACL2 is "all
or not at all", it can be made much simpler; and given that PERMISSIONS
exists as a lighter-weight model, it's alright that ACL2 be "all or not
all all".

> >  . I contend that MOST-SPECIFIC should be the *only* access calculation
> >    rule
> This makes it very hard or even impossible for a server to upgrade from
> ACL (using UNION).  To do so, you would need to calculate the rights at a
> given moment in time, and then re-advertise them.

I don't think that's really the case.  The server should be able to
calculate the ACL2 equivalent of ACL rights fairly easily.  Backwards
calculation will be harder to do reversibly, but the point is that we're
not trying to make that be perfect.

> > 4) The design of the lightweight mechanism should not preclude a server
> > implementation being able to support both lightweight and ACL2.
> I would hope that any server implementing ACL2 would be able to trivially
> implement any sort of "lightweight" system.

The difficulty would be expressing more complex ACL2 patterns in
lightweight.  My answer is not to try to make it perfect.

> > 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> > will be left up to the server implementation.
> I think some rights are inherently tied though -- you wouldn't want a
> server that uses 'r' as a READ-WRITE right.

Yes, of course.  My point is that implementations should have latitude of
how they interpret lightweight WRITE in the context of "s", "t", and "w".

> However, I fear that the use of groups in a "lightweight" system will just
> recreate the current ACL2 situation -- loads of complexity to deal with
> the fact that the lightweight system may not be able to handle more than
> one group.

I don't think that there's a problem.  A server, whether ACL2 or
lightweight, has the freedom to decide how many groups it supports; and
that number can be 1.

Of greater concern is that some lightweight implementations may wish to
support multiple groups, but have all groups have the same rights.  I
don't think that we really need to address this as long as the server
announces the result of any changes.

> If I change the group with the lightweight interface -- what happens in
> the ACL/ACL2 representation?  What if the ACL contains multiple groups?
> What does the lightweight system report?

I would do an end run around all of this and say that *any* lightweight
changes immediately resets all ACL2 settings to reflect the lightweight
setting.  If you don't want this to happen to your acls, then don't use a
lightweight interface to manipulate them ("doctor, it hurts when I do
this"/"so don't do it!").

If you just access ACL2 settings through lightweight, then you'll get a
"reasonable approximation".

The presumption here is that a user will be lightweight or ACL2, but not
both except for an upgrade of a lightweight user to an ACL2 user.

So, we concentrate our attention on making upgrade be correct, but we
don't worry too much about downgrade.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Sat, 20 Dec 2003 12:07:23 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Wed, 10 Dec 2003, Mark Crispin wrote:

> I agree with the desire to "do the minimum required to fix ACL".  I don't
> think that it's quite as small as you'd like.  In particular I don't think
> that a "fix" to ACL would leave UNION as the only access calculation rule.

I'm willing to discuss this, the initial proposal didn't address it at
all, really.

> Also, just as eliminating the need to support non-ACL access control
> models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> compatibility.

I'm not convinced that this "simplifies" ACL2 much, other than eliminating
the need to tie the 'd' right.

> 1) We all agree that RFC 2086 is broken.  ACL is dead, long live ACL2 and
> PERMISSIONS.

I think we all agree that 2086 is broken now, or we wouldn't be talking
about ACL2.

> 2) ACL2 will not attempt to be compatible with RFC 2086.  It should be a
> redesign, and do what's right:
>  . I contend that MOST-SPECIFIC should be the *only* access calculation
>    rule, on the grounds that it makes ACLs easier for clients and users to
>    understand, and allows the removal of negative rights from the
>    specification.

This makes it very hard or even impossible for a server to upgrade from
ACL (using UNION).  To do so, you would need to calculate the rights at a
given moment in time, and then re-advertise them.  If we needs
MOST-SPECIFIC semantics in ACL2 for adoption, then we have to deal with
having two rulesets -- not one.

>  . no "t" right.  Redefine "d" instead.

As long as we have tied rights, I don't think this is a serious concern.

> 3) ACL2 will not attempt to support any other existing access control
> models either [this is my big concession]; this is unnecessary since there
> will be a separate lightweight access control mechanism [this is your big
> concession].

Ok.

> 4) The design of the lightweight mechanism should not preclude a server
> implementation being able to support both lightweight and ACL2.

I would hope that any server implementing ACL2 would be able to trivially
implement any sort of "lightweight" system.

> Conceivably, a server might be able to support ACL too.

This is very desirable, but as long as a direct upgrade of existing
ACLs could be made, it isn't a showstopper.

> 5) There should be some guidelines for mappings right from one to the
> other, but it should be understood from the onset that the mapping is
> focused on:
>  . users who use one form exclusively
>  . users upgrading from lightweight (or ACL) to ACL2
> In particular, a downgrade *will* be lossy.  Life is tough.

I *think* the original proposal accepted this.  (i.e. in PERMISSIONS+ACL2
there was a loss of information if you only looked at the PERMISSIONS
data [no groups + tied rights], likewise with ACL+ACL2 [the d right was
lossy].

> 6) Precise mapping details, such as the lightweight mapping of "s" or "t",
> will be left up to the server implementation.

I think some rights are inherently tied though -- you wouldn't want a
server that uses 'r' as a READ-WRITE right.

> 7) Lightweight will have read/write/list rights.  It will also have
> groups.  Details to be determined.  What you proposed was too minimal.

I'm fine with r/w/l rights in the lightweight system.

However, I fear that the use of groups in a "lightweight" system will just
recreate the current ACL2 situation -- loads of complexity to deal with
the fact that the lightweight system may not be able to handle more than
one group.

If I change the group with the lightweight interface -- what happens in
the ACL/ACL2 representation?  What if the ACL contains multiple groups?
What does the lightweight system report?

I think there are far too many questions if we do this, and if this is
necessary, going to a PERMISSIONS+ACL2 system gains us nothing, and loses
a LOT in on interoperability and complexity of the spec.  I'd rather
see ACL2 as it is now (modulo the recent round of comments) than see
this system.

The main benefit of the PERMISSIONS proposal is that it holds PERMISSIONS
as a subset (owner, anyone) of the ACL -- there's no complicated mapping
between the identifiers in the two systems for a server that implements
both.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 10 Dec 2003 19:34:15 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: [email-masked]
Subject: Re: Yet another ACL Strawman
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Rob -

I've meant to answer your message, but I've kept on putting it off.

I observed some time ago that the issue isn't about ACL (access control
lists) but rather about access control.

Your proposal is a variation of something that I suggested quite some time
ago, which is to have a lightweight form of access control (which you call
PERMISSIONS), and ACL as a heavyweight form.  A server could support both,
so there would need to be some set of mapping and conflict resolution
rules.  At the time, this was opposed on the grounds that for many people,
lightweight would be good enough and it would preclude the widespread
deployment of ACL.

I am willing to revisit the issue.  However, I think that the people who
want a lightweight form should define what is in (and more importantly,
what is absent from!!) the lightweight form.

I agree with the desire to "do the minimum required to fix ACL".  I don't
think that it's quite as small as you'd like.  In particular I don't think
that a "fix" to ACL would leave UNION as the only access calculation rule.

Also, just as eliminating the need to support non-ACL access control
models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
compatibility.

With this in mind, here's what I would consider a good alterative to the
current ACL2 document:

1) We all agree that RFC 2086 is broken.  ACL is dead, long live ACL2 and
PERMISSIONS.

2) ACL2 will not attempt to be compatible with RFC 2086.  It should be a
redesign, and do what's right:
 . I contend that MOST-SPECIFIC should be the *only* access calculation
   rule, on the grounds that it makes ACLs easier for clients and users to
   understand, and allows the removal of negative rights from the
   specification.
 . no "t" right.  Redefine "d" instead.
 . etc. etc.

3) ACL2 will not attempt to support any other existing access control
models either [this is my big concession]; this is unnecessary since there
will be a separate lightweight access control mechanism [this is your big
concession].

4) The design of the lightweight mechanism should not preclude a server
implementation being able to support both lightweight and ACL2.
Conceivably, a server might be able to support ACL too.

5) There should be some guidelines for mappings right from one to the
other, but it should be understood from the onset that the mapping is
focused on:
 . users who use one form exclusively
 . users upgrading from lightweight (or ACL) to ACL2
In particular, a downgrade *will* be lossy.  Life is tough.

6) Precise mapping details, such as the lightweight mapping of "s" or "t",
will be left up to the server implementation.

7) Lightweight will have read/write/list rights.  It will also have
groups.  Details to be determined.  What you proposed was too minimal.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 10 Dec 2003 17:19:37 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

I realize I probably originally posted this at a bad time, directly after
everyone was returning from the IETF meeting... But are there further
comments/compliments/flames?

Is this something we are interested in pursuing or are we too far down our
current path already?

-Rob

On Fri, 14 Nov 2003, Rob Siemborski wrote:

>
> After the IMAPext meeting I spoke with some people and got to thinking if
> there was a way we could come up with a way to do IMAP sharing that will
> satisfy both the enterprise people who need detailed ACL support, and those
> who feel the need to implement permissions with limited backend support
> (e.g. UNIX file permissions).  Ideally, such a mechanism would be simple to
> implement and not have complexity problems getting past the IESG.
>
> I'd like to propose the following as a strawman INSTEAD of the
> current ACL2 draft (or whatever ACL2 became after the last round of
> comments):
>
> Create an ACL+ capability that does the following:
>
>   * Can only be advertised if ACL is advertised
>   * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE)
> bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2)
>
> There may be other changes from ACL2 that I missed here, but the general
> goal is "do the minimum required to fix ACL".  This may imply changing how
> the namespace of identifiers are treated as well (e.g. user=foo,
> group=bar), but I'd really like to keep the changes as minimal as possible
> here if we can.
>
> Create a new PERMISSIONS capability that works along the lines of the
> following:
>
>   * Define four bits you can set on a mailbox: owner read/write and
> anyone read/write.  Have a command other than the ACL manipulation
> commands that can manipulate/report these.
>
> If a server advertises *both* PERMISSIONS and ACL, then it must also
> advertise ACL+.  Also, the PERMISSIONS bits are tied as follows to ACL
> bits for the *owner* of a mailbox and for the "anyone" identifier (in the
> ACL):
>
> On a mailbox that can contain messages:
>   read: lr
>   write: wite
>
> (I'm not sure how to tie 's' -- maybe Mark can answer that).
>
> On a mailbox that can contain mailboxes:
>   read: l
>   write: cx
>
> "Dual-use" mailboxes get the union of the applicable above sets of bits.
>
> Identifiers in the ACL that correspond to entities other than the
> owner and 'anyone' are not advertised through the permissions extension.
>
> Note that in a ACL+PERMISSIONS system, the rights advertised through the
> PERMISSIONS extension are exactly the rights that match the owner's identifier
> and the "anyone" identifier.  Negative rights are not advertised through,
> the PERMISSIONS system.  When resolving actual rights, the ACL must be fully
> calculated (i.e. the PERMISSIONS interface is just an alternate way to get
> to *some* of the functionality of ACL).
>
> Note also that this does not tie 'a' or 'p' to anything,
> I would expect the PERMISSIONS extension to honor 'a', and I would expect
> 'p' to only be manipulatable through the ACL extension, though perhaps that
> isn't quite the right thing.
>
> If a server implements *only* PERMISSIONS and does not implement ACL, then it
> should keep the semantics that would be provided by the ACL bits as
> defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner).
> However, in this case, the bits advertised through PERMISSIONS *are*
> authoritative.
>
> I think that this setup is significantly simpler than having to bend over
> backwards to force ACLs onto unix filesystem semantics just to allow simple
> folder sharing, and it still allows enterprise servers to continue to
> support the flexibility provided by the ACL extension.
>
> I've intentionally left some things open here: specifically interaction
> with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire.
> I have also left open the question of interpreting the ACL (rather, I left
> it as it was in 2086).  The syntax question, at least, could be worked out when
> a formal draft was issued.
>
> I will note that this does not provide for groups to be used through the
> PERMISSIONS mechanism.  However, it seems to me that the large demand
> is "share folders globally", and this provides for that.
>
> This would also provide a simple standard mapping for "read" and "write"
> acls to mailboxes, which sees to also have been in demand.
>
> Comments?
>
> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski | Andrew Systems Group * Research Systems Programmer
> PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
> -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
> w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
> ------END GEEK CODE BLOCK-----
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'IMAP Extension for Conditional STORE  operation' to Proposed Standard 
Date: Mon, 08 Dec 2003 14:02:48 -0500
Sender: [email-masked]

The IESG has approved following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-05.txt> as a Proposed Standard

This document is the product of the Internet Message Access Protocol Extension 
Working Group. 

The IESG contact persons are Ned Freed and Ted Hardie.

Technical Summary

    Often, multiple IMAP clients need to coordinate changes to a common
    IMAP mailbox.  Examples include different clients for the same user,
    and multiple users accessing shared mailboxes. These clients
    need a mechanism to synchronize state changes for messages within the
    mailbox. They must be able to guarantee that only one client can 
change
    message state (e.g., message flags or annotations) at any time.  An
    example of such an application is use of an IMAP mailbox as a message
    queue with multiple dequeueing clients.

    The Conditional Store facility provides a protected update mechanism 
    for message state information that can detect and resolve conflicts 
    between multiple writing mail clients.
  
Working Group Summary
 
    This document is a product of the imapext working group.
 
Protocol Quality
 
    Ned Freed reviewed the specification for the IESG.

To: IETF-Announce: ;
From: [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-02.txt
Date: Fri, 05 Dec 2003 15:28:53 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IMAP Extension for SASL Initial Client Response
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-imap-sasl-initial-response-02.txt
	Pages		: 8
	Date		: 2003-12-5
	
To date, the Internet Message Access Protocol (IMAP) has used a
Simple Authentication and Security Layer (SASL) profile which always
required at least one complete round trip for an authentication, as
it did not support an initial client response argument.  This
additional round trip at the beginning of the session is
undesirable, especially when round trip costs are high.

This document defines an extension to IMAP which allows clients and
servers to avoid this round trip by allowing an initial client
response argument to the IMAP AUTHENTICATE command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-siemborski-imap-sasl-initial-response-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-imap-sasl-initial-response-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-14.txt
Date: Thu, 04 Dec 2003 15:38:23 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-14.txt
	Pages		: 19
	Date		: 2003-12-4
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-sort-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-sort-14.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-sort-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-05.txt
Date: Mon, 01 Dec 2003 15:29:16 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-05.txt
	Pages		: 16
	Date		: 2003-12-1
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time.  An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

This document defines an extension to IMAP (RFC 3501).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-condstore-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--