Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Fri, 30 November 2018 12:00 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
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 17D74130DDF for <extra@ietfa.amsl.com>; Fri, 30 Nov 2018 04:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 3Hsitjc3fWPp for <extra@ietfa.amsl.com>; Fri, 30 Nov 2018 04:00:09 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24564130DE0 for <extra@ietf.org>; Fri, 30 Nov 2018 04:00:08 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 46511C00EE; Fri, 30 Nov 2018 12:01:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1543579276; bh=ON3yKSodFM2Cav2vgkfFaaiwvAhjhLekaRGUISDSwNE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=N3z/Y5CbvGHvGQnA4Dh6JagylpY67Wsy4eHO55GZMeQ2QA+HAS5kejY20GMgC1lVy BYBMS4BAc83t2UOrWxBB19D/FWhEoW0PWGDeMTLUZaPNPnAoRPliuaIlWSQNwce6Q/ Cij57CZ7iibTQDTihnYfl4leoxfMhyz2X5iYGcLU=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1543579274-32426-32424/9/269; Fri, 30 Nov 2018 12:01:14 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: extra@ietf.org
Date: Fri, 30 Nov 2018 13:00:05 +0100
Mime-Version: 1.0
Message-Id: <c506aa45-da39-4e27-bbc6-4b0396d0e725@gulbrandsen.priv.no>
In-Reply-To: <F3CA8758-0897-4A5D-B275-E634CCA43207@oracle.com>
References: <F3CA8758-0897-4A5D-B275-E634CCA43207@oracle.com>
User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie)
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/is60UhVozEgv5XEYWq2wy0uCJ-A>
Subject: Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementation experience: input to IMAP4rev2
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, 30 Nov 2018 12:00:12 -0000

Chris Newman wrote:
> It's interesting that my implementer hat and standards hat 
> result in diametrically opposed positions on this issue, but so 
> be it.

I think this is because RFCs are obliged to respect other RFCs more than 
implementers are. You, as implementer, may reasonably look at what hurts 
most in practice in your part of the world; the set of RFCs ought to be 
consistent if at all possible.

BTW, this is why RFC 6858 exists in the first place. Enabling reading using 
6857 is IMO too much work compared to just-send-8, which is IMO tantamount 
to encouraging violating 3501's rules. The simplest possible conformant 
implementation shouldn't be hard.

You should find 6858 easy to implement well enough that mail can be read 
without violating any rule in 3501. If not, I failed. Almost as an aside, 
doing so should minimise the risk of provoking a bug related to sending 
mail, by making replying and composing fail in a safe/predictable manner. 
But not implementing it is IMO also entirely reasonable, even if an RFC 
should not say so.

Arnt