I'm afraid that we are reaching (or have already reached) the point where we
will have to do another Last Call.
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.
There is another advantage, which is that IESG has asked why MULTIAPPEND is
needed (or why isn't it in APPEND). The answer is simple but remains non-
obvious:
1) it provides an atomic append of multiple messages.
2) it is superior to LITERAL+ with single append in this regard, and
equivalent in RTTs.
3) LITERAL+ can be used with MULTIAPPEND to eliminate all per-message RTTs.
I think that we can better answer the question by folding MULTIAPPEND into the
base specification as a "server-optional" extended APPEND syntax. That way,
it becomes clear that it isn't a "different" APPEND, but rather an extension
to APPEND.
There is, however, a disadvantage. Either RFC 2359 would have to be made
normative to the base specification (with the base specification modifying RFC
2359), or RFC 2359 would have to be revised to the new base specification. I
think that it is preferable to do the latter, meaning that the MULTIAPPEND
text in the base specification would not reference RFC 2359.
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.
While I am at it....
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?
I would not think of suggesting such things if it weren't for the fact that I
think we're going to need to take it back to a new Last Call.
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
