Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03
From: Randall Gellens <[email-masked]>
To: "Darryl Champagne" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "'Alexey Melnikov'" <[email-masked]>, "'Ned Freed'" <[email-masked]>
Date: Fri, 30 Nov 2007 12:17:22 -0800
List-Id: <ietf-imapext.imc.org>

At 2:01 PM -0500 11/27/07, Darryl Champagne wrote:

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

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.

>  - There is no indication if an extension is not supported (other than
>  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.

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

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)

Date: Tue, 27 Nov 2007 20:49:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Darryl Champagne <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Darryl Champagne wrote:

>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?
>
>- Enable gets registered with IANA.
>  
>
Not sure why this is important.

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

>- One can enable arbitrary extensions.
>  
>
Yes.

>- There is no indication if an extension is not supported (other than
>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.

>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?
>  
>
This should be possible: a client can construct an ENABLE command after 
checking CAPABILITY.

Date: Tue, 27 Nov 2007 20:45:29 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: "Friends of IMAP" dinner on Monday, December 3rd
Sender: [email-masked]

There seem to be some interest in having [now traditional] "friends of 
IMAP" dinner in Vancouver on Monday, December 3rd.
People who didn't tell me before and who would like to come should email 
me directly, so that I can estimate how big the reservation should be.

Date: Wed, 21 Nov 2007 19:45:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Fred Batty <[email-masked]>
CC: [email-masked]
Subject: Re: LIST-EXTENDED and child mailboxes
Sender: [email-masked]

Hi Fred,
Sorry for slow response.

Fred Batty wrote:

>Hi. I am trying to implement LIST-EXTENDED and have a problem with this
>paragraph in section 3.5:
>
>   Note: Some servers allow for mailboxes to exist without requiring
>   their parent to exist.  For example, a mailbox "Customers/ABC" can
>   exist while the mailbox "Customers" does not.  As CHILDINFO extended
>   data item is not allowed if the RECURSIVEMATCH selection option is
>   not specified, such servers SHOULD use the "\NonExistent
>   \HasChildren" attribute pair to signal to the client that there is a
>   descendant mailbox that matches the selection criteria.
>
>Doesn't it force the server to do the same work as if the client had asked for
>RECURSIVEMATCH, even when the client didn't specify it, thus probably doesn't
>care?
>
No, this text doesn't require the server to do recursive matching.
It just says that *if* the server wants to tell the client that a 
particular level of mailbox hierarchy doesn't exist, then it should 
return \NonExistent.

>If so, wouldn't this be a serious problem if the selection criteria is
>expensive to determine, e.g. involving annotations?
>
>
>Also, I guess this is more minor but shouldn't the word 'exactly' in this
>section 3.1 paragraph be replaced by 'at most':
>
>   1.  Exactly one LIST response should be returned for each mailbox
>       name which matches the canonical LIST pattern.  Server
>       implementors must not assume that clients will be able to
>       assemble mailbox attributes and other information returned in
>       multiple LIST responses.
>  
>
Noted, thanks.

Cc: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Date: Wed, 21 Nov 2007 08:50:58 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

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

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.

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

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.

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

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

Date: Wed, 21 Nov 2007 12:43:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 21 Nov 2007 11:29:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked], Ned Freed <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Dan Karp writes:
>
>> If that is the point of this, we should stop trying to be tricky and 
>> 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.

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.

Date: Wed, 21 Nov 2007 10:03:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>, Peter Coates <[email-masked]>, Dan Karp <[email-masked]>
Sender: [email-masked]

Dan Karp writes:
> If that is the point of this, we should stop trying to be tricky and 
> 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: [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, [email-masked]
Date: Tue, 20 Nov 2007 14:52:28 -0800 (PST)
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

> At 10:40 AM -0800 11/20/07, Ned Freed wrote:

> >>  Why do you prefer not having ENABLEable extensions in the initial
> >>  CAPABILITY response?
> >
> >  Because it removes the ability to use the response to determine what is or is
> >  not enabled.

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

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.

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

No, the pre-authentication response is completely irrelevant.

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

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.

> >>  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.
> >
> >  Correct, but clients already have to look at capabilitiez after
> > authentication
> >  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).

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

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

Yep, that's it.

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

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: [email-masked]
Cc: Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 20 Nov 2007 10:40:42 -0800 (PST)
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

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

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

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

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

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.

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

Yes, but IMO that's a good thing.

				Ned

Date: Tue, 20 Nov 2007 16:05:48 -0800
To: Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 2:52 PM -0800 11/20/07, Ned Freed wrote:

>>  At 10:40 AM -0800 11/20/07, Ned Freed wrote:
>
>>   >>  Why do you prefer not having ENABLEable extensions in the initial
>>>>   CAPABILITY response?
>>>
>>>   Because it removes the ability to use the response to determine 
>>> what is or is
>>>   not enabled.
>
>>  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?
>
>  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.

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.

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

>
>>  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)
>
>  Yep, that's it.

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.

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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

Date: Tue, 20 Nov 2007 11:52:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], Peter Coates <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

+1

On Tue, 20 Nov 2007, Dan Karp wrote:

>>> Why do you prefer not having ENABLEable extensions in the initial
>>> CAPABILITY response?
>>
>> 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.
>
>
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade
>

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

Date: Tue, 20 Nov 2007 11:49:19 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > Why do you prefer not having ENABLEable extensions in the initial
> > CAPABILITY response?
> 
> 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.

Date: Tue, 20 Nov 2007 11:22:56 -0800
To: Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:40 AM -0800 11/20/07, Ned Freed wrote:

>>  Why do you prefer not having ENABLEable extensions in the initial
>>  CAPABILITY response?
>
>  Because it removes the ability to use the response to determine what is or is
>  not enabled.

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?

>>  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.
>
>  Correct, but clients already have to look at capabilitiez after 
> authentication
>  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)

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

Date: Tue, 20 Nov 2007 10:33:16 -0800
To: Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
No one would choose a friendless existence even if they had
all other good things in the world.             --Aristotle

Date: Thu, 15 Nov 2007 09:29:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Sender: [email-masked]

Mark Crispin wrote:

> I am uneasy about having COMPARATOR and UNICASEMAP as separate 
> capabilities, especially since COMPARATOR implies but does not require 
> UNICASEMAP.  This means that a client that only cares about UNICASEMAP 
> capability must test for both requirements.
>
> As an alternative, how about I18NLEVEL=<version #>, where version 1 
> means UNICASEMAP capability and version 2 means COMPARATOR?  This 
> implies that any subsequent additions will be additive with all 
> previous ones being mandatory-to-implement; but I think that is the 
> right thing in this case.

Let me think about this for a bit.

