Mark Crispin | 1 Jun 01:05 2000

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

> Inheritance (3) will be a very interesting discussion, but because
> formalization of it is a "new thing" we *should* be able to converge on
> that as well.

My position is that it is better not to have inheritance at all rather
than the definition in the draft.  If you have inheritance, it is
relatively simple to work around a lack of inheritance in the ACL
specification.

Otherwise, you need a complex specification of how inheritance works;
either by being able to stipulate when inheritance happens or by having a
priority mechanism which indicates when inheritance applies.  The problem
comes in with negative rights.

Consider this example: a particular mailbox is open to anyone except
those who are members of a particular group (overriding anyone inheritance
with a negative right) but user fred who is in that group has access
(overriding the group negative right).  This is something that people want
to do, and it's easy to do in UNIX.  The draft makes it impossible; once a
negative right is acquired through inheritance there's no way to lose it.

I identified some missing functionality in inheritance, but I wouldn't be
at all surprised if someone else finds other missing functionality.  I
don't think that it's possible to make a simple definition of inheritance
that is going to have long-term viability.

I contend that inheritance is a rathole, and an unnecessary one at that.

If, on the other hand, there is no inheritance, then the problem doesn't
exist.  Even better, negative rights can also be deleted from the
(Continue reading)

Mark Crispin | 1 Jun 01:04 2000

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

On Mon, 29 May 2000, Steve Hole wrote:
> (1)   The interpretation of various rights identifiers.
> (2)   The definition/management of identifiers.
> (3)   Rights inheritance.

I think that this is a good summary.  Add a fourth issue:

(4) Structure of ACL commands and (especially) responses.

This relates to things such as issuing automatic ACL responses at SELECT
time; the ability to have wildcards in mailbox names; the ability to
replace the entire ACL and/or redefine ACL for multiple identifiers; the
ability to query potential rights for multiple identifiers.

> We have had trouble with (1)
> ourselves and I think that it should be fairly easy to come to concensus
> on.

I hope so.  Since rights tying exists, it would be better to add a new
right rather than to overload existing rights with semantics that may not
necessarily make sense to tie together.  I'm thinking here about the "c"
right, which should not be overloaded with "delete mailbox".

Mark Crispin | 1 Jun 01:37 2000

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

On Mon, 29 May 2000, Steve Hole wrote:
> I think that (2) (identifier theory) is where we are going to run aground.
> A flexible identifier theory and semantic strikes me as being a strategy
> much like flexible hierarchy notation.     This scares me.

Let's be clear on this.  I don't intend that "UNIX owner" or "UNIX group"
be defined as such in ACL.  Rather, it should be possible to express these
concepts as part of a general (not flexible!) mechanism.

By general, I mean "a mechanism whose ideal state is full implementation"
as opposed to "flexible" which means "a mechanism which expresses
contradictory models, and therefore would never be fully implemented."

Hierarchy is "flexible"; what I propose for identifiers is "general".

My idea basically boils down to this:
 1) a mechanism to define identifiers: global, per-mailbox, and perhaps
    also per-user (I don't need the last one, but perhaps other people
    do).  Defined identifiers can be defined in terms of other
    defined identifiers.
 2) a system of naming that makes the type of identifier unambiguous.
 3) a mechanism to look up (expands) the definition of a defined
    identifier.

The impact of this is:
 . definition of identifier nomenclature
 . command to define an identifier
 . command to get the definition of an identifier

Note that there is no specific "change group" or "change owner"; however,
(Continue reading)

Mark Crispin | 1 Jun 04:48 2000

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

On Wed, 31 May 2000 15:16:49 -0700, Cyrus Daboo wrote:
> >> 'The server SHOULD issue an untagged MYRIGHTS response
> > I agree completely, but you can't do this in the RFC 2086 framework,
> > because a base level IMAP client would complain about getting a MYRIGHTS
> > response.
> Not if its a resp-cond-state:
> * OK [MYRIGHTS lrwia] myrights ACL response

Well, yes and no.

Yes, that is certainly valid in the base spec.  No, because a resp-cond-status
of MYRIGHTS is different from an RFC 2086 MYRIGHTS response.

That seems to be splitting hairs, but it means we'd have two ways of doing the
same response forever, unless the untagged MYRIGHTS response is deprecated in
favor of the resp-cond-state.  That might be a good idea, actually; it could
be carried in the tagged OK response for the MYRIGHTS command and not use an
untagged response at all.

However, I still contend that leveraging off the LIST response would be a
better idea.  It could be useful for the client to get \NoInferiors state at
SELECT time; and there's a lot more that could be delivered as well.

There's another reason why I advocate a LIST response; I think that the
current GETACL, LISTRIGHTS, and MYRIGHTS commands should be deprecated in
favor of an extended form of LIST.  That way, we could use wildcards, and
avoid the current situation where a client does a LIST then a MYRIGHTS for
each returned mailbox.

PS: Ofhand observation: the interesting rights at SELECT time are lipca.  The
(Continue reading)

Randall Gellens | 2 Jun 01:20 2000

Single-letter codes

>  alphabet soup of one letter codes.

I think it would be more clear if the rights were longer than 
single-letters, and less likely to be confused with Unix or other 
rights.  But 2086 already defined them that way.  It also means 
bundling would need another method, perhaps "-", as in "list-adm read 
seen-write-ins-create-del" instead of "la r swicd"

Steve Hole | 2 Jun 19:23 2000

Re: QUIET option for FETCH

