Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard

[Mark Crispin <[e-mail]>]

I have read and considered Alexey's comment.

I believe that the underlying problem is with RFC 2359 (which the IESG has
already accepted as a Proposed Standard), and not with the MULTIAPPEND
extension.  The section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND
works with RFC 2359.

If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes
in his postscript ("The same problem exists with COPYUID response code
described in UIDPLUS extension").  If so, then the proper action is to block
further standards-track advancement of RFC 2359 until this problem is fixed in
a revision to RFC 2359.  The MULTIAPPEND extension can be published by
eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension", and require that the revision to RFC 2359 document how UIDPLUS
should work in the MULTIAPPEND extension.

Disclaimer: I do not implement the UIDPLUS extension, so it's of little
consequence to me if it is blocked.  It is, however, of great consequence if
MULTIAPPEND is blocked since MULTIAPPEND is a major performace and
functionality boost.

I am not convinced that Alexey's concerns are valid.

Given his example of
	a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.
his possible interpretation of
	#1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)
is forbidden by RFC 2060, section 2.3.1.1:
   [...]  Unique identifiers are assigned in a strictly ascending
   fashion in the mailbox; as each message is added to the mailbox it is
   assigned a higher UID than the message(s) which were added
   previously.
This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to
RFC 2060 which is currently in IESG last call.  Consequently, only the
interpretation:
	#1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)
is valid.

Furthermore, the specific example ("10121:10117") is silly and in all other
cases in IMAP is exactly equivalent to 10117:10221.

In conclusion, I do not believe that MULTIAPPEND should be blocked for
publication by this concern; and if this concern triggers any action it should
be in the form of a revision to RFC 2359.  Nothing in the MULTIAPPEND
extension can define the semantics of UIDPLUS behavior; such definition
belongs in the UIDPLUS extension (RFC 2359 or successor).

-- Mark --