Re: [imapext] Referencing RFC 2088 (was: AD review of draft-ietf-imapapnd-appendlimit-extension-06)

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "S Moonesamy" <[e-mail]>
To: "[e-mail]" <[e-mail]>; "Jayantheesh S B" 
<[e-mail]>; "Narendra Bisht" <[e-mail]>; 
"Alexey Melnikov" <[e-mail]>
Cc: "[e-mail]" 
<[e-mail]>; "Barry Leiba" 
<[e-mail]>; "[e-mail]" <[e-mail]>
Sent: 9/12/2015 4:05:57 a.m.
Subject: [imapext] Referencing RFC 2088 (was: AD review of 
draft-ietf-imapapnd-appendlimit-extension-06)

>Hi Jay, Naren, Alexey,
>
>Although I did not mention all the working group participants by name, 
>please comment if you have an opinion about this.
>
>At 10:24 07-12-2015, Barry Leiba wrote:
>>-- Section 4 --
>>
>>"Client can avoid use of LITERAL+ [RFC2088], when maximum upload size
>>  supported by the IMAP server is unknown."
>>
>>What?
>>Don't you mean "The client SHOULD avoid"?  I'd even use this as an
>>opportunity to make it firmer, and say "The client MUST avoid".  No?
>>If not, why not?

The proposal that a client MUST avoid LITERAL+/NSLs presumes there is a 
limit when in fact there may actually not be one.  Of course there is 
always a finite limit, but there may be no policy limit.  In fact we 
don't plan to implement the limit as we've never had a request for it 
and don't see a need to deny authenticated users from appending a mail 
(and see some dangers in that).

I think MAY works in that it proposes a strategy, and doesn't confuse 
issues with servers that already implement LITERAL+ but not a limit.  
Otherwise you may be placing a new requirement on old software to police 
the new MUST, or implementing the limit places addition requirements to 
alter behaviour of LITERAL+ support to enforce this which IMO 
over-complicates it.

  Adrien
>>