Subject: [lemonade] draft-gulbrandsen-imap-enable-03

From: Ken Murchison <[email-masked]>
Date: Fri, 02 Nov 2007 07:07:41 -0400

After looking at the current draft on my way towards implementing 
QRESYNC, I'm wondering why ENABLE is allowed to be used blindly.  I 
don't see any reason why ENABLE should be allowed before the client 
knows that a particular extension is supported (via CAPABILITY).

In particular, the second example in section 3 seems strange to me, and 
AFAICT, doing ENABLE before CAPABILITY doesn't gain anything in terms of 
round trips.  I also don't like the fact that we're documenting that 
ENABLE can be used to probe for extensions (as per paragraph 2 in 
section 5).  We already have a command to list extensions.

If we specify that a client MUST NOT try to enable an extension that 
isn't listed by CAPABILITY, then all the server has to worry about 
parsing are those extensions that it supports and are enable-able. 
Trying to ENABLE any other other extensions, whether unknown, 
unenable-able, or unsupported can all result in BAD.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Ken Murchison <[email-masked]>
Date: Fri, 02 Nov 2007 07:25:01 -0400

> unenable-able, or unsupported can all result in BAD.

One more thing:

What is supposed to happen if a client does 'ENABLE CONDSTORE THREAD' on 
a server that supports both extensions?  Should we use untagged OK 
responses to tell the client which extensions were enabled?  What is the 
final result of the command?

---

From: Peter Coates <[email-masked]>
Date: Fri, 02 Nov 2007 08:16:20 -0700

Let's consider ENABLE and QRESYNC.

Is the QRESYNC capability is in effect for a session, the responses sent by
the server are different from those that would otherwise be sent.  VANISHED
instead of EXPUNGED, for instance.  So, it is important that the server not
use QRESYNC features until told to by the client.

I am really against any extension that can change the protocol during the
life of the session.  I would like to see the protocol negotiated at the
start of the session.

Thus, the server does not advertise QRESYNC initially.  If the client issues
an ENABLE command, and then issues a CAPABILITY command it can try to turn
on the feature and see if the server supported it.

S: * OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS
CHILDREN 
   BINARY UNSELECT SORT IDLE URLAUTH LANGUAGE ESEARCH THREAD=ORDEREDSUBJECT 
   THREAD=REFERENCES CONDSTORE ENABLE CONTEXT WITHIN XSENDER X-NETSCAPE
XSERVERINFO
   X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP
X-ANNOTATEMORE XUM1
   AUTH=PLAIN] sandman.red.iplanet.com IMAP4 service (Sun Java(tm) System
Messaging
   Server 7.0-0.01 32bit (built Oct 26 2007))
C: 1 login YYYYY XXXXX
S: 1 OK User logged in
C: 2 enable qresync foobar
S: 2 OK Completed
C: 3 capability
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS
CHILDREN 
   BINARY UNSELECT SORT CATENATE URLAUTH LANGUAGE ESEARCH
THREAD=ORDEREDSUBJECT
   THREAD=REFERENCES IDLE ENABLE CONTEXT WITHIN XSENDER X-NETSCAPE
XSERVERINFO
   X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP
X-ANNOTATEMORE XUM1
   CONDSTORE QRESYNC
S: 3 OK Completed

The new capability vector sent after the enable command reflect the new
negotiated protocol level.  I would have liked CONDSTORE to have to be
enabled, but it was too late to do that, and we are stuck with 42 different
ways that the CONDSTORE extension can be enabled. (note that turning on
QRESYNC implies turning on CONDSTORE)

I have argued that the enable command only be allowed near the start of a
session, only at the first command, or as the first command after
authentication, but I do not think I have achieved much traction on that
idea as it implies another state for the protocol engine.  I can see that
that is an attractive argument for some, but if feels a bit academic and
pedantic to me.

Peter

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Murchison
Sent: November 2, 2007 04:08
To: [email-masked]; IMAP Extensions WG
Subject: draft-gulbrandsen-imap-enable-03

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Nov 2007 11:45:06 +0100

> knows that a particular extension is supported (via CAPABILITY).

Two reasons.

1. It allows the client to use a single invariant enable command. The 
client doesn't have to do any string concatenation, it can just do "if 
( server supports enable ) send its enable command".

2. It allows the client to send a single enable command early, even 
though the server it's talking to (before authentication) may not even 
know the complete list of capabilities that will be available after 
authentication.

People asked for both of these properties.

