[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

  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