[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] draft-gulbrandsen-imap-enable-03
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
Because it removes the ability to use the response to determine
what is or is
I don't understand your reply. I parse it as: you prefer prohibiting
any extension that can be ENABLEd from appearing in the initial
(pre-authentication) CAPABILITY response because this way clients
can't use the initial CAPABILITY response to determine what is or is
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
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
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
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.
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.