Subject: Re: Fwd: Request for security review
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Date: Thu, 29 Jan 2004 13:33:28 -0800 (Pacific Standard Time)
List-Id: <ietf-imapext.imc.org>

On Thu, 29 Jan 2004, Rob Siemborski wrote:
> > As we've discussed already, UNION-based ACL semantics is incapable of
> > representing filesystem semantics.
> I didn't say *only* union of course.  The current ACL2 draft addresses
> this issue just fine.

OK with me.

-- Mark --

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

Date: Thu, 29 Jan 2004 16:30:23 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

On Thu, 29 Jan 2004, Mark Crispin wrote:

> As we've discussed already, UNION-based ACL semantics is incapable of
> representing filesystem semantics.

I didn't say *only* union of course.  The current ACL2 draft addresses
this issue just fine.

> > b) some way to represent the "large enough but not too large" mechanism
> > within the ACL2 semantics.
>
> That's fine with me, but wouldn't it be simpler to do my idea of saying
> that the way to enable ACL is to set the "large enough but not too large"
> to deny-all?

This would, of course, depend somewhat on whatever "large enough but not
too large" became in the long run.  I can see models where there is no
distinction and models where there is.

However, I'd prefer us following up on (a) before we decide we definately
need a second non-trivial model.

-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: Thu, 29 Jan 2004 13:24:32 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 29 Jan 2004, Rob Siemborski wrote:
> I suspect doing the modifications to ACL2 so as to advertise the semantics
> of how identifiers are handled (as we discussed in the middle of last
> year) might be the way to go.

I agree to this.

> > 2) Adopt a simplified ACL2 and a separate "large enough but not too large"
> >    mechanism for compatibility.  If the latter turns out to be the only
> >    one that is widely implemented, that's life.
> If we want to go this way instead, I'd want to make sure we see the
> following:
> a) backwards compatibility (or atleast a sane upgrade path that doesn't
> result in the interpretation of ACLs being changed -- this is NOT the same
> as a server being able to advertise both ACL and ACL2 at the same time)
> for UNION-based ACL implementations.

As we've discussed already, UNION-based ACL semantics is incapable of
representing filesystem semantics.

> b) some way to represent the "large enough but not too large" mechanism
> within the ACL2 semantics.

That's fine with me, but wouldn't it be simpler to do my idea of saying
that the way to enable ACL is to set the "large enough but not too large"
to deny-all?

-- Mark --

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

Date: Thu, 29 Jan 2004 12:52:22 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

--On 2004-1-29 3:21 PM -0500 Rob Siemborski <[email-masked]> wrote:

> I suspect doing the modifications to ACL2 so as to advertise the
> semantics of how identifiers are handled (as we discussed in the
> middle of last year) might be the way to go.

I don't think we have any other choice. "Hope and pray" security 
semantics simply don't cut it. The result of a security operation 
*must* be deterministic, otherwise you can't call it "secure" in any 
sense of the word.

--lyndon

Date: Thu, 29 Jan 2004 15:21:13 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

On Thu, 29 Jan 2004, Mark Crispin wrote:

> I see the acceptable solutions as:
>
> 1) Adopt ACL2, declare victory, and go home.  If it's a lot of work for
>    everybody, that's life.

Since the major objection (that I know of) to doing this is that "clients
can't understand what's about to happen", and one of Charlie's comments
is:

>>
Going back to my first inclination, I would urge the designers to put
something in the protocol whereby a client can ask a server for a
name and version of its implementation so that clients that want to
be agile can figure out what's going on rather than poking and
guessing.
<<

I suspect doing the modifications to ACL2 so as to advertise the semantics
of how identifiers are handled (as we discussed in the middle of last
year) might be the way to go.

> 2) Adopt a simplified ACL2 and a separate "large enough but not too large"
>    mechanism for compatibility.  If the latter turns out to be the only
>    one that is widely implemented, that's life.

If we want to go this way instead, I'd want to make sure we see the
following:

a) backwards compatibility (or atleast a sane upgrade path that doesn't
result in the interpretation of ACLs being changed -- this is NOT the same
as a server being able to advertise both ACL and ACL2 at the same time)
for UNION-based ACL implementations.

b) some way to represent the "large enough but not too large" mechanism
within the ACL2 semantics.

-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: Thu, 29 Jan 2004 10:07:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

Thank you Charlie for your security review.

Tndeed, your observation that RFC 2086 "impl[ies] that there is no one
correct behavior and that a client that wants to know the exact semantics
of the server will have to experiment to figure it out."  This is one of
the bugs of RFC 2086 that needs to be fixed.

Here's some background:

You are correct in identifying a conflict between "backwards
compatibility" and "doing it right".  There is another conflict, this one
between "ideal" (at least in some viewpoints) and "compatible with (and
implementable on) existing mail stores."

The "ideal" camp once claimed that "compatible" was a proper subset of
"ideal".  In RFC 2086, it provably isn't; not only are some valid access
controls in "ideal" not expressible in "compatible", but some valid access
controls in "compatible" are not expressible in "ideal".

ACL2 is an attempt, first to resolve the ambiguities in RFC 2086 and to
ensure that "compatible" is a proper subset.  Doing this made ACL2 quite a
bit more complicated than RFC 2086.

The "ideal" camp is unhappy about this.  The "compatible" camp, on the
other hand, sees that it's being put through a great deal of complexity
anyway, so they don't sympathize; rather, they see it as necessary for ACL
to be implementable at all.

Rob's strawman was an attempt to reduce the complexity for the "ideal"
camp by providing a smaller mechanism for the "compatible" camp.
Unfortunately, the smaller mechanism is too small for the "compatible"
camp, but with a few minor extensions it would be fine -- "large enough
but not too large."

There is a suspicion, held by both camps, that the "large enough but not
too large" mechanism desired by the "compatible" camp will be "good
enough" for almost all users.

The resulting positions taken by the players are obvious. :-)

I see the acceptable solutions as:

1) Adopt ACL2, declare victory, and go home.  If it's a lot of work for
   everybody, that's life.

2) Adopt a simplified ACL2 and a separate "large enough but not too large"
   mechanism for compatibility.  If the latter turns out to be the only
   one that is widely implemented, that's life.

I see the following as unacceptable:

1) Retain RFC 2086.

2) Simplify ACL2 without any attempt to support compatible access control.

-- Mark --

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

Date: Thu, 29 Jan 2004 10:56:42 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Fwd: Request for security review
Cc: Charlie Kaufman <[email-masked]>
Sender: [email-masked]