> On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>
>>> I think that there should be some informative text to the effect 
>>> that the current IMAP specification specifies i;ascii-casemap, but 
>>> that for some time most servers have actually implemented 
>>> i;unicode-casemap.  So there may be legacy servers that still do 
>>> i;ascii-casemap.
>>
>> Sure. If you suggest some text I will add it ;-).
>
> How about:
>
> x. Compatibility Notes
>
>     Several server implementations deployed prior to the publication of
>     this specification comply with I18NLEVEL=1, but do not advertise
>     that.  Other legacy servers use the i;ascii-casemap (see [RFC4790])
>     comparator.
>
>     There is no good way for a client to know which comparator that a
>     legacy server uses.  If the client has to assume the worst, it may
>     end up doing expensive local operations to obtain i;unicode-casemap
>     comparisons even though the server implements it.
>
>     Legacy server implementations which comply with I18NLEVEL=1 should
>     be updated to advertise I18NLEVEL=1.  All server implementations
>     should eventually be updated to comply with I18NLEVEL=2.

Ok, this would work. I like your text.

>> An IMAP server that implements the i;unicode-casemap comparator [UCM]
>> and satisfies all requirements specified in sections 4, 4.1 and 4.2
>> of this document, but doesn't implement the COMPARATOR command and
>> response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
>> response.
>
> This is awkward: "this and this, but not that, should do the other 
> thing." Ugh.
>
> Also, 4.3 is not part of this but "section 4" implies otherwise (you 
> actually intend the introduction of section 4).

Yes, I should have moved the introduction to a subsection of section 4.1

> If we do I18NLEVEL, then the current introduction to section 4, 
> section 4.1, and section 4.2 would be the requirements of I18NLEVEL=1, 
> and I18NLEVEL=1 plus the former section 4.3 (should be a new major 
> section) would be the requirements of I18NLEVEL=2.
>
> That seems cleaner to me.

Date: Wed, 14 Nov 2007 16:55:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Organization: Networks & Distributed Computing
Sender: [email-masked]

I am uneasy about having COMPARATOR and UNICASEMAP as separate 
capabilities, especially since COMPARATOR implies but does not require 
UNICASEMAP.  This means that a client that only cares about UNICASEMAP 
capability must test for both requirements.

As an alternative, how about I18NLEVEL=<version #>, where version 1 means 
UNICASEMAP capability and version 2 means COMPARATOR?  This implies that 
any subsequent additions will be additive with all previous ones being 
mandatory-to-implement; but I think that is the right thing in this case.

On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>> I think that there should be some informative text to the effect that the 
>> current IMAP specification specifies i;ascii-casemap, but that for some 
>> time most servers have actually implemented i;unicode-casemap.  So there 
>> may be legacy servers that still do i;ascii-casemap.
> Sure. If you suggest some text I will add it ;-).

How about:

x. Compatibility Notes

     Several server implementations deployed prior to the publication of
     this specification comply with I18NLEVEL=1, but do not advertise
     that.  Other legacy servers use the i;ascii-casemap (see [RFC4790])
     comparator.

     There is no good way for a client to know which comparator that a
     legacy server uses.  If the client has to assume the worst, it may
     end up doing expensive local operations to obtain i;unicode-casemap
     comparisons even though the server implements it.

     Legacy server implementations which comply with I18NLEVEL=1 should
     be updated to advertise I18NLEVEL=1.  All server implementations
     should eventually be updated to comply with I18NLEVEL=2.

> An IMAP server that implements the i;unicode-casemap comparator [UCM]
> and satisfies all requirements specified in sections 4, 4.1 and 4.2
> of this document, but doesn't implement the COMPARATOR command and
> response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
> response.

This is awkward: "this and this, but not that, should do the other thing." 
Ugh.

Also, 4.3 is not part of this but "section 4" implies otherwise (you 
actually intend the introduction of section 4).

If we do I18NLEVEL, then the current introduction to section 4, section 
4.1, and section 4.2 would be the requirements of I18NLEVEL=1, and 
I18NLEVEL=1 plus the former section 4.3 (should be a new major section) 
would be the requirements of I18NLEVEL=2.

That seems cleaner to me.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-13.txt 
Date: Wed, 14 Nov 2007 16:15:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, et al.
	Filename	: draft-ietf-imapext-i18n-13.txt
	Pages		: 18
	Date		: 2007-11-14
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-imapext-i18n-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 14 Nov 2007 17:58:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>
>> 1). i;unicode-casemap is the mandatory to implement collation now. I 
>> also removed any requirements to implement i;octet or 
>> i;ascii-casemap, as there was no consensus to keep them.
>
> So how are i;octet and i;ascii-casemap referenced now?

They aren't. (i;octet is only references in the section which describes 
SEARCH behavior)

> I think that there should be some informative text to the effect that 
> the current IMAP specification specifies i;ascii-casemap, but that for 
> some time most servers have actually implemented i;unicode-casemap.  
> So there may be legacy servers that still do i;ascii-casemap.

Sure. If you suggest some text I will add it ;-).

> Since i;unicode-casemap references i;octet, that means that some form 
> of i;octet has to be implemented

True, but it doesn't have to be selectable using the COMPARATOR command.

> (if only as part of i;unicode-casemap). i;octet is basically memcmp() 
> with unsigned octets.
>
>> 3). Added the UNICASEMAP capability, which basically means support 
>> i;unicode-casemap + SEARCH behavior as described by the COMPARATOR 
>> extension.
>
> Also SORT and THREAD, correct?

Yes, that was the intent.
If you find that the new text is unclear, please let me know:

An IMAP server that implements the i;unicode-casemap comparator [UCM]
and satisfies all requirements specified in sections 4, 4.1 and 4.2
of this document, but doesn't implement the COMPARATOR command and
response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
response.

Date: Wed, 14 Nov 2007 08:23:54 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 Nov 2007, Alexey Melnikov wrote:
> 1). i;unicode-casemap is the mandatory to implement collation now. I also 
> removed any requirements to implement i;octet or i;ascii-casemap, as there 
> was no consensus to keep them.

So how are i;octet and i;ascii-casemap referenced now?

I think that there should be some informative text to the effect that the 
current IMAP specification specifies i;ascii-casemap, but that for some 
time most servers have actually implemented i;unicode-casemap.  So there 
may be legacy servers that still do i;ascii-casemap.

Since i;unicode-casemap references i;octet, that means that some form of 
i;octet has to be implemented (if only as part of i;unicode-casemap). 
i;octet is basically memcmp() with unsigned octets.

> 3). Added the UNICASEMAP capability, which basically means support 
> i;unicode-casemap + SEARCH behavior as described by the COMPARATOR extension.

Also SORT and THREAD, correct?

-- Mark --

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

Date: Wed, 14 Nov 2007 15:45:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: error in draft-ietf-imapext-i18n-12.txt
Sender: [email-masked]

Mark Crispin wrote:

> The word "presently" is used twice in this document.
>
> The English word "presently" means "soon"/"after a short time", as in 
> "I will wash the dishes presently."  The use of "presently" to mean 
> "currently" (which in context seems to be the intended meaning) is 
> American English slang and not accepted by all authorities.
>
> In the name of unambiguity and good diction, please change "presently" 
> to "currently" or "at present".  Thanks

I forgot to change this in -13, but this will be changed in -14.

Date: Wed, 14 Nov 2007 15:39:59 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Updated IMAP I18N document
Sender: [email-masked]

I've just posted -13, it should be announced in a couple of days. The 
following changes to the document were made:

1). i;unicode-casemap is the mandatory to implement collation now. I 
also removed any requirements to implement i;octet or i;ascii-casemap, 
as there was no consensus to keep them.

2). Updated text about use of collations in SEARCH/SORT/THREAD. This 
pretty much replaces section 4.2. Please review and let me know if you 
happy with the new text.

3). Added the UNICASEMAP capability, which basically means support 
i;unicode-casemap + SEARCH behavior as described by the COMPARATOR 
extension.

4). Updated references.

=======
Note that some other changes were discussed on the mailing list, but 
they will have to wait till -14.

Regards,
Alexey

Date: Mon, 12 Nov 2007 19:34:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Dan Karp <[email-masked]>, Peter Coates <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ned Freed wrote:

>>>>Why not just have ENABLE fail unless all the requested capabilities
>>>>are implemented and enable-able?  This would generally require waiting
>>>>until after authentication to call ENABLE, but I'm not even sure why
>>>>it's ever useful in the NOT AUTHENTICATED state...
>>>>        
>>>>
>>>Because clients can have have both features they require and features
>>>they can use if available. If things work this way a client would have
>>>to issue one ENABLE for the required stuff and then a separate ENABLE
>>>for each optional thing they can use.      
>>>
>>Why?  Authenticate, issue CAPABILITY (or get an unsolicited one from the
>>authentication step), check to see if it includes all the required
>>capabilities, and issue a single ENABLE containing all the capabilities
>>(required and desired) that you want to enable.    
>>
>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.
>  
>
Can you think of an example when enabling would fail for any reason 
other than the feature not being supported?

>I strongly prefer a model where it is possible to check to see what's turned 
>on and what is not.
>
Agreed.
(The CAPABILITY response code works for that).

Date: Mon, 12 Nov 2007 09:29:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

On Mon, 12 Nov 2007, Alexey Melnikov wrote:
> Many years ago, when I was still an IMAP client developer, I thought that the 
> CAPABILITY response is immutable for the duration of an IMAP connection (e.g. 
> before and after AUTHENTICATE/LOGIN). This doesn't seem to be the case in 
> real world now.

Nor was it ever the case.

> Many servers advertise different capabilities upon connection 
> (in the CAPABILITY response code) and after authentication.

Yes.

> However this is not explicitly defined in RFC 3501. It only says that the 
> list of capabilities can change after STARTTLS or AUTHENTICATE/LOGIN. RFC 
> 3501 is silent if the list of capabilities can change at any other moment.

I certainly hope not.  If it does, someone badly misdesigned something.

