Re: AD review of draft-ietf-imapapnd-rfc2088bis-03

Hi Barry,
I've applied most of the comments (thank you!). Regarding the two
remaining issues:

On 04/03/2016 23:03, Barry Leiba wrote:
> Here's my review of draft-ietf-imapapnd-rfc2088bis-03.  Much of this
> is editorial, but there are a couple of substantive things here.


> In bullet 1:
> 
>        (The server is allowed to send the tagged BAD/NO response before
>        reading the whole non-synchronizing literal.)
> 
> Substantive: Shouldn't that be "the server is not allowed" (missing "not")?

I reply to this in a separate email.

> 
> -- Section 5 --
> Substantive: Shouldn't references to "APPEND" be removed from here,
> since we re-spun LITERAL- as applying to all commands?  Also, the last
> sentence doesn't really make sense.  In order to reject the command
> with BAD and TOOBIG, the server has to read (and discard) the literal
> -- that is, it's already processing according to bullet 1 in Section
> 4.

I fixed the problem you stated in the last sentence, see below.

> So:
> 
> OLD
>    The "LITERAL-" extension is almost identical to "LITERAL+", with one
>    exception: when "LITERAL-" is advertised, non-synchronizing literals
>    used in any command MUST NOT be larger than 4096 bytes.  Any literal
>    larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing
>    literal.  A "LITERAL-" compliant server that encounters a non-
>    synchronizing literal in APPEND larger than 4096 bytes MUST reject
>    such APPEND command with a tagged BAD response that contains the
>    TOOBIG response code [RFC4469].  It then MAY proceed as described in
>    Section 4.
> 
> NEW
>    The "LITERAL-" extension is almost identical to "LITERAL+", with one
>    exception: when "LITERAL-" is advertised, non-synchronizing literals
>    used in any command MUST NOT be larger than 4096 bytes.  Any literal
>    larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing
>    literal.  A "LITERAL-" compliant server that encounters a non-
>    synchronizing literal larger than 4096 bytes MUST read (and discard)
>    the literal, and then reject the command with a tagged BAD response
>    that contains the TOOBIG response code [RFC4469].
> 
> END

Unfortunately TOOBIG is defined as:

4.2.  TOOBIG Response

   The TOOBIG response code is returned if the resulting message will
   exceed the 4-GB IMAP message limit.  This might happen, for example,
   if the client specifies 3 URLs for 2-GB messages.  Note that even if
   the server doesn't return TOOBIG, it still has to be defensive
   against misbehaving or malicious clients that try to construct a
   message over the 4-GB limit.  The server may also wish to return the
   TOOBIG response code if the resulting message exceeds a server-
   specific message size limit.

So this is really APPEND specific. And I think having a response code is
important to debugging and problem diagnostic. So I initially rewrote
the last sentence as:

   A "LITERAL-" compliant server that encounters a non-synchronizing
   literal larger than 4096 bytes MUST read (and discard) the literal,
   and then reject the command with a tagged BAD response. If
   responding to an APPEND command, the tagged BAD response that
   contains the TOOBIG response code <xref target="RFC4469"/>.

However, I realized that the server should still be allowed to return
BYE and disconnect. So my final version is:

   A "LITERAL-" compliant server that encounters a non-synchronizing
   literal larger than 4096 bytes proceeds as described in
   Section 4. If responding to an APPEND command, the tagged BAD
   response MUST contains the TOOBIG response code [RFC4469].
   If responding with untagged BYE response, it SHOULD include
   the TOOBIG response code.

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext