Re: [Extra] Review: draft-ietf-extra-imap4rev2-11

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 07 February 2020 13:32 UTC

Return-Path: <alexey.melnikov@isode.com>
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 9B07D12086A for <extra@ietfa.amsl.com>; Fri, 7 Feb 2020 05:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 m7BJX-n3nkTB for <extra@ietfa.amsl.com>; Fri, 7 Feb 2020 05:32:14 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C4CF3120869 for <extra@ietf.org>; Fri, 7 Feb 2020 05:32:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1581082333; d=isode.com; s=june2016; i=@isode.com; bh=WyDAM/nhb0Y7BlXo3cTjUCpX/i3WH3KOU4iFfWYYSss=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EKuO9YnxQLe0wG37XCmbJG6m0zzY82tKmkntKCHKqqQk5dzuoeua/lBQe1laqcMa2gep1S 1iL0fjJJ13K+2zRgDudUqA6c15elfB7bz130W5m6vBCPfZJl5BThwras+rKwyQIUM4590R 32QflmZAtu4XhpLO3plboqKRA94eUOo=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <Xj1m3ABD4GSr@waldorf.isode.com>; Fri, 7 Feb 2020 13:32:12 +0000
To: Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <0f234581-1648-4549-b80f-3af97b3d1080@beta.fastmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <c1dcfb6a-0cab-baac-98b9-2ff1b124c54f@isode.com>
Date: Fri, 7 Feb 2020 13:31:53 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <0f234581-1648-4549-b80f-3af97b3d1080@beta.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------6EC6D6D1427D7F983C6AEB8C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/3c4Oh7dX8jrGnJdR-sTPf0FnQDo>
Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 Feb 2020 13:32:17 -0000

Hi Bron,

On 07/02/2020 04:03, Bron Gondwana wrote:
> Hi Alexey,
>
> I agree with all the things Timo said. I've added a couple more 
> comments below.
I started replying to your emails and applied some changes, but I 
haven't done all of them. I will send an email on this.
> Do you want me to create github issues to track each thing, or are you 
> happy that you know what changes are needed?
I think I am Ok for now without tracking issues in github.
> Again - sorry for the late final review and hence pushing the timeline 
> back on this.

No worries.


Best Regards,

Alexey

>
> Cheers,
>
> Bron.
>
>
> On Sun, Feb 2, 2020, at 06:00, Alexey Melnikov wrote:
>> On 29 Jan 2020, at 14:20, Timo Sirainen <timo@sirainen.com 
>> <mailto:timo@sirainen..com>> wrote:
>>> Is it too late to add a new response code? Something like:
>>>
>>> * OK [CREATED] TAG "a123" NAME "Denormalized name"
>>
>> Response codes are cheap and don’t break older clients, so I am happy 
>> to add one.
>
> Along with the instruction to add MAILBOXID if RFC8474 is supported, 
> I'm good with this.
>
>>> Current behaviour of our server right now is to drop the connection 
>>> entirely, which is ugly - but it's rare and all clients already need 
>>> to handle it cleanly, so it guarantees no messed up data model for 
>>> the clients.
>>>
>>> Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't 
>>> think clients are going to implement it correctly since it almost 
>>> never happens, so nobody tests that code path.
>>
>> Let me think about this.
>
> We still need a decision on this. I'm going to keep dropping 
> connections regardless in this rare case, because there's a horrible 
> long tail of clients, and debugging their broken caches if we ever 
> confuse them is very difficult.
>
>>> It sounds like your issues are with \NoSelect mailboxes in general, 
>>> not just this specific way of creating them with DELETE? For example 
>>> CREATE a/b could create "a" se \NoSelect also..
>>
>> I am happy to disallow this, or at least say that servers can either 
>> disallow delete of a mailbox with children or add \NoSelect to it.
>
> Sounds good to me.  Allowing the disallow is enough :)
>
>>>
>>>> *6.3.6 RENAME*
>>>>
>>>> I thought we had agreed to strongly recommend against clients using 
>>>> RENAME INBOX Other, but maybe I've forgotten.  I don't see it in 
>>>> the minutes, so maybe it's just my wishful thinking.
>>>
>>> Dovecot doesn't allow RENAME INBOX in some configurations. I don't 
>>> remember people complaining.
>>
>> From the client prospective I am disagreeing with this, renaming 
>> INBOX is useful for archiving.
>>
>> I am happy to say that some servers might disallow this though. Would 
>> that be Ok with people?
>
> Works for me.
>
>>>
>>>> We definitely have an option in Cyrus IMAP to make subscriptions 
>>>> follow RENAME.  It's one of the warts (largely due to Thunderbird 
>>>> showing greyed out folders and confusing people).
>>>
>>> We haven't needed to do this yet. I think the \NoSelect folders have 
>>> been more of a reason for Thunderbird confusion.
>>>
>>>> *6.3.7 SUBSCRIBE*
>>>>
>>>> Speak of the devil.  Lots of sites violate the MUST NOT 
>>>> unilaterally remove rule.  Should we weaken it to SHOULD?  The 
>>>> justification for the MUST is "the server site might choose to do 
>>>> X" - well, if the server site is doing that, then maybe they 
>>>> SHOULDN'T unilaterally remove the subscriptions, but otherwise it's 
>>>> a better user experience and what people want.
>>>>
>>>> (also: by enabling a non-default break the rules config, it's what 
>>>> our server does!)
>>>
>>> The original use case for not auto-removing a subscription is rather 
>>> ancient already. I'd be fine with changing subscriptions to follow 
>>> deletes and renames in the rev2 mode (but better not change behavior 
>>> in rev1 mode).
>>
>> I think I would rather weaken this to SHOULD and I would rather not 
>> require change in behaviour for servers that already comply with the 
>> MUST NOT.
>
> Yeah, totally.  I'm fine with SHOULD, and I don't care about
>
>>>
>>>> *6.3.10 NAMESPACE*
>>>>
>>>> We've created a conflict here.  The NAMESPACE command contains 
>>>> prefix strings for the individual namespaces, and says:
>>>>
>>>>     The prefix string allows a client to do things such as automatically
>>>>     creating personal mailboxes or LISTing all available mailboxes within
>>>>     a namespace.
>>>>
>>>> Which contradicts the advice we gave back in the LIST command not 
>>>> to use prefix.  Perhaps we should change the LIST advice to be 
>>>> "only use the empty prefix or prefixes given in the NAMESPACE 
>>>> response"?
>>>
>>> I think you're mixing "namespace prefixes" with "list references"? I 
>>> don't think the above sentence advocates using LIST reference 
>>> parameter, just using the namespace prefix for listing e.g. LIST "" 
>>> ns-prefix/*
>>
>> Exactly.
>>>
>>> Anyway, I see lots and lots of text is still preserved for the LIST 
>>> reference parameter explanation, even though it shouldn't be used. 
>>> Couldn't we just decide to get rid of it entirely in rev2 and say 
>>> the reference MUST be empty? Or say only that is is 
>>> implementation-defined and refer to IMAP4rev1 if anyone wants to see 
>>> how it used to be implemented?
>>
>> I kept the text because non empty reference is still allowed. I think 
>> I would rather allow it and mark the text as recommended server 
>> behaviour if non empty reference parameter is supplied. Maybe move it 
>> to a separate section for clarity?
>
> I don't think any change is needed here, sorry for adding confusion.
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra