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

[Ned Freed <[e-mail]>]

> At 7:03 PM +0000 11/9/07, Alexey Melnikov wrote:

> >>  Thus the sequence should be either
> >>  C: t1 CAPABILITY
> >>  S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
> >>  S: t1 OK foo
> >>  C: t2 ENABLE CONDSTORE X-GOOD-IDEA
> >>  S: t2 OK foo
> >>  C: t3 CAPABILITY
> >>  S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
> >>  CONDSTORE
> >>  S: t3 OK foo again
> >>
> >  I dislike that, because you now implicitly saying that there are
> > magic extensions which don't work unless the client knows how to
> > enable them. Really, the server should have advertised the
> > CONDSTORE extension to begin with.

> I agree.

> The client shouldn't have to parse both the CAPABILITY response and
> the ENABLE response to learn if an extension has been negotiated.  If
> we put all ENABLEable extensions in the CAPABILITY response, then the
> response to ENABLE can be OK even if it contains unknown extensions.

> At 2:42 PM -0800 11/9/07, Ned Freed wrote:
> >  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.

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

> At 7:59 AM -0800 11/10/07, Ned Freed wrote:
> >  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.

> >  In my approach the client authenticates and then sends the enable command
> >  followed by a capability command to see the results of the enable.

> So ENABLE returns OK even if some extensions are not known or
> couldn't be turned on for whatever reason (temporary failure of a
> resource perhaps).  The post-authentication post-ENABLE CAPABILITY
> response omits anything that failed during ENABLE.  So a
> post-authentication pre-ENABLE CAPABILITY response may be different
> from a post-authentication post-ENABLE CAPABILITY response.  That
> seems a little odd, but it may be easier on the client, since the
> client only has to parse the CAPABILITY response, not the ENABLE
> response.  But it does effectively force the sequence
> CAPABILITY-authentication-ENABLE-CAPABILITY.

Correct, but clients already have to look at capabilitiez after authentication
so this adds no overhead.

No matter how you slice it the client has to be able to determine what's
enabled - the present situation as I understand is unacceptable since
situations can arise where the client doesn't know what's on and what's off.
The three options as I seee it are:

(1) Have enable return this information as some sort of extended response.
(2) have the client send multiple enables and use the response status to
    determine success or failure.
(3) Piggyback this on the existing capabilities mechanism.

I believe (3) is the simplest by far from a client perspective. An existing,
compliant client need only add code to send a single enable command (which can
even have a fixed set of arguments). The client then uses the capability
response it already has to find out what extensions it can use, and more
importantly what changes those extenaions have made to the syntax and semantics
of server responses.

If we don't do (3) I think the only viable alternative is (1). (2) looks an
awful lot like telnet option negiation to me, which hasn't worked all that
well.

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

				Ned


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