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

From: Dan Karp <[email-masked]>
Date: Fri, 9 Nov 2007 19:35:28 -0800 (PST)

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

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 Nov 2007 07:59:30 -0800 (PST)

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

I strongly prefer a model where it is possible to check to see what's turned 
on and what is not.

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

I think the latter is safer, allows more flexibility for server
implementations, and is actually simpler on the client side ot implement.

				Ned

---

From: Dan Karp <[email-masked]>
Date: Sat, 10 Nov 2007 08:58:02 -0800 (PST)

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 Nov 2007 10:25:51 -0800 (PST)

> Yeah, but that's not how IMAP or CONDSTORE work.

We get to define how IMAP and CONDSTORE work.

> If a server supports a capability, it must come back in a
> post-authentication CAPABILITY response. 

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.

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

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sat, 10 Nov 2007 10:56:40 -0800 (PST)

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

---

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

>>>command followed by a capability command to see the results of the
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.

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

>>post-authentication CAPABILITY response. 
I agree with Dan. Note that this actually doesn't contradict what you've 
suggested.

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

>change command response syntax. In fact I think such a requirement would be a
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.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 12 Nov 2007 09:29:04 -0800 (PST)

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 12 Nov 2007 19:34:18 +0000

>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 
Agreed.
(The CAPABILITY response code works for that).