Below is the security review of ACL that I asked Charlie Kaufman to 
do for us. I've Cc'ed Charlie on this; please reply to all if you 
have questions or comments on this review.

--- begin forwarded text

Subject: RE: Request for security review - IMAPEXT
Date: Sun, 25 Jan 2004 20:35:34 -0800
From: "Charlie Kaufman" <[email-masked]>
To: "Pete Resnick" <[email-masked]>

I read RFC 2086, draft-ietf-imapext-acl-09.txt, Rob Siemborski's 14 
Nov email "Yet another ACL Strawman", and his email of 7 Jan 
questioning the wisdom of layering two subtly different security 
systems. I couldn't get from that the full set of proposals and 
arguments, but I think I get the gist.

This effort is clearly dealing with problems to standards groups: 
backwards compatibility vs. "doing it right", different opinions as 
to what "doing it right" means, and the temptation to compromise by 
having the standard allow many variations so that everyone can do 
their own thing at the expense of interoperability.

While my first inclination is to jump in and try to propose my 
version of "doing it right", first let me respond to the question you 
asked: are any of these proposals unacceptable from a security 
standpoint (which could help narrow the decision space). My answer, 
sadly, is 'no'. While it is particularly dangerous to allow ambiguity 
in a spec with respect to security semantics, RFC 2086 set the bar on 
the bottom of page 2 with "An implementation may tie rights together 
or may force rights to always or never be granted to particular 
identifiers" and on the top of page 3 with "How these rights are 
combined to determine the user's access is implementation-defined".

These imply that there is no one correct behavior and that a client 
that wants to know the exact semantics of the server will have to 
experiment to figure it out. None of the proposed revisions (that I 
looked at) make this situation substantially worse. So I don't think 
anyone can make any strong security arguments for or against the 
layering.

Going back to my first inclination, I would urge the designers to put 
something in the protocol whereby a client can ask a server for a 
name and version of its implementation so that clients that want to 
be agile can figure out what's going on rather than poking and 
guessing.

--- end forwarded text

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

Date: Sat, 24 Jan 2004 13:35:24 -0800
To: (various IETF lists)
From: Paul Hoffman / IMC <[email-masked]>
Subject: New mail-ng mailing list open for sign-ups
Sender: [email-masked]

Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See <http://www.imc.org/mail-ng/> for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce :;
From: The IESG <[email-masked]>
Subject: Last Call: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD  EXTENSION' to Proposed Standard 
Reply-to: [email-masked]
Date: Fri, 23 Jan 2004 14:06:02 -0500
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION '
   <draft-ietf-imapext-sort-14.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-02-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt

Date: Tue, 20 Jan 2004 16:37:39 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On 1/7/04 at 1:03 PM -0600, I wrote:

>On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote:
>
>>It may help to get IESG/Security area comments on:
>>
>>a) the current ACL2 draft
>>b) ACL2 with the behavior description announcement (as discussed
>>    by the most recent thread)
>>c) Layering of two systems
>
>I'll try to find a security person with enough mail-clue to help us out.

Charlie Kaufman has kindly accepted my request to have a gander.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 15 Jan 2004 08:55:47 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:
> 
>> Ken Murchison wrote:
>>
>>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>>> wanted to make a few comments/suggestions before the document gets 
>>> too far along in the queue.
>>>
>>> Here is what I have come up with over the last day.  I might have 
>>> more as I get further into my implementation.
>>
>>
>>
>> Section 3.6:  The phrase in the first sentence "to include 
>> mod-sequence" should be changed to read "to include the highest 
>> mod-sequence". 
> 
> 
> Correct (as per your explanation below)
> 
>> Since the mod-sequence being returned in the untagged SEARCH, SORT and 
>> possibly THREAD responses is the *highest* of the messages in the 
>> response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
>> of MODSEQ?  This seems more intuitive, unless you think it conflicts 
>> with the HIGHESTMODSEQ response code. 
> 
> 
> I would like not to change syntax at this point. Once again, the draft 
> is already approved as RFC.

Right, I understand.  I'd also like to see SEARCH MODSEQ changed to 
SEARCH CHANGEDSINCE if we had the time.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 23:07:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
>
> Section 3.6:  The phrase in the first sentence "to include 
> mod-sequence" should be changed to read "to include the highest 
> mod-sequence". 

Correct (as per your explanation below)

> Since the mod-sequence being returned in the untagged SEARCH, SORT and 
> possibly THREAD responses is the *highest* of the messages in the 
> response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
> of MODSEQ?  This seems more intuitive, unless you think it conflicts 
> with the HIGHESTMODSEQ response code. 

I would like not to change syntax at this point. Once again, the draft 
is already approved as RFC.

Alexey

Date: Wed, 14 Jan 2004 23:10:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
> The first two examples in section 3.5 are reversed (the first shows 
> the MODSEQ sort crit, and the second shows the MODSEQ search crit). 

Good catch. Fixed.

Alexey

Date: Wed, 14 Jan 2004 14:37:56 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

Section 3.6:  The phrase in the first sentence "to include mod-sequence" 
should be changed to read "to include the highest mod-sequence".

Since the mod-sequence being returned in the untagged SEARCH, SORT and 
possibly THREAD responses is the *highest* of the messages in the 
response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
of MODSEQ?  This seems more intuitive, unless you think it conflicts 
with the HIGHESTMODSEQ response code.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 14:11:26 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

The first two examples in section 3.5 are reversed (the first shows the 
MODSEQ sort crit, and the second shows the MODSEQ search crit).

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 18:25:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Steve Hole wrote:

>On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison <[email-masked]> wrote:
>  
>
>>So, assume the client is CONDSTORE enabled, and then sends:
>>
>>FETCH 1:* ENVELOPE
>>
>>We should return the MODSEQ for each message?  That seems 
>>counter-intuitive.  First, the client didn't ask for it, and second, any 
>>meta-data changes would be sent in the form of unsolicited FETCH 
>>responses anyways.
>>    
>>
>
>Ah ... I see what you're after.
>
>You would include any changed MODSEQ as unsolicited data.  You don't need 
>to include the MODSEQ for unchanged items as along with the ENVELOPE 
>response.
>
I agree, but the document has to clarify this.