> The document is also silent on whether CAPABILITY responses/response codes 
> are additive or not (i.e. if * "CAPABILITY FOO" followed by "* CAPABILITY 
> BAR" is the same as "* CAPABILITY FOO BAR"). I think these things should be 
> clarified for the sake of existing and future client developers.

I hope that this question never comes up in real life; but I don't think 
that capabilities should be additive.

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

Date: Mon, 12 Nov 2007 13:37:24 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Dan Karp <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ned Freed wrote:

>>>>That's about as simple as you can make it if some servers won't
>>>>return a full capability list until after authentication.        
>>>>
>>>Well, let's see. In your approach the client authenticates, sends a
>>>capability command, checks the result to make sure the stuff that's
>>>required is there, and then constructs a enable command depending
>>>on that response.
>>>
>>>In my approach the client authenticates and then sends the enable
>>>command followed by a capability command to see the results of the
>>>enable.
>>>
Ned, while I agree that your proposal is simpler (when I saw your 
message I was about to reply to Dan saying that he moved complexity from 
the server end to the client end), I have to agree with Dan that what 
you propose is not what existing mail clients do.

>>Yeah, but that's not how IMAP or CONDSTORE work.
>>
>
>We get to define how IMAP and CONDSTORE work.
>
We can redefine how IMAP works with new extensions, but I don't think we 
can change CONDSTORE now, as it is an RFC for more than a year now. (But 
we still can change QRESYNC, if needed)

>>If a server supports a capability, it must come back in a
>>post-authentication CAPABILITY response. 
>>
I agree with Dan. Note that this actually doesn't contradict what you've 
suggested.

>I quite simply disagree. This may be how things have been done in the past but
>it isn't necessarily how things need to work in the future.
>
Yes, we can change how this works, but I frankly don't think that the 
client should ask for the list of available capabilities yet again after 
issuing the ENABLE command.

Many years ago, when I was still an IMAP client developer, I thought 
that the CAPABILITY response is immutable for the duration of an IMAP 
connection (e.g. before and after AUTHENTICATE/LOGIN). This doesn't seem 
to be the case in real world now. Many servers advertise different 
capabilities upon connection (in the CAPABILITY response code) and after 
authentication.
However this is not explicitly defined in RFC 3501. It only says that 
the list of capabilities can change after STARTTLS or 
AUTHENTICATE/LOGIN. RFC 3501 is silent if the list of capabilities can 
change at any other moment. The document is also silent on whether 
CAPABILITY responses/response codes are additive or not (i.e. if * 
"CAPABILITY FOO" followed by "* CAPABILITY BAR" is the same as "* 
CAPABILITY FOO BAR"). I think these things should be clarified for the 
sake of existing and future client developers.

>>Not every client will support ENABLE.  When you have extensions like CONDSTORE
>>that can be enabled either explicitly via ENABLE or implicitly via certain
>>command arguments, a non-ENABLE-savvy client will have no idea that it can use
>>CONDSTORE.
>>    
>>
>
>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 with this statement. But I think this is an orthogonal issue to 
whether something needs to be advertised in the CAPABILITY response or not.

Date: Mon, 12 Nov 2007 13:24:46 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meeting in Vancouver]
Sender: [email-masked]

--------------000608020702030204090502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I meant to send this to the IMAPEXT mailing list.

--------------000608020702030204090502
Content-Type: message/rfc822;
 name="Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meetingin Vancouver"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meetingin Vancouver"

Date: Mon, 12 Nov 2007 13:20:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Lemonade WG <[email-masked]>, IMAP Mailing List <[email-masked]>
Subject: Request to discuss draft-ietf-imapext-i18n at the Lemonade WG
         meeting in Vancouver

Hi everybody,

The IMAPEXT WG is not going to meet in Vancouver. Lemonade Profile Bis 
currently depends on draft-ietf-imapext-i18n (via LISTEXT and METADATA). 
Any objections to quickly discussing open issue with 
draft-ietf-imapext-i18n at the Lemonade WG meeting in Vancouver?

Regards,
Alexey

--------------000608020702030204090502--

Date: Mon, 12 Nov 2007 13:17:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> 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 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 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.

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

Date: Mon, 12 Nov 2007 14:12:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> 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 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

Date: Mon, 12 Nov 2007 12:56:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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.
>>>
>>> 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.
>>
>> Based on various off-list discussions I got impression that several 
>> people really disliked that.
>
> 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.

Date: Mon, 12 Nov 2007 13:54:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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.
>>
>> 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.
>
> Based on various off-list discussions I got impression that several 
> 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

Date: Sat, 10 Nov 2007 10:56:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Dan Karp <[email-masked]>, [email-masked], [email-masked], Peter Coates <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

On Sat, 10 Nov 2007, Ned Freed wrote:
> We get to define how IMAP and CONDSTORE work.

Slight note of unpleasant reality:

IMAP is a very large and complex protocol, even at its base level.  It is 
difficult to implement correctly; and fewer people are trying.

The IMAP client world is dominated by programs such as Outlook and 
Thunderbird, which use only a tiny fraction of the base specification 
facilities and (with the possible exception of UIDPLUS) none of the 
extensions.

The IMAP server world is being taken over by Exchange and GMail, neither 
of which implement more than a fraction (as in one or two) of the current 
set of extensions.  What's more, Exchange's implementation of the base 
specification is buggy, and GMail's implementation of the base 
specification is incomplete.  There are numerous other servers which have 
incomplete and/or incorrect implementations of the base specification, and 
it gets worse when you get to extensions.

Pine/Alpine is rapidly becoming less viable in the world, not because it 
is text based but because it depends upon servers that offer full and 
correct implementation of the base specification and of any extensions.

I am currently fighting a losing battle on deployment of [censored] server 
which does not correctly implement IMAP (and thus breaks Pine/Alpine) with 
the counter-argument being "it works fine for Outlook and Thunderbird."

That's right, boys and girls, you (meaning the IETF) are no longer 
defining IMAP.  Microsoft, Mozilla, Google, etc. are who defines IMAP 
today.  They may pay lip service to your definition, but they ignore it in 
real life.

It bewilders me that you are still talking about making IMAP large and 
more complex.  Do you really think that the tide is going to be turned 
back?

I now return you back to your fascinating discussion.

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

Date: Sat, 10 Nov 2007 08:58:02 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Ned Freed <[email-masked]>, Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > That's about as simple as you can make it if some servers won't
> > return a full capability list until after authentication.
> 
> Well, let's see. In your approach the client authenticates, sends a
> capability command, checks the result to make sure the stuff that's
> required is there, and then constructs a enable command depending
> on that response.
> 
> In my approach the client authenticates and then sends the enable
> command followed by a capability command to see the results of the
> enable.

Yeah, but that's not how IMAP or CONDSTORE work.  If a server supports a capability, it must come back in a post-authentication CAPABILITY response.  Not every client will support ENABLE.  When you have extensions like CONDSTORE that can be enabled either explicitly via ENABLE or implicitly via certain command arguments, a non-ENABLE-savvy client will have no idea that it can use CONDSTORE.

Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
From: Timo Sirainen <[email-masked]>
To: Dan Karp <[email-masked]>
Cc: Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Date: Sat, 10 Nov 2007 15:54:02 +0200
Sender: [email-masked]

--=-7On8w524wMwiKs5SaFt3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2007-11-09 at 09:43 -0800, Dan Karp wrote:
> I think that we're unnecessarily complicating a fundamentally simple
> idea.  Why not just have ENABLE fail unless all the requested
> capabilities are implemented and enable-able?  This would generally
> require waiting until after authentication to call ENABLE, but I'm not
> even sure why it's ever useful in the NOT AUTHENTICATED state...

I'd really like if it worked only after authentication. I think NOT
AUTHENTICATED state should be as simple as possible. The user is still
untrusted at that point, so the less features server needs to worry
about at that point, the less chances there are for bugs/security holes.

--=-7On8w524wMwiKs5SaFt3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-7On8w524wMwiKs5SaFt3--

Date: Fri, 9 Nov 2007 19:35:28 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > Why not just have ENABLE fail unless all the requested capabilities
> > are implemented and enable-able?  This would generally require waiting
> > until after authentication to call ENABLE, but I'm not even sure why
> > it's ever useful in the NOT AUTHENTICATED state...
> 
> Because clients can have have both features they require and features
> they can use if available. If things work this way a client would have
> to issue one ENABLE for the required stuff and then a separate ENABLE
> for each optional thing they can use.

Why?  Authenticate, issue CAPABILITY (or get an unsolicited one from the authentication step), check to see if it includes all the required capabilities, and issue a single ENABLE containing all the capabilities (required and desired) that you want to enable.

That's about as simple as you can make it if some servers won't return a full capability list until after authentication.

Date: Fri, 09 Nov 2007 19:03:20 +0000
From: Alexey Melnikov <[email-masked]>
To: Peter Coates <[email-masked]>
CC: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Peter Coates wrote:

>What?  If Enabling an extension does not affect the CAPABILITY vector, and
>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
> 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
>
>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
>  
>
Agreed, but this can (and I think should) be done in a way which doesn't 
contradict text I've suggested. See below.

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

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

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

Date: Fri, 9 Nov 2007 09:43:33 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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

I think that we're unnecessarily complicating a fundamentally simple idea.  Why not just have ENABLE fail unless all the requested capabilities are implemented and enable-able?  This would generally require waiting until after authentication to call ENABLE, but I'm not even sure why it's ever useful in the NOT AUTHENTICATED state...

I'm told that the "ignore unknown capabilities" behavior was added so one client author could use a static ENABLE request, but simpler is probably better here.

Date: Fri, 09 Nov 2007 09:24:40 -0800
From: Peter Coates <[email-masked]>
Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03
To: "'Alexey Melnikov'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

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

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.

Date: Fri, 09 Nov 2007 16:16:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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

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.

Date: Tue, 6 Nov 2007 18:20:52 -0800
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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.

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

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.

Date: Sun, 4 Nov 2007 11:50:33 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 4 Nov 2007 11:45:06 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> 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).

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.

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

Please discuss that with Peter Coates.

Arnt

Date: Fri, 02 Nov 2007 08:16:20 -0700
From: Peter Coates <[email-masked]>
Subject: RE: draft-gulbrandsen-imap-enable-03
To: "'Ken Murchison'" <[email-masked]>, [email-masked], "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

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

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

Date: Fri, 02 Nov 2007 07:25:01 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ken Murchison wrote:
> 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.

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?

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

Date: Fri, 02 Nov 2007 07:07:41 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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

Date: Fri, 30 Nov 2007 12:17:22 -0800
To: "Darryl Champagne" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: "'Alexey Melnikov'" <[email-masked]>, "'Ned Freed'" <[email-masked]>
Sender: [email-masked]

At 2:01 PM -0500 11/27/07, Darryl Champagne wrote:

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

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.

>  - There is no indication if an extension is not supported (other than
>  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.

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

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)

Date: Tue, 27 Nov 2007 20:49:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Darryl Champagne <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Darryl Champagne wrote:

