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

[Alexey Melnikov <[e-mail]>]

Mark Crispin wrote:

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

IMHO, I think you should keep this section as there is currently no revision of
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.

Ok, you might be right for APPENDUID, but my example still stands for COPYUID, as
there is no guaranty in which order server will perform COPY of a set of messages.
Arguably MULTIAPPEND can be considered as a series of APPENDs in the order
messages were specified. On the other hand MULTIAPPEND is atomic, so server can
assign UIDs in any order it likes ;-).

I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID
response. Yes, this follows from the syntax, but this might not occur to client
impelementors. An example would be handy and as well as saying that "m:n" must not
be sent by server if m>n.

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

I didn't say blocked ;-).

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

Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: [phone]

I speak for myself only, not for my employer.
__________________________________________