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

p.s. it seems pretty common to use LITERAL+ on APPEND, Thunderbird and 
iOS clients do it.  eM Client does not.  No data on others.

Adrien


------ Original Message ------
From: "Adrien de Croy" <[email protected]>
To: "Barry Leiba" <[email protected]>; "Narendra Bisht" 
<[email protected]>
Cc: "[email protected]" 
<[email protected]>; "[email protected]" 
<[email protected]>
Sent: 11/12/2015 11:45:25 p.m.
Subject: Re: [imapext] 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

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