>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?
>
>- Enable gets registered with IANA.
>  
>
Not sure why this is important.

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

>- One can enable arbitrary extensions.
>  
>
Yes.

>- There is no indication if an extension is not supported (other than
>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.

>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?
>  
>
This should be possible: a client can construct an ENABLE command after 
checking CAPABILITY.

Date: Tue, 27 Nov 2007 20:45:29 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Lemonade WG <[email-masked]>
Subject: "Friends of IMAP" dinner on Monday, December 3rd
Sender: [email-masked]

There seem to be some interest in having [now traditional] "friends of 
IMAP" dinner in Vancouver on Monday, December 3rd.
People who didn't tell me before and who would like to come should email 
me directly, so that I can estimate how big the reservation should be.

Date: Wed, 21 Nov 2007 19:45:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Fred Batty <[email-masked]>
CC: [email-masked]
Subject: Re: LIST-EXTENDED and child mailboxes
Sender: [email-masked]

Hi Fred,
Sorry for slow response.

Fred Batty wrote:

>Hi. I am trying to implement LIST-EXTENDED and have a problem with this
>paragraph in section 3.5:
>
>   Note: Some servers allow for mailboxes to exist without requiring
>   their parent to exist.  For example, a mailbox "Customers/ABC" can
>   exist while the mailbox "Customers" does not.  As CHILDINFO extended
>   data item is not allowed if the RECURSIVEMATCH selection option is
>   not specified, such servers SHOULD use the "\NonExistent
>   \HasChildren" attribute pair to signal to the client that there is a
>   descendant mailbox that matches the selection criteria.
>
>Doesn't it force the server to do the same work as if the client had asked for
>RECURSIVEMATCH, even when the client didn't specify it, thus probably doesn't
>care?
>
No, this text doesn't require the server to do recursive matching.
It just says that *if* the server wants to tell the client that a 
particular level of mailbox hierarchy doesn't exist, then it should 
return \NonExistent.

>If so, wouldn't this be a serious problem if the selection criteria is
>expensive to determine, e.g. involving annotations?
>
>
>Also, I guess this is more minor but shouldn't the word 'exactly' in this
>section 3.1 paragraph be replaced by 'at most':
>
>   1.  Exactly one LIST response should be returned for each mailbox
>       name which matches the canonical LIST pattern.  Server
>       implementors must not assume that clients will be able to
>       assemble mailbox attributes and other information returned in
>       multiple LIST responses.
>  
>
Noted, thanks.

Cc: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Date: Wed, 21 Nov 2007 08:50:58 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

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

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.

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

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.

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

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

Date: Wed, 21 Nov 2007 12:43:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 21 Nov 2007 11:29:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked], Ned Freed <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Dan Karp writes:
>
>> If that is the point of this, we should stop trying to be tricky and 
>> 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.

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.

Date: Wed, 21 Nov 2007 10:03:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>, Peter Coates <[email-masked]>, Dan Karp <[email-masked]>
Sender: [email-masked]

Dan Karp writes:
> If that is the point of this, we should stop trying to be tricky and 
> 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: [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, [email-masked]
Date: Tue, 20 Nov 2007 14:52:28 -0800 (PST)
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

> At 10:40 AM -0800 11/20/07, Ned Freed wrote:

> >>  Why do you prefer not having ENABLEable extensions in the initial
> >>  CAPABILITY response?
> >
> >  Because it removes the ability to use the response to determine what is or is
> >  not enabled.

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

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.

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

No, the pre-authentication response is completely irrelevant.

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

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.

> >>  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.
> >
> >  Correct, but clients already have to look at capabilitiez after
> > authentication
> >  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).

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

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

Yep, that's it.

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

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: [email-masked]
Cc: Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 20 Nov 2007 10:40:42 -0800 (PST)
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
To: Randall Gellens <[email-masked]>
Sender: [email-masked]

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

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

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

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

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.

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

Yes, but IMO that's a good thing.

				Ned

Date: Tue, 20 Nov 2007 16:05:48 -0800
To: Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 2:52 PM -0800 11/20/07, Ned Freed wrote:

>>  At 10:40 AM -0800 11/20/07, Ned Freed wrote:
>
>>   >>  Why do you prefer not having ENABLEable extensions in the initial
>>>>   CAPABILITY response?
>>>
>>>   Because it removes the ability to use the response to determine 
>>> what is or is
>>>   not enabled.
>
>>  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?
>
>  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.

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.

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

>
>>  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)
>
>  Yep, that's it.

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.

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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

Date: Tue, 20 Nov 2007 11:52:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Ned Freed <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], Peter Coates <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

+1

On Tue, 20 Nov 2007, Dan Karp wrote:

>>> Why do you prefer not having ENABLEable extensions in the initial
>>> CAPABILITY response?
>>
>> 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.
>
>
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade
>

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

Date: Tue, 20 Nov 2007 11:49:19 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > Why do you prefer not having ENABLEable extensions in the initial
> > CAPABILITY response?
> 
> 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.

Date: Tue, 20 Nov 2007 11:22:56 -0800
To: Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:40 AM -0800 11/20/07, Ned Freed wrote:

>>  Why do you prefer not having ENABLEable extensions in the initial
>>  CAPABILITY response?
>
>  Because it removes the ability to use the response to determine what is or is
>  not enabled.

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?

>>  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.
>
>  Correct, but clients already have to look at capabilitiez after 
> authentication
>  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)

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

Date: Tue, 20 Nov 2007 10:33:16 -0800
To: Alexey Melnikov <[email-masked]>, Peter Coates <[email-masked]>, Ned Freed <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
No one would choose a friendless existence even if they had
all other good things in the world.             --Aristotle

Date: Thu, 15 Nov 2007 09:29:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Sender: [email-masked]

Mark Crispin wrote:

> I am uneasy about having COMPARATOR and UNICASEMAP as separate 
> capabilities, especially since COMPARATOR implies but does not require 
> UNICASEMAP.  This means that a client that only cares about UNICASEMAP 
> capability must test for both requirements.
>
> As an alternative, how about I18NLEVEL=<version #>, where version 1 
> means UNICASEMAP capability and version 2 means COMPARATOR?  This 
> implies that any subsequent additions will be additive with all 
> previous ones being mandatory-to-implement; but I think that is the 
> right thing in this case.

Let me think about this for a bit.

> On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>
>>> I think that there should be some informative text to the effect 
>>> that the current IMAP specification specifies i;ascii-casemap, but 
>>> that for some time most servers have actually implemented 
>>> i;unicode-casemap.  So there may be legacy servers that still do 
>>> i;ascii-casemap.
>>
>> Sure. If you suggest some text I will add it ;-).
>
> How about:
>
> x. Compatibility Notes
>
>     Several server implementations deployed prior to the publication of
>     this specification comply with I18NLEVEL=1, but do not advertise
>     that.  Other legacy servers use the i;ascii-casemap (see [RFC4790])
>     comparator.
>
>     There is no good way for a client to know which comparator that a
>     legacy server uses.  If the client has to assume the worst, it may
>     end up doing expensive local operations to obtain i;unicode-casemap
>     comparisons even though the server implements it.
>
>     Legacy server implementations which comply with I18NLEVEL=1 should
>     be updated to advertise I18NLEVEL=1.  All server implementations
>     should eventually be updated to comply with I18NLEVEL=2.

