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

Hi All,

Please find our response updated. 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email protected]] On Behalf Of Adrien de Croy
Sent: Friday, December 11, 2015 5:45 AM
To: Barry Leiba; Narendra Bisht
Cc: [email protected]; [email protected]
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.


[Jay] We will update the draft with 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