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

From: Dan Karp <[email-masked]>
Date: Fri, 9 Nov 2007 09:43:33 -0800 (PST)

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

_______________________________________________
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: Fri, 09 Nov 2007 14:42:08 -0800 (PST)

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

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.

Some clients may be able to get away with requiring certain extensions be
present. Others have to work in more heterogenous environments.

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

Your proposal is at least a complex IMO.

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.

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 10 Nov 2007 15:54:02 +0200

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.