Ok, this would work. I like your text.

>> An IMAP server that implements the i;unicode-casemap comparator [UCM]
>> and satisfies all requirements specified in sections 4, 4.1 and 4.2
>> of this document, but doesn't implement the COMPARATOR command and
>> response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
>> response.
>
> This is awkward: "this and this, but not that, should do the other 
> thing." Ugh.
>
> Also, 4.3 is not part of this but "section 4" implies otherwise (you 
> actually intend the introduction of section 4).

Yes, I should have moved the introduction to a subsection of section 4.1

> If we do I18NLEVEL, then the current introduction to section 4, 
> section 4.1, and section 4.2 would be the requirements of I18NLEVEL=1, 
> and I18NLEVEL=1 plus the former section 4.3 (should be a new major 
> section) would be the requirements of I18NLEVEL=2.
>
> That seems cleaner to me.

Date: Wed, 14 Nov 2007 16:55:50 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Organization: Networks & Distributed Computing
Sender: [email-masked]

I am uneasy about having COMPARATOR and UNICASEMAP as separate 
capabilities, especially since COMPARATOR implies but does not require 
UNICASEMAP.  This means that a client that only cares about UNICASEMAP 
capability must test for both requirements.

As an alternative, how about I18NLEVEL=<version #>, where version 1 means 
UNICASEMAP capability and version 2 means COMPARATOR?  This implies that 
any subsequent additions will be additive with all previous ones being 
mandatory-to-implement; but I think that is the right thing in this case.

On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>> I think that there should be some informative text to the effect that the 
>> current IMAP specification specifies i;ascii-casemap, but that for some 
>> time most servers have actually implemented i;unicode-casemap.  So there 
>> may be legacy servers that still do i;ascii-casemap.
> Sure. If you suggest some text I will add it ;-).

How about:

x. Compatibility Notes

     Several server implementations deployed prior to the publication of
     this specification comply with I18NLEVEL=1, but do not advertise
     that.  Other legacy servers use the i;ascii-casemap (see [RFC4790])
     comparator.

     There is no good way for a client to know which comparator that a
     legacy server uses.  If the client has to assume the worst, it may
     end up doing expensive local operations to obtain i;unicode-casemap
     comparisons even though the server implements it.

     Legacy server implementations which comply with I18NLEVEL=1 should
     be updated to advertise I18NLEVEL=1.  All server implementations
     should eventually be updated to comply with I18NLEVEL=2.

> An IMAP server that implements the i;unicode-casemap comparator [UCM]
> and satisfies all requirements specified in sections 4, 4.1 and 4.2
> of this document, but doesn't implement the COMPARATOR command and
> response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
> response.

This is awkward: "this and this, but not that, should do the other thing." 
Ugh.

Also, 4.3 is not part of this but "section 4" implies otherwise (you 
actually intend the introduction of section 4).

If we do I18NLEVEL, then the current introduction to section 4, section 
4.1, and section 4.2 would be the requirements of I18NLEVEL=1, and 
I18NLEVEL=1 plus the former section 4.3 (should be a new major section) 
would be the requirements of I18NLEVEL=2.

That seems cleaner to me.

-- Mark --

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-13.txt 
Date: Wed, 14 Nov 2007 16:15:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, et al.
	Filename	: draft-ietf-imapext-i18n-13.txt
	Pages		: 18
	Date		: 2007-11-14
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-imapext-i18n-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 14 Nov 2007 17:58:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 14 Nov 2007, Alexey Melnikov wrote:
>
>> 1). i;unicode-casemap is the mandatory to implement collation now. I 
>> also removed any requirements to implement i;octet or 
>> i;ascii-casemap, as there was no consensus to keep them.
>
> So how are i;octet and i;ascii-casemap referenced now?

They aren't. (i;octet is only references in the section which describes 
SEARCH behavior)

> I think that there should be some informative text to the effect that 
> the current IMAP specification specifies i;ascii-casemap, but that for 
> some time most servers have actually implemented i;unicode-casemap.  
> So there may be legacy servers that still do i;ascii-casemap.

Sure. If you suggest some text I will add it ;-).

> Since i;unicode-casemap references i;octet, that means that some form 
> of i;octet has to be implemented

True, but it doesn't have to be selectable using the COMPARATOR command.

> (if only as part of i;unicode-casemap). i;octet is basically memcmp() 
> with unsigned octets.
>
>> 3). Added the UNICASEMAP capability, which basically means support 
>> i;unicode-casemap + SEARCH behavior as described by the COMPARATOR 
>> extension.
>
> Also SORT and THREAD, correct?

Yes, that was the intent.
If you find that the new text is unclear, please let me know:

An IMAP server that implements the i;unicode-casemap comparator [UCM]
and satisfies all requirements specified in sections 4, 4.1 and 4.2
of this document, but doesn't implement the COMPARATOR command and
response, SHOULD advertise the UNICASEMAP capability in the CAPABILITY
response.

Date: Wed, 14 Nov 2007 08:23:54 -0800
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Updated IMAP I18N document
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 14 Nov 2007, Alexey Melnikov wrote:
> 1). i;unicode-casemap is the mandatory to implement collation now. I also 
> removed any requirements to implement i;octet or i;ascii-casemap, as there 
> was no consensus to keep them.

So how are i;octet and i;ascii-casemap referenced now?

I think that there should be some informative text to the effect that the 
current IMAP specification specifies i;ascii-casemap, but that for some 
time most servers have actually implemented i;unicode-casemap.  So there 
may be legacy servers that still do i;ascii-casemap.

Since i;unicode-casemap references i;octet, that means that some form of 
i;octet has to be implemented (if only as part of i;unicode-casemap). 
i;octet is basically memcmp() with unsigned octets.

> 3). Added the UNICASEMAP capability, which basically means support 
> i;unicode-casemap + SEARCH behavior as described by the COMPARATOR extension.

Also SORT and THREAD, correct?

-- Mark --

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

Date: Wed, 14 Nov 2007 15:45:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: error in draft-ietf-imapext-i18n-12.txt
Sender: [email-masked]

Mark Crispin wrote:

> The word "presently" is used twice in this document.
>
> The English word "presently" means "soon"/"after a short time", as in 
> "I will wash the dishes presently."  The use of "presently" to mean 
> "currently" (which in context seems to be the intended meaning) is 
> American English slang and not accepted by all authorities.
>
> In the name of unambiguity and good diction, please change "presently" 
> to "currently" or "at present".  Thanks

I forgot to change this in -13, but this will be changed in -14.