>A more interesting question is something like:
>
> FETCH 2:4 ENVELOPE
>
>and there is a changed MODSEQ for message 7 -- should you issue and 
>unsolicited MODSEQ for it triggered by the FETCH even though it is 
>outside the fetch set. The answer is yes because you want to learn about 
>the state change as soon as possible in the application (just like FLAGS).
>The client can always ignore the data.
>  
>
>>Am I missing something?
>>    
>>
>No.   I just didn't get what you were asking.   Sorry about that.
>
>Cheers.
>  
>
Alexey

From: Steve Hole <[email-masked]>
Date: Wed, 14 Jan 2004 11:19:57 -0700
To: Ken Murchison <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison <[email-masked]> wrote:

> So, assume the client is CONDSTORE enabled, and then sends:
> 
> FETCH 1:* ENVELOPE
>
> We should return the MODSEQ for each message?  That seems 
> counter-intuitive.  First, the client didn't ask for it, and second, any 
> meta-data changes would be sent in the form of unsolicited FETCH 
> responses anyways.

Ah ... I see what you're after.

You would include any changed MODSEQ as unsolicited data.  You don't need 
to include the MODSEQ for unchanged items as along with the ENVELOPE 
response.

A more interesting question is something like:

 FETCH 2:4 ENVELOPE

and there is a changed MODSEQ for message 7 -- should you issue and 
unsolicited MODSEQ for it triggered by the FETCH even though it is 
outside the fetch set. The answer is yes because you want to learn about 
the state change as soon as possible in the application (just like FLAGS).
The client can always ignore the data.

> Am I missing something?

No.   I just didn't get what you were asking.   Sorry about that.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 14 Jan 2004 12:32:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Steve Hole <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Steve Hole wrote:

> On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison <[email-masked]> wrote:
> 
> 
>>Ken Murchison wrote:
> 
>>Other issue:  The end of section 2 says that once a CONDSTORE enabling 
>>command is used by the client, that *all* FETCH responses must include 
>>MODSEQ.  Is this also the case with responses to a FETCH command, or is 
>>this still controlled by whether or not the MODSEQ fetch data item is 
>>used?  I'm assuming the latter, but if the former, what's the point of 
>>having the MODSEQ data item?
> 
> 
> Once you use a MODSEQ modifier in any command, including FETCH, then you 
> have to return MODSEQ data in any FETCH response whether solicited or not.
> This is because the client will be (presumably) caching and using the 
> modseq data advisory "locking".

So, assume the client is CONDSTORE enabled, and then sends:

FETCH 1:* ENVELOPE

We should return the MODSEQ for each message?  That seems 
counter-intuitive.  First, the client didn't ask for it, and second, any 
meta-data changes would be sent in the form of unsolicited FETCH 
responses anyways.

Am I missing something?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: Steve Hole <[email-masked]>
Date: Wed, 14 Jan 2004 10:06:02 -0700
To: Ken Murchison <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison <[email-masked]> wrote:

> Ken Murchison wrote:
> 
> > 
> > I just starting working on a CONDSTORE implementation in Cyrus, and I 
> > wanted to make a few comments/suggestions before the document gets too 
> > far along in the queue.
> > 
> > Here is what I have come up with over the last day.  I might have more 
> > as I get further into my implementation.
> 
> General question:  Do the MODSEQ for each message have to be unique, or 
> can multiple messages have the same MODSEQ?  For instance, if I do:
> 
> FETCH 1:* +FLAGS (\Seen)
> 
> can all of the messages have the same MODSEQ?  I'd like to think yes.

Yes, they can have the same MODSEQ.   The MODSEQ is strictly ascending for
any change to a particular message.
 
> Other issue:  The end of section 2 says that once a CONDSTORE enabling 
> command is used by the client, that *all* FETCH responses must include 
> MODSEQ.  Is this also the case with responses to a FETCH command, or is 
> this still controlled by whether or not the MODSEQ fetch data item is 
> used?  I'm assuming the latter, but if the former, what's the point of 
> having the MODSEQ data item?

Once you use a MODSEQ modifier in any command, including FETCH, then you 
have to return MODSEQ data in any FETCH response whether solicited or not.
This is because the client will be (presumably) caching and using the 
modseq data advisory "locking".

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 14 Jan 2004 09:42:57 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

General question:  Do the MODSEQ for each message have to be unique, or 
can multiple messages have the same MODSEQ?  For instance, if I do:

FETCH 1:* +FLAGS (\Seen)

can all of the messages have the same MODSEQ?  I'd like to think yes.

Other issue:  The end of section 2 says that once a CONDSTORE enabling 
command is used by the client, that *all* FETCH responses must include 
MODSEQ.  Is this also the case with responses to a FETCH command, or is 
this still controlled by whether or not the MODSEQ fetch data item is 
used?  I'm assuming the latter, but if the former, what's the point of 
having the MODSEQ data item?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Sun, 11 Jan 2004 19:23:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
> The grammar doesn't seem to include the extension of SELECT/EXAMINE 
> for the CONDSTORE parameter.

If I remember correctly the generic syntax for SELECT/EXAMINE parameters 
is defined in ANNOTATE document, which is a normative reference for 
CONDSTORE.

>   Is this supposed to be a generic extension and CONDSTORE is one such 
> parameter, or the only valid parameter is CONDSTORE?

The former.

>   If the latter, is there a reason why the parameter is in the form of 
> a list?

Alexey

__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Sun, 11 Jan 2004 19:22:01 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
>
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.
>
> - As a general note, should the STORE/FETCH modifier syntax be broken 
> out into a separate draft and then referenced by CONDSTORE? 

I thought about this as well. I don't remember now, but I thought I've 
asked this question on the mailing list.
Anyway, CONDSTORE is approved as RFC now and I fear it will take another 
3 years before updated CONDSTORE and that separate document get published.

>   Any subsequent draft which introduces a new modifier will have to 
> reference CONDSTORE, which seems a bit awkward.
>
> - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE 
> enabling command?  Is this by design or an oversight? 

An oversight.

> - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* 
> returned for SELECT/EXAMINE.

That is correct.

>   Why is this necessary when we explicitly have CONSTORE enabling 
> commands which require that we return HIGHESTMODSEQ?  It seems 
> redundant that weShould we just return HIGHESTMODSEQ for 
> SELECT/EXAMINE CONDSTORE? would return this on SELECT/EXAMINE and then 
> again on the first CONDSTORE-specific STORE/FETCH.  

You are probably right, but I don't see a problem with returning 
HIGHESTMODSEQ on the first CONDSTORE-aware STORE/FETCH.

