Subject: Re: Capability balooning and restructuring
From: Arnt Gulbrandsen <[email-masked]>
To: Michael Fair <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Mon, 29 Sep 2003 13:52:08 +0200
List-Id: <ietf-imapext.imc.org>

Michael Fair writes:
> At the time the response was more of a "they should remain their own 
> commands, and we should find a way to reduce round trip requests" but 
> I never saw any concrete suggestions after that nor do I have any 
> myself.

1. More servers should send the CAPABILITY response code in the banner 
OK/PREAUTH (RFC 3501 page 64). Perhaps also in the LOGIN/AUTHENTICATE 
tagged OK.

2. Smart clients can use the lull provided by asking the user for a 
password. Like this:

C: connects
S: OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5]
at this point, the client starts asking its user for a password
C: a starttls
S: a OK
negotiation
C: b authenticate cram-md5
S: + 4327814372483274832
client waits until the user has finished typing the password
C: 47817348927134893217
S: b OK
C: c select inbox
...

The rule that all capabilities disappear when STARTTLS succeeds is a bit 
of a bother. (RFC 2595 section 3.1.) Hm.

> Now we're talking about adding even more distinct items to CAPABILITY 
> to support LISTEXT.

CAPABILITY is an eyesore, but its length isn't such a big problem. IMO, 
the number of capabilities is worse. A lot of combinations to test. All 
that can be done about that is careful design in each particular case.

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: CAPABILITYPLUS
Cc: IMAP Extensions WG <[email-masked]>
Date: Mon, 29 Sep 2003 13:27:20 +0200
Sender: [email-masked]

Mark Crispin writes:
> I think that a preferable option would be to have a means to 
> "compress" IMAP. It could be either abbreviated text or even binary.

I submitted an i-d for that an hour ago. Assuming I've put in all the 
right bits of boilerplate, it should be in the i-d repositories RSN.

(I've implemented the extension both as server and client. Both were 
well under 100 lines excluding test code.)

--Arnt

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 12:01:26 -0700
Lines: 30
Sender: [email-masked]

"Timo Sirainen" <[email-masked]> wrote in message
news:[email-masked]...
>
> If I set rules:
>
> user=user "rw"
> group=group1 "r"
> -group=group2 "r"
>
> and user belongs to both groups, UNION rule would give user only "w"
> access, right? It could be better if user rights would always override
> group rights, but in some situations it could be better if they didn't
> (eg. temporarily drop rights).

Ok in all fairness to the current structure of ACL2, when would you
ever do the above if you didn't mean to strip away the read right from user?

Under what circumstances would you ever apply a negative right to a
group and then put a user in that group if you didn't mean for the right
to be stripped?

If you didn't want the group to have the right, you'd just omit it from
the list.  Why go through the trouble of putting a negative right on it
if just omitting it does what you intended?

-- Michael --

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 11:56:56 -0700
Lines: 38
Sender: [email-masked]

> The classic UNIX example is the "noprint" group: Everyone has execute
> access ti lpr except group "noprint". Thus, ten thousand students can
> print, except the dozen-odd who have gravely abused the printers in the
> past and have been added to group "noprint".

This seems more a case where everybody by default is a member
of the "print" group and those that abuse the privilege get removed.
Certainly "anonymous" must be excluded here as well.

Or, again, make acl order processing significant and just make
sure the negative rights appear before the positive rights.

noprint: -w
user: rw
authuser: rw

Since there is an exact match on the negative right before hitting
anything with a positive right the system would know to disallow.

Expanding this to a shared folder where by default everyone can
post but a dozen start posting gobs of porn, you would either
have a group specified for that shared folder, or shared folders
in general which once the abusers are removed they can no longer
access the shared folders.

Or if you'd still rather have a negative rights solution, then
you add the offenders to the "noaccess" group and then put that
group early enough in the list of groups so the negative rights
get processed first.

-- Michael --

-- Michael --

Date: Fri, 12 Sep 2003 11:18:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Ken Murchison wrote:
> I think you misread him.  I think what Larry meant (and Rob and I would
> like) is:
> "anonymous" - special identifer that refers to all users authenticated
>           as the anonymous identity
> "authuser" - special identifier that refers to all authenticated users,
>           excluding anonymous.
> "anyone" - special identifier that refers to the universal identity
>           (all authentications, including anonymous).
> In other words "anyone" = "anonymous" + "authuser"

This idea sounds fine to me.

-- Mark --

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

Date: Fri, 12 Sep 2003 14:09:38 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

Alexey Melnikov wrote:

> 
> Rob Siemborski wrote:
> 
>> On Fri, 12 Sep 2003, Michael Fair wrote:
>>  
>>
>>> I've tried to come up with one, but it seems silly to me that an admin
>>> would give a right to world without knowing exactly what that meant.
>>>   
>>
>>
>> With ACL, we commonly have a situation that looks like this on our public
>> folders:
>>
>> anyone rls
>> -anonymous s
>>
>> Obviously with ACL2 you can do this like this instead:
>>
>> anyone rl
>> authuser s
>>
>> However, for backwards compatiblity with ACL, this sort of thing becomes
>> pretty hairy.
>>
>> Actually, I'm not sure how to easily do bacwards compatibility with 
>> ACL in
>> this situation given the current spec, where anyone and anonymous are the
>> same.
>>
> Larry was the one who suggested this (unless I've misread him). I have 
> no strong opinion on this.

I think you misread him.  I think what Larry meant (and Rob and I would 
like) is:

"anonymous" - special identifer that refers to all users authenticated
          as the anonymous identity
"authuser" - special identifier that refers to all authenticated users,
          excluding anonymous.
"anyone" - special identifier that refers to the universal identity
          (all authentications, including anonymous).

In other words "anyone" = "anonymous" + "authuser"

-- 
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: Fri, 12 Sep 2003 10:28:10 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Alexey Melnikov wrote:

> >Actually, I'm not sure how to easily do bacwards compatibility with ACL in
> >this situation given the current spec, where anyone and anonymous are the
> >same.
> >
> Larry was the one who suggested this (unless I've misread him). I have
> no strong opinion on this.

I think its possible to be backwards compatible in the current form (see
my previous message).  I just think it feels burdensome.  I'd prefer
anonymous and anyone to not be synonyms, but I'm not going to stand in the
way of a steam roller if the WG disagrees.

> >(if the decision is 'don't implement both ACL and ACL2').
> >
> At least my intention was to allow them to be compatible (probably
> except for the 'x' right).

Good.

-Rob

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

Date: Fri, 12 Sep 2003 15:23:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

Rob Siemborski wrote:

>On Fri, 12 Sep 2003, Michael Fair wrote:
>  
>
>>I've tried to come up with one, but it seems silly to me that an admin
>>would give a right to world without knowing exactly what that meant.
>>    
>>
>
>With ACL, we commonly have a situation that looks like this on our public
>folders:
>
>anyone rls
>-anonymous s
>
>Obviously with ACL2 you can do this like this instead:
>
>anyone rl
>authuser s
>
>However, for backwards compatiblity with ACL, this sort of thing becomes
>pretty hairy.
>
>Actually, I'm not sure how to easily do bacwards compatibility with ACL in
>this situation given the current spec, where anyone and anonymous are the
>same.
>
Larry was the one who suggested this (unless I've misread him). I have 
no strong opinion on this.

>  I'm not even really sure how to do upgrades in an automated fashion
>(if the decision is 'don't implement both ACL and ACL2').
>
At least my intention was to allow them to be compatible (probably 
except for the 'x' right).

Alexey

Date: Fri, 12 Sep 2003 10:21:01 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Rob Siemborski wrote:

> Actually, I'm not sure how to easily do bacwards compatibility with ACL in
> this situation given the current spec, where anyone and anonymous are the
> same.  I'm not even really sure how to do upgrades in an automated fashion
> (if the decision is 'don't implement both ACL and ACL2').

Nevermind, I've not had my coffee this morning apparently.

I don't think there's actually a problem here:

ACL:
 anyone rls
ACL2:
 anyone rls

ACL:
 anyone rls
 -anonymous s
ACL2:
 anyone rl
 authuser s

ACL:
 anymous rli
 anyone l
ACL2:
 anyone rli
 -authuser ri

So, while pretty bizarre looking, its doable (I think this is the only
affected case).

-Rob

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

Date: Fri, 12 Sep 2003 10:08:25 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Michael Fair wrote:

> I've tried to come up with one, but it seems silly to me that an admin
> would give a right to world without knowing exactly what that meant.

With ACL, we commonly have a situation that looks like this on our public
folders:

anyone rls
-anonymous s

Obviously with ACL2 you can do this like this instead:

anyone rl
authuser s

However, for backwards compatiblity with ACL, this sort of thing becomes
pretty hairy.

Actually, I'm not sure how to easily do bacwards compatibility with ACL in
this situation given the current spec, where anyone and anonymous are the
same.  I'm not even really sure how to do upgrades in an automated fashion
(if the decision is 'don't implement both ACL and ACL2').

-Rob

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

Date: Fri, 12 Sep 2003 10:03:45 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Michael Fair <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Thu, 11 Sep 2003, Mark Crispin wrote:

> Adding "negative negative rights" would make it possible to implement the
> functionality of MOST-SPECIFIC in UNION and thus allow the removal of
> MOST-SPECIFIC.  But I think that the result would be even more complex
> and harder to implement than ACL2 is now.

I agree.  This level of complexity is unnecessary and will only make this
spec harder to implement, something we definately do not need (especially
given the recent change it underwent).

-Rob

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

From: Arnt Gulbrandsen <[email-masked]>
To: Michael Fair <[email-masked]>
Subject: Re: ACL2 rules
Cc: IMAP List <[email-masked]>
Date: Fri, 12 Sep 2003 11:01:02 +0200
Sender: [email-masked]

Michael Fair writes:
> Has anyone in the camp that thinks it's important to disallow rights 
> granted to group/world for user/group given a valid/useful use case?

The classic UNIX example is the "noprint" group: Everyone has execute 
access ti lpr except group "noprint". Thus, ten thousand students can 
print, except the dozen-odd who have gravely abused the printers in the 
past and have been added to group "noprint".

With a little thought, I'm sure I could construct a similar case with 
mail... but I'd rather do some work.

--Arnt

From: "Michael Fair" <[email-masked]>
To: "IMAP List" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 00:48:56 -0700
Organization: DaClubhouse
Sender: [email-masked]

> If you have inheritance without negative rights, then you have the sort of
> situation typified by the TOPS-20 filesystem, in which owner could not be
> denied rights given to group or world, and group could not be denied
> rights given to world.
> 
> For whatever reason, some people think that it's important to be able to
> deny rights to a specific user that were given to group or world, or deny
> rights to a specific group that were given to world.  The UNIX filesystem
> offers this, but does not use inheritance (MOST-SPECIFIC) so negative
> rights are moot.

Thanks for the description.

As it stands, I think I'm more in the TOPS-20 camp.

Has anyone in the camp that thinks it's important to disallow rights
granted to group/world for user/group given a valid/useful use case?

I've tried to come up with one, but it seems silly to me that an admin
would give a right to world without knowing exactly what that meant.

With all due respect to the contributors here, as I think some very 
elegant and wonderful things come out of this group, on this issue
it seems strange that people would advocate an end user saying 
something like:
"Oh wait I can't do that as me, I have to go become anonymous to do that"

I'll admit I don't deal with ACLs a whole lot... 
If someone can provide a valid/useful case where this becomes important
I'd love to see it.

-- Michael --

Date: Thu, 11 Sep 2003 23:45:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Thu, 11 Sep 2003, Michael Fair wrote:
> If a user is a member
> of two groups, then they should have the positive rights of both groups

Most people agree on this point.  The problem is whether a user's
membership in a group should cause the group's rights to add or subtract
from the user's rights in the case where the user has explicit (not
implied) rights.

Inheritance combined with negative rights makes things quite difficult.

> Perhaps I just don't understand why negative rights are considered
> more important.

If you have inheritance without negative rights, then you have the sort of
situation typified by the TOPS-20 filesystem, in which owner could not be
denied rights given to group or world, and group could not be denied
rights given to world.

For whatever reason, some people think that it's important to be able to
deny rights to a specific user that were given to group or world, or deny
rights to a specific group that were given to world.  The UNIX filesystem
offers this, but does not use inheritance (MOST-SPECIFIC) so negative
rights are moot.

ACL tries to have both inheritance *and* the provision to deny rights that
would otherwise be inherited.  Negative rights are how ACL does this, but
this then leads to the problem that there is no way to disinherit a
negative right (the way a negative right disinherits a right).

There are two ways of punting on the question, both involving not
implementing negative rights.  One is to use MOST-SPECIFIC (punting on
inheritance) ala UNIX; the other is to use UNION but not offer negative
rights (punting on not being able to deny inherited rights) ala TOPS-20.
Either one of these are, to my mind, simpler and more flexible than the
Byzantine complexity of inheritance plus negative rights; but some people
want the complexity so that's why ACL2 is the way it is.

Adding "negative negative rights" would make it possible to implement the
functionality of MOST-SPECIFIC in UNION and thus allow the removal of
MOST-SPECIFIC.  But I think that the result would be even more complex
and harder to implement than ACL2 is now.

-- Mark --

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

From: "Michael Fair" <[email-masked]>
Cc: "IMAP List" <[email-masked]>
Subject: Re: ACL2 rules
Date: Thu, 11 Sep 2003 21:13:43 -0700
Organization: DaClubhouse
Sender: [email-masked]

> However, this is a religious argument and I doubt we'll ever reach
> concensus.

Agreed on the consensus bit.

Out of curiousity and in an attempt to learn something, why would group1 
rights have any impact on group2 rights at all?  If a user is a member
of two groups, then they should have the positive rights of both groups
and it's an admins responsibility to make sure the groups and users all
match up with what they are trying to accomplish...

I don't want to rehash any flame wars, I'm just trying to understand
the logic.

When does "UNION" make sense?
It seems to me that either positive rights should always be favored or
make processing order significant and go with the first positive
or negative right encountered.

It also seems that +r UNION +r UNION -r = -r is just a bad algorithm
(even if there weren't two +r's).

Perhaps I just don't understand why negative rights are considered 
more important.

-- Michael --

Date: Thu, 11 Sep 2003 20:24:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Timo Sirainen wrote:
> If I set rules:
> user=user "rw"
> group=group1 "r"
> -group=group2 "r"
> and user belongs to both groups, UNION rule would give user only "w"
> access, right?

Yes.  This is why I lobbied so hard for a choice other than UNION.

> It could be better if user rights would always override
> group rights,

Yes!

> but in some situations it could be better if they didn't
> (eg. temporarily drop rights).

That is why there is both UNION and MOST-SPECIFIC in the specification.

> Maybe there should be rule-specific option to specify if negative rule
> overrides more specific non-negative rules?
> Now, if we have that, we don't actually really need the MOST-SPECIFIC
> rule at all

True, but IMHO MOST-SPECIFIC is better since it is unambiguous for a
client what a listed user's rights are.  If we have
	user=fred "r"
it is surprising to most people to find that fred has "w" rights because
of inheritance from a group.

However, this is a religious argument and I doubt we'll ever reach
concensus.

-- Mark --

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

Date: Fri, 12 Sep 2003 05:31:54 +0300
Subject: ACL2 rules
From: Timo Sirainen <[email-masked]>
To: IMAP List <[email-masked]>
Sender: [email-masked]

If I set rules:

user=user "rw"
group=group1 "r"
-group=group2 "r"

and user belongs to both groups, UNION rule would give user only "w" 
access, right? It could be better if user rights would always override 
group rights, but in some situations it could be better if they didn't 
(eg. temporarily drop rights).

Maybe there should be rule-specific option to specify if negative rule 
overrides more specific non-negative rules? Such as --group=group2 "r" 
would mean that it's a negative non-overriding rule. I think better 
would be to default to non-overriding rules, but maybe there are some 
backwards compatibility issues?

Now, if we have that, we don't actually really need the MOST-SPECIFIC 
rule at all :) It would rather be just a hint to client, just as there 
would be hints for max. number of users/groups.

The difference is that the rule parsing would always be the same for 
client no matter how the server works. UNIX mode 0642 mailbox would be 
just shown as having rules:

user=user "rw"
group=group1 "r"
--group=group1 "w"
other "w"

If client then changes user's ACL to just "r", it would implicitly add 
-user=user "w" rule.

Date: Tue, 9 Sep 2003 16:04:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-melnikov-imap-keywords-02.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

Some comments after a review:

I believe that $Work and $Personal, while undoubtably useful for a human
user, are *not* needed by an MUA and therefore do not belong in this
document.  I do not see how "Work" and "Personal" are of such importance
that they need to be in the registry, and not "Family", "Party",
"Meeting", "Flames", "Bugs", "Politics", "Orders", "Memos", "Notice", etc.

Eliminating $Work and $Personal as registered flags eliminates three silly
states.  Anyway, who is to say that a message can't be both work and
personal related, or that it may not also be junk?

I'm not reconciled to $Important either.  There is a tendency in this
group to say "oh, such-and-such isn't used right by some implementations,
lets create a whole new mechanism."  This tendency should be resisted.

$AutoMaybeJunk is unnecessary and IMHO harmful due to the creation of
silly states.  There are four states, therefore only two keywords are
necessary:
 1) not autoprocessed
 2) auto junk
 3) auto not junk
 4) auto indeterminate
State (4) can be achieved by lighting both the state (2) and (3) flags.
This has another advantage in that it removes the possibility of a silly
state.  With $AutoMaybeJunk, there are four(!!) silly states.

$Junk and $NoJunk together is currently a silly state, and defined as an
error.  It should instead mean that auto-junk processing is *NOT* to take
place on this message, and the message is *NOT* to be considered in
training auto-junk processing.

Recommendations:

Remove all silly states (which the document calls "mutually exclusive").
Silly states are a wart on the face of IMAP, should never have been
allowed to happen where they did, and vigorous efforts should be
undertaken to prohibit new ones from coming into being.

Add $Junk, $NotJunk, $AutoJunk, $AutoNotJunk, with semantics modified as
proposed in this message so that there are no silly states.

Add $Forwarded and $ShouldReply since MUAs use these.

Remove $Work, $Personal.  These are human keywords, not MUA keywords.

Possibly retain $Important but stress that \Flagged should be used
instead.

-- Mark --

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

Date: Thu, 4 Sep 2003 08:14:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: CAPABILITYPLUS
Sender: [email-masked]

On Thu, 4 Sep 2003, Paul Smith wrote:
> Binary protocols are so much harder to debug IME. It is good to be
> able to telnet to a server and type in commands manually and get responses
> back, rather than having to write test programs/scripts to generate the
> binary for you.

This goes without saying.  I wouldn't even think of replacing text-based
IMAP with a binary protocol.  Any binary compressed version of IMAP would
have to be completely parallel to non-compressed IMAP.

Personally, I don't think that compression at the IMAP level (as opposed
to transport layer compression) is necessary.  I'm simply offering it as a
possible alternative.

> Also, having a 'standard' set of abbreviations it's not hard to imagine a
> server which could transparently understand both 'chatty' IMAP and 'terse'
> IMAP (it could even switch between both in the same session).

That also goes without saying.

> To increase
> efficiency, having an abbreviated FETCH response (for instance) would be
> much more useful.

Yup.  FETCH is what really needs a compressed form.

-- Mark --

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

Date: Thu, 04 Sep 2003 09:45:48 +0100
To: IMAP Extensions WG <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: CAPABILITYPLUS
Sender: [email-masked]

At 17:08 03/09/2003 -0700, Mark Crispin wrote:

>IMAP is a very chatty protocol, and CAPABILITY is a very chatty command.
>We're talking about a new command to make CAPABILITY a little less chatty,
>instead of addressing the overall chattiness.
>
>I think that a preferable option would be to have a means to "compress"
>IMAP.  It could be either abbreviated text or even binary.  The capability
>list could be a bitstream in which all IANA-registered capabilities are in
>a well-known position and only unregistered capabilities are listed by
>name.  It isn't difficult to imagine other compressions.

If you were to compress IMAP, I'd be happy with an abbreviated text version 
(eg 'S' for 'SELECT', 'F' for 'FETCH' etc), but not really with a binary 
one. Binary protocols are so much harder to debug IME. It is good to be 
able to telnet to a server and type in commands manually and get responses 
back, rather than having to write test programs/scripts to generate the 
binary for you. (We always find it much easier to test/debug text protocols 
like SMTP, POP3, IMAP etc than it is to test binary protocols like LDAP etc)

Also, having a 'standard' set of abbreviations it's not hard to imagine a 
server which could transparently understand both 'chatty' IMAP and 'terse' 
IMAP (it could even switch between both in the same session). If you get 
into binary protocols it starts getting harder to have the same server 
doing both

If you want a 'binary' capability list, I'm sure there's a way you could 
come up with a text version (eg using a string of letters/digits, where 
each letter indicates a capability (that gives you 62 possible capabilities 
easily)). But, as you say, it's only done once or twice. To increase 
efficiency, having an abbreviated FETCH response (for instance) would be 
much more useful.

JM2P

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: Capability balooning and restructuring
Date: Thu, 4 Sep 2003 00:41:36 -0700
Lines: 126
Sender: [email-masked]

Sorry to reply to my own post, but I just realized
that I forgot to credit where the ideas came from.

Nothing in this email was an original idea, I meant
to draw attention to the constantly contradicting
goals when modifying CAPABILITY comes up and that it
appears we will remain caught in this endless cycle
until a conclusion is drawn on the direction to go.
Sacrifice bandwidth, or Round Trips I don't think the
group will ever be able to consolidate on a solution
that gives us both.

The examples I used were drawn from CAPABILITYPLUS,
Mark's last email, and other conversations from months
ago in regards to VHOST and LANG.

I apologize if I offended anyone by repeating suggestions
that have already been made and making them look like
my own, I didn't mean to do that.

-- Michael --

"Michael Fair" <[email-masked]> wrote in message
news:[email-masked]...
>
> This CAPABILTIY changing discussion is a painful
> recurring them on this list.
>
> I remember a number of things impacting the CAPABILITY
> line that meant more and more round trips for a client
> to get a session established wasn't desirable to the
> clients, but the WG preferred to add discrete commands
> rather than a client capability line.
>
> Virtual domain changes, TLS, and authentication are
> three round trips that I distinctly remember.
>
> At the time the response was more of a "they should
> remain their own commands, and we should find a way
> to reduce round trip requests" but I never saw any
> concrete suggestions after that nor do I have any
> myself.
>
> Now we're talking about adding even more distinct
> items to CAPABILITY to support LISTEXT.
>
> I can't think of a way to meet all the goals at the
> same time.
>
> And with this latest suggestion that addressing CAPABILITYPLUS
> is also the wrong way to go, I'm wondering what the basis
> is on how it should get decided?
>
> Compressing CAPABILITY to binary kills any telnet debugging
> possibilities which I've used on several occasions, how
> important is text debugging in the decision?
>
> Reducing round trips means being able to combine more
> commands into a single trip, but it makes the CAPABILITY
> command larger and more complicated.
>
> The more optional features added to the protocol means the
> more that is needed to tell the client....  Currently
> CAPABILITY is the only thing there is to give this kind
> of feedback...
>
> Perhaps the various LISTEXT responses should be shoved off
> into there own query command and just LISTEXT, to tell the
> client that it should go look there, should appear in the
> CAPABILITY response itself.
>
>
> Overall it just seems that this WG has conflicting goals
> depending on how important the feature is to the people
> recommending it and the WG doesn't have a clear concensus
> on what CAPABILITY should be.
>
> The fact that questions regarding "What is the goal" usually
> receive silence as a response tells me that the members of
> the list don't really know what the answer is for certain.
>
> It seems to me that this issue has got enough merit behind it
> and comes up often enough that a structure should be worked
> on to address the "ballooning" of the CAPABILITY response and
> the client round trip times.  My first thoughts are that
> CAPABILITY as it was originally intended, has outgrown
> its usefulness and needs to be yanked and replaced with a new
> methodology, but I don't think that's going to work.
>
> Things that are important to different people are going to
> want to go in that CAPABILITY response and I think "the people
> with the weightiest voices" wins is a bad way to decide what
> goes in and what doesn't.
>
> I see the CAPABILITY line only getting larger in the future
> and thus I see no end in sight to the "how big is too big"
> discussions.  I don't think compression is a good answer
> as clarity has always seemed to be a goal for the WG.
>
>
> In general the WG has been more in favor of adding more
> targetted individual commands than making a more complicated
> CAPABILITY command.  This was the general result of the VHOST
> command, and the LANG command.  So I'm pulling from possibly
> reusing that general strategy to move forward.
>
>
> Perhaps CAPABILITY turns into a QUERY request, where the
> client submits to the server everything it would like to
> try and use and the server responds with what in that
> list the current state supports?  This way instead of
> just dumping every possible feature any client could ever
> want on the wire, the protocol only passes back and forth
> what the client can actually use...
>
> This smells a lot like a "Client Capability" line which
> has been frowned upon in the past...  Is that still the case?
>
> -- Michael --
>
>
>
>

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Capability balooning and restructuring
Date: Wed, 3 Sep 2003 20:38:05 -0700
Lines: 96
Sender: [email-masked]

This CAPABILTIY changing discussion is a painful
recurring them on this list.

I remember a number of things impacting the CAPABILITY
line that meant more and more round trips for a client
to get a session established wasn't desirable to the
clients, but the WG preferred to add discrete commands
rather than a client capability line.

Virtual domain changes, TLS, and authentication are
three round trips that I distinctly remember.

At the time the response was more of a "they should
remain their own commands, and we should find a way
to reduce round trip requests" but I never saw any
concrete suggestions after that nor do I have any
myself.

Now we're talking about adding even more distinct
items to CAPABILITY to support LISTEXT.

I can't think of a way to meet all the goals at the
same time.

And with this latest suggestion that addressing CAPABILITYPLUS
is also the wrong way to go, I'm wondering what the basis
is on how it should get decided?

Compressing CAPABILITY to binary kills any telnet debugging
possibilities which I've used on several occasions, how
important is text debugging in the decision?

Reducing round trips means being able to combine more
commands into a single trip, but it makes the CAPABILITY
command larger and more complicated.

The more optional features added to the protocol means the
more that is needed to tell the client....  Currently
CAPABILITY is the only thing there is to give this kind
of feedback...

Perhaps the various LISTEXT responses should be shoved off
into there own query command and just LISTEXT, to tell the
client that it should go look there, should appear in the
CAPABILITY response itself.

Overall it just seems that this WG has conflicting goals
depending on how important the feature is to the people
recommending it and the WG doesn't have a clear concensus
on what CAPABILITY should be.

The fact that questions regarding "What is the goal" usually
receive silence as a response tells me that the members of
the list don't really know what the answer is for certain.

It seems to me that this issue has got enough merit behind it
and comes up often enough that a structure should be worked
on to address the "ballooning" of the CAPABILITY response and
the client round trip times.  My first thoughts are that
CAPABILITY as it was originally intended, has outgrown
its usefulness and needs to be yanked and replaced with a new
methodology, but I don't think that's going to work.

Things that are important to different people are going to
want to go in that CAPABILITY response and I think "the people
with the weightiest voices" wins is a bad way to decide what
goes in and what doesn't.

I see the CAPABILITY line only getting larger in the future
and thus I see no end in sight to the "how big is too big"
discussions.  I don't think compression is a good answer
as clarity has always seemed to be a goal for the WG.

In general the WG has been more in favor of adding more
targetted individual commands than making a more complicated
CAPABILITY command.  This was the general result of the VHOST
command, and the LANG command.  So I'm pulling from possibly
reusing that general strategy to move forward.