Date: Wed, 14 Nov 2007 15:39:59 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Updated IMAP I18N document
Sender: [email-masked]

I've just posted -13, it should be announced in a couple of days. The 
following changes to the document were made:

1). i;unicode-casemap is the mandatory to implement collation now. I 
also removed any requirements to implement i;octet or i;ascii-casemap, 
as there was no consensus to keep them.

2). Updated text about use of collations in SEARCH/SORT/THREAD. This 
pretty much replaces section 4.2. Please review and let me know if you 
happy with the new text.

3). Added the UNICASEMAP capability, which basically means support 
i;unicode-casemap + SEARCH behavior as described by the COMPARATOR 
extension.

4). Updated references.

=======
Note that some other changes were discussed on the mailing list, but 
they will have to wait till -14.

Regards,
Alexey

Date: Mon, 12 Nov 2007 19:34:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Dan Karp <[email-masked]>, Peter Coates <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ned Freed wrote:

>>>>Why not just have ENABLE fail unless all the requested capabilities
>>>>are implemented and enable-able?  This would generally require waiting
>>>>until after authentication to call ENABLE, but I'm not even sure why
>>>>it's ever useful in the NOT AUTHENTICATED state...
>>>>        
>>>>
>>>Because clients can have have both features they require and features
>>>they can use if available. If things work this way a client would have
>>>to issue one ENABLE for the required stuff and then a separate ENABLE
>>>for each optional thing they can use.      
>>>
>>Why?  Authenticate, issue CAPABILITY (or get an unsolicited one from the
>>authentication step), check to see if it includes all the required
>>capabilities, and issue a single ENABLE containing all the capabilities
>>(required and desired) that you want to enable.    
>>
>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.
>  
>
Can you think of an example when enabling would fail for any reason 
other than the feature not being supported?

>I strongly prefer a model where it is possible to check to see what's turned 
>on and what is not.
>
Agreed.
(The CAPABILITY response code works for that).

Date: Mon, 12 Nov 2007 09:29:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

On Mon, 12 Nov 2007, Alexey Melnikov wrote:
> Many years ago, when I was still an IMAP client developer, I thought that the 
> CAPABILITY response is immutable for the duration of an IMAP connection (e.g. 
> before and after AUTHENTICATE/LOGIN). This doesn't seem to be the case in 
> real world now.

Nor was it ever the case.

> Many servers advertise different capabilities upon connection 
> (in the CAPABILITY response code) and after authentication.

Yes.

> However this is not explicitly defined in RFC 3501. It only says that the 
> list of capabilities can change after STARTTLS or AUTHENTICATE/LOGIN. RFC 
> 3501 is silent if the list of capabilities can change at any other moment.

I certainly hope not.  If it does, someone badly misdesigned something.

