begin quotation by Mark Crispin on 2002/9/25 9:57 -0700:
> If that is the case, would there be any objection to folding the
> MULTIAPPEND draft into the base specification? Unlike other extensions,
> MULTIAPPEND is not a new command; it is an obvious compatible enhancement
> to the APPEND command which should have been made to begin with. We
> would still have the MULTIAPPEND extension to indicate that the server
> accepts the MULTIAPPEND syntax.
I am opposed to moving MULTIAPPEND into the base spec. On the following
grounds:
1) It is largely an optimization option as opposed to a necessary option.
We shouldn't put things in the base spec that don't have to be there.
2) It has not deployed sufficiently widely to justify the merge.
3) As I've previously stated a year or so ago, I don't believe MULTIAPPEND
is the best way to solve the problem (you can either fill the pipe via
LITERAL+ _or_ get intermediate success results; you can't do both). As I
lack the time to write up a complete alternative proposal I'm not going to
object to MULTIAPPEND in last call as a separate extension. But I do
object to adding it to the base spec.
4) The base spec is already long, we should only make it longer for
extremely good reasons.
> There is another advantage, which is that IESG has asked why MULTIAPPEND
> is needed (or why isn't it in APPEND).
Some of the IESG just doesn't understand IMAP or the distinction between a
transfer protocol (which should remain simple indefinitely) and an access
protocol (which has to get increasingly complex over time). I suggest we
determine which IESG members have the most trouble understanding those
concepts and provide appropriate feedback to the nominations commitee. I
prefer to fix the source of the problem rather than work around the
symptoms.
> I have NOT folded the MULTIAPPEND text into the base specification. In
> general, I think that it is a bad idea to have extensions in the base
> specification. However, we already have done so with STARTTLS and
> AUTH=???, and I think that a case can be made that MULTIAPPEND is also
> special.
We have to put STARTTLS and LOGINDISABLED in the base spec so that we can
mandate an interoperable authentication solution that's better than
unencrypted plaintext passwords.
The only other extension I'd consider folding into the base spec is
NAMESPACE because it works around an interoperability problem in the base
spec, but I'm not convinced it's been sufficiently successful to justify
that step.
> The new base specification uses RFC 2595 as normative for STARTTLS and
> AUTH=PLAIN, but modifies the STARTTLS specification. Should the base
> specification incorporate the STARTTLS specification (thus obsoleting RFC
> 2595 in that regard), and use RFC 2595 as normative only for AUTH=PLAIN?
Sounds like a reasonable plan.
- Chris