> In particular, the second example in section 3 seems strange to me, 
> and AFAICT, doing ENABLE before CAPABILITY doesn't gain anything in 
> terms of round trips.

That's right.

> I also don't like the fact that we're documenting that ENABLE can be 
> used to probe for extensions (as per paragraph 2 in section 5).  We 
> already have a command to list extensions.

I'm perfectly happy taking that out, if that would be appropriate. I 
thought this sort of thing was supposed to be listed in security 
considerations.

> unenable-able, or unsupported can all result in BAD.

Please discuss that with Peter Coates.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Nov 2007 11:50:33 +0100

Ken Murchison writes:
> One more thing:
>
> What is supposed to happen if a client does 'ENABLE CONDSTORE THREAD' 
> on a server that supports both extensions?

BAD if the server is careful, because THREAD isn't ENABLE-ish.

> Should we use untagged OK responses to tell the client which 
> extensions were enabled?

If so, then a server handling unauthenticated connections would have to 
know what capabilities will be available to that user after 
authentication.

> What is the final result of the command?

'ENABLE CONDSTORE' before authentication has no immediate effect. It 
takes effect only after authentication, at which point it has acted as 
a 'condstore enabling command'.

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Nov 2007 18:20:52 -0800

At 11:50 AM +0100 11/4/07, Arnt Gulbrandsen wrote:

>  If so, then a server handling unauthenticated connections would 
> have to know what capabilities will be available to that user after 
> authentication.

I think it is worth mentioning this in the draft, as a clarification 
for the response not indicating which capabilities were/will be 
enabled.  It'll save readers wondering about it.

>  'ENABLE CONDSTORE' before authentication has no immediate effect. 
> It takes effect only after authentication, at which point it has 
> acted as a 'condstore enabling command'.

This also is worth mentioning in the draft.

In the case of CONDSTORE, the server could internally enable it right 
away; it just won't have any effect until after a mailbox is 
selected, which can't be until after authentication.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Good night to spend with family, but avoid arguments with your
mate's new lover.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 09 Nov 2007 16:16:19 +0000

> thought this sort of thing was supposed to be listed in security 

Based on various off-list discussions I got impression that several 
people really disliked that.
So I am suggesting the following change:

Replace:
 The server MUST NOT change the CAPABILITY list as a result of
 executing ENABLE.

With:
 The server MUST NOT change the CAPABILITY list as a result of
 executing ENABLE, i.e. a CAPABILITY command issued right after
 an ENABLE command MUST list the same capabilities as a CAPABILITY
 command issued before the ENABLE command. The following example
 demonstrates that:
 
 C: t1 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t1 OK foo
 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
 S: t2 OK foo
 C: t3 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t3 OK foo again
 
and also add:
 
 Note that according to [RFC3501] the list of advertised capabilities MAY
 change after a STARTTLS and/or AUTHENTICATE/LOGIN command. The ENABLE 
command
 doesn't change that.

---

From: Peter Coates <[email-masked]>
Date: Fri, 09 Nov 2007 09:24:40 -0800

What?  If Enabling an extension does not affect the CAPABILITY vector, and
if the ENABLE command silenty ignores extensions the server does not wan to
allow or which it doe not know, then after the sequence

 C: t1 CAPABILITY

