headers
Alexey Melnikov | 5 Feb 2002 19:00

Re: I-D ACTION:draft-ietf-imapext-acl-02.txt


A new revision is out. Major changes in this version:

1). Changed ACL capability name to ACL2=<access calculation rule ID>
Added registry for the rules. Described two rules: UNION (union of the positive minus union of negative),
MOST-SPECIFIC (most specific identifier describes the rights).

2). Added "t" right for performing STORE \Deleted. Changed "d" to be a macro for "x", "t" and "e".

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 6 Feb 2002 00:02

Re: I-D ACTION:draft-melnikov-imap-condstore-06.txt


This is the second revision submitted this year.

Changes from -05 to -06:
      1.  Replaced "/message/flags/system" with "/message/flags" to
          match ANNOTATE draft.
      2.  Extended FETCH/SEARCH/SORT syntax to allow for specifying
          whether an operation should be performed on a shared or a private
          annotation (or both).
      3.  Corrected several examples.

Changes from -04 to -05:
      1.  Added support for SORT extension.
      2.  Multiple language/spelling fixes by Randall Gellens.

There is one major open issue left:
    MODSEQ fetch response as the result of STORE/UID STORE of a flag in any IMAP
session: what _type_ of modseq should be returned: private, shared, both? This is
related to the change 2) between 05 and 06.

Comments?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 15 Feb 2002 00:11

Do we need to meet?


It looks to me that ANNOTATE is getting close. CONDSTORE doesn't seem 
to have too much in the way of open issues. I'm not sure what the 
state of ACL is. Do we have reason to meet in Minneapolis or not?

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 4 comments |
headers
Cyrus Daboo | 15 Feb 2002 16:48

ACL and STATUS


The current ACL rfc and the latest draft for the updated version don't
indicate which ACL bit controls the behaviour of the STATUS command. I
would guess that at least read 'r' access is required in order to get
status information on a mailbox. Can we have STATUS explicitly listed as
one of the commands available for the 'r' bit?

The other option would be to allow status with only the 'l' bit, which
currently allows LIST/LSUB for a mailbox. If we ever get around to
extending list, I believe one of the proposals did have list returning the
equivalent of status information, so there might be some awkward
interaction with ACL on that.

--

-- 
Cyrus Daboo
Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 15 Feb 2002 16:51

ACL2 backward compatability


I think the current ACL2 draft has backwards compatibility with the old ACL
draft wrt the the defined ACL bits. So should the current draft require
servers to also advertise 'ACL' in the capability response as well as
ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

--

-- 
Cyrus Daboo
Permalink | Reply | 3 comments |
headers
Alexey Melnikov | 15 Feb 2002 18:31

Re: ACL2 backward compatability


Cyrus Daboo wrote:

> I think the current ACL2 draft has backwards compatibility with the old ACL
> draft wrt the the defined ACL bits. So should the current draft require
> servers to also advertise 'ACL' in the capability response as well as
> ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

IMHO, only if a particular server implementation uses "$" prefix for groups and
other special identifiers.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________
Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 15 Feb 2002 19:02
Picon
Favicon
Gravatar

Re: ACL2 backward compatability


Alexey Melnikov <mel <at> messagingdirect.com>
> IMHO, only if a particular server implementation uses "$" prefix for groups and
> other special identifiers.

The draft lists the incompatibilities; should it also explictly recommend
that servers advertise "ACL" if these incompatibilities don't apply in
that server's case?

--Arnt
Permalink | Reply | 1 comment |
headers
Pete Resnick | 20 Feb 2002 18:06

Re: Do we need to meet?


On 2/14/02 at 5:11 PM -0600, I wrote:

>It looks to me that ANNOTATE is getting close. CONDSTORE doesn't 
>seem to have too much in the way of open issues. I'm not sure what 
>the state of ACL is. Do we have reason to meet in Minneapolis or not?

I will take this silence to mean that we don't have to meet. Any objections?

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 3 comments |
headers
Alexey Melnikov | 21 Feb 2002 01:45

Re: ACL2 backward compatability


Arnt Gulbrandsen wrote:

> Alexey Melnikov <mel <at> messagingdirect.com>
> > IMHO, only if a particular server implementation uses "$" prefix for groups and
> > other special identifiers.
>
> The draft lists the incompatibilities; should it also explictly recommend
> that servers advertise "ACL" if these incompatibilities don't apply in
> that server's case?

I've just added this to the version 03 I've sent yesterday.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________
Permalink | Reply | 0 comments |
headers
Mark Crispin | 21 Feb 2002 06:45

ACL2


Since ACL2 can be incompatible from ACL, we should define a replacement
identifier for "anyone" that does not conflict with a login id of "anyone".
As matters stand now, the text:
   [...] The identifier "anyone" is reserved to
   refer to the universal identity (all authentications, including
   anonymous).  All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.
is self-contradictory.

Delete "PARTIAL" as a permitted operation of the "r" right.  PARTIAL is a
deprecated feature of RFC1730 which should now be extinct.

The "d" right should first be described as "RFC 2086 compatible delete right"
and then its semantics listed.  Unfortunately, the given semantics don't work.
What if one or more of the "x", "e", or "t" rights can not be set or cleared?
Suggest changing the MUST to SHOULD.  Consider deprecating the "d" right
entirely for an ACL2-only server.

Paragraph describing negative rights should make it clear that a negative
right is not the same thing as a DELETACL.

ACL2=MOST-SPECIFIC is a big improvement.  Is ACL2=UNION really still
necessary?  Wouldn't it be better to do this in the semantics of the naming?

Note that the addition of ACL2=MOST-SPECIFIC renders certain parts of my
proposed naming system moot.  However, there are other part of it which remain
desirable, including:
 . new commands to access and define groups
(Continue reading)

Permalink | Reply | 0 comments |

Gmane