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

------ Original Message ------
From: "S Moonesamy" <[email protected]>
To: "[email protected]" <[email protected]>; "Jayantheesh S B" 
<[email protected]>; "Narendra Bisht" <[email protected]>; 
"Alexey Melnikov" <[email protected]>
Cc: "[email protected]" 
<[email protected]>; "Barry Leiba" 
<[email protected]>; "[email protected]" <[email protected]>
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
>>

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