the client does not know whether CONDSTORE is enabled or not.  I assert that
either the enable command has to tell the client which things worked (or
which things didn't), or the capability vector has to change

Thus the sequence should be either
 C: t1 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t1 OK foo
 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
 S: t2 OK foo
 C: t3 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
CONDSTORE
 S: t3 OK foo again

Or
 C: t1 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t1 OK foo
 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
 S: * OK [ENABLED CONDSTORE] or some variant of this
 S: t2 OK foo
 C: t3 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t3 OK foo again

Peter

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: November 9, 2007 08:16
To: Arnt Gulbrandsen
Cc: [email-masked]; [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03

Replace:

With:
 
 C: t1 CAPABILITY
 
and also add:

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 09 Nov 2007 19:03:20 +0000

Peter Coates wrote:

>if the ENABLE command silenty ignores extensions the server does not want to
>allow or which it does not know, then after the sequence
>
> C: t1 CAPABILITY
>the client does not know whether CONDSTORE is enabled or not.
>
>I assert that either the enable command has to tell the client which things worked (or
Agreed, but this can (and I think should) be done in a way which doesn't 
contradict text I've suggested. See below.

> S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
I dislike that, because you now implicitly saying that there are magic 
extensions which don't work unless the client knows how to enable them. 
Really, the server should have advertised the CONDSTORE extension to 
begin with.

> S: * OK [ENABLED CONDSTORE] or some variant of this
(Or just use the CAPABILITY response code: it serves the same purpose + 
can save a round trip in this case.)

So if you insist on being able to change the capability list, it is much 
better to return the updated list using the CAPABILITY response code. 
Clients should already be able to handle unsolicited updates, in 
particular because the CAPABILITY response code payload frequently 
changes after LOGIN/AUTHENTICATE.
This allows the client to figure out if an extension can be enabled 
after all.

> command doesn't change that.
>  
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 Nov 2007 13:54:02 +0100

> people really disliked that.

Are we talking about the same thing? I thought Peter referred to the 
security considerations, but now you suggest changing something else.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 12 Nov 2007 12:56:53 +0000

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Arnt Gulbrandsen wrote:
>>
>>>> I also don't like the fact that we're documenting that ENABLE can 
>>>> be used to probe for extensions (as per paragraph 2 in section 5).  
>>>> We already have a command to list extensions.
>>>
> Are we talking about the same thing?

As it turned out we weren't. I though Peter disliked probing for 
available extensions using ENABLE, but he didn't.
After reading this thread it looks like Ken and myself dislike probing, 
but I am not sure who else dislikes it.

> I thought Peter referred to the security considerations, but now you 
> suggest changing something else.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 12 Nov 2007 14:12:48 +0100

Alexey Melnikov writes:
> available extensions using ENABLE, but he didn't. After reading this 
> thread it looks like Ken and myself dislike probing, but I am not 
> sure who else dislikes it.

I dislike probing.

My _personal_ preferences would be for an ENABLE which is usable only 
after login, which can be used any time, but where all the examples 
show it being used as part of connection startup. I'm neutral on 
whether ENABLE CONDSTORE should fail on a CONDSTORE-ignorant server. 
(I'm happy with the text there now, but it's not exactly what I would 
have put in if it were only up to me.)

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 12 Nov 2007 13:17:30 +0000

> whether ENABLE CONDSTORE should fail on a CONDSTORE-ignorant server. 

I prefer that the server just ignores extensions that it doesn't 
recognize or which can't be enabled.
There are ways for the client to figure out which extensions were 
enabled and which were not.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 20 Nov 2007 10:33:16 -0800

At 7:03 PM +0000 11/9/07, Alexey Melnikov wrote:

>  I dislike that, because you now implicitly saying that there are 
> magic extensions which don't work unless the client knows how to 
> enable them. Really, the server should have advertised the 
> CONDSTORE extension to begin with.

I agree.

The client shouldn't have to parse both the CAPABILITY response and 
the ENABLE response to learn if an extension has been negotiated.  If 
we put all ENABLEable extensions in the CAPABILITY response, then the 
response to ENABLE can be OK even if it contains unknown extensions.

At 2:42 PM -0800 11/9/07, Ned Freed wrote:
>  My personal preference is to have the initial capability list not list things
>  that can be enabled, have enable turn on whatit can and ignore the rest, and
>  have any enabled changes show up in subsequent capability lists. This
>  leverages existing protocol features and doesn't invent new syntax or
>  require multiple commands.

Why do you prefer not having ENABLEable extensions in the initial 
CAPABILITY response?

At 7:59 AM -0800 11/10/07, Ned Freed wrote:
>  One problem is that this presumes that enable will always succeed 
> for anything
>  that was previousliy listed as a capability. This strikes me as risky - there
>  could be things where the server cannot tell there's  a problem enabling it
>  until it actually goes through the steps of doing so.
>
>  I strongly prefer a model where it is possible to check to see what's turned
>  on and what is not.

>  In my approach the client authenticates and then sends the enable command
>  followed by a capability command to see the results of the enable.

So ENABLE returns OK even if some extensions are not known or 
couldn't be turned on for whatever reason (temporary failure of a 
resource perhaps).  The post-authentication post-ENABLE CAPABILITY 
response omits anything that failed during ENABLE.  So a 
post-authentication pre-ENABLE CAPABILITY response may be different 
from a post-authentication post-ENABLE CAPABILITY response.  That 
seems a little odd, but it may be easier on the client, since the 
client only has to parse the CAPABILITY response, not the ENABLE 
response.  But it does effectively force the sequence 
CAPABILITY-authentication-ENABLE-CAPABILITY.

At 10:25 AM -0800 11/10/07, Ned Freed wrote:
>  Nothing prevents us from requiring ENABLE in order to use extensions that
>  change command response syntax. In fact I think such a requirement would be a
>  very good idea.

I agree, but this requires a revision to CONDSTORE that deprecates 
the current extension and defines a new one, doesn't it?

-------------- Randomly-selected tag: ---------------
No one would choose a friendless existence even if they had
all other good things in the world.             --Aristotle

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Nov 2007 10:40:42 -0800 (PST)

> Why do you prefer not having ENABLEable extensions in the initial

Because it removes the ability to use the response to determine what is or is
not enabled.

> CAPABILITY-authentication-ENABLE-CAPABILITY.

Correct, but clients already have to look at capabilitiez after authentication
so this adds no overhead.

No matter how you slice it the client has to be able to determine what's
enabled - the present situation as I understand is unacceptable since
situations can arise where the client doesn't know what's on and what's off.
The three options as I seee it are:

(1) Have enable return this information as some sort of extended response.
(2) have the client send multiple enables and use the response status to
    determine success or failure.
(3) Piggyback this on the existing capabilities mechanism.

I believe (3) is the simplest by far from a client perspective. An existing,
compliant client need only add code to send a single enable command (which can
even have a fixed set of arguments). The client then uses the capability
response it already has to find out what extensions it can use, and more
importantly what changes those extenaions have made to the syntax and semantics
of server responses.

If we don't do (3) I think the only viable alternative is (1). (2) looks an
awful lot like telnet option negiation to me, which hasn't worked all that
well.

> the current extension and defines a new one, doesn't it?

Yes, but IMO that's a good thing.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 20 Nov 2007 11:22:56 -0800

>  Because it removes the ability to use the response to determine what is or is

I don't understand your reply.  I parse it as: you prefer prohibiting 
any extension that can be ENABLEd from appearing in the initial 
(pre-authentication) CAPABILITY response because this way clients 
can't use the initial CAPABILITY response to determine what is or is 
not ENABLEd?

Do you mean that you want to keep all non-TLS non-authentication 
extensions out of the initial CAPABILITY response to avoid revealing 
information to an unauthenticated client?

Or do you mean that you want to prevent clients from assuming that 
any ENABLEable extension listed in the initial CAPABILITY response 
and included in the ENABLE command was successfully ENABLEd, without 
looking at the post-ENABLE CAPABILITY response?

>  so this adds no overhead.

True, but it does force any client that uses ENABLE to issue it after 
authenticating and before issuing the post-authentication CAPABILITY 
command (unless the client wants to issue a third CAPABILITY command, 
which seems pointless).

So the required command sequence becomes:

     1: CAPABILITY (only to determine if TLS and which authentication
         mechanisms are supported)
     2: TLS (if being used) and authentication
     3: ENABLE (with all desired ENABLEable extensions)
     4: CAPABILITY (to see which ENABLEable extensions were turned
         on, and which other extensions are supported)

>  Yes, but IMO that's a good thing.

It would make things much cleaner, so long-term would be helpful.  Is 
there support in the group for doing this?  Are there deployments of 
CONDSTORE?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Note that although IBM 'invented' virtual memory in 1972 it had
been available in a multi-processor multi-tasking environment on
the Burroughs B5000 line since 1963 and the B6000 line since 1968.

---

From: Dan Karp <[email-masked]>
Date: Tue, 20 Nov 2007 11:49:19 -0800 (PST)

> Because it removes the ability to use the response to determine what
> is or is not enabled.

If that is the point of this, we should stop trying to be tricky and 
just add an untagged ENABLED response:

   A001 ENABLE X-UNKNOWN-EXTENSION QRESYNC CONDSTORE
   * ENABLED QRESYNC CONDSTORE
   A001 OK ENABLE completed

I don't like changing the semantics of CAPABILITY just to avoid having 
a new untagged response.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Nov 2007 11:52:42 -0800 (PST)

+1

> I don't like changing the semantics of CAPABILITY just to avoid having

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Nov 2007 14:52:28 -0800 (PST)

> can't use the initial CAPABILITY response to determine what is or is

It's extremely simple: If the availabity of an extension is sufficient for it
to appear in the CAPABILITY response then that response cannot be used as an
indication of whether or not the extension is enabled.

I suppose you could change the response in some way, but I have to wonder why a
client would care about the existance of an extension that it didn't bother
trying to enable.

> information to an unauthenticated client?

No, the pre-authentication response is completely irrelevant.

> looking at the post-ENABLE CAPABILITY response?

Again, the initial capability response isn't relevant to any of this. The only
thing I can think of that would make it relevant is to misdesign enable so that
it's all or nothing. In that case you'd need to look at that response to find
out what you could put in your enable command. But in that case you still
shouldn't be paying attention to the pre-authentication response. Rather, you'd
need to CAPA-TLS-CAPA-AUTH-CAPA-ENABLE sequence. Blech.

> command (unless the client wants to issue a third CAPABILITY command,

Correct, but IMO this is a very good thing. Limiting the places where enable
can be used results in a tremendous reduction in the number of places where a
state transition can occur. (Unfortunately it doesn't reduce the number of
actual protocol states, but nothing short of a redesign of the way responses
are structured so they can be extended at any time can accomplish that.)

>          on, and which other extensions are supported)

Yep, that's it.

> there support in the group for doing this?  Are there deployments of

That's the real question. If there's significant deployment we pretty much
have no choice but to do this by adding additional response inforation to
enable, which adds client complexity.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 20 Nov 2007 16:05:48 -0800

>  client would care about the existance of an extension that it didn't bother

Thanks, I see the source of my confusion now: the term "initial 
CAPABILITY response".  I took it to mean the pre-authentication 
CAPABILITY response, but I see now you only talking about 
post-authentication.

>>           on, and which other extensions are supported)

This makes sense.  If an extension that is normally ENABLE-able is 
sent by the client in ENABLE, but for some reason fails, the server 
omits it from the CAPABILITY response in step 4.  This is reasonable 
because in reality it isn't actually available just at the moment for 
whatever reason, even though the server does support it.  This might 
change the next time the client connects, but that's always the case. 
This is different from how I am used to thinking of the CAPABILITY 
response, but is simpler for the client, I think.

-------------- Randomly-selected tag: ---------------
You think it's a conspiracy by the networks to put bad shows on TV. But
the shows are bad because that's what people want. It's not like
Windows users don't have any power. I think they are happy with
Windows, and that's an incredibly depressing thought.
                                                           --Steve Jobs

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Nov 2007 10:03:55 +0100

> just add an untagged ENABLED response:

Absolutely.

Not sure I agree with the need for ENABLED, but it certainly is THE 
straightforward and sensible solution to the perceived problem.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Nov 2007 11:29:17 +0000

> straightforward and sensible solution to the perceived problem.

Agreed.

But can somebody please give me a useful use case of why a client would 
need to know if something is enabled or not. The client still needs to 
cope with a server that doesn't support an extension.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Nov 2007 12:43:22 +0100

Alexey Melnikov writes:
> But can somebody please give me a useful use case of why a client 
> would need to know if something is enabled or not. The client still 
> needs to cope with a server that doesn't support an extension.

I believe there won't be any such useful case with regular clients. 
There could be three other kinds of cases:

1. A test suite client., which wants to test at the start that it has 
the same idea of state as the server.

2. A client which can tell the user about the server it's using in a 
little dialog box:
       Server host: <name>
       Protocol: IMAP
       Server name: <name and stuff from ID>
       Using TLS: <Yes or no>
       Logged in as: <login>
       Extensions used: <list>
That last list would be the ones the server offers and client uses that 
aren't ENABLE fodder, plus the ones from ENABLED.

3. Really badly written extensions. For example, if Peter makes a 
complete mess of his FAT NIL proposal, a client might need to know.

IMO, 1 is a weak reason (we do this in a nonstandard way and that's 
perfect for testing), 2 is even weaker and 3 is laughable.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Wed, 21 Nov 2007 08:50:58 -0800 (PST)

> I believe there won't be any such useful case with regular clients.

Not true. The obvious one is any extension which, once enabled, changes
response syntax in some way and for which an attempt to enable it can fail due
to some local condition on the server. So suppose a client tries to enable the
extension. The enable succeeds or fails but the client cannot tell from the
response which one it was. Now what? Does the client have to try some command
that should have an altered response in order to see if the enable worked? And
do this for each of several extensions? This is terrible protocol design,
nothing more and nothing less.

Even worse, the likely behavior of client writers will be to simply assume that
all enable actions succeed. Then when an enable doesn't work the client and
server get desynchronized.

> the same idea of state as the server.

This is getting close to another important case: Various sorts of proxies and
stateful firewalls. I'm not particularly fond of these sorts of things, but my
dislike doesn't change the fact that they are commonly used. And any time you
have a protocol that has lots of possible state changes that can occur at
various different times and for which it is even slightly difficult to
determine current state, you are pretty much guaranteed to have problems.

> complete mess of his FAT NIL proposal, a client might need to know.

Mind you, the best way to solve these problems would be to devise
a response format whose syntax doesn't need to change in order to return
more stuff. But I don't think there's any desire to engage in such a
major redesign of IMAP at this point.

				Ned

---

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 27 Nov 2007 14:01:38 -0500

Hi,
I'm a bit confused about where this has ended up.  Is this the current
status?

- Enable gets registered with IANA.
- Extensions do not get registered (although they might be described in
specific RFCs).
- One can enable arbitrary extensions.
- There is no indication if an extension is not supported (other than
potentially some change to other data returned).
- There is no way to disable an extension once it has been enabled.

I'm not advocating anything here - solely asking if this is the current way
consensus thinks it should work.  Is this where it stands at the moment?

Also, isn't there another case where a client would care about what
extensions work - where there is some interaction between extensions?

For example, don't bother with X, Y, and Z unless all 3 work?

Thanks,
Dgc
Darryl G. Champagne

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2007 6:43 AM
To: [email-masked]; [email-masked]
Cc: Alexey Melnikov; Ned Freed
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Nov 2007 20:49:34 +0000

>Hi,
Hi Darryl,

>I'm a bit confused about where this has ended up.
>
I am not sure that the dust has settled yet. But here are my guesses 
where things are going:

>Is this the current status?
>
Not sure why this is important.

>- Extensions do not get registered (although they might be described in
Not sure what do you mean here. Registered where?

>- One can enable arbitrary extensions.
Yes.

>potentially some change to other data returned).
The current CAPABILITY mechanism is still going to be used to find out 
if an extension is supported or not.

I think there is some form of consensus that a new response should be 
added to signal which extensions were successfully enabled.

>- There is no way to disable an extension once it has been enabled.
Correct. The ability to disable extensions was discarded long time ago.

>For example, don't bother with X, Y, and Z unless all 3 work?
This should be possible: a client can construct an ENABLE command after 
checking CAPABILITY.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 30 Nov 2007 12:17:22 -0800

>  - Extensions do not get registered (although they might be described in

ENABLE, as an extension, gets registered with IANA at 
<http://www.iana.org/assignments/imap4-capabilities>.  So do new 
extensions.  ENABLE doesn't change this at all.  ENABLE is merely a 
clean way to flip a switch during an IMAP session that otherwise 
requires magic.  That is, ENABLE just makes state changes explicit 
(and maybe at a more constrained time) rather than having them occur 
at arbitrary points as a result of the client's use of certain 
command forms.

>  - One can enable arbitrary extensions.

Any ENABLE-able extension can be used with ENABLE, but that's a tautology.

>  potentially some change to other data returned).

Extensions still are listed in the CAPABILITY response -- ENABLE 
doesn't change that.  But the client needs to know which of them can 
be used with ENABLE.

>  - There is no way to disable an extension once it has been enabled.

Correct.

>  For example, don't bother with X, Y, and Z unless all 3 work?

The client can examine the CAPABILITY response.  But I think there is 
still an open issue as to inclusion or exclusion of an extension 
which the client included in ENABLE but whose ENABLE-ment failed.

So, the standard/recommended command sequence might be:

a1 CAPABILITY (to see if TLS is and which authentication mechanisms 
are supported)
a2 STARTTLS (if supported)
a3 AUTHENTICATE
b1 ENABLE (to try and enable all desired mechanisms)
b2 CAPABILITY (to see which extensions are supported, and which 
extensions included in the NOTIFY command were in fact ENABLEd)

Or,

a1 CAPABILITY (to see if TLS is and which authentication mechanisms 
are supported)
a2 STARTTLS (if supported)
a3 AUTHENTICATE
b1 CAPABILITY (to see which extensions are supported)
b1 ENABLE (to try and enable all desired and supported mechanisms)

In the first case, the client learns from the post-authentication 
CAPABILITY response which extensions were successfully ENABLEd.  The 
second case, the ENABLE response needs to indicate this.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
As soon as we started programming, we found to our surprise that it
wasn't as easy to get programs right as we had thought.  Debugging had
to be discovered.  I can remember the exact instant when I realized
that a large part of my life from then on was going to be spent in
finding mistakes in my own programs.
 --Maurice Wilkes discovers debugging, 1949 (courtesy of Paul Robinson)