Re: AD review of draft-ietf-imapapnd-appendlimit-extension-06

------ Original Message ------
From: "Barry Leiba" <[email protected]>

>>  -- 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?
>>
>>   [Naren] We will change it to a MUST
>
>Hold off on this, because there's still discussion based on Adrian's
>message in another thread... which I'll bring back here:
>
>On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[email protected]> wrote:
>>
>>  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.
>
>But the point of the use of LITERAL+ with APPEND isn't just about this
>spec and overall limits -- it's about whether we should use LITERAL+
>with APPEND *at all*.  There are other reasons that any particular
>APPEND might fail, and one point of using literals (and *never*
>allowing quoted strings, for example) is exactly to give the server a
>chance to say "NO" to the APPEND *before* the message data is shipped
>over.  Using LITERAL+ for APPEND data violates that.
OK fair point, the extra round trip for APPEND only isn't that big a 
deal.

Do we need to ad an addenda to LITERAL+ then?


>
>It was always the intent of LITERAL+ that it be used as a way to
>eliminate the extra round trip on short strings, where the OK from the
>server isn't necessary -- such as for username and password at login,
>or for mailbox names in various places (including the mailbox name in
>an APPEND command.
>
>My point here is that we now have an opportunity to stress this: that
>it's not a generally good idea to use LITERAL+ for the message data in
>an APPEND command, because it doesn't give the server the opportunity
>to say, "OK, yes, go ahead and send me the message."
>
>I'm absolutely willing to accept that "MUST NOT" use LITERAL+ for that
>is too strong.  But I'm still going to hold out for "SHOULD NOT", and
>would like to continue the discussion of why you disapprove.

Happy with the SHOULD NOT.

Adrien

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