If Ned agrees that just returning HIGHESTMODSEQ on SELECT/EXAMINE 
CONDSTORE is not a substantial change to the document, I can try to 
modify it.

> - Section 3.2, first example: the MODSEQ value of UID 6 is less than 
> UNCHANGEDSINCE 

Good catch.

> - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last 
> argument.

Corrected in my copy, thanks.

> - Section 4.  The grammar for the STORE and FETCH modifiers seem 
> inconsistent with one another.  The STORE grammar defines 
> UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier 
> in general terms, and has the chgsince-fetch-mod terminal unused. 

The latter approach is probably better.

chgsince-fetch-mod is not really unused. There is a comment that it 
conforms to fetch-modifier syntax.

> - Does the MODSEQ search criterion also apply to THREAD in the same 
> way that it does to SORT?

Yes, search criterion applies to all commands that make use of it.

> - Grammatical nits:
>
> Section 2, paragraph 3, sentence 2: perhaps replacing both instances 
> of "and before" with "where previously" would read better.
>
> Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" 
> should probably read "SELECT or EXAMINE command"

I've changed this in my copy, thanks.

Alexey

Date: Sat, 10 Jan 2004 19:26:47 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>, [email-masked]
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

The grammar doesn't seem to include the extension of SELECT/EXAMINE for 
the CONDSTORE parameter.  Is this supposed to be a generic extension and 
CONDSTORE is one such parameter, or the only valid parameter is 
CONDSTORE?  If the latter, is there a reason why the parameter is in the 
form of a list?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Sat, 10 Jan 2004 16:50:13 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>, [email-masked]
CC: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-condstore-05
Sender: [email-masked]

I just starting working on a CONDSTORE implementation in Cyrus, and I 
wanted to make a few comments/suggestions before the document gets too 
far along in the queue.

Here is what I have come up with over the last day.  I might have more 
as I get further into my implementation.

- As a general note, should the STORE/FETCH modifier syntax be broken 
out into a separate draft and then referenced by CONDSTORE?  Any 
subsequent draft which introduces a new modifier will have to reference 
CONDSTORE, which seems a bit awkward.

- Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE 
enabling command?  Is this by design or an oversight?

- Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* 
returned for SELECT/EXAMINE.  Why is this necessary when we explcitly 
have CONSTORE enabling commands which require that we return 
HIGHESTMODSEQ?  It seems redundant that we would return this on 
SELECT/EXAMINE and then again on the first CONDSTORE-specific 
STORE/FETCH.  Should we just return HIGHESTMODSEQ for SELECT/EXAMINE 
CONDSTORE?

- Section 3.2, first example: the MODSEQ value of UID 6 is less than 
UNCHANGEDSINCE

- Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last argument.

- Section 4.  The grammar for the STORE and FETCH modifiers seem 
inconsistent with one another.  The STORE grammar defines UNCHANGEDSINCE 
as the only modifier, where FETCH defines the modifier in general terms, 
and has the chgsince-fetch-mod terminal unused.

- Does the MODSEQ search criterion also apply to THREAD in the same way 
that it does to SORT?

- Grammatical nits:

Section 2, paragraph 3, sentence 2: perhaps replacing both instances of 
"and before" with "where previously" would read better.

Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" 
should probably read "SELECT or EXAMINE command"

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 7 Jan 2004 13:03:51 -0600
To: Rob Siemborski <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Yet another ACL Strawman
Cc: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote:

>It may help to get IESG/Security area comments on:
>
>a) the current ACL2 draft
>b) ACL2 with the behavior description announcement (as discussed
>    by the most recent thread)
>c) Layering of two systems

I'll try to find a security person with enough mail-clue to help us out.

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

Date: Wed, 7 Jan 2004 13:46:27 -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, Rob Siemborski wrote:

> 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.

After some consideration, I'm still forced to believe that having two
distinct permissions systems where one is not a full and proper subset of
the other is a poor long-term design choice.

However, I am not a security expert, and thus cannot judge the
implications of layering PERMISSIONS on top of UNION ACL (or even a
MOST-SPECIFIC ACL, which is certainly a better fit).

My gut is telling me that this will lead to a very complicated
specification that will lead to implementation and
interoperability problems.

It may help to get IESG/Security area comments on:

a) the current ACL2 draft
b) ACL2 with the behavior description announcement (as discussed
   by the most recent thread)
c) Layering of two systems

-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, 7 Jan 2004 13:38:48 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Tue, 30 Dec 2003, Timo Sirainen wrote:

> 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

After consideration, I don't think this is an acceptable upgrade path.
Merging rights down to users (especially in the user+groups situation) is
a very poor solution for deployments with extensive usage of both groups
and users in UNION based ACLs.

While it is true that in many cases it will probably be good enough to
munge ACLs in this way, once the upgrade is done enterprises that may be
used to managing groups in one way (and may be unable to change!) will
now have to deal with the fact that removing a user from a group will not
necessarily remove the rights that this group once granted to that user.

IMAP servers may also not be able to create arbitrary groups (such as a
'world' group), unless this means "create a virtual world group outside of
the local group management system" which would only create more problems:

Imagine an ACL of:

  anyone lrs
  group=anyone lrs

When I change the ACL of 'anyone' to lrsp, should the phantom group just
track it and become group=anyone lrsp?  Is it reasonable for the client to
predict this sort of behavior?

These problems will have the effect of prohibiting existing ACL servers
from upgrading to ACL2 -- this should be just as unacceptable to the
working group as forbidding a unix-filesystem based system from having any
sort of rights management (especially if, as I have been told, the ACL2
draft started as an attempt to fix the 'd' right situation in ACL and
nothing more).

-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, 7 Jan 2004 09:24:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Shall we meet in Seoul?
Sender: [email-masked]

On Wed, 7 Jan 2004, Alexey Melnikov wrote:
> > 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?
> I am planning to attend. But I don't have tickets yet, so I can't give any
> guaranty.

I am not going to be there.

-- Mark --

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

Date: Wed, 07 Jan 2004 11:34:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Shall we meet in Seoul?
Sender: [email-masked]

Pete Resnick wrote:

> 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? 

I am planning to attend. But I don't have tickets yet, so I can't give 
any guaranty.

Alexey

Date: Thu, 29 Jan 2004 13:33:28 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 29 Jan 2004, Rob Siemborski wrote:
> > As we've discussed already, UNION-based ACL semantics is incapable of
> > representing filesystem semantics.
> I didn't say *only* union of course.  The current ACL2 draft addresses
> this issue just fine.

OK with me.

-- Mark --

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

