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
- [Extra] IMAP RFC 6855 (IMAP EAI) implementation e… Chris Newman
- Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementati… Jiankang Yao
- Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementati… Ned Freed
- Re: [Extra] IMAP RFC 6855 (IMAP EAI) implementati… Arnt Gulbrandsen