Re: [imapext] qresync WG adoption call

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 23 May 2013 10:08 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D019621F96F2 for <imapext@ietfa.amsl.com>; Thu, 23 May 2013 03:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.349
X-Spam-Level:
X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmvgm+6CHmcF for <imapext@ietfa.amsl.com>; Thu, 23 May 2013 03:08:54 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F3F5C21F96F4 for <imapext@ietf.org>; Thu, 23 May 2013 03:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369303728; d=isode.com; s=selector; i=@isode.com; bh=V33AznPB5hLnlg8tzr/lwwP1Ee5taMQDYri0Fm7mHL8=; 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=uxVY/ZkLuwXVLISbGJFOW8+xKQw1Od7Aw6G38bfm/olmdGI27R+7OrgJ1EO3VHjvQWGNSW xq0sOx/+6R1Ia2YVjRXaTYVExcXN6e/ZzSowBS8pChynVy9KgVeCAYJQ8ZDYYrkyh+yAMj 7GJGY/rT9S/ihrGc/1671vpbfxLMKmY=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UZ3qsAA6F1aI@statler.isode.com>; Thu, 23 May 2013 11:08:48 +0100
Message-ID: <519DDAFB.7060207@isode.com>
Date: Thu, 23 May 2013 10:01:47 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Michael M Slusarz <slusarz@horde.org>
References: <CAKHUCzxM2C4tyVDQfUVVTm2ecXVHLE7pZBAa=7EpmCUv8OQ-jA@mail.gmail.com> <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org>
In-Reply-To: <20130520135303.Horde.npUBqY2PMh-9C3OAQje4LA1@bigworm.curecanti.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: imapext@ietf.org
Subject: Re: [imapext] qresync WG adoption call
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 10:08:59 -0000

On 20/05/2013 20:53, Michael M Slusarz wrote:
> Quoting Dave Cridland <dave@cridland.net>:
>
>> Folks,
>>
>> We now have two drafts by Alexey published:
>>
>>  - draft-melnikov-rfc4551-bis-00 (CONDSTORE)
>>  - draft-melnikov-5162bis-00 (QRESYNC)
>>
>> I'd like to propose that the working group adopt these as our start 
>> point.
>
> Does this mean the current inclination is to issue updates of the 
> current documents rather than trying to combine into a single "IMAP 
> synchronization extensions" doc?
>
> I personally feel the latter makes more sense from a protocol 
> implementor's standpoint, especially since the subtleties and 
> interplay between the two extensions could more easily be explained.  
> Although I understand this requires drafting of an entirely new 
> document rather than incremental tweaking of existing text.
As Dave said, our WG Charter doesn't restrict us in what we can do here. 
If people want a single document, my preferred way of doing that would be:
1) first post 2 separate drafts updating CONDSTORE and QRESYNC first (so 
that people can use wdiff to see what changed)
2) then produce a combined document with CONDSTORE inserted into QRESYNC 
(again, so that people can diff relevant parts)
3) start rearranging & rewriting text to make sure that CONDSTORE and 
QRESYNC bits are consistent with each other.

This is going to be more work, but I am happy to try if people see benefits.