Date: Thu, 29 Jan 2004 16:30:23 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

On Thu, 29 Jan 2004, Mark Crispin wrote:

> As we've discussed already, UNION-based ACL semantics is incapable of
> representing filesystem semantics.

I didn't say *only* union of course.  The current ACL2 draft addresses
this issue just fine.

> > b) some way to represent the "large enough but not too large" mechanism
> > within the ACL2 semantics.
>
> That's fine with me, but wouldn't it be simpler to do my idea of saying
> that the way to enable ACL is to set the "large enough but not too large"
> to deny-all?

This would, of course, depend somewhat on whatever "large enough but not
too large" became in the long run.  I can see models where there is no
distinction and models where there is.

However, I'd prefer us following up on (a) before we decide we definately
need a second non-trivial model.

-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: Thu, 29 Jan 2004 13:24:32 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 29 Jan 2004, Rob Siemborski wrote:
> I suspect doing the modifications to ACL2 so as to advertise the semantics
> of how identifiers are handled (as we discussed in the middle of last
> year) might be the way to go.

I agree to this.

> > 2) Adopt a simplified ACL2 and a separate "large enough but not too large"
> >    mechanism for compatibility.  If the latter turns out to be the only
> >    one that is widely implemented, that's life.
> If we want to go this way instead, I'd want to make sure we see the
> following:
> a) backwards compatibility (or atleast a sane upgrade path that doesn't
> result in the interpretation of ACLs being changed -- this is NOT the same
> as a server being able to advertise both ACL and ACL2 at the same time)
> for UNION-based ACL implementations.

As we've discussed already, UNION-based ACL semantics is incapable of
representing filesystem semantics.

> b) some way to represent the "large enough but not too large" mechanism
> within the ACL2 semantics.

That's fine with me, but wouldn't it be simpler to do my idea of saying
that the way to enable ACL is to set the "large enough but not too large"
to deny-all?

-- Mark --

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

Date: Thu, 29 Jan 2004 12:52:22 -0800
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
cc: Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

--On 2004-1-29 3:21 PM -0500 Rob Siemborski <[email-masked]> wrote:

> I suspect doing the modifications to ACL2 so as to advertise the
> semantics of how identifiers are handled (as we discussed in the
> middle of last year) might be the way to go.

I don't think we have any other choice. "Hope and pray" security 
semantics simply don't cut it. The result of a security operation 
*must* be deterministic, otherwise you can't call it "secure" in any 
sense of the word.

--lyndon

Date: Thu, 29 Jan 2004 15:21:13 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

On Thu, 29 Jan 2004, Mark Crispin wrote:

> I see the acceptable solutions as:
>
> 1) Adopt ACL2, declare victory, and go home.  If it's a lot of work for
>    everybody, that's life.

Since the major objection (that I know of) to doing this is that "clients
can't understand what's about to happen", and one of Charlie's comments
is:

>>
Going back to my first inclination, I would urge the designers to put
something in the protocol whereby a client can ask a server for a
name and version of its implementation so that clients that want to
be agile can figure out what's going on rather than poking and
guessing.
<<

I suspect doing the modifications to ACL2 so as to advertise the semantics
of how identifiers are handled (as we discussed in the middle of last
year) might be the way to go.

> 2) Adopt a simplified ACL2 and a separate "large enough but not too large"
>    mechanism for compatibility.  If the latter turns out to be the only
>    one that is widely implemented, that's life.

If we want to go this way instead, I'd want to make sure we see the
following:

a) backwards compatibility (or atleast a sane upgrade path that doesn't
result in the interpretation of ACLs being changed -- this is NOT the same
as a server being able to advertise both ACL and ACL2 at the same time)
for UNION-based ACL implementations.

b) some way to represent the "large enough but not too large" mechanism
within the ACL2 semantics.

-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: Thu, 29 Jan 2004 10:07:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked], Charlie Kaufman <[email-masked]>
Subject: Re: Fwd: Request for security review
Sender: [email-masked]

Thank you Charlie for your security review.

Tndeed, your observation that RFC 2086 "impl[ies] that there is no one
correct behavior and that a client that wants to know the exact semantics
of the server will have to experiment to figure it out."  This is one of
the bugs of RFC 2086 that needs to be fixed.

Here's some background:

You are correct in identifying a conflict between "backwards
compatibility" and "doing it right".  There is another conflict, this one
between "ideal" (at least in some viewpoints) and "compatible with (and
implementable on) existing mail stores."

The "ideal" camp once claimed that "compatible" was a proper subset of
"ideal".  In RFC 2086, it provably isn't; not only are some valid access
controls in "ideal" not expressible in "compatible", but some valid access
controls in "compatible" are not expressible in "ideal".

ACL2 is an attempt, first to resolve the ambiguities in RFC 2086 and to
ensure that "compatible" is a proper subset.  Doing this made ACL2 quite a
bit more complicated than RFC 2086.

The "ideal" camp is unhappy about this.  The "compatible" camp, on the
other hand, sees that it's being put through a great deal of complexity
anyway, so they don't sympathize; rather, they see it as necessary for ACL
to be implementable at all.

Rob's strawman was an attempt to reduce the complexity for the "ideal"
camp by providing a smaller mechanism for the "compatible" camp.
Unfortunately, the smaller mechanism is too small for the "compatible"
camp, but with a few minor extensions it would be fine -- "large enough
but not too large."

There is a suspicion, held by both camps, that the "large enough but not
too large" mechanism desired by the "compatible" camp will be "good
enough" for almost all users.

The resulting positions taken by the players are obvious. :-)

I see the acceptable solutions as:

1) Adopt ACL2, declare victory, and go home.  If it's a lot of work for
   everybody, that's life.

2) Adopt a simplified ACL2 and a separate "large enough but not too large"
   mechanism for compatibility.  If the latter turns out to be the only
   one that is widely implemented, that's life.

I see the following as unacceptable:

1) Retain RFC 2086.

2) Simplify ACL2 without any attempt to support compatible access control.

-- Mark --

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

Date: Thu, 29 Jan 2004 10:56:42 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Fwd: Request for security review
Cc: Charlie Kaufman <[email-masked]>
Sender: [email-masked]

Below is the security review of ACL that I asked Charlie Kaufman to 
do for us. I've Cc'ed Charlie on this; please reply to all if you 
have questions or comments on this review.

--- begin forwarded text

