Re: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)

Michael Slusarz <michael.slusarz@open-xchange.com> Thu, 11 April 2019 03:45 UTC

Return-Path: <michael.slusarz@open-xchange.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 8965D1201EE; Wed, 10 Apr 2019 20:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 93owC844B981; Wed, 10 Apr 2019 20:45:53 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83EC1201A0; Wed, 10 Apr 2019 20:45:53 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 1851F6A25F; Thu, 11 Apr 2019 05:45:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554954352; bh=jGIpOL9VjCLta7vDulBdsgY+VyJksTmM2UIkKq8n8ic=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=xA3umboOczk8UPebOb0BVaQbZVWteO6u0n6PBLw6jZdTOiEaXS6yhCA3p/CpjkzFp Iz+oBmpLmmszqY/c22MzIVTGq36C42ognbaAcvAH5CoI+v250wAGBFowICqrhTI3vE uNsklu65DBIdDeWTCItL3Wa0VdZaKNnshkbhw3wkvW0VmyYAoD4nquGtWtRaHp28Q6 dqMXhwxHMExOO7GC+HmE1fA5xs32r1gABDd5fyLcbotkANVzDsoQz9fELBodGWuFUD accaAK2YRim88lkHO6OCKW67yIAVQZHHUuywY/vQRb+WNDbKI7uIkNGni6bS+l5laN F4g/mzX3EgXZw==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 053E13C0066; Thu, 11 Apr 2019 05:45:52 +0200 (CEST)
Date: Wed, 10 Apr 2019 21:45:48 -0600 (MDT)
From: Michael Slusarz <michael.slusarz@open-xchange.com>
To: Adam Roach <adam@nostrum.com>, Adam Roach via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>
Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org
Message-ID: <589634421.18028.1554954351946@appsuite.open-xchange.com>
In-Reply-To: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com>
References: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/TUYusIqUA0qJB2EKl2zYi4S81to>
Subject: Re: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)
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: Thu, 11 Apr 2019 03:45:56 -0000

Adam,

Thanks for your comments.  Discussion below.

> On April 8, 2019 at 2:38 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> §3.1:
> 
> >  These algorithms MUST be one
> >  of the algorithms identified as supported in the PREVIEW capability
> >  responses.
> 
> This is confusing, as "algorithms" and "one of" don't make sense with each
> other. Is it meant to say something like "...MUST be a subset of the
> algorithms..."?

Noted that the topic of multiple algorithm selection is being discussed in Barry's DISCUSS.

That being said, if multiple algorithm support is decided to be kept, what about changing this to:

"All algorithms specified in the list MUST be identified as being supported by the server by appearing in a PREVIEW capability response." (or "PREVIEW= capability response" maybe?)

> §3.1:
> 
> >  If a client requests an algorithm that is unsupported,
> >  the server MUST return a tagged BAD response.
> 
> This appear to be underspecified, or at least nonintuitive. As written,
> it seems to say that an algorithm list of (known-1, known-2, unknown, known-3)
> would be considered invalid, even though there are plenty of supported,
> requested algorithms that could be used. Is this actually intended to be an
> error? If so, please make it explicit, as it's pretty counterintuitive.
> 
> (As an aside: it's also unnecessarily fragile from an interop perspective, so I
> would suggest that this is not the desired behavior: I believe you want to
> return an error only when *none* of the requested algorithms are supported).

See Barry's DISCUSS response.  Agreed that error handling is not specified adequately in current text.

To mirror duplicate algorithm language, how about: "Unsupported algorithms in the list MUST be ignored. If the list contains no supported algorithms, the server MUST return a tagged BAD response to the FETCH command."

> 
> ---------------------------------------------------------------------------
> 
> §6, example 5:
> 
> >    C: E1 CAPABILITY
> >    S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES
> >    S: E1 OK Capability command completed.
> >    [...a mailbox is SELECTed...]
> >    C: E2 SEARCH RETURN (SAVE) FROM "FOO"
> >    C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY))
> 
> This example shows the use of a modifier ("LAZY") with an algorithm; however,
> this modifier doesn't appear to be advertised by the server in its CAPABILITY
> line. If I understand how this is supposed to work (looking at the definitions
> in section 7), I would have expected:
> 
>      S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY PREVIEW=LAZY SEARCHRES
> 
> I'll note that this syntax effectively places algorithms and modifiers in the
> same namespace, although IANA doesn't seem to be given any explicit
> instructions about this. I think this needs to be cleaned up prior to
> publication.  I would make this last point a DISCUSS, except that it appears
> to be covered by Benjamin's DISCUSS already.

This has been discussed in several other places already.  I am proposing removing priority modifier extensions, which would address this concern.

michael