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

[Naren <[e-mail]>]

I agree with Adrien, on this.
I think MAY will be more appropriate here.

On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[e-mail]> wrote:

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


-- 
Thanks & Regards
-Narendra