> The document is also silent on whether CAPABILITY responses/response codes 
> are additive or not (i.e. if * "CAPABILITY FOO" followed by "* CAPABILITY 
> BAR" is the same as "* CAPABILITY FOO BAR"). I think these things should be 
> clarified for the sake of existing and future client developers.

I hope that this question never comes up in real life; but I don't think 
that capabilities should be additive.

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

Date: Mon, 12 Nov 2007 13:37:24 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Dan Karp <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ned Freed wrote:

>>>>That's about as simple as you can make it if some servers won't
>>>>return a full capability list until after authentication.        
>>>>
>>>Well, let's see. In your approach the client authenticates, sends a
>>>capability command, checks the result to make sure the stuff that's
>>>required is there, and then constructs a enable command depending
>>>on that response.
>>>
>>>In my approach the client authenticates and then sends the enable
>>>command followed by a capability command to see the results of the
>>>enable.
>>>
Ned, while I agree that your proposal is simpler (when I saw your 
message I was about to reply to Dan saying that he moved complexity from 
the server end to the client end), I have to agree with Dan that what 
you propose is not what existing mail clients do.

>>Yeah, but that's not how IMAP or CONDSTORE work.
>>
>
>We get to define how IMAP and CONDSTORE work.
>
We can redefine how IMAP works with new extensions, but I don't think we 
can change CONDSTORE now, as it is an RFC for more than a year now. (But 
we still can change QRESYNC, if needed)

>>If a server supports a capability, it must come back in a
>>post-authentication CAPABILITY response. 
>>
I agree with Dan. Note that this actually doesn't contradict what you've 
suggested.

>I quite simply disagree. This may be how things have been done in the past but
>it isn't necessarily how things need to work in the future.
>
Yes, we can change how this works, but I frankly don't think that the 
client should ask for the list of available capabilities yet again after 
issuing the ENABLE command.

Many years ago, when I was still an IMAP client developer, I thought 
that the CAPABILITY response is immutable for the duration of an IMAP 
connection (e.g. before and after AUTHENTICATE/LOGIN). This doesn't seem 
to be the case in real world now. Many servers advertise different 
capabilities upon connection (in the CAPABILITY response code) and after 
authentication.
However this is not explicitly defined in RFC 3501. It only says that 
the list of capabilities can change after STARTTLS or 
AUTHENTICATE/LOGIN. RFC 3501 is silent if the list of capabilities can 
change at any other moment. The document is also silent on whether 
CAPABILITY responses/response codes are additive or not (i.e. if * 
"CAPABILITY FOO" followed by "* CAPABILITY BAR" is the same as "* 
CAPABILITY FOO BAR"). I think these things should be clarified for the 
sake of existing and future client developers.

>>Not every client will support ENABLE.  When you have extensions like CONDSTORE
>>that can be enabled either explicitly via ENABLE or implicitly via certain
>>command arguments, a non-ENABLE-savvy client will have no idea that it can use
>>CONDSTORE.
>>    
>>
>
>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 with this statement. But I think this is an orthogonal issue to 
whether something needs to be advertised in the CAPABILITY response or not.

Date: Mon, 12 Nov 2007 13:24:46 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meeting in Vancouver]
Sender: [email-masked]

--------------000608020702030204090502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I meant to send this to the IMAPEXT mailing list.

--------------000608020702030204090502
Content-Type: message/rfc822;
 name="Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meetingin Vancouver"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Request to discuss draft-ietf-imapext-i18n at the Lemonade WG         meetingin Vancouver"

Date: Mon, 12 Nov 2007 13:20:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Lemonade WG <[email-masked]>, IMAP Mailing List <[email-masked]>
Subject: Request to discuss draft-ietf-imapext-i18n at the Lemonade WG
         meeting in Vancouver

Hi everybody,

The IMAPEXT WG is not going to meet in Vancouver. Lemonade Profile Bis 
currently depends on draft-ietf-imapext-i18n (via LISTEXT and METADATA). 
Any objections to quickly discussing open issue with 
draft-ietf-imapext-i18n at the Lemonade WG meeting in Vancouver?

Regards,
Alexey

--------------000608020702030204090502--

Date: Mon, 12 Nov 2007 13:17:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> 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 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 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.

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

Date: Mon, 12 Nov 2007 14:12:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> 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 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

Date: Mon, 12 Nov 2007 12:56:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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.
>>>
>>> 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.
>>
>> Based on various off-list discussions I got impression that several 
>> people really disliked that.
>
> 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.

Date: Mon, 12 Nov 2007 13:54:02 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

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.
>>
>> 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.
>
> Based on various off-list discussions I got impression that several 
> 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

Date: Sat, 10 Nov 2007 10:56:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Dan Karp <[email-masked]>, [email-masked], [email-masked], Peter Coates <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

On Sat, 10 Nov 2007, Ned Freed wrote:
> We get to define how IMAP and CONDSTORE work.

Slight note of unpleasant reality:

IMAP is a very large and complex protocol, even at its base level.  It is 
difficult to implement correctly; and fewer people are trying.

The IMAP client world is dominated by programs such as Outlook and 
Thunderbird, which use only a tiny fraction of the base specification 
facilities and (with the possible exception of UIDPLUS) none of the 
extensions.

The IMAP server world is being taken over by Exchange and GMail, neither 
of which implement more than a fraction (as in one or two) of the current 
set of extensions.  What's more, Exchange's implementation of the base 
specification is buggy, and GMail's implementation of the base 
specification is incomplete.  There are numerous other servers which have 
incomplete and/or incorrect implementations of the base specification, and 
it gets worse when you get to extensions.

Pine/Alpine is rapidly becoming less viable in the world, not because it 
is text based but because it depends upon servers that offer full and 
correct implementation of the base specification and of any extensions.

I am currently fighting a losing battle on deployment of [censored] server 
which does not correctly implement IMAP (and thus breaks Pine/Alpine) with 
the counter-argument being "it works fine for Outlook and Thunderbird."

That's right, boys and girls, you (meaning the IETF) are no longer 
defining IMAP.  Microsoft, Mozilla, Google, etc. are who defines IMAP 
today.  They may pay lip service to your definition, but they ignore it in 
real life.

It bewilders me that you are still talking about making IMAP large and 
more complex.  Do you really think that the tide is going to be turned 
back?

I now return you back to your fascinating discussion.

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

Date: Sat, 10 Nov 2007 08:58:02 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Ned Freed <[email-masked]>, Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > That's about as simple as you can make it if some servers won't
> > return a full capability list until after authentication.
> 
> Well, let's see. In your approach the client authenticates, sends a
> capability command, checks the result to make sure the stuff that's
> required is there, and then constructs a enable command depending
> on that response.
> 
> In my approach the client authenticates and then sends the enable
> command followed by a capability command to see the results of the
> enable.

Yeah, but that's not how IMAP or CONDSTORE work.  If a server supports a capability, it must come back in a post-authentication CAPABILITY response.  Not every client will support ENABLE.  When you have extensions like CONDSTORE that can be enabled either explicitly via ENABLE or implicitly via certain command arguments, a non-ENABLE-savvy client will have no idea that it can use CONDSTORE.

Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
From: Timo Sirainen <[email-masked]>
To: Dan Karp <[email-masked]>
Cc: Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Date: Sat, 10 Nov 2007 15:54:02 +0200
Sender: [email-masked]

--=-7On8w524wMwiKs5SaFt3
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2007-11-09 at 09:43 -0800, Dan Karp wrote:
> I think that we're unnecessarily complicating a fundamentally simple
> idea.  Why not just have ENABLE fail unless all the requested
> capabilities are implemented and enable-able?  This would generally
> require waiting until after authentication to call ENABLE, but I'm not
> even sure why it's ever useful in the NOT AUTHENTICATED state...

I'd really like if it worked only after authentication. I think NOT
AUTHENTICATED state should be as simple as possible. The user is still
untrusted at that point, so the less features server needs to worry
about at that point, the less chances there are for bugs/security holes.

--=-7On8w524wMwiKs5SaFt3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-7On8w524wMwiKs5SaFt3--

Date: Fri, 9 Nov 2007 19:35:28 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Peter Coates <[email-masked]>, [email-masked], [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

> > Why not just have ENABLE fail unless all the requested capabilities
> > are implemented and enable-able?  This would generally require waiting
> > until after authentication to call ENABLE, but I'm not even sure why
> > it's ever useful in the NOT AUTHENTICATED state...
> 
> Because clients can have have both features they require and features
> they can use if available. If things work this way a client would have
> to issue one ENABLE for the required stuff and then a separate ENABLE
> for each optional thing they can use.

Why?  Authenticate, issue CAPABILITY (or get an unsolicited one from the authentication step), check to see if it includes all the required capabilities, and issue a single ENABLE containing all the capabilities (required and desired) that you want to enable.

That's about as simple as you can make it if some servers won't return a full capability list until after authentication.

Date: Fri, 09 Nov 2007 19:03:20 +0000
From: Alexey Melnikov <[email-masked]>
To: Peter Coates <[email-masked]>
CC: "'Arnt Gulbrandsen'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Peter Coates wrote:

>What?  If Enabling an extension does not affect the CAPABILITY vector, and
>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
> 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
>
>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
>  
>
Agreed, but this can (and I think should) be done in a way which doesn't 
contradict text I've suggested. See below.

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

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

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

Date: Fri, 9 Nov 2007 09:43:33 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Peter Coates <[email-masked]>
Cc: [email-masked], [email-masked], Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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

I think that we're unnecessarily complicating a fundamentally simple idea.  Why not just have ENABLE fail unless all the requested capabilities are implemented and enable-able?  This would generally require waiting until after authentication to call ENABLE, but I'm not even sure why it's ever useful in the NOT AUTHENTICATED state...

I'm told that the "ignore unknown capabilities" behavior was added so one client author could use a static ENABLE request, but simpler is probably better here.

Date: Fri, 09 Nov 2007 09:24:40 -0800
From: Peter Coates <[email-masked]>
Subject: RE: [lemonade] draft-gulbrandsen-imap-enable-03
To: "'Alexey Melnikov'" <[email-masked]>, "'Arnt Gulbrandsen'" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

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

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

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.

Date: Fri, 09 Nov 2007 16:16:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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

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.

Date: Tue, 6 Nov 2007 18:20:52 -0800
To: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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.

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

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.

Date: Sun, 4 Nov 2007 11:50:33 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 4 Nov 2007 11:45:06 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Cc: Ken Murchison <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> 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).

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.

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

Please discuss that with Peter Coates.

Arnt

Date: Fri, 02 Nov 2007 08:16:20 -0700
From: Peter Coates <[email-masked]>
Subject: RE: draft-gulbrandsen-imap-enable-03
To: "'Ken Murchison'" <[email-masked]>, [email-masked], "'IMAP Extensions WG'" <[email-masked]>
Sender: [email-masked]

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

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

Date: Fri, 02 Nov 2007 07:25:01 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

Ken Murchison wrote:
> 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.

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?

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

Date: Fri, 02 Nov 2007 07:07:41 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: draft-gulbrandsen-imap-enable-03
Sender: [email-masked]

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