On Thu, 1 Jun 2000 11:51:25 +1200 David Harris <David.Harris <at> pmail.gen.nz> 
wrote:

> I think you've misunderstood the scope of what I mean. What I want to 
> be able to do is reduce the bulk of the exchange with the server... I 
> want to be able to send this -
> 
> A1 FETCH 1 BODY.PEEK[HEADERS ($PMSET)]
> 
> and have the server respond with:
> 
> * 1 FETCH BODY[HEADERS ($PMSET)]
> 
> - but actually act as though I had sent it my list of required headers.
> 
> This is, in fact, exactly how I've done it in Mercury/Pegasus Mail. I've 
> declared an X- extension via CAPABILITY that tells Pegasus Mail it 
> can use a new MACRO command at the start of the session to create 
> a macro for the list of headers it wants. This macro can then be used 
> in a FETCH command. In my case, this saves something like 350 
> completely superfluous bytes per header fetch. I felt this would be a 
> generally useful addition, since header fetching is something that most 
> mail clients will need to do extensively.

What smoking idea!   I love this.   David, you have renewed my opinion 
that you are chap with a head on his shoulders.

I see no reason why this should be restricted to header sets.   It would 
be very nice to make it a general feature for any set of commands.

(Continue reading)

Steve Hole | 2 Jun 22:46 2000

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

On Wed, 31 May 2000 16:37:57 -0700 (PDT) Mark Crispin 
<mrc <at> CAC.Washington.EDU> wrote:

> On Mon, 29 May 2000, Steve Hole wrote:

> By general, I mean "a mechanism whose ideal state is full implementation"
> as opposed to "flexible" which means "a mechanism which expresses
> contradictory models, and therefore would never be fully implemented."
> 
> Hierarchy is "flexible"; what I propose for identifiers is "general".

Exactly.   This sounds like a good definition to me. 

> My idea basically boils down to this:
>  1) a mechanism to define identifiers: global, per-mailbox, and perhaps
>     also per-user (I don't need the last one, but perhaps other people
>     do).  Defined identifiers can be defined in terms of other
>     defined identifiers.
>  2) a system of naming that makes the type of identifier unambiguous.
>  3) a mechanism to look up (expands) the definition of a defined
>     identifier.
> 
> The impact of this is:
>  . definition of identifier nomenclature
>  . command to define an identifier
>  . command to get the definition of an identifier

Sounds OK.   The devil is in the details.

I think that it is very important that the definition of an identifier can 
(Continue reading)

Steve Hole | 2 Jun 23:01 2000

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

On Wed, 31 May 2000 16:04:50 -0700 (PDT) Mark Crispin 
<mrc <at> CAC.Washington.EDU> wrote:

> On Mon, 29 May 2000, Steve Hole wrote:
> > (1)   The interpretation of various rights identifiers.
> > (2)   The definition/management of identifiers.
> > (3)   Rights inheritance.
> 
> I think that this is a good summary.  Add a fourth issue:
> 
> (4) Structure of ACL commands and (especially) responses.
>
> This relates to things such as issuing automatic ACL responses at SELECT
> time; the ability to have wildcards in mailbox names; the ability to
> replace the entire ACL and/or redefine ACL for multiple identifiers; the
> ability to query potential rights for multiple identifiers.

Sounds good.    I would propose a simple table of "what is there now" vs
a "what we propose to have".    That way we can compare the value of each 
and get a nice "deprecate" and "add" set to work with after we have 
debated the differences.   I think that we want to put aside the things 
that are OK and get to the differences. 

> > We have had trouble with (1)
> > ourselves and I think that it should be fairly easy to come to concensus
> > on.
> 
> I hope so.  Since rights tying exists, it would be better to add a new
> right rather than to overload existing rights with semantics that may not
> necessarily make sense to tie together.  I'm thinking here about the "c"
(Continue reading)

Tim Showalter | 3 Jun 01:47 2000

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

Steve Hole <steve.hole <at> messagingdirect.com> writes:

> The problem will be with old clients that expect "c" to give you "create" 
> and "delete" mailbox rights.    Is it important?

Cyrus (and presumably all of its derivatives at some point) assigned
that permission to the `d' bit.

FWIW, I also prefer adding a new bit.  Overloading anything seems gross
to me.  

Tim

Mark Crispin | 3 Jun 01:05 2000

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

On Fri, 2 Jun 2000 14:46:27 -0600, Steve Hole wrote:
> Sounds OK.   The devil is in the details.

I hope to keep the details as minimal as possible. :)

> I think that it is very important that the definition of an identifier can
> orginate "out-of-band" of IMAP itself, and have an ACL extended client be
> able to get that information.    "Out-of-band" definition of identifiers
> will be the situation for server implementors in the case of a mapping to
> other identifier sources.   It must be possible for a server do reject
> definition of an identifier if it is not "authoritative" for the
> identifier namespace.

I'm not sure what you mean by this.  Could you give an example?

My idea is a relatively simple "macro" type mechanism, where an identifier can
expand to other identifiers; and certain semantics to indicate whether this
"macro" identifier is global, per-mailbox, or possibly per-user.

The server can always say NO to any client request.  Isn't that sufficient?

> Do you have some text (even outline) that specs this so that we can see
> what it would look like?

I have an outline.  I'm not sure that it makes sense to anyone other than me
as it stands now.

> You can emulate the "change owner" and "change group" by
> changing what we would call the "default" ACL set on an entry.    It is
> not something that we allow in our server (it doesn't really make sense),
(Continue reading)


Gmane