Subject: RE: Request for security review - IMAPEXT
Date: Sun, 25 Jan 2004 20:35:34 -0800
From: "Charlie Kaufman" <[email-masked]>
To: "Pete Resnick" <[email-masked]>

I read RFC 2086, draft-ietf-imapext-acl-09.txt, Rob Siemborski's 14 
Nov email "Yet another ACL Strawman", and his email of 7 Jan 
questioning the wisdom of layering two subtly different security 
systems. I couldn't get from that the full set of proposals and 
arguments, but I think I get the gist.

This effort is clearly dealing with problems to standards groups: 
backwards compatibility vs. "doing it right", different opinions as 
to what "doing it right" means, and the temptation to compromise by 
having the standard allow many variations so that everyone can do 
their own thing at the expense of interoperability.

While my first inclination is to jump in and try to propose my 
version of "doing it right", first let me respond to the question you 
asked: are any of these proposals unacceptable from a security 
standpoint (which could help narrow the decision space). My answer, 
sadly, is 'no'. While it is particularly dangerous to allow ambiguity 
in a spec with respect to security semantics, RFC 2086 set the bar on 
the bottom of page 2 with "An implementation may tie rights together 
or may force rights to always or never be granted to particular 
identifiers" and on the top of page 3 with "How these rights are 
combined to determine the user's access is implementation-defined".

These imply that there is no one correct behavior and that a client 
that wants to know the exact semantics of the server will have to 
experiment to figure it out. None of the proposed revisions (that I 
looked at) make this situation substantially worse. So I don't think 
anyone can make any strong security arguments for or against the 
layering.

Going back to my first inclination, I would urge the designers to put 
something in the protocol whereby a client can ask a server for a 
name and version of its implementation so that clients that want to 
be agile can figure out what's going on rather than poking and 
guessing.

--- end forwarded text

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

Date: Sat, 24 Jan 2004 13:35:24 -0800
To: (various IETF lists)
From: Paul Hoffman / IMC <[email-masked]>
Subject: New mail-ng mailing list open for sign-ups
Sender: [email-masked]

Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See <http://www.imc.org/mail-ng/> for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce :;
From: The IESG <[email-masked]>
Subject: Last Call: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD  EXTENSION' to Proposed Standard 
Reply-to: [email-masked]
Date: Fri, 23 Jan 2004 14:06:02 -0500
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION '
   <draft-ietf-imapext-sort-14.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-02-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt

Date: Tue, 20 Jan 2004 16:37:39 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On 1/7/04 at 1:03 PM -0600, I wrote:

>On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote:
>
>>It may help to get IESG/Security area comments on:
>>
>>a) the current ACL2 draft
>>b) ACL2 with the behavior description announcement (as discussed
>>    by the most recent thread)
>>c) Layering of two systems
>
>I'll try to find a security person with enough mail-clue to help us out.

Charlie Kaufman has kindly accepted my request to have a gander.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 15 Jan 2004 08:55:47 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Alexey Melnikov wrote:
> Ken Murchison wrote:
> 
>> Ken Murchison wrote:
>>
>>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>>> wanted to make a few comments/suggestions before the document gets 
>>> too far along in the queue.
>>>
>>> Here is what I have come up with over the last day.  I might have 
>>> more as I get further into my implementation.
>>
>>
>>
>> Section 3.6:  The phrase in the first sentence "to include 
>> mod-sequence" should be changed to read "to include the highest 
>> mod-sequence". 
> 
> 
> Correct (as per your explanation below)
> 
>> Since the mod-sequence being returned in the untagged SEARCH, SORT and 
>> possibly THREAD responses is the *highest* of the messages in the 
>> response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
>> of MODSEQ?  This seems more intuitive, unless you think it conflicts 
>> with the HIGHESTMODSEQ response code. 
> 
> 
> I would like not to change syntax at this point. Once again, the draft 
> is already approved as RFC.

Right, I understand.  I'd also like to see SEARCH MODSEQ changed to 
SEARCH CHANGEDSINCE if we had the time.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 23:07:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
>
> Section 3.6:  The phrase in the first sentence "to include 
> mod-sequence" should be changed to read "to include the highest 
> mod-sequence". 

Correct (as per your explanation below)

> Since the mod-sequence being returned in the untagged SEARCH, SORT and 
> possibly THREAD responses is the *highest* of the messages in the 
> response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
> of MODSEQ?  This seems more intuitive, unless you think it conflicts 
> with the HIGHESTMODSEQ response code. 

I would like not to change syntax at this point. Once again, the draft 
is already approved as RFC.

Alexey

Date: Wed, 14 Jan 2004 23:10:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
> The first two examples in section 3.5 are reversed (the first shows 
> the MODSEQ sort crit, and the second shows the MODSEQ search crit). 

Good catch. Fixed.

Alexey

Date: Wed, 14 Jan 2004 14:37:56 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

Section 3.6:  The phrase in the first sentence "to include mod-sequence" 
should be changed to read "to include the highest mod-sequence".

Since the mod-sequence being returned in the untagged SEARCH, SORT and 
possibly THREAD responses is the *highest* of the messages in the 
response, shouldn't the extended response tag be HIGHESTMODSEQ instead 
of MODSEQ?  This seems more intuitive, unless you think it conflicts 
with the HIGHESTMODSEQ response code.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 14:11:26 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

The first two examples in section 3.5 are reversed (the first shows the 
MODSEQ sort crit, and the second shows the MODSEQ search crit).

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 14 Jan 2004 18:25:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Steve Hole <[email-masked]>
CC: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Steve Hole wrote:

>On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison <[email-masked]> wrote:
>  
>
>>So, assume the client is CONDSTORE enabled, and then sends:
>>
>>FETCH 1:* ENVELOPE
>>
>>We should return the MODSEQ for each message?  That seems 
>>counter-intuitive.  First, the client didn't ask for it, and second, any 
>>meta-data changes would be sent in the form of unsolicited FETCH 
>>responses anyways.
>>    
>>
>
>Ah ... I see what you're after.
>
>You would include any changed MODSEQ as unsolicited data.  You don't need 
>to include the MODSEQ for unchanged items as along with the ENVELOPE 
>response.
>
I agree, but the document has to clarify this.

>A more interesting question is something like:
>
> FETCH 2:4 ENVELOPE
>
>and there is a changed MODSEQ for message 7 -- should you issue and 
>unsolicited MODSEQ for it triggered by the FETCH even though it is 
>outside the fetch set. The answer is yes because you want to learn about 
>the state change as soon as possible in the application (just like FLAGS).
>The client can always ignore the data.
>  
>
>>Am I missing something?
>>    
>>
>No.   I just didn't get what you were asking.   Sorry about that.
>
>Cheers.
>  
>
Alexey

