IETF Logo Mail Archive

Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01

Stephan Bosch <stephan.bosch@dovecot.fi> Thu, 17 May 2018 19:43 UTC

Return-Path: <stephan.bosch@dovecot.fi>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD1126C0F for <extra@ietfa.amsl.com>; Thu, 17 May 2018 12:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGi0LCBHOEAI for <extra@ietfa.amsl.com>; Thu, 17 May 2018 12:43:49 -0700 (PDT)
Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0C12025C for <extra@ietf.org>; Thu, 17 May 2018 12:43:48 -0700 (PDT)
Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7D92D2A6900; Thu, 17 May 2018 22:43:38 +0300 (EEST)
To: Alexey Melnikov <alexey.melnikov@isode.com>, Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <D6002572-B87C-47FA-98A1-D963F25F5B0E@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <EFB3AA82-1076-4947-AACA-63102C5220CE@oracle.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> <f8d52d37-cdac-808c-9e12-2397d0139b6d@isode.com>
From: Stephan Bosch <stephan.bosch@dovecot.fi>
Message-ID: <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi>
Date: Thu, 17 May 2018 21:43:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <f8d52d37-cdac-808c-9e12-2397d0139b6d@isode.com>
Content-Type: multipart/alternative; boundary="------------4A096D4DCA4D667404093939"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/rzpmcBIPdCBw7LovquS1cP10U38>
Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 19:43:51 -0000

Hi,

So, in summary, what should be done here for the draft?


Regards,

Stephan.


Op 15/05/2018 om 12:04 schreef Alexey Melnikov:
>
>
>
> On 15/05/2018 02:14, Bron Gondwana wrote:
>> On Tue, May 15, 2018, at 09:54, Chris Newman wrote:
>>> On 10 May 2018, at 19:01, Bron Gondwana wrote:
>>>
>>>     My opinion is - just define this response as a 63 bit number.
>>>
>>>     Crappy thing here with RFC4466 is:
>>>
>>>       tagged-ext-simple   = sequence-set / number
>>>
>>>     And "number" is defined in RFC3501:
>>>
>>>     number          = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n <
>>>     4,294,967,296)
>>>
>>>     Which means that the response SHOULD be:
>>>
>>>     "SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be
>>>     tagged-ext.
>>>
>>>
>>> Clients have a parser. That parser will either support 32-bit numbers or
>>> 63-bit numbers. Clients implementing SIZE should just support 63-bit
>>> numbers; that's less client code than supporting 32-bit numbers outside
>>> parens and 63-bit numbers inside parens; thus less risk of bugs. The
>>> extra parentheses make the parser more complex for no good reason. The
>>> extra parentheses make the extension incompatible with an already
>>> implemented extension in my server for no good reason (yes, I'm willing
>>> to make incompatible changes to private extensions, but only if there is
>>> a technical reason to do so). I object to adding the extra parentheses
>>> for those two reasons.
>>
>> I'm totally fine with all those reasons.
>
> I am fine with increasing the numeric range for "tagged-ext-simple".
>
>>   Do we need to do a 4466bis for this,
>
> Maybe :-).
>
>> or do we let that get folded with the 64bit extension work in general 
>> and IMAP4rev2?
>
> I am happy to do this in IMAP4rev2. If people also want to have 
> rfc4466bis, this can be done as well.
>
>> I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant 
>> things like this, but I think it's good to have the discussion and 
>> have a clear answer for why we're going with a number without parens 
>> - particularly since OBJECTID is doing parans everywhere.
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra

v2.23.0 | Report a Bug | By Email