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

>> There are only two choices, and in no one's reckoning does two count
>> as "several".
>
> I thought several was any number other than 1.

This is just for fun now, because it really doesn't matter either way:
Well, dictionary.reference.com says...

   1. being more than two but fewer than many in number or kind:
         several ways of doing it.

In general, if you said "Barry has several Furbies," and it turned out
I had two, no one would say you were wrong, but many might accuse you
of exaggerating.  (In fact, I have no Furbies
<https://en.wikipedia.org/wiki/Furby>; sorry.)

>> 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")?
>
> No, the sentence is correct as written. Some servers send BAD right after
> observing the non-synchronising literal prefix and that is Ok.

Hm, but then I think the sentence is meaningless.  The server still
has to read and discard the literal, so whether it sends the BAD
before or after it does that hardly matters.  What are you really
trying to say with that parenthetical that's useful?

>> -- Section 5 --
>> Substantive: Shouldn't references to "APPEND" be removed from here,
>> since we re-spun LITERAL- as applying to all commands?
>
> I double check, but I prefer to keep it.

Really?  Why.  My understanding was that the working group agreed that
the 4K limitation on LITERAL- applies to all literals, not just those
in APPEND commands.  So why should this text explicitly talk about
APPEND?

>> 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.
...
>> 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].
>
> Hmm. Or it can close the connection. I will try to reword, as your text
> seems to imply that that is the only option.

I'll look forward to your rewording.

Barry

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