Subject: [lemonade] Dis-ENABLEd Chair

From: Eric Burger <[email-masked]>
Date: Fri, 07 Dec 2007 16:36:17 -0500

I do not fully understand ENABLE, and from the nearly 50 messages on the
list, it is not clear that it is clear what it is for.

For example, the text says the purpose of ENABLE is for the *client* to tell
the *server* the client can support some extensions.  Think of it as push
CAPABILITIES ;-)

Great.  So now I do not understand any of the discussion about CAPABILITY.
For that matter, I do not understand the example in
draft-gulbrandsen-imap-enable-03.  Namely, why is CONDSTORE not in the
initial CAPABILITY?  I don't see anything in RFC 4551 that says, "keep this
a secret until the client logs in" or "keep this a secret until the client
ENABLEs condstore."

As far as I can tell, there is nothing in imap-enable to say *what* a server
*does* with ENABLE.  All it does is says it lets the server know the client
supports the extension.  Like the text says, "most IMAP implementations do
not require the client to enable the extension in any way."  This would
imply the specifications for CONDSTORE and ANNOTATE have text explaining how
the client has to issue an ENABLE, or at least have text explaining how it
would be good if the client issues an ENABLE.  However, they do not.

The text says ENABLE "turns on" extensions without side effects.  But it
never says why that is important.

Text describing *why* we do ENABLE and *how* it works would go a long way.

I would offer that would end decisively the mystery of CAPABILITY values
coming and going (yes or now).  Likewise, it would end decisively the
question of whether there is any value to the server returning BAD for a
capability that exists but is not available to the client.  If the
capability is not available to the client, it does not get listed to the
client in the CAPABILITY response.  If it does not get listed, then the
client never even thinks of issuing an ENABLE, because the server has told
the client the server does not support the capability.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 07 Dec 2007 19:58:03 -0800

Hi Eric,

> Text describing *why* we do ENABLE and *how* it works would go a long way.

One key reason:

Some IMAP extensions allow the server to return unsolicited responses 
specific to that extension in certain circumstances. However, servers 
cannot send those unsolicited responses until they know that the clients 
"know" about the extension and thus won't choke on the extension response 
data.

Up until now extensions have typically stated that a server cannot send the 
unsolicited responses until after the client has used a command with the 
extension data (i.e. at that point the server knows the client is aware of 
the extension). This is somewhat awkward.

What ENABLE does is provide an explicit indication from the client that it 
supports a particular extension. As soon as it sees that the server knows 
that extension response data for the enabled extensions is OK to send.

I will leave it to someone else to explain the interaction with CAPABILITY.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Dec 2007 04:55:10 +0000

>a secret until the client logs in" or "keep this a secret until the client
Indeed. I don't believe this behavior is described in RFC 3501 either, 
but in practice several servers "hide" some capabilities before 
authentication and list a full (or different) set of capabilities after 
authentication.

Arguably, this is something that needs to be clarifier in 3501bis.

 [...]

>coming and going (yes or no).  Likewise, it would end decisively the
>capability that exists but is not available to the client.
>
I hope this particular issue is closed: server should never reject 
extensions that can't be enabled with BAD.

>If the capability is not available to the client, it does not get listed to the
Several people have requested to allow ENABLE to be used in "dumb mode", 
i.e. the client just tries to ENABLE all extensions is supports 
unconditionally. This might save a roundtrip in some cases.
This can also be used by clients to tell servers their capabilities, 
kind of CAPABILITY command in reverse.

---

From: Eric Burger <[email-masked]>
Date: Fri, 14 Dec 2007 07:37:10 -0500

Anyone have a problem including this (or similar) explanatory text in the
document?

Remember, implementers will be even more clueless than your Chairs.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 16 Dec 2007 18:05:57 +0000

>Remember, implementers will be even more clueless than your Chairs.
No objection from me.
A reworded version of Cyrus' text will appear in -05.