From: Steve Hole <[email-masked]>
Date: Wed, 14 Jan 2004 11:19:57 -0700
To: Ken Murchison <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison <[email-masked]> wrote:

> So, assume the client is CONDSTORE enabled, and then sends:
> 
> FETCH 1:* ENVELOPE
>
> We should return the MODSEQ for each message?  That seems 
> counter-intuitive.  First, the client didn't ask for it, and second, any 
> meta-data changes would be sent in the form of unsolicited FETCH 
> responses anyways.

Ah ... I see what you're after.

You would include any changed MODSEQ as unsolicited data.  You don't need 
to include the MODSEQ for unchanged items as along with the ENVELOPE 
response.

A more interesting question is something like:

 FETCH 2:4 ENVELOPE

and there is a changed MODSEQ for message 7 -- should you issue and 
unsolicited MODSEQ for it triggered by the FETCH even though it is 
outside the fetch set. The answer is yes because you want to learn about 
the state change as soon as possible in the application (just like FLAGS).
The client can always ignore the data.

> Am I missing something?

No.   I just didn't get what you were asking.   Sorry about that.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 14 Jan 2004 12:32:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Steve Hole <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Steve Hole wrote:

> On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison <[email-masked]> wrote:
> 
> 
>>Ken Murchison wrote:
> 
>>Other issue:  The end of section 2 says that once a CONDSTORE enabling 
>>command is used by the client, that *all* FETCH responses must include 
>>MODSEQ.  Is this also the case with responses to a FETCH command, or is 
>>this still controlled by whether or not the MODSEQ fetch data item is 
>>used?  I'm assuming the latter, but if the former, what's the point of 
>>having the MODSEQ data item?
> 
> 
> Once you use a MODSEQ modifier in any command, including FETCH, then you 
> have to return MODSEQ data in any FETCH response whether solicited or not.
> This is because the client will be (presumably) caching and using the 
> modseq data advisory "locking".

So, assume the client is CONDSTORE enabled, and then sends:

FETCH 1:* ENVELOPE

We should return the MODSEQ for each message?  That seems 
counter-intuitive.  First, the client didn't ask for it, and second, any 
meta-data changes would be sent in the form of unsolicited FETCH 
responses anyways.

Am I missing something?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

From: Steve Hole <[email-masked]>
Date: Wed, 14 Jan 2004 10:06:02 -0700
To: Ken Murchison <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison <[email-masked]> wrote:

> Ken Murchison wrote:
> 
> > 
> > I just starting working on a CONDSTORE implementation in Cyrus, and I 
> > wanted to make a few comments/suggestions before the document gets too 
> > far along in the queue.
> > 
> > Here is what I have come up with over the last day.  I might have more 
> > as I get further into my implementation.
> 
> General question:  Do the MODSEQ for each message have to be unique, or 
> can multiple messages have the same MODSEQ?  For instance, if I do:
> 
> FETCH 1:* +FLAGS (\Seen)
> 
> can all of the messages have the same MODSEQ?  I'd like to think yes.

Yes, they can have the same MODSEQ.   The MODSEQ is strictly ascending for
any change to a particular message.
 
> Other issue:  The end of section 2 says that once a CONDSTORE enabling 
> command is used by the client, that *all* FETCH responses must include 
> MODSEQ.  Is this also the case with responses to a FETCH command, or is 
> this still controlled by whether or not the MODSEQ fetch data item is 
> used?  I'm assuming the latter, but if the former, what's the point of 
> having the MODSEQ data item?

Once you use a MODSEQ modifier in any command, including FETCH, then you 
have to return MODSEQ data in any FETCH response whether solicited or not.
This is because the client will be (presumably) caching and using the 
modseq data advisory "locking".

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Wed, 14 Jan 2004 09:42:57 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

General question:  Do the MODSEQ for each message have to be unique, or 
can multiple messages have the same MODSEQ?  For instance, if I do:

FETCH 1:* +FLAGS (\Seen)

can all of the messages have the same MODSEQ?  I'd like to think yes.

Other issue:  The end of section 2 says that once a CONDSTORE enabling 
command is used by the client, that *all* FETCH responses must include 
MODSEQ.  Is this also the case with responses to a FETCH command, or is 
this still controlled by whether or not the MODSEQ fetch data item is 
used?  I'm assuming the latter, but if the former, what's the point of 
having the MODSEQ data item?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Sun, 11 Jan 2004 19:23:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> Ken Murchison wrote:
>
>> I just starting working on a CONDSTORE implementation in Cyrus, and I 
>> wanted to make a few comments/suggestions before the document gets 
>> too far along in the queue.
>>
>> Here is what I have come up with over the last day.  I might have 
>> more as I get further into my implementation.
>
> The grammar doesn't seem to include the extension of SELECT/EXAMINE 
> for the CONDSTORE parameter.

If I remember correctly the generic syntax for SELECT/EXAMINE parameters 
is defined in ANNOTATE document, which is a normative reference for 
CONDSTORE.

>   Is this supposed to be a generic extension and CONDSTORE is one such 
> parameter, or the only valid parameter is CONDSTORE?

The former.

>   If the latter, is there a reason why the parameter is in the form of 
> a list?

Alexey

__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Sun, 11 Jan 2004 19:22:01 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
>
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.
>
> - As a general note, should the STORE/FETCH modifier syntax be broken 
> out into a separate draft and then referenced by CONDSTORE? 

I thought about this as well. I don't remember now, but I thought I've 
asked this question on the mailing list.
Anyway, CONDSTORE is approved as RFC now and I fear it will take another 
3 years before updated CONDSTORE and that separate document get published.

>   Any subsequent draft which introduces a new modifier will have to 
> reference CONDSTORE, which seems a bit awkward.
>
> - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE 
> enabling command?  Is this by design or an oversight? 

An oversight.

> - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* 
> returned for SELECT/EXAMINE.

That is correct.

>   Why is this necessary when we explicitly have CONSTORE enabling 
> commands which require that we return HIGHESTMODSEQ?  It seems 
> redundant that weShould we just return HIGHESTMODSEQ for 
> SELECT/EXAMINE CONDSTORE? would return this on SELECT/EXAMINE and then 
> again on the first CONDSTORE-specific STORE/FETCH.  

You are probably right, but I don't see a problem with returning 
HIGHESTMODSEQ on the first CONDSTORE-aware STORE/FETCH.

If Ned agrees that just returning HIGHESTMODSEQ on SELECT/EXAMINE 
CONDSTORE is not a substantial change to the document, I can try to 
modify it.

> - Section 3.2, first example: the MODSEQ value of UID 6 is less than 
> UNCHANGEDSINCE 

Good catch.

> - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last 
> argument.

Corrected in my copy, thanks.

> - Section 4.  The grammar for the STORE and FETCH modifiers seem 
> inconsistent with one another.  The STORE grammar defines 
> UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier 
> in general terms, and has the chgsince-fetch-mod terminal unused. 

The latter approach is probably better.

chgsince-fetch-mod is not really unused. There is a comment that it 
conforms to fetch-modifier syntax.

> - Does the MODSEQ search criterion also apply to THREAD in the same 
> way that it does to SORT?

Yes, search criterion applies to all commands that make use of it.

> - Grammatical nits:
>
> Section 2, paragraph 3, sentence 2: perhaps replacing both instances 
> of "and before" with "where previously" would read better.
>
> Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" 
> should probably read "SELECT or EXAMINE command"

I've changed this in my copy, thanks.

Alexey

Date: Sat, 10 Jan 2004 19:26:47 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>, [email-masked]
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-condstore-05
Sender: [email-masked]

Ken Murchison wrote:

> 
> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
> 
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.

The grammar doesn't seem to include the extension of SELECT/EXAMINE for 
the CONDSTORE parameter.  Is this supposed to be a generic extension and 
CONDSTORE is one such parameter, or the only valid parameter is 
CONDSTORE?  If the latter, is there a reason why the parameter is in the 
form of a list?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Sat, 10 Jan 2004 16:50:13 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>, [email-masked]
CC: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-condstore-05
Sender: [email-masked]

I just starting working on a CONDSTORE implementation in Cyrus, and I 
wanted to make a few comments/suggestions before the document gets too 
far along in the queue.

Here is what I have come up with over the last day.  I might have more 
as I get further into my implementation.

- As a general note, should the STORE/FETCH modifier syntax be broken 
out into a separate draft and then referenced by CONDSTORE?  Any 
subsequent draft which introduces a new modifier will have to reference 
CONDSTORE, which seems a bit awkward.

- Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE 
enabling command?  Is this by design or an oversight?

- Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* 
returned for SELECT/EXAMINE.  Why is this necessary when we explcitly 
have CONSTORE enabling commands which require that we return 
HIGHESTMODSEQ?  It seems redundant that we would return this on 
SELECT/EXAMINE and then again on the first CONDSTORE-specific 
STORE/FETCH.  Should we just return HIGHESTMODSEQ for SELECT/EXAMINE 
CONDSTORE?

- Section 3.2, first example: the MODSEQ value of UID 6 is less than 
UNCHANGEDSINCE

- Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last argument.

- Section 4.  The grammar for the STORE and FETCH modifiers seem 
inconsistent with one another.  The STORE grammar defines UNCHANGEDSINCE 
as the only modifier, where FETCH defines the modifier in general terms, 
and has the chgsince-fetch-mod terminal unused.

- Does the MODSEQ search criterion also apply to THREAD in the same way 
that it does to SORT?

- Grammatical nits:

Section 2, paragraph 3, sentence 2: perhaps replacing both instances of 
"and before" with "where previously" would read better.

Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" 
should probably read "SELECT or EXAMINE command"

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 7 Jan 2004 13:03:51 -0600
To: Rob Siemborski <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Yet another ACL Strawman
Cc: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote:

>It may help to get IESG/Security area comments on:
>
>a) the current ACL2 draft
>b) ACL2 with the behavior description announcement (as discussed
>    by the most recent thread)
>c) Layering of two systems

I'll try to find a security person with enough mail-clue to help us out.

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

Date: Wed, 7 Jan 2004 13:46:27 -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, Rob Siemborski wrote:

> 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.

After some consideration, I'm still forced to believe that having two
distinct permissions systems where one is not a full and proper subset of
the other is a poor long-term design choice.

However, I am not a security expert, and thus cannot judge the
implications of layering PERMISSIONS on top of UNION ACL (or even a
MOST-SPECIFIC ACL, which is certainly a better fit).

My gut is telling me that this will lead to a very complicated
specification that will lead to implementation and
interoperability problems.

It may help to get IESG/Security area comments on:

a) the current ACL2 draft
b) ACL2 with the behavior description announcement (as discussed
   by the most recent thread)
c) Layering of two systems

-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, 7 Jan 2004 13:38:48 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: Yet another ACL Strawman
Sender: [email-masked]

On Tue, 30 Dec 2003, Timo Sirainen wrote:

> 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

After consideration, I don't think this is an acceptable upgrade path.
Merging rights down to users (especially in the user+groups situation) is
a very poor solution for deployments with extensive usage of both groups
and users in UNION based ACLs.

While it is true that in many cases it will probably be good enough to
munge ACLs in this way, once the upgrade is done enterprises that may be
used to managing groups in one way (and may be unable to change!) will
now have to deal with the fact that removing a user from a group will not
necessarily remove the rights that this group once granted to that user.

IMAP servers may also not be able to create arbitrary groups (such as a
'world' group), unless this means "create a virtual world group outside of
the local group management system" which would only create more problems:

Imagine an ACL of:

  anyone lrs
  group=anyone lrs

When I change the ACL of 'anyone' to lrsp, should the phantom group just
track it and become group=anyone lrsp?  Is it reasonable for the client to
predict this sort of behavior?

These problems will have the effect of prohibiting existing ACL servers
from upgrading to ACL2 -- this should be just as unacceptable to the
working group as forbidding a unix-filesystem based system from having any
sort of rights management (especially if, as I have been told, the ACL2
draft started as an attempt to fix the 'd' right situation in ACL and
nothing more).

-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, 7 Jan 2004 09:24:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Shall we meet in Seoul?
Sender: [email-masked]

On Wed, 7 Jan 2004, Alexey Melnikov wrote:
> > 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?
> I am planning to attend. But I don't have tickets yet, so I can't give any
> guaranty.

I am not going to be there.

-- Mark --

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

Date: Wed, 07 Jan 2004 11:34:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Shall we meet in Seoul?
Sender: [email-masked]

Pete Resnick wrote:

> 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? 

I am planning to attend. But I don't have tickets yet, so I can't give 
any guaranty.

Alexey