Perhaps CAPABILITY turns into a QUERY request, where the
client submits to the server everything it would like to
try and use and the server responds with what in that
list the current state supports?  This way instead of
just dumping every possible feature any client could ever
want on the wire, the protocol only passes back and forth
what the client can actually use...

This smells a lot like a "Client Capability" line which
has been frowned upon in the past...  Is that still the case?

-- Michael --

Date: Wed, 3 Sep 2003 17:08:29 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: CAPABILITYPLUS
Organization: Networks & Distributed Computing
Sender: [email-masked]

Although CAPABILITYPLUS sounds like a good idea, I'm concerned that we may
be solving the wrong problem.

IMAP is a very chatty protocol, and CAPABILITY is a very chatty command.
We're talking about a new command to make CAPABILITY a little less chatty,
instead of addressing the overall chattiness.

I think that a preferable option would be to have a means to "compress"
IMAP.  It could be either abbreviated text or even binary.  The capability
list could be a bitstream in which all IANA-registered capabilities are in
a well-known position and only unregistered capabilities are listed by
name.  It isn't difficult to imagine other compressions.

In the case of CAPABILITY, I don't think that it matters much.  A
CAPABILITY command is only done once or twice in a session, not enough to
effect the overall scheme of things.  Certainly LISTEXT won't do so; it
isn't as if we will have thousands of LISTEXT options.

Speaking of which, the more that I think about it, the more that I believe
that it is essential that a capability for LISTEXT options be all or none.
That is, either *every* LISTEXT option is mandatory to implement if the
server advertises the LISTEXT capability, or that *every* LISTEXT option
have its own capability.

That is, I advocate one of the following:

1) Add LIST=SUBSCRIBED, LIST=REMOTE, and LIST=CHILDREN capabilities.
Make CHILDREN optional to implement.

2) Add LISTEXT capability.  Make SUBSCRIBED, REMOTE, and CHILDREN
mandatory to implement.  Support for CHILDREN is no longer optional, and
RFC 3348 is deprecated.

I do not object to mandatory-to-implement.  SUBSCRIBED should be easy
enough, as long as it can be done as an LSUB that does an internal LIST.
CHILDREN is alright too, as long as the client is required to ask for it
explicitly (as opposed to RFC 3348's implicit action).

-- Mark --

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

Date: Wed, 3 Sep 2003 15:05:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 3 Sep 2003, Arnt Gulbrandsen wrote:
> > At most two RTTs for a client that wants "everything"; done to get the
> > base capabilities, one for the desired expansions.
> If CAPABILITYPLUS mandates a [CAPABILITY ...] in the banner OK response,
> clients expend at most one RTT to get everything they want.

Exactly.

-- Mark --

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

Date: Wed, 3 Sep 2003 15:06:34 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

> «IMAP4 servers that support this extension MUST include a CHANNEL
> capability response in the response list to the CAPABILITY command.
> This entry indicates the server supports the extension, and lists the
> schemes available to the CHANNEL command. The capability response
> consists of the string "CHANNEL=" followed by a list of schemes
> supported by the CHANNEL extension.»

As has been pointed out, this doesn't work. I'm changing Channel to
advertise "Channel" as the capability, and will add a new command for
discovering the list of supported schemes.

--lyndon

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: LISTEXT capabilities
Cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 3 Sep 2003 21:23:44 +0200
Sender: [email-masked]

Mark Crispin writes:
> At most two RTTs for a client that wants "everything"; done to get the 
> base capabilities, one for the desired expansions.

If CAPABILITYPLUS mandates a [CAPABILITY ...] in the banner OK response, 
clients expend at most one RTT to get everything they want.

--Arnt

Date: Wed, 3 Sep 2003 13:17:22 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

> The latter, LIST=FOO,BAR, requires more intelligence in the parser,
> which generates new error situations -- e.g., is LIST=FOO,,BAR ok?

Sorry, I meant LIST=FOO LIST=BAR, not LIST=A,B,C.

--lyndon

Date: Wed, 03 Sep 2003 13:43:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Mark,

--On Wednesday, September 03, 2003 9:47 AM -0700 Mark Crispin 
<[email-masked]> wrote:

| Everybody is going to do a CAPABILITY without any arguments, so it seems
| pointless to have an extra command to get the "short" version after you've
| already gotten the "long" version.
|
| At most two RTTs for a client that wants "everything"; done to get the
| base capabilities, one for the desired expansions.

I actually want to be able to have one RTT to get a version of the full 
capabilites with some of them (the ones I care about) expanded. So how 
about allowing capability with arguments to have the option of a '%' 
argument that means return all the non-expandable capabilities as well.

i.e. if my client only cares about expanded LISTEXT I could do:

a CAPABILITY (% LISTEXT)

as the one and only capability command to get all I want in one RTT.

-- 
Cyrus Daboo

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: LISTEXT capabilities
Cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 3 Sep 2003 19:06:02 +0200
Sender: [email-masked]

Mark Crispin writes:
> I propose something much simpler:
>
> CAPABILITY (without any arguments) and auto-capability: return base 
> capabilities using "*" prefix for those that can be enumerated.
>
> CAPABILITY (with arguments) - return enumerated capabilities for those 
> listed in argument list. Don't list other capabilities.

Sounds good (through a haze of jetlag at least)... I assume the OK 
[CAPABILITY ...] response always uses *, then?

--Arnt

Date: Wed, 3 Sep 2003 09:47:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

I propose something much simpler:

CAPABILITY (without any arguments) and auto-capability: return base
capabilities using "*" prefix for those that can be enumerated.

CAPABILITY (with arguments) - return enumerated capabilities for those
listed in argument list.  Don't list other capabilities.

Rationale:

Everybody is going to do a CAPABILITY without any arguments, so it seems
pointless to have an extra command to get the "short" version after you've
already gotten the "long" version.

At most two RTTs for a client that wants "everything"; done to get the
base capabilities, one for the desired expansions.

-- Mark --

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

Date: Wed, 03 Sep 2003 12:16:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Mark,

--On Wednesday, September 3, 2003 9:05 -0700 Mark Crispin 
<[email-masked]> wrote:

| CAPABILITYPLUS can not encompass AUTH, since that would force an extra RTT
| at session startup as clients need to learn which mechanisms they use to
| authenticate (and at startup that's the only thing they really need).
|
| It's also too late (by 5 years or so) to do this for THREAD, although
| THREAD is an obvious candidate for this.
|
| We can do this for new extensions such as LISTEXT and ACL.

Agreed to the above.

| We don't need a new CAPABILITYPLUS command; the CAPABILITYPLUS extension
| can expand the CAPABILITY command.  I also think that CAPABILITYPLUS
| should be the expanded version and not the other way around; don't forget
| auto-capability announcement.
|
| Perhaps we can indicate that a capability has an expansion by prefixing it
| with a well-known character such as "*"?  Since these are new
| capabilities, it's alright to have *ACL2, *LISTEXT, etc.

OK - sounds good. So we can have the following for CAPABILITLYPLUS:

CAPABILITY (without any arguments) - return the fully enumerated 
capabilities.

CAPABILITY (with empty parenthesized argument set) - return base 
capabilities using '*' prefix for those that can be enumerated.

CAPABILITY (with parenthesized  arguments) - return enumerated capabilities 
for those listed in argument list, base capabilities for others. 
Unrecognized arguments are ignored.

-- 
Cyrus Daboo

Date: Wed, 3 Sep 2003 09:05:16 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

CAPABILITYPLUS can not encompass AUTH, since that would force an extra RTT
at session startup as clients need to learn which mechanisms they use to
authenticate (and at startup that's the only thing they really need).

It's also too late (by 5 years or so) to do this for THREAD, although
THREAD is an obvious candidate for this.

We can do this for new extensions such as LISTEXT and ACL.

We don't need a new CAPABILITYPLUS command; the CAPABILITYPLUS extension
can expand the CAPABILITY command.  I also think that CAPABILITYPLUS
should be the expanded version and not the other way around; don't forget
auto-capability announcement.

Perhaps we can indicate that a capability has an expansion by prefixing it
with a well-known character such as "*"?  Since these are new
capabilities, it's alright to have *ACL2, *LISTEXT, etc.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:55:55 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

On Wed, 3 Sep 2003, Ken Murchison wrote:
> With regards to the discussion of the CAPABILITY response getting too
> large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in
> the CAPABILITY response, and use a modified LIST command to get the
> available LISTEXT keywords
> . LIST () "" ""
> * LIST (SUBSCRIBED CHILDREN) "." ""

I like this idea.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:47:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

On Wed, 3 Sep 2003, Arnt Gulbrandsen wrote:
> Ken Murchison writes:
> > By my reading of the drafts (00 - 04), CHILDREN is part o fthe base
> > LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a
> > valid option.
> I see what you mean, but that seems a little too subtle. Expecting J.
> Random Client Author to get that one right seems like stretching it.

This has been my concern all along.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:45:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Simon Josefsson <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

On Wed, 3 Sep 2003, Alexey Melnikov wrote:
> I am afraid you will have to modify your code. There will be more
> extensions coming that will use some kind of prefix.

I agree.  SORT and THREAD also do this.

-- Mark --

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

Date: Wed, 03 Sep 2003 11:21:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Ken,

--On Wednesday, September 3, 2003 9:39 -0400 Ken Murchison <[email-masked]> 
wrote:

| With regards to the discussion of the CAPABILITY response getting too
| large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in
| the CAPABILITY response, and use a modified LIST command to get the
| available LISTEXT keywords, eg:

That does not address other extensions which may need something similar 
(e.g. LANGUAGE has a command mode to enumerate available languages, 
separate from the capability response). Having a mode of each new command 
that is used to enumerate its options leads to more roundtrips etc - I did 
propose something like that with the ACLMODEL response, but I think a 
better solution can be achieved:

Here's an alternative using a new capability behaviour.

We have a new CAPABILITYPLUS extension: a server that supports this returns 
it as part of the initial greeting string CAPABILITY response.

A client can then use a 'CAPABILITYPLUS' command with or without arguments 
in the following manner:

1) Without arguments: the capability response lists the 'base' extension 
capabilities, e.g. 'AUTH' 'LISTEXT', 'ACL2', 'THREAD', 'SORT', etc without 
any '=XXX' enumerations.

a CAPABILITYPLUS
* CAPABILITY IMAP4rev1 AUTH STARTTLS UIDPLUS NAMESPACE LISTEXT THREAD ACL2 
LANGUAGE
a OK

2) With arguments: arguments are 'base' extension names. If the server 
supports one of the listed base extensions it returns the full enumeration 
of options for that base extension, in addition to all the others it would 
normally return. If it does not support the base extension, it ignores the 
argument. e.g.

a CAPABILITYPLUS AUTH LISTEXT THREAD FOOBAR ACL2 LANGUAGE
* CAPABILITY IMAP4rev1 AUTH=PLAIN STARTTLS UIDPLUS ACL2 NAMESPACE 
LISTEXT=CHILDREN LISTEXT=ACL THREAD=ORDEREDSUBJECT THREAD=REFERENCES 
LANGUAGE
* ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a")
* ACLMODEL "model2" "UNION" "*u *g" ("lr" "switextd" "p" "a")
* ACLMODEL "model3" "UNION" "*u *g" NIL
* LANGUAGE (EN DE IT i-default)
a OK

Note that in the above example the presence of ACL2 and LANGUAGE results in 
implicit ACLMODEL and LANGUAGE responses enumerating the more detailed 
capabilities of those extensions.

The original CAPABILITY command would still be present and would list the 
entire set of detailed capabilities as it does now - with all the bloat.

The benefit of a new capability mechanism like this is that clients that 
are aware of specific extensions can request more detail about those 
extensions, and those that don't care will not get back a bloated 
capability response. It can also reduce the number of round trips to get 
more detailed capabilities of specific extensions such as ACL2 and LANGUAGE.

We could of course do more with an extended capability command - such as 
introduce client switches (e.g. turn on UTF8 support in the server etc).

So if people are worried about capability bloat, this might be one way to 
address it.

-- 
Cyrus Daboo

Date: Wed, 03 Sep 2003 16:01:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Simon Josefsson wrote:

>Arnt Gulbrandsen <[email-masked]> writes:
>  
>
>>Only a language lawyer can find a way to make that cohabit with other
>>use of the prefix, so I'd say that for all practical purposes the
>>prefix is reserved.
>>    
>>
>
>The problem isn't purely academic -- there are IMAP libraries designed
>around the text in RFC 3501 (and earlier) on CAPABILITY names.
>Specifically: one of my IMAP APIs only allow applications to query if
>capability X is supported by the server.  If now IMAP extensions are
>allowed to allocate an entire CAPABILITY prefix, I'll have to modify
>my API to support this.  I'd prefer not to do this, of course, unless
>there is a really good reason for it.  Sticking to what RFC 3501 said
>would be better.
>
I am afraid you will have to modify your code. There will be more 
extensions coming that will use some kind of prefix.

Alexey

To: Arnt Gulbrandsen <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 16:28:52 +0200
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Only a language lawyer can find a way to make that cohabit with other
> use of the prefix, so I'd say that for all practical purposes the
> prefix is reserved.

The problem isn't purely academic -- there are IMAP libraries designed
around the text in RFC 3501 (and earlier) on CAPABILITY names.
Specifically: one of my IMAP APIs only allow applications to query if
capability X is supported by the server.  If now IMAP extensions are
allowed to allocate an entire CAPABILITY prefix, I'll have to modify
my API to support this.  I'd prefer not to do this, of course, unless
there is a really good reason for it.  Sticking to what RFC 3501 said
would be better.

Date: Wed, 03 Sep 2003 09:39:21 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
Subject: LISTEXT capabilities
Sender: [email-masked]

With regards to the discussion of the CAPABILITY response getting too 
large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in 
the CAPABILITY response, and use a modified LIST command to get the 
available LISTEXT keywords, eg:

. LIST () "" ""
* LIST (SUBSCRIBED CHILDREN) "." ""

We simply replace the flags that would normally be returned in the 
hierarchy separator query (which are meaningless in this case anyways), 
with the supported LISTEXT keywords.

-- 
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: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 15:27:23 +0200
Sender: [email-masked]

Simon Josefsson writes:
> Arnt Gulbrandsen <[email-masked]> writes:
>> 2. Then there's one simple LHS=RHS, where both sides are constant,
>>     such as ACL2=UNION, and LHS= is reserved.
>
> See http://www.iana.org/assignments/imap4-capabilities, none of the 
> officially registered schemes, after a brief examination only, seem 
> to reserve only a part of the CAPABILITY name. The entire CAPABILITY 
> name must be allocated and reserved.

Good point. Never the less, language such as «The QUOTA extension is 
present in any IMAP4rev1 server which advertises any CAPABILITY 
beginning with "QUOTA="» openly conflicts with any other use of the 
prefix "QUOTA=".

>>  4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing
>>     and the LHS= is reserved.
>
> I disagree, for the same reason as in 2.

«IMAP4 servers that support this extension MUST include a CHANNEL 
capability response in the response list to the CAPABILITY command. 
This entry indicates the server supports the extension, and lists the 
schemes available to the CHANNEL command. The capability response 
consists of the string "CHANNEL=" followed by a list of schemes 
supported by the CHANNEL extension.»

Only a language lawyer can find a way to make that cohabit with other 
use of the prefix, so I'd say that for all practical purposes the 
prefix is reserved.

Someone clearly had forgotten 2087.

> The way I read it, you cannot reserve part of a CAPABILITY response 
> (except AUTH= which is documented in the main specification). So all 
> those extensions should register all possible CAPABILITY names they 
> support.

Oh, yes, I forgot AUTH. Sorry. That's another argument that LISTEXT (and 
CHANNEL) should be like AUTH, QUOTA and THREAD.

--Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 15:13:22 +0200
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Simon Josefsson writes:
>> Lyndon Nerenberg <[email-masked]> writes:
>>
>>>  Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?
>>
>> IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better
>> than LIST=FOO,BAR.
>
> Well, it's not quite so simple.
>
> There number of different CAPABILITY schemes is growing, and the
> growth doesn't seem justified. A shortish review:
>
> 1. Many extensions use a single, simple word. ID, SORT and
>    ANNOTATEMORE are examples of this.
>
> 2. Then there's one simple LHS=RHS, where both sides are constant,
>    such as ACL2=UNION, and LHS= is reserved.

See http://www.iana.org/assignments/imap4-capabilities, none of the
officially registered schemes, after a brief examination only, seem to
reserve only a part of the CAPABILITY name.  The entire CAPABILITY
name must be allocated and reserved.

> 3. Then there's n simple LHS=RHS capabilities, as used by QUOTA or
>    THREAD. For example, "QUOTA=RES-STORAGE QUOTA=RES-MESSAGES". Here
>    too, LHS= is reserved.

Not according to RFC 2087 nor the IANA page, and to me it looks like
that would violate RFC 3501, unless both QUOTA=RES-STORAGE and
QUOTA=RES-MESSAGES were allocated with IANA.

> 4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing
>    and the LHS= is reserved.

I disagree, for the same reason as in 2.

> 5. The current LISTEXT draft leaves the impression that the "LIST-" 
> prefix is to be used for list extensions only.
>
> From this list, the most important thing I see is that LISTEXT should
> move in line with the others and reserve LHS= instead of LHS-.
>
> The second is that if LISTEXT and CHANNEL are to use LHS=A,B,C, their
> rules should match perfectly. And that they should use the same
> solution: Either both use commas or neither does.

The way I read it, you cannot reserve part of a CAPABILITY response
(except AUTH= which is documented in the main specification).  So all
those extensions should register all possible CAPABILITY names they
support.

> Ideally, IMO, both LISTEXT and CHANNEL should move into line with
> QUOTA/THREAD.

I agree, although with the possible modification that I think the
entire QUOTA/THREAD CAPABILITY keyword should be registered, no LHS=
reservation is allowed.  Like RFC 2087.

So if a LIST extension want to use variable RHS it could register
LIST=FOO, LIST=BAR, LIST=FOO,BAR, LIST=BAR,FOO.  Of course, if that is
considered ugly (which I would agree with), the IANA registry
pre-conditions should be updated.

Regards,
Simon

From: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 14:51:40 +0200
Sender: [email-masked]

Simon Josefsson writes:
> Lyndon Nerenberg <[email-masked]> writes:
>
>>  Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?
>
> IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better than 
> LIST=FOO,BAR.

Well, it's not quite so simple.

There number of different CAPABILITY schemes is growing, and the growth 
doesn't seem justified. A shortish review:

1. Many extensions use a single, simple word. ID, SORT and ANNOTATEMORE 
are examples of this.

2. Then there's one simple LHS=RHS, where both sides are constant, such 
as ACL2=UNION, and LHS= is reserved.

3. Then there's n simple LHS=RHS capabilities, as used by QUOTA or 
THREAD. For example, "QUOTA=RES-STORAGE QUOTA=RES-MESSAGES". Here too, 
LHS= is reserved.

4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing and 
the LHS= is reserved.

5. The current LISTEXT draft leaves the impression that the "LIST-" 
prefix is to be used for list extensions only.

>From this list, the most important thing I see is that LISTEXT should 
move in line with the others and reserve LHS= instead of LHS-.

The second is that if LISTEXT and CHANNEL are to use LHS=A,B,C, their 
rules should match perfectly. And that they should use the same 
solution: Either both use commas or neither does.

Ideally, IMO, both LISTEXT and CHANNEL should move into line with QUOTA/THREAD.

Does any CHANNEL people read this list?

> The latter, LIST=FOO,BAR, requires more intelligence in the parser,

(I agree with these concerns. I also agree with Mark's (?) concern about 
overly long capability lists.)

--Arnt

To: Lyndon Nerenberg <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 14:18:25 +0200
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

> Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?

IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better than
LIST=FOO,BAR.

The latter, LIST=FOO,BAR, requires more intelligence in the parser,
which generates new error situations -- e.g., is LIST=FOO,,BAR ok?
LIST=,,,FOO?  LIST=FOO=BAZ,BAR?  What should an entity do when a
invalid keyword is present?  Warn about it?  Disconnect?  It is easier
to do a string comparison directly than to first parse it and then do
a string comparison on the parsed result.  The parser step adds
complexity and error conditions, all without an obvious gain.  A
design that lead to error conditions in some situations is worse than
a design that prevent the error condition to ever arise.  Furthermore,
LIST=FOO,BAR requires more text in a specification, and longer ABNF
rules to specify the right-hand part of LIST=VALUES.  I think we all
know that more text, and longer ABNF, leads to higher risk of errors
and confusion.

Date: Wed, 3 Sep 2003 04:12:48 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?

--lyndon (who prefers '=' but is mostly just curious)

Date: Wed, 03 Sep 2003 10:50:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Mark Crispin wrote:

>On Tue, 2 Sep 2003, Arnt Gulbrandsen wrote:
>  
>
>>How would the client know that it can send LIST (CHILDREN), unless by
>>seeing that capability? The latest draft names two capabilities:
>>LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for
>>CHILDREN.
>>    
>>
>
>I agree that LIST-CHILDREN should be there.
>
I am second (third, ...) on this.
Personally, I see no use in CHILDREN, I was able to implement reasonable 
GUI without it.

Alexey

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 11:11:56 +0200
Sender: [email-masked]

Ken Murchison writes:
> By my reading of the drafts (00 - 04), CHILDREN is part o fthe base 
> LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a 
> valid option.

I see what you mean, but that seems a little too subtle. Expecting J. 
Random Client Author to get that one right seems like stretching it.

--Arnt

Date: Tue, 2 Sep 2003 16:55:09 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Pete Maclean wrote:
> > > LIST () "" % should not return it, but for backwards compatibility I
> > > think the old style LIST should return it when it can.
> >Right, that's why it was left there: compatibility with clients that expected
> >a plain LIST to return CHILDREN info.  I agree with the concern, and with the
> >suggested compromise.  Pete & Mark, does that work for you?
> If Mark agrees, then it's fine with me.

I don't think that it's important enough for me to stand in the way, and I
won't.

Nevertheless, it still seems to me that LIST-CHILDREN should be a
capability.  It just seems to be a cleaner (and safer design).

I agree that the current specification will work.

-- Mark --

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

Date: Tue, 02 Sep 2003 19:29:29 -0400
To: "Barry Leiba" <[email-masked]>, "IMAP extensions Mailing List" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

> > LIST () "" % should not return it, but for backwards compatibility I
> > think the old style LIST should return it when it can.
>
>Right, that's why it was left there: compatibility with clients that expected
>a plain LIST to return CHILDREN info.  I agree with the concern, and with the
>suggested compromise.  Pete & Mark, does that work for you?

If Mark agrees, then it's fine with me.

Pete

Date: Tue, 02 Sep 2003 18:04:59 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Mark Crispin wrote:
> On Tue, 2 Sep 2003, Ken Murchison wrote:
> 
>>>I'd prefer some wording to the effect that servers may choose not to have
>>>"old style" list return CHILDREN information, and thus the only reliable
>>>way to get CHILDREN information is to use LISTEXT.
>>
>>All the server has to do is no longer advertise CHILDREN, and then it no
>>longer has to return CHILDREN info for "old style" LIST.
> 
> 
> But doesn't CHILDREN have to be advertised if the server supports it in
> LISTEXT?

By my reading of the drafts (00 - 04), CHILDREN is part o fthe base 
LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a 
valid option.

-- 
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: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 2 Sep 2003 20:56:45 +0200
Sender: [email-masked]

Is it permitted to ask why it's LIST-* instead of LIST=*? IMAP seems to 
lean towards the latter in general.

--Arnt

Date: Tue, 2 Sep 2003 11:51:12 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Arnt Gulbrandsen wrote:
> How would the client know that it can send LIST (CHILDREN), unless by
> seeing that capability? The latest draft names two capabilities:
> LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for
> CHILDREN.

I agree that LIST-CHILDREN should be there.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 2 Sep 2003 20:47:39 +0200
Sender: [email-masked]

Ken Murchison writes:
> All the server has to do is no longer advertise CHILDREN, and then it 
> no longer has to return CHILDREN info for "old style" LIST.

How would the client know that it can send LIST (CHILDREN), unless by 
seeing that capability? The latest draft names two capabilities: 
LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for 
CHILDREN.

--Arnt

Date: Tue, 2 Sep 2003 11:39:11 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Ken Murchison wrote:
> > I'd prefer some wording to the effect that servers may choose not to have
> > "old style" list return CHILDREN information, and thus the only reliable
> > way to get CHILDREN information is to use LISTEXT.
> All the server has to do is no longer advertise CHILDREN, and then it no
> longer has to return CHILDREN info for "old style" LIST.

But doesn't CHILDREN have to be advertised if the server supports it in
LISTEXT?

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 2 Sep 2003 20:31:06 +0200
Sender: [email-masked]

Mark Crispin writes:
> I'd prefer some wording to the effect that servers may choose not to 
> have "old style" list return CHILDREN information, and thus the only 
> reliable way to get CHILDREN information is to use LISTEXT.

That sounds bad to me. If listext and CHILDREN are both present, then a 
client that supports CHILDREN but not listext would be hampered.

If that's desirable, a more honest way would be to provide a 
LIST=CHILDREN that says effectively "the functionality of 3348 is 
present, but not the syntax".

--Arnt

Date: Tue,  2 Sep 2003 14:27:55 -0400
From: Ken Murchison <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Quoting Mark Crispin <[email-masked]>:

> 
> On Tue, 2 Sep 2003, Barry Leiba wrote:
> > > LIST () "" % should not return it, but for backwards compatibility I
> > > think the old style LIST should return it when it can.
> > Right, that's why it was left there: compatibility with clients that
> expected
> > a plain LIST to return CHILDREN info.  I agree with the concern, and with
> the
> > suggested compromise.  Pete & Mark, does that work for you?
> 
> I'd prefer some wording to the effect that servers may choose not to have
> "old style" list return CHILDREN information, and thus the only reliable
> way to get CHILDREN information is to use LISTEXT.

All the server has to do is no longer advertise CHILDREN, and then it no 
longer has to return CHILDREN info for "old style" 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: Tue, 2 Sep 2003 10:55:34 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Barry Leiba wrote:
> > LIST () "" % should not return it, but for backwards compatibility I
> > think the old style LIST should return it when it can.
> Right, that's why it was left there: compatibility with clients that expected
> a plain LIST to return CHILDREN info.  I agree with the concern, and with the
> suggested compromise.  Pete & Mark, does that work for you?

I'd prefer some wording to the effect that servers may choose not to have
"old style" list return CHILDREN information, and thus the only reliable
way to get CHILDREN information is to use LISTEXT.

-- Mark --

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

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 2 Sep 2003 08:10:47 -0400
Sender: [email-masked]

> LIST () "" % should not return it, but for backwards compatibility I 
> think the old style LIST should return it when it can.

Right, that's why it was left there: compatibility with clients that expected
a plain LIST to return CHILDREN info.  I agree with the concern, and with the
suggested compromise.  Pete & Mark, does that work for you?

Barry
--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Arnt Gulbrandsen <[email-masked]>
To: Michael Fair <[email-masked]>
Subject: Re: Capability balooning and restructuring
Cc: IMAP extensions Mailing List <[email-masked]>
Date: Mon, 29 Sep 2003 13:52:08 +0200
Sender: [email-masked]

Michael Fair writes:
> At the time the response was more of a "they should remain their own 
> commands, and we should find a way to reduce round trip requests" but 
> I never saw any concrete suggestions after that nor do I have any 
> myself.

1. More servers should send the CAPABILITY response code in the banner 
OK/PREAUTH (RFC 3501 page 64). Perhaps also in the LOGIN/AUTHENTICATE 
tagged OK.

2. Smart clients can use the lull provided by asking the user for a 
password. Like this:

C: connects
S: OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5]
at this point, the client starts asking its user for a password
C: a starttls
S: a OK
negotiation
C: b authenticate cram-md5
S: + 4327814372483274832
client waits until the user has finished typing the password
C: 47817348927134893217
S: b OK
C: c select inbox
...

The rule that all capabilities disappear when STARTTLS succeeds is a bit 
of a bother. (RFC 2595 section 3.1.) Hm.

> Now we're talking about adding even more distinct items to CAPABILITY 
> to support LISTEXT.

CAPABILITY is an eyesore, but its length isn't such a big problem. IMO, 
the number of capabilities is worse. A lot of combinations to test. All 
that can be done about that is careful design in each particular case.

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: CAPABILITYPLUS
Cc: IMAP Extensions WG <[email-masked]>
Date: Mon, 29 Sep 2003 13:27:20 +0200
Sender: [email-masked]

Mark Crispin writes:
> I think that a preferable option would be to have a means to 
> "compress" IMAP. It could be either abbreviated text or even binary.

I submitted an i-d for that an hour ago. Assuming I've put in all the 
right bits of boilerplate, it should be in the i-d repositories RSN.

(I've implemented the extension both as server and client. Both were 
well under 100 lines excluding test code.)

--Arnt

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 12:01:26 -0700
Lines: 30
Sender: [email-masked]

"Timo Sirainen" <[email-masked]> wrote in message
news:[email-masked]...
>
> If I set rules:
>
> user=user "rw"
> group=group1 "r"
> -group=group2 "r"
>
> and user belongs to both groups, UNION rule would give user only "w"
> access, right? It could be better if user rights would always override
> group rights, but in some situations it could be better if they didn't
> (eg. temporarily drop rights).

Ok in all fairness to the current structure of ACL2, when would you
ever do the above if you didn't mean to strip away the read right from user?

Under what circumstances would you ever apply a negative right to a
group and then put a user in that group if you didn't mean for the right
to be stripped?

If you didn't want the group to have the right, you'd just omit it from
the list.  Why go through the trouble of putting a negative right on it
if just omitting it does what you intended?

-- Michael --

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 11:56:56 -0700
Lines: 38
Sender: [email-masked]

> The classic UNIX example is the "noprint" group: Everyone has execute
> access ti lpr except group "noprint". Thus, ten thousand students can
> print, except the dozen-odd who have gravely abused the printers in the
> past and have been added to group "noprint".

This seems more a case where everybody by default is a member
of the "print" group and those that abuse the privilege get removed.
Certainly "anonymous" must be excluded here as well.

Or, again, make acl order processing significant and just make
sure the negative rights appear before the positive rights.

noprint: -w
user: rw
authuser: rw

Since there is an exact match on the negative right before hitting
anything with a positive right the system would know to disallow.

Expanding this to a shared folder where by default everyone can
post but a dozen start posting gobs of porn, you would either
have a group specified for that shared folder, or shared folders
in general which once the abusers are removed they can no longer
access the shared folders.

Or if you'd still rather have a negative rights solution, then
you add the offenders to the "noaccess" group and then put that
group early enough in the list of groups so the negative rights
get processed first.

-- Michael --

-- Michael --

Date: Fri, 12 Sep 2003 11:18:07 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Rob Siemborski <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Ken Murchison wrote:
> I think you misread him.  I think what Larry meant (and Rob and I would
> like) is:
> "anonymous" - special identifer that refers to all users authenticated
>           as the anonymous identity
> "authuser" - special identifier that refers to all authenticated users,
>           excluding anonymous.
> "anyone" - special identifier that refers to the universal identity
>           (all authentications, including anonymous).
> In other words "anyone" = "anonymous" + "authuser"

This idea sounds fine to me.

-- Mark --

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

Date: Fri, 12 Sep 2003 14:09:38 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Alexey Melnikov <[email-masked]>
CC: Rob Siemborski <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

Alexey Melnikov wrote:

> 
> Rob Siemborski wrote:
> 
>> On Fri, 12 Sep 2003, Michael Fair wrote:
>>  
>>
>>> I've tried to come up with one, but it seems silly to me that an admin
>>> would give a right to world without knowing exactly what that meant.
>>>   
>>
>>
>> With ACL, we commonly have a situation that looks like this on our public
>> folders:
>>
>> anyone rls
>> -anonymous s
>>
>> Obviously with ACL2 you can do this like this instead:
>>
>> anyone rl
>> authuser s
>>
>> However, for backwards compatiblity with ACL, this sort of thing becomes
>> pretty hairy.
>>
>> Actually, I'm not sure how to easily do bacwards compatibility with 
>> ACL in
>> this situation given the current spec, where anyone and anonymous are the
>> same.
>>
> Larry was the one who suggested this (unless I've misread him). I have 
> no strong opinion on this.

I think you misread him.  I think what Larry meant (and Rob and I would 
like) is:

"anonymous" - special identifer that refers to all users authenticated
          as the anonymous identity
"authuser" - special identifier that refers to all authenticated users,
          excluding anonymous.
"anyone" - special identifier that refers to the universal identity
          (all authentications, including anonymous).

In other words "anyone" = "anonymous" + "authuser"

-- 
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: Fri, 12 Sep 2003 10:28:10 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Alexey Melnikov wrote:

> >Actually, I'm not sure how to easily do bacwards compatibility with ACL in
> >this situation given the current spec, where anyone and anonymous are the
> >same.
> >
> Larry was the one who suggested this (unless I've misread him). I have
> no strong opinion on this.

I think its possible to be backwards compatible in the current form (see
my previous message).  I just think it feels burdensome.  I'd prefer
anonymous and anyone to not be synonyms, but I'm not going to stand in the
way of a steam roller if the WG disagrees.

> >(if the decision is 'don't implement both ACL and ACL2').
> >
> At least my intention was to allow them to be compatible (probably
> except for the 'x' right).

Good.

-Rob

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

Date: Fri, 12 Sep 2003 15:23:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

Rob Siemborski wrote:

>On Fri, 12 Sep 2003, Michael Fair wrote:
>  
>
>>I've tried to come up with one, but it seems silly to me that an admin
>>would give a right to world without knowing exactly what that meant.
>>    
>>
>
>With ACL, we commonly have a situation that looks like this on our public
>folders:
>
>anyone rls
>-anonymous s
>
>Obviously with ACL2 you can do this like this instead:
>
>anyone rl
>authuser s
>
>However, for backwards compatiblity with ACL, this sort of thing becomes
>pretty hairy.
>
>Actually, I'm not sure how to easily do bacwards compatibility with ACL in
>this situation given the current spec, where anyone and anonymous are the
>same.
>
Larry was the one who suggested this (unless I've misread him). I have 
no strong opinion on this.

>  I'm not even really sure how to do upgrades in an automated fashion
>(if the decision is 'don't implement both ACL and ACL2').
>
At least my intention was to allow them to be compatible (probably 
except for the 'x' right).

Alexey

Date: Fri, 12 Sep 2003 10:21:01 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Rob Siemborski wrote:

> Actually, I'm not sure how to easily do bacwards compatibility with ACL in
> this situation given the current spec, where anyone and anonymous are the
> same.  I'm not even really sure how to do upgrades in an automated fashion
> (if the decision is 'don't implement both ACL and ACL2').

Nevermind, I've not had my coffee this morning apparently.

I don't think there's actually a problem here:

ACL:
 anyone rls
ACL2:
 anyone rls

ACL:
 anyone rls
 -anonymous s
ACL2:
 anyone rl
 authuser s

ACL:
 anymous rli
 anyone l
ACL2:
 anyone rli
 -authuser ri

So, while pretty bizarre looking, its doable (I think this is the only
affected case).

-Rob

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

Date: Fri, 12 Sep 2003 10:08:25 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Michael Fair wrote:

> I've tried to come up with one, but it seems silly to me that an admin
> would give a right to world without knowing exactly what that meant.

With ACL, we commonly have a situation that looks like this on our public
folders:

anyone rls
-anonymous s

Obviously with ACL2 you can do this like this instead:

anyone rl
authuser s

However, for backwards compatiblity with ACL, this sort of thing becomes
pretty hairy.

Actually, I'm not sure how to easily do bacwards compatibility with ACL in
this situation given the current spec, where anyone and anonymous are the
same.  I'm not even really sure how to do upgrades in an automated fashion
(if the decision is 'don't implement both ACL and ACL2').

-Rob

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

Date: Fri, 12 Sep 2003 10:03:45 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Michael Fair <[email-masked]>, IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Thu, 11 Sep 2003, Mark Crispin wrote:

> Adding "negative negative rights" would make it possible to implement the
> functionality of MOST-SPECIFIC in UNION and thus allow the removal of
> MOST-SPECIFIC.  But I think that the result would be even more complex
> and harder to implement than ACL2 is now.

I agree.  This level of complexity is unnecessary and will only make this
spec harder to implement, something we definately do not need (especially
given the recent change it underwent).

-Rob

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

From: Arnt Gulbrandsen <[email-masked]>
To: Michael Fair <[email-masked]>
Subject: Re: ACL2 rules
Cc: IMAP List <[email-masked]>
Date: Fri, 12 Sep 2003 11:01:02 +0200
Sender: [email-masked]

Michael Fair writes:
> Has anyone in the camp that thinks it's important to disallow rights 
> granted to group/world for user/group given a valid/useful use case?

The classic UNIX example is the "noprint" group: Everyone has execute 
access ti lpr except group "noprint". Thus, ten thousand students can 
print, except the dozen-odd who have gravely abused the printers in the 
past and have been added to group "noprint".

With a little thought, I'm sure I could construct a similar case with 
mail... but I'd rather do some work.

--Arnt

From: "Michael Fair" <[email-masked]>
To: "IMAP List" <[email-masked]>
Subject: Re: ACL2 rules
Date: Fri, 12 Sep 2003 00:48:56 -0700
Organization: DaClubhouse
Sender: [email-masked]

> If you have inheritance without negative rights, then you have the sort of
> situation typified by the TOPS-20 filesystem, in which owner could not be
> denied rights given to group or world, and group could not be denied
> rights given to world.
> 
> For whatever reason, some people think that it's important to be able to
> deny rights to a specific user that were given to group or world, or deny
> rights to a specific group that were given to world.  The UNIX filesystem
> offers this, but does not use inheritance (MOST-SPECIFIC) so negative
> rights are moot.

Thanks for the description.

As it stands, I think I'm more in the TOPS-20 camp.

Has anyone in the camp that thinks it's important to disallow rights
granted to group/world for user/group given a valid/useful use case?

I've tried to come up with one, but it seems silly to me that an admin
would give a right to world without knowing exactly what that meant.

With all due respect to the contributors here, as I think some very 
elegant and wonderful things come out of this group, on this issue
it seems strange that people would advocate an end user saying 
something like:
"Oh wait I can't do that as me, I have to go become anonymous to do that"

I'll admit I don't deal with ACLs a whole lot... 
If someone can provide a valid/useful case where this becomes important
I'd love to see it.

-- Michael --

Date: Thu, 11 Sep 2003 23:45:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Thu, 11 Sep 2003, Michael Fair wrote:
> If a user is a member
> of two groups, then they should have the positive rights of both groups

Most people agree on this point.  The problem is whether a user's
membership in a group should cause the group's rights to add or subtract
from the user's rights in the case where the user has explicit (not
implied) rights.

Inheritance combined with negative rights makes things quite difficult.

> Perhaps I just don't understand why negative rights are considered
> more important.

If you have inheritance without negative rights, then you have the sort of
situation typified by the TOPS-20 filesystem, in which owner could not be
denied rights given to group or world, and group could not be denied
rights given to world.

For whatever reason, some people think that it's important to be able to
deny rights to a specific user that were given to group or world, or deny
rights to a specific group that were given to world.  The UNIX filesystem
offers this, but does not use inheritance (MOST-SPECIFIC) so negative
rights are moot.

ACL tries to have both inheritance *and* the provision to deny rights that
would otherwise be inherited.  Negative rights are how ACL does this, but
this then leads to the problem that there is no way to disinherit a
negative right (the way a negative right disinherits a right).

There are two ways of punting on the question, both involving not
implementing negative rights.  One is to use MOST-SPECIFIC (punting on
inheritance) ala UNIX; the other is to use UNION but not offer negative
rights (punting on not being able to deny inherited rights) ala TOPS-20.
Either one of these are, to my mind, simpler and more flexible than the
Byzantine complexity of inheritance plus negative rights; but some people
want the complexity so that's why ACL2 is the way it is.

Adding "negative negative rights" would make it possible to implement the
functionality of MOST-SPECIFIC in UNION and thus allow the removal of
MOST-SPECIFIC.  But I think that the result would be even more complex
and harder to implement than ACL2 is now.

-- Mark --

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

From: "Michael Fair" <[email-masked]>
Cc: "IMAP List" <[email-masked]>
Subject: Re: ACL2 rules
Date: Thu, 11 Sep 2003 21:13:43 -0700
Organization: DaClubhouse
Sender: [email-masked]

> However, this is a religious argument and I doubt we'll ever reach
> concensus.

Agreed on the consensus bit.

Out of curiousity and in an attempt to learn something, why would group1 
rights have any impact on group2 rights at all?  If a user is a member
of two groups, then they should have the positive rights of both groups
and it's an admins responsibility to make sure the groups and users all
match up with what they are trying to accomplish...

I don't want to rehash any flame wars, I'm just trying to understand
the logic.

When does "UNION" make sense?
It seems to me that either positive rights should always be favored or
make processing order significant and go with the first positive
or negative right encountered.

It also seems that +r UNION +r UNION -r = -r is just a bad algorithm
(even if there weren't two +r's).

Perhaps I just don't understand why negative rights are considered 
more important.

-- Michael --

Date: Thu, 11 Sep 2003 20:24:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP List <[email-masked]>
Subject: Re: ACL2 rules
Sender: [email-masked]

On Fri, 12 Sep 2003, Timo Sirainen wrote:
> If I set rules:
> user=user "rw"
> group=group1 "r"
> -group=group2 "r"
> and user belongs to both groups, UNION rule would give user only "w"
> access, right?

Yes.  This is why I lobbied so hard for a choice other than UNION.

> It could be better if user rights would always override
> group rights,

Yes!

> but in some situations it could be better if they didn't
> (eg. temporarily drop rights).

That is why there is both UNION and MOST-SPECIFIC in the specification.

> Maybe there should be rule-specific option to specify if negative rule
> overrides more specific non-negative rules?
> Now, if we have that, we don't actually really need the MOST-SPECIFIC
> rule at all

True, but IMHO MOST-SPECIFIC is better since it is unambiguous for a
client what a listed user's rights are.  If we have
	user=fred "r"
it is surprising to most people to find that fred has "w" rights because
of inheritance from a group.

However, this is a religious argument and I doubt we'll ever reach
concensus.

-- Mark --

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

Date: Fri, 12 Sep 2003 05:31:54 +0300
Subject: ACL2 rules
From: Timo Sirainen <[email-masked]>
To: IMAP List <[email-masked]>
Sender: [email-masked]

If I set rules:

user=user "rw"
group=group1 "r"
-group=group2 "r"

and user belongs to both groups, UNION rule would give user only "w" 
access, right? It could be better if user rights would always override 
group rights, but in some situations it could be better if they didn't 
(eg. temporarily drop rights).

Maybe there should be rule-specific option to specify if negative rule 
overrides more specific non-negative rules? Such as --group=group2 "r" 
would mean that it's a negative non-overriding rule. I think better 
would be to default to non-overriding rules, but maybe there are some 
backwards compatibility issues?

Now, if we have that, we don't actually really need the MOST-SPECIFIC 
rule at all :) It would rather be just a hint to client, just as there 
would be hints for max. number of users/groups.

The difference is that the rule parsing would always be the same for 
client no matter how the server works. UNIX mode 0642 mailbox would be 
just shown as having rules:

user=user "rw"
group=group1 "r"
--group=group1 "w"
other "w"

If client then changes user's ACL to just "r", it would implicitly add 
-user=user "w" rule.

Date: Tue, 9 Sep 2003 16:04:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-melnikov-imap-keywords-02.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

Some comments after a review:

I believe that $Work and $Personal, while undoubtably useful for a human
user, are *not* needed by an MUA and therefore do not belong in this
document.  I do not see how "Work" and "Personal" are of such importance
that they need to be in the registry, and not "Family", "Party",
"Meeting", "Flames", "Bugs", "Politics", "Orders", "Memos", "Notice", etc.

Eliminating $Work and $Personal as registered flags eliminates three silly
states.  Anyway, who is to say that a message can't be both work and
personal related, or that it may not also be junk?

I'm not reconciled to $Important either.  There is a tendency in this
group to say "oh, such-and-such isn't used right by some implementations,
lets create a whole new mechanism."  This tendency should be resisted.

$AutoMaybeJunk is unnecessary and IMHO harmful due to the creation of
silly states.  There are four states, therefore only two keywords are
necessary:
 1) not autoprocessed
 2) auto junk
 3) auto not junk
 4) auto indeterminate
State (4) can be achieved by lighting both the state (2) and (3) flags.
This has another advantage in that it removes the possibility of a silly
state.  With $AutoMaybeJunk, there are four(!!) silly states.

$Junk and $NoJunk together is currently a silly state, and defined as an
error.  It should instead mean that auto-junk processing is *NOT* to take
place on this message, and the message is *NOT* to be considered in
training auto-junk processing.

Recommendations:

Remove all silly states (which the document calls "mutually exclusive").
Silly states are a wart on the face of IMAP, should never have been
allowed to happen where they did, and vigorous efforts should be
undertaken to prohibit new ones from coming into being.

Add $Junk, $NotJunk, $AutoJunk, $AutoNotJunk, with semantics modified as
proposed in this message so that there are no silly states.

Add $Forwarded and $ShouldReply since MUAs use these.

Remove $Work, $Personal.  These are human keywords, not MUA keywords.

Possibly retain $Important but stress that \Flagged should be used
instead.

-- Mark --

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

Date: Thu, 4 Sep 2003 08:14:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Paul Smith <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: CAPABILITYPLUS
Sender: [email-masked]

On Thu, 4 Sep 2003, Paul Smith wrote:
> Binary protocols are so much harder to debug IME. It is good to be
> able to telnet to a server and type in commands manually and get responses
> back, rather than having to write test programs/scripts to generate the
> binary for you.

This goes without saying.  I wouldn't even think of replacing text-based
IMAP with a binary protocol.  Any binary compressed version of IMAP would
have to be completely parallel to non-compressed IMAP.

Personally, I don't think that compression at the IMAP level (as opposed
to transport layer compression) is necessary.  I'm simply offering it as a
possible alternative.

> Also, having a 'standard' set of abbreviations it's not hard to imagine a
> server which could transparently understand both 'chatty' IMAP and 'terse'
> IMAP (it could even switch between both in the same session).

That also goes without saying.

> To increase
> efficiency, having an abbreviated FETCH response (for instance) would be
> much more useful.

Yup.  FETCH is what really needs a compressed form.

-- Mark --

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

Date: Thu, 04 Sep 2003 09:45:48 +0100
To: IMAP Extensions WG <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: CAPABILITYPLUS
Sender: [email-masked]

At 17:08 03/09/2003 -0700, Mark Crispin wrote:

>IMAP is a very chatty protocol, and CAPABILITY is a very chatty command.
>We're talking about a new command to make CAPABILITY a little less chatty,
>instead of addressing the overall chattiness.
>
>I think that a preferable option would be to have a means to "compress"
>IMAP.  It could be either abbreviated text or even binary.  The capability
>list could be a bitstream in which all IANA-registered capabilities are in
>a well-known position and only unregistered capabilities are listed by
>name.  It isn't difficult to imagine other compressions.

If you were to compress IMAP, I'd be happy with an abbreviated text version 
(eg 'S' for 'SELECT', 'F' for 'FETCH' etc), but not really with a binary 
one. Binary protocols are so much harder to debug IME. It is good to be 
able to telnet to a server and type in commands manually and get responses 
back, rather than having to write test programs/scripts to generate the 
binary for you. (We always find it much easier to test/debug text protocols 
like SMTP, POP3, IMAP etc than it is to test binary protocols like LDAP etc)

Also, having a 'standard' set of abbreviations it's not hard to imagine a 
server which could transparently understand both 'chatty' IMAP and 'terse' 
IMAP (it could even switch between both in the same session). If you get 
into binary protocols it starts getting harder to have the same server 
doing both

If you want a 'binary' capability list, I'm sure there's a way you could 
come up with a text version (eg using a string of letters/digits, where 
each letter indicates a capability (that gives you 62 possible capabilities 
easily)). But, as you say, it's only done once or twice. To increase 
efficiency, having an abbreviated FETCH response (for instance) would be 
much more useful.

JM2P

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Re: Capability balooning and restructuring
Date: Thu, 4 Sep 2003 00:41:36 -0700
Lines: 126
Sender: [email-masked]

Sorry to reply to my own post, but I just realized
that I forgot to credit where the ideas came from.

Nothing in this email was an original idea, I meant
to draw attention to the constantly contradicting
goals when modifying CAPABILITY comes up and that it
appears we will remain caught in this endless cycle
until a conclusion is drawn on the direction to go.
Sacrifice bandwidth, or Round Trips I don't think the
group will ever be able to consolidate on a solution
that gives us both.

The examples I used were drawn from CAPABILITYPLUS,
Mark's last email, and other conversations from months
ago in regards to VHOST and LANG.

I apologize if I offended anyone by repeating suggestions
that have already been made and making them look like
my own, I didn't mean to do that.

-- Michael --

"Michael Fair" <[email-masked]> wrote in message
news:[email-masked]...
>
> This CAPABILTIY changing discussion is a painful
> recurring them on this list.
>
> I remember a number of things impacting the CAPABILITY
> line that meant more and more round trips for a client
> to get a session established wasn't desirable to the
> clients, but the WG preferred to add discrete commands
> rather than a client capability line.
>
> Virtual domain changes, TLS, and authentication are
> three round trips that I distinctly remember.
>
> At the time the response was more of a "they should
> remain their own commands, and we should find a way
> to reduce round trip requests" but I never saw any
> concrete suggestions after that nor do I have any
> myself.
>
> Now we're talking about adding even more distinct
> items to CAPABILITY to support LISTEXT.
>
> I can't think of a way to meet all the goals at the
> same time.
>
> And with this latest suggestion that addressing CAPABILITYPLUS
> is also the wrong way to go, I'm wondering what the basis
> is on how it should get decided?
>
> Compressing CAPABILITY to binary kills any telnet debugging
> possibilities which I've used on several occasions, how
> important is text debugging in the decision?
>
> Reducing round trips means being able to combine more
> commands into a single trip, but it makes the CAPABILITY
> command larger and more complicated.
>
> The more optional features added to the protocol means the
> more that is needed to tell the client....  Currently
> CAPABILITY is the only thing there is to give this kind
> of feedback...
>
> Perhaps the various LISTEXT responses should be shoved off
> into there own query command and just LISTEXT, to tell the
> client that it should go look there, should appear in the
> CAPABILITY response itself.
>
>
> Overall it just seems that this WG has conflicting goals
> depending on how important the feature is to the people
> recommending it and the WG doesn't have a clear concensus
> on what CAPABILITY should be.
>
> The fact that questions regarding "What is the goal" usually
> receive silence as a response tells me that the members of
> the list don't really know what the answer is for certain.
>
> It seems to me that this issue has got enough merit behind it
> and comes up often enough that a structure should be worked
> on to address the "ballooning" of the CAPABILITY response and
> the client round trip times.  My first thoughts are that
> CAPABILITY as it was originally intended, has outgrown
> its usefulness and needs to be yanked and replaced with a new
> methodology, but I don't think that's going to work.
>
> Things that are important to different people are going to
> want to go in that CAPABILITY response and I think "the people
> with the weightiest voices" wins is a bad way to decide what
> goes in and what doesn't.
>
> I see the CAPABILITY line only getting larger in the future
> and thus I see no end in sight to the "how big is too big"
> discussions.  I don't think compression is a good answer
> as clarity has always seemed to be a goal for the WG.
>
>
> In general the WG has been more in favor of adding more
> targetted individual commands than making a more complicated
> CAPABILITY command.  This was the general result of the VHOST
> command, and the LANG command.  So I'm pulling from possibly
> reusing that general strategy to move forward.
>
>
> Perhaps CAPABILITY turns into a QUERY request, where the
> client submits to the server everything it would like to
> try and use and the server responds with what in that
> list the current state supports?  This way instead of
> just dumping every possible feature any client could ever
> want on the wire, the protocol only passes back and forth
> what the client can actually use...
>
> This smells a lot like a "Client Capability" line which
> has been frowned upon in the past...  Is that still the case?
>
> -- Michael --
>
>
>
>

To: [email-masked]
From: "Michael Fair" <[email-masked]>
Subject: Capability balooning and restructuring
Date: Wed, 3 Sep 2003 20:38:05 -0700
Lines: 96
Sender: [email-masked]

This CAPABILTIY changing discussion is a painful
recurring them on this list.

I remember a number of things impacting the CAPABILITY
line that meant more and more round trips for a client
to get a session established wasn't desirable to the
clients, but the WG preferred to add discrete commands
rather than a client capability line.

Virtual domain changes, TLS, and authentication are
three round trips that I distinctly remember.

At the time the response was more of a "they should
remain their own commands, and we should find a way
to reduce round trip requests" but I never saw any
concrete suggestions after that nor do I have any
myself.

Now we're talking about adding even more distinct
items to CAPABILITY to support LISTEXT.

I can't think of a way to meet all the goals at the
same time.

And with this latest suggestion that addressing CAPABILITYPLUS
is also the wrong way to go, I'm wondering what the basis
is on how it should get decided?

Compressing CAPABILITY to binary kills any telnet debugging
possibilities which I've used on several occasions, how
important is text debugging in the decision?

Reducing round trips means being able to combine more
commands into a single trip, but it makes the CAPABILITY
command larger and more complicated.

The more optional features added to the protocol means the
more that is needed to tell the client....  Currently
CAPABILITY is the only thing there is to give this kind
of feedback...

Perhaps the various LISTEXT responses should be shoved off
into there own query command and just LISTEXT, to tell the
client that it should go look there, should appear in the
CAPABILITY response itself.

Overall it just seems that this WG has conflicting goals
depending on how important the feature is to the people
recommending it and the WG doesn't have a clear concensus
on what CAPABILITY should be.

The fact that questions regarding "What is the goal" usually
receive silence as a response tells me that the members of
the list don't really know what the answer is for certain.

It seems to me that this issue has got enough merit behind it
and comes up often enough that a structure should be worked
on to address the "ballooning" of the CAPABILITY response and
the client round trip times.  My first thoughts are that
CAPABILITY as it was originally intended, has outgrown
its usefulness and needs to be yanked and replaced with a new
methodology, but I don't think that's going to work.

Things that are important to different people are going to
want to go in that CAPABILITY response and I think "the people
with the weightiest voices" wins is a bad way to decide what
goes in and what doesn't.

I see the CAPABILITY line only getting larger in the future
and thus I see no end in sight to the "how big is too big"
discussions.  I don't think compression is a good answer
as clarity has always seemed to be a goal for the WG.

In general the WG has been more in favor of adding more
targetted individual commands than making a more complicated
CAPABILITY command.  This was the general result of the VHOST
command, and the LANG command.  So I'm pulling from possibly
reusing that general strategy to move forward.

Perhaps CAPABILITY turns into a QUERY request, where the
client submits to the server everything it would like to
try and use and the server responds with what in that
list the current state supports?  This way instead of
just dumping every possible feature any client could ever
want on the wire, the protocol only passes back and forth
what the client can actually use...

This smells a lot like a "Client Capability" line which
has been frowned upon in the past...  Is that still the case?

-- Michael --

Date: Wed, 3 Sep 2003 17:08:29 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: CAPABILITYPLUS
Organization: Networks & Distributed Computing
Sender: [email-masked]

Although CAPABILITYPLUS sounds like a good idea, I'm concerned that we may
be solving the wrong problem.

IMAP is a very chatty protocol, and CAPABILITY is a very chatty command.
We're talking about a new command to make CAPABILITY a little less chatty,
instead of addressing the overall chattiness.

I think that a preferable option would be to have a means to "compress"
IMAP.  It could be either abbreviated text or even binary.  The capability
list could be a bitstream in which all IANA-registered capabilities are in
a well-known position and only unregistered capabilities are listed by
name.  It isn't difficult to imagine other compressions.

In the case of CAPABILITY, I don't think that it matters much.  A
CAPABILITY command is only done once or twice in a session, not enough to
effect the overall scheme of things.  Certainly LISTEXT won't do so; it
isn't as if we will have thousands of LISTEXT options.

Speaking of which, the more that I think about it, the more that I believe
that it is essential that a capability for LISTEXT options be all or none.
That is, either *every* LISTEXT option is mandatory to implement if the
server advertises the LISTEXT capability, or that *every* LISTEXT option
have its own capability.

That is, I advocate one of the following:

1) Add LIST=SUBSCRIBED, LIST=REMOTE, and LIST=CHILDREN capabilities.
Make CHILDREN optional to implement.

2) Add LISTEXT capability.  Make SUBSCRIBED, REMOTE, and CHILDREN
mandatory to implement.  Support for CHILDREN is no longer optional, and
RFC 3348 is deprecated.

I do not object to mandatory-to-implement.  SUBSCRIBED should be easy
enough, as long as it can be done as an LSUB that does an internal LIST.
CHILDREN is alright too, as long as the client is required to ask for it
explicitly (as opposed to RFC 3348's implicit action).

-- Mark --

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

Date: Wed, 3 Sep 2003 15:05:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 3 Sep 2003, Arnt Gulbrandsen wrote:
> > At most two RTTs for a client that wants "everything"; done to get the
> > base capabilities, one for the desired expansions.
> If CAPABILITYPLUS mandates a [CAPABILITY ...] in the banner OK response,
> clients expend at most one RTT to get everything they want.

Exactly.

-- Mark --

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

Date: Wed, 3 Sep 2003 15:06:34 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

> «IMAP4 servers that support this extension MUST include a CHANNEL
> capability response in the response list to the CAPABILITY command.
> This entry indicates the server supports the extension, and lists the
> schemes available to the CHANNEL command. The capability response
> consists of the string "CHANNEL=" followed by a list of schemes
> supported by the CHANNEL extension.»

As has been pointed out, this doesn't work. I'm changing Channel to
advertise "Channel" as the capability, and will add a new command for
discovering the list of supported schemes.

--lyndon

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: LISTEXT capabilities
Cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 3 Sep 2003 21:23:44 +0200
Sender: [email-masked]

Mark Crispin writes:
> At most two RTTs for a client that wants "everything"; done to get the 
> base capabilities, one for the desired expansions.

If CAPABILITYPLUS mandates a [CAPABILITY ...] in the banner OK response, 
clients expend at most one RTT to get everything they want.

--Arnt

Date: Wed, 3 Sep 2003 13:17:22 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

> The latter, LIST=FOO,BAR, requires more intelligence in the parser,
> which generates new error situations -- e.g., is LIST=FOO,,BAR ok?

Sorry, I meant LIST=FOO LIST=BAR, not LIST=A,B,C.

--lyndon

Date: Wed, 03 Sep 2003 13:43:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Mark,

--On Wednesday, September 03, 2003 9:47 AM -0700 Mark Crispin 
<[email-masked]> wrote:

| Everybody is going to do a CAPABILITY without any arguments, so it seems
| pointless to have an extra command to get the "short" version after you've
| already gotten the "long" version.
|
| At most two RTTs for a client that wants "everything"; done to get the
| base capabilities, one for the desired expansions.

I actually want to be able to have one RTT to get a version of the full 
capabilites with some of them (the ones I care about) expanded. So how 
about allowing capability with arguments to have the option of a '%' 
argument that means return all the non-expandable capabilities as well.

i.e. if my client only cares about expanded LISTEXT I could do:

a CAPABILITY (% LISTEXT)

as the one and only capability command to get all I want in one RTT.

-- 
Cyrus Daboo

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: LISTEXT capabilities
Cc: Cyrus Daboo <[email-masked]>, Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 3 Sep 2003 19:06:02 +0200
Sender: [email-masked]

Mark Crispin writes:
> I propose something much simpler:
>
> CAPABILITY (without any arguments) and auto-capability: return base 
> capabilities using "*" prefix for those that can be enumerated.
>
> CAPABILITY (with arguments) - return enumerated capabilities for those 
> listed in argument list. Don't list other capabilities.

Sounds good (through a haze of jetlag at least)... I assume the OK 
[CAPABILITY ...] response always uses *, then?

--Arnt

Date: Wed, 3 Sep 2003 09:47:45 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

I propose something much simpler:

CAPABILITY (without any arguments) and auto-capability: return base
capabilities using "*" prefix for those that can be enumerated.

CAPABILITY (with arguments) - return enumerated capabilities for those
listed in argument list.  Don't list other capabilities.

Rationale:

Everybody is going to do a CAPABILITY without any arguments, so it seems
pointless to have an extra command to get the "short" version after you've
already gotten the "long" version.

At most two RTTs for a client that wants "everything"; done to get the
base capabilities, one for the desired expansions.

-- Mark --

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

Date: Wed, 03 Sep 2003 12:16:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Mark,

--On Wednesday, September 3, 2003 9:05 -0700 Mark Crispin 
<[email-masked]> wrote:

| CAPABILITYPLUS can not encompass AUTH, since that would force an extra RTT
| at session startup as clients need to learn which mechanisms they use to
| authenticate (and at startup that's the only thing they really need).
|
| It's also too late (by 5 years or so) to do this for THREAD, although
| THREAD is an obvious candidate for this.
|
| We can do this for new extensions such as LISTEXT and ACL.

Agreed to the above.

| We don't need a new CAPABILITYPLUS command; the CAPABILITYPLUS extension
| can expand the CAPABILITY command.  I also think that CAPABILITYPLUS
| should be the expanded version and not the other way around; don't forget
| auto-capability announcement.
|
| Perhaps we can indicate that a capability has an expansion by prefixing it
| with a well-known character such as "*"?  Since these are new
| capabilities, it's alright to have *ACL2, *LISTEXT, etc.

OK - sounds good. So we can have the following for CAPABILITLYPLUS:

CAPABILITY (without any arguments) - return the fully enumerated 
capabilities.

CAPABILITY (with empty parenthesized argument set) - return base 
capabilities using '*' prefix for those that can be enumerated.

CAPABILITY (with parenthesized  arguments) - return enumerated capabilities 
for those listed in argument list, base capabilities for others. 
Unrecognized arguments are ignored.

-- 
Cyrus Daboo

Date: Wed, 3 Sep 2003 09:05:16 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

CAPABILITYPLUS can not encompass AUTH, since that would force an extra RTT
at session startup as clients need to learn which mechanisms they use to
authenticate (and at startup that's the only thing they really need).

It's also too late (by 5 years or so) to do this for THREAD, although
THREAD is an obvious candidate for this.

We can do this for new extensions such as LISTEXT and ACL.

We don't need a new CAPABILITYPLUS command; the CAPABILITYPLUS extension
can expand the CAPABILITY command.  I also think that CAPABILITYPLUS
should be the expanded version and not the other way around; don't forget
auto-capability announcement.

Perhaps we can indicate that a capability has an expansion by prefixing it
with a well-known character such as "*"?  Since these are new
capabilities, it's alright to have *ACL2, *LISTEXT, etc.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:55:55 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

On Wed, 3 Sep 2003, Ken Murchison wrote:
> With regards to the discussion of the CAPABILITY response getting too
> large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in
> the CAPABILITY response, and use a modified LIST command to get the
> available LISTEXT keywords
> . LIST () "" ""
> * LIST (SUBSCRIBED CHILDREN) "." ""

I like this idea.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:47:19 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

On Wed, 3 Sep 2003, Arnt Gulbrandsen wrote:
> Ken Murchison writes:
> > By my reading of the drafts (00 - 04), CHILDREN is part o fthe base
> > LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a
> > valid option.
> I see what you mean, but that seems a little too subtle. Expecting J.
> Random Client Author to get that one right seems like stretching it.

This has been my concern all along.

-- Mark --

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

Date: Wed, 3 Sep 2003 08:45:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Simon Josefsson <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

On Wed, 3 Sep 2003, Alexey Melnikov wrote:
> I am afraid you will have to modify your code. There will be more
> extensions coming that will use some kind of prefix.

I agree.  SORT and THREAD also do this.

-- Mark --

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

Date: Wed, 03 Sep 2003 11:21:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT capabilities
Sender: [email-masked]

Hi Ken,

--On Wednesday, September 3, 2003 9:39 -0400 Ken Murchison <[email-masked]> 
wrote:

| With regards to the discussion of the CAPABILITY response getting too
| large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in
| the CAPABILITY response, and use a modified LIST command to get the
| available LISTEXT keywords, eg:

That does not address other extensions which may need something similar 
(e.g. LANGUAGE has a command mode to enumerate available languages, 
separate from the capability response). Having a mode of each new command 
that is used to enumerate its options leads to more roundtrips etc - I did 
propose something like that with the ACLMODEL response, but I think a 
better solution can be achieved:

Here's an alternative using a new capability behaviour.

We have a new CAPABILITYPLUS extension: a server that supports this returns 
it as part of the initial greeting string CAPABILITY response.

A client can then use a 'CAPABILITYPLUS' command with or without arguments 
in the following manner:

1) Without arguments: the capability response lists the 'base' extension 
capabilities, e.g. 'AUTH' 'LISTEXT', 'ACL2', 'THREAD', 'SORT', etc without 
any '=XXX' enumerations.

a CAPABILITYPLUS
* CAPABILITY IMAP4rev1 AUTH STARTTLS UIDPLUS NAMESPACE LISTEXT THREAD ACL2 
LANGUAGE
a OK

2) With arguments: arguments are 'base' extension names. If the server 
supports one of the listed base extensions it returns the full enumeration 
of options for that base extension, in addition to all the others it would 
normally return. If it does not support the base extension, it ignores the 
argument. e.g.

a CAPABILITYPLUS AUTH LISTEXT THREAD FOOBAR ACL2 LANGUAGE
* CAPABILITY IMAP4rev1 AUTH=PLAIN STARTTLS UIDPLUS ACL2 NAMESPACE 
LISTEXT=CHILDREN LISTEXT=ACL THREAD=ORDEREDSUBJECT THREAD=REFERENCES 
LANGUAGE
* ACLMODEL "model1" "MOST_SPECIFIC" "u g" ("lrs" "witextd" "p" "a")
* ACLMODEL "model2" "UNION" "*u *g" ("lr" "switextd" "p" "a")
* ACLMODEL "model3" "UNION" "*u *g" NIL
* LANGUAGE (EN DE IT i-default)
a OK

Note that in the above example the presence of ACL2 and LANGUAGE results in 
implicit ACLMODEL and LANGUAGE responses enumerating the more detailed 
capabilities of those extensions.

The original CAPABILITY command would still be present and would list the 
entire set of detailed capabilities as it does now - with all the bloat.

The benefit of a new capability mechanism like this is that clients that 
are aware of specific extensions can request more detail about those 
extensions, and those that don't care will not get back a bloated 
capability response. It can also reduce the number of round trips to get 
more detailed capabilities of specific extensions such as ACL2 and LANGUAGE.

We could of course do more with an extended capability command - such as 
introduce client switches (e.g. turn on UTF8 support in the server etc).

So if people are worried about capability bloat, this might be one way to 
address it.

-- 
Cyrus Daboo

Date: Wed, 03 Sep 2003 16:01:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Simon Josefsson wrote:

>Arnt Gulbrandsen <[email-masked]> writes:
>  
>
>>Only a language lawyer can find a way to make that cohabit with other
>>use of the prefix, so I'd say that for all practical purposes the
>>prefix is reserved.
>>    
>>
>
>The problem isn't purely academic -- there are IMAP libraries designed
>around the text in RFC 3501 (and earlier) on CAPABILITY names.
>Specifically: one of my IMAP APIs only allow applications to query if
>capability X is supported by the server.  If now IMAP extensions are
>allowed to allocate an entire CAPABILITY prefix, I'll have to modify
>my API to support this.  I'd prefer not to do this, of course, unless
>there is a really good reason for it.  Sticking to what RFC 3501 said
>would be better.
>
I am afraid you will have to modify your code. There will be more 
extensions coming that will use some kind of prefix.

Alexey

To: Arnt Gulbrandsen <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 16:28:52 +0200
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Only a language lawyer can find a way to make that cohabit with other
> use of the prefix, so I'd say that for all practical purposes the
> prefix is reserved.

The problem isn't purely academic -- there are IMAP libraries designed
around the text in RFC 3501 (and earlier) on CAPABILITY names.
Specifically: one of my IMAP APIs only allow applications to query if
capability X is supported by the server.  If now IMAP extensions are
allowed to allocate an entire CAPABILITY prefix, I'll have to modify
my API to support this.  I'd prefer not to do this, of course, unless
there is a really good reason for it.  Sticking to what RFC 3501 said
would be better.

Date: Wed, 03 Sep 2003 09:39:21 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
Subject: LISTEXT capabilities
Sender: [email-masked]

With regards to the discussion of the CAPABILITY response getting too 
large and using LIST=* vs. LIST-*, why not advertise *only* LISTEXT in 
the CAPABILITY response, and use a modified LIST command to get the 
available LISTEXT keywords, eg:

. LIST () "" ""
* LIST (SUBSCRIBED CHILDREN) "." ""

We simply replace the flags that would normally be returned in the 
hierarchy separator query (which are meaningless in this case anyways), 
with the supported LISTEXT keywords.

-- 
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: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 15:27:23 +0200
Sender: [email-masked]

Simon Josefsson writes:
> Arnt Gulbrandsen <[email-masked]> writes:
>> 2. Then there's one simple LHS=RHS, where both sides are constant,
>>     such as ACL2=UNION, and LHS= is reserved.
>
> See http://www.iana.org/assignments/imap4-capabilities, none of the 
> officially registered schemes, after a brief examination only, seem 
> to reserve only a part of the CAPABILITY name. The entire CAPABILITY 
> name must be allocated and reserved.

Good point. Never the less, language such as «The QUOTA extension is 
present in any IMAP4rev1 server which advertises any CAPABILITY 
beginning with "QUOTA="» openly conflicts with any other use of the 
prefix "QUOTA=".

>>  4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing
>>     and the LHS= is reserved.
>
> I disagree, for the same reason as in 2.

«IMAP4 servers that support this extension MUST include a CHANNEL 
capability response in the response list to the CAPABILITY command. 
This entry indicates the server supports the extension, and lists the 
schemes available to the CHANNEL command. The capability response 
consists of the string "CHANNEL=" followed by a list of schemes 
supported by the CHANNEL extension.»

Only a language lawyer can find a way to make that cohabit with other 
use of the prefix, so I'd say that for all practical purposes the 
prefix is reserved.

Someone clearly had forgotten 2087.

> The way I read it, you cannot reserve part of a CAPABILITY response 
> (except AUTH= which is documented in the main specification). So all 
> those extensions should register all possible CAPABILITY names they 
> support.

Oh, yes, I forgot AUTH. Sorry. That's another argument that LISTEXT (and 
CHANNEL) should be like AUTH, QUOTA and THREAD.

--Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 15:13:22 +0200
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Simon Josefsson writes:
>> Lyndon Nerenberg <[email-masked]> writes:
>>
>>>  Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?
>>
>> IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better
>> than LIST=FOO,BAR.
>
> Well, it's not quite so simple.
>
> There number of different CAPABILITY schemes is growing, and the
> growth doesn't seem justified. A shortish review:
>
> 1. Many extensions use a single, simple word. ID, SORT and
>    ANNOTATEMORE are examples of this.
>
> 2. Then there's one simple LHS=RHS, where both sides are constant,
>    such as ACL2=UNION, and LHS= is reserved.

See http://www.iana.org/assignments/imap4-capabilities, none of the
officially registered schemes, after a brief examination only, seem to
reserve only a part of the CAPABILITY name.  The entire CAPABILITY
name must be allocated and reserved.

> 3. Then there's n simple LHS=RHS capabilities, as used by QUOTA or
>    THREAD. For example, "QUOTA=RES-STORAGE QUOTA=RES-MESSAGES". Here
>    too, LHS= is reserved.

Not according to RFC 2087 nor the IANA page, and to me it looks like
that would violate RFC 3501, unless both QUOTA=RES-STORAGE and
QUOTA=RES-MESSAGES were allocated with IANA.

> 4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing
>    and the LHS= is reserved.

I disagree, for the same reason as in 2.

> 5. The current LISTEXT draft leaves the impression that the "LIST-" 
> prefix is to be used for list extensions only.
>
> From this list, the most important thing I see is that LISTEXT should
> move in line with the others and reserve LHS= instead of LHS-.
>
> The second is that if LISTEXT and CHANNEL are to use LHS=A,B,C, their
> rules should match perfectly. And that they should use the same
> solution: Either both use commas or neither does.

The way I read it, you cannot reserve part of a CAPABILITY response
(except AUTH= which is documented in the main specification).  So all
those extensions should register all possible CAPABILITY names they
support.

> Ideally, IMO, both LISTEXT and CHANNEL should move into line with
> QUOTA/THREAD.

I agree, although with the possible modification that I think the
entire QUOTA/THREAD CAPABILITY keyword should be registered, no LHS=
reservation is allowed.  Like RFC 2087.

So if a LIST extension want to use variable RHS it could register
LIST=FOO, LIST=BAR, LIST=FOO,BAR, LIST=BAR,FOO.  Of course, if that is
considered ugly (which I would agree with), the IANA registry
pre-conditions should be updated.

Regards,
Simon

From: Arnt Gulbrandsen <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Lyndon Nerenberg <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 14:51:40 +0200
Sender: [email-masked]

Simon Josefsson writes:
> Lyndon Nerenberg <[email-masked]> writes:
>
>>  Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?
>
> IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better than 
> LIST=FOO,BAR.

Well, it's not quite so simple.

There number of different CAPABILITY schemes is growing, and the growth 
doesn't seem justified. A shortish review:

1. Many extensions use a single, simple word. ID, SORT and ANNOTATEMORE 
are examples of this.

2. Then there's one simple LHS=RHS, where both sides are constant, such 
as ACL2=UNION, and LHS= is reserved.

3. Then there's n simple LHS=RHS capabilities, as used by QUOTA or 
THREAD. For example, "QUOTA=RES-STORAGE QUOTA=RES-MESSAGES". Here too, 
LHS= is reserved.

4. The hard stuff: CHANNEL=imap,ftp, where the RHS requires parsing and 
the LHS= is reserved.

5. The current LISTEXT draft leaves the impression that the "LIST-" 
prefix is to be used for list extensions only.

>From this list, the most important thing I see is that LISTEXT should 
move in line with the others and reserve LHS= instead of LHS-.

The second is that if LISTEXT and CHANNEL are to use LHS=A,B,C, their 
rules should match perfectly. And that they should use the same 
solution: Either both use commas or neither does.

Ideally, IMO, both LISTEXT and CHANNEL should move into line with QUOTA/THREAD.

Does any CHANNEL people read this list?

> The latter, LIST=FOO,BAR, requires more intelligence in the parser,

(I agree with these concerns. I also agree with Mark's (?) concern about 
overly long capability lists.)

--Arnt

To: Lyndon Nerenberg <[email-masked]>
Cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 14:18:25 +0200
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

> Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?

IMHO, either of LIST-FOO LIST-BAR or LIST=FOO LIST=BAR is better than
LIST=FOO,BAR.

The latter, LIST=FOO,BAR, requires more intelligence in the parser,
which generates new error situations -- e.g., is LIST=FOO,,BAR ok?
LIST=,,,FOO?  LIST=FOO=BAZ,BAR?  What should an entity do when a
invalid keyword is present?  Warn about it?  Disconnect?  It is easier
to do a string comparison directly than to first parse it and then do
a string comparison on the parsed result.  The parser step adds
complexity and error conditions, all without an obvious gain.  A
design that lead to error conditions in some situations is worse than
a design that prevent the error condition to ever arise.  Furthermore,
LIST=FOO,BAR requires more text in a specification, and longer ABNF
rules to specify the right-hand part of LIST=VALUES.  I think we all
know that more text, and longer ABNF, leads to higher risk of errors
and confusion.

Date: Wed, 3 Sep 2003 04:12:48 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

Where do we stand on LIST-FOO LIST-BAR vs. LIST=FOO,BAR ?

--lyndon (who prefers '=' but is mostly just curious)

Date: Wed, 03 Sep 2003 10:50:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Mark Crispin wrote:

>On Tue, 2 Sep 2003, Arnt Gulbrandsen wrote:
>  
>
>>How would the client know that it can send LIST (CHILDREN), unless by
>>seeing that capability? The latest draft names two capabilities:
>>LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for
>>CHILDREN.
>>    
>>
>
>I agree that LIST-CHILDREN should be there.
>
I am second (third, ...) on this.
Personally, I see no use in CHILDREN, I was able to implement reasonable 
GUI without it.

Alexey

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Wed, 3 Sep 2003 11:11:56 +0200
Sender: [email-masked]

Ken Murchison writes:
> By my reading of the drafts (00 - 04), CHILDREN is part o fthe base 
> LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a 
> valid option.

I see what you mean, but that seems a little too subtle. Expecting J. 
Random Client Author to get that one right seems like stretching it.

--Arnt

Date: Tue, 2 Sep 2003 16:55:09 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Pete Maclean <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Pete Maclean wrote:
> > > LIST () "" % should not return it, but for backwards compatibility I
> > > think the old style LIST should return it when it can.
> >Right, that's why it was left there: compatibility with clients that expected
> >a plain LIST to return CHILDREN info.  I agree with the concern, and with the
> >suggested compromise.  Pete & Mark, does that work for you?
> If Mark agrees, then it's fine with me.

I don't think that it's important enough for me to stand in the way, and I
won't.

Nevertheless, it still seems to me that LIST-CHILDREN should be a
capability.  It just seems to be a cleaner (and safer design).

I agree that the current specification will work.

-- Mark --

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

Date: Tue, 02 Sep 2003 19:29:29 -0400
To: "Barry Leiba" <[email-masked]>, "IMAP extensions Mailing List" <[email-masked]>
From: Pete Maclean <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

> > LIST () "" % should not return it, but for backwards compatibility I
> > think the old style LIST should return it when it can.
>
>Right, that's why it was left there: compatibility with clients that expected
>a plain LIST to return CHILDREN info.  I agree with the concern, and with the
>suggested compromise.  Pete & Mark, does that work for you?

If Mark agrees, then it's fine with me.

Pete

Date: Tue, 02 Sep 2003 18:04:59 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Mark Crispin <[email-masked]>
CC: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Mark Crispin wrote:
> On Tue, 2 Sep 2003, Ken Murchison wrote:
> 
>>>I'd prefer some wording to the effect that servers may choose not to have
>>>"old style" list return CHILDREN information, and thus the only reliable
>>>way to get CHILDREN information is to use LISTEXT.
>>
>>All the server has to do is no longer advertise CHILDREN, and then it no
>>longer has to return CHILDREN info for "old style" LIST.
> 
> 
> But doesn't CHILDREN have to be advertised if the server supports it in
> LISTEXT?

By my reading of the drafts (00 - 04), CHILDREN is part o fthe base 
LISTEXT spec.  The LISTEXT capability means that LIST (CHILDREN) is a 
valid option.

-- 
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: Arnt Gulbrandsen <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 2 Sep 2003 20:56:45 +0200
Sender: [email-masked]

Is it permitted to ask why it's LIST-* instead of LIST=*? IMAP seems to 
lean towards the latter in general.

--Arnt

Date: Tue, 2 Sep 2003 11:51:12 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Ken Murchison <[email-masked]>, Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Arnt Gulbrandsen wrote:
> How would the client know that it can send LIST (CHILDREN), unless by
> seeing that capability? The latest draft names two capabilities:
> LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for
> CHILDREN.

I agree that LIST-CHILDREN should be there.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 2 Sep 2003 20:47:39 +0200
Sender: [email-masked]

Ken Murchison writes:
> All the server has to do is no longer advertise CHILDREN, and then it 
> no longer has to return CHILDREN info for "old style" LIST.

How would the client know that it can send LIST (CHILDREN), unless by 
seeing that capability? The latest draft names two capabilities: 
LIST-SUBSCRIBED and LIST-REMOTE. It does not specify a capability for 
CHILDREN.

--Arnt

Date: Tue, 2 Sep 2003 11:39:11 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Ken Murchison wrote:
> > I'd prefer some wording to the effect that servers may choose not to have
> > "old style" list return CHILDREN information, and thus the only reliable
> > way to get CHILDREN information is to use LISTEXT.
> All the server has to do is no longer advertise CHILDREN, and then it no
> longer has to return CHILDREN info for "old style" LIST.

But doesn't CHILDREN have to be advertised if the server supports it in
LISTEXT?

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Date: Tue, 2 Sep 2003 20:31:06 +0200
Sender: [email-masked]

Mark Crispin writes:
> I'd prefer some wording to the effect that servers may choose not to 
> have "old style" list return CHILDREN information, and thus the only 
> reliable way to get CHILDREN information is to use LISTEXT.

That sounds bad to me. If listext and CHILDREN are both present, then a 
client that supports CHILDREN but not listext would be hampered.

If that's desirable, a more honest way would be to provide a 
LIST=CHILDREN that says effectively "the functionality of 3348 is 
present, but not the syntax".

--Arnt

Date: Tue,  2 Sep 2003 14:27:55 -0400
From: Ken Murchison <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Barry Leiba <[email-masked]>, IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Sender: [email-masked]

Quoting Mark Crispin <[email-masked]>:

> 
> On Tue, 2 Sep 2003, Barry Leiba wrote:
> > > LIST () "" % should not return it, but for backwards compatibility I
> > > think the old style LIST should return it when it can.
> > Right, that's why it was left there: compatibility with clients that
> expected
> > a plain LIST to return CHILDREN info.  I agree with the concern, and with
> the
> > suggested compromise.  Pete & Mark, does that work for you?
> 
> I'd prefer some wording to the effect that servers may choose not to have
> "old style" list return CHILDREN information, and thus the only reliable
> way to get CHILDREN information is to use LISTEXT.

All the server has to do is no longer advertise CHILDREN, and then it no 
longer has to return CHILDREN info for "old style" 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: Tue, 2 Sep 2003 10:55:34 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Sep 2003, Barry Leiba wrote:
> > LIST () "" % should not return it, but for backwards compatibility I
> > think the old style LIST should return it when it can.
> Right, that's why it was left there: compatibility with clients that expected
> a plain LIST to return CHILDREN info.  I agree with the concern, and with the
> suggested compromise.  Pete & Mark, does that work for you?

I'd prefer some wording to the effect that servers may choose not to have
"old style" list return CHILDREN information, and thus the only reliable
way to get CHILDREN information is to use LISTEXT.

-- Mark --

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

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Last Calling the LISTEXT draft?
Date: Tue, 2 Sep 2003 08:10:47 -0400
Sender: [email-masked]

> LIST () "" % should not return it, but for backwards compatibility I 
> think the old style LIST should return it when it can.

Right, that's why it was left there: compatibility with clients that expected
a plain LIST to return CHILDREN info.  I agree with the concern, and with the
suggested compromise.  Pete & Mark, does that work for you?

Barry
--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba