Re: [MORG] [Editorial Errata Reported] RFC6154 (5431)

Ned Freed <> Thu, 19 July 2018 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3BF130EE8 for <>; Thu, 19 Jul 2018 15:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FyOUMes7MPHQ for <>; Thu, 19 Jul 2018 15:56:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95EEE130DD2 for <>; Thu, 19 Jul 2018 15:56:55 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Thu, 19 Jul 2018 15:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201712; t=1532040708; bh=DHwddQiXbtg1GCkbUZ/8DJa60QTIAkIU15PGvML26/Q=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=esUqQP6Q/i/Lh7oOKeEsAoT1gjzR1beMXI3Lc7cLMhIx+rZssdDEkqUknugVn5UMJ KivY5vxhbK6vip/fzdLN2R9UaE8FN/C0bTF/Wg5FUOwC56TQNPKd1UObSZJlfaA2Ix jIvRVFCqXSlOtxLkhGT9Z6T/+nq+43SzcVHO/Uds=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Thu, 19 Jul 2018 15:51:44 -0700 (PDT)
Cc: RFC Errata System <>,,,,,,,
Message-id: <>
Date: Thu, 19 Jul 2018 15:36:31 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Thu, 19 Jul 2018 18:26:03 -0400" <>
References: <> <>
To: Barry Leiba <>
Archived-At: <>
Subject: Re: [MORG] [Editorial Errata Reported] RFC6154 (5431)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Messaging Organization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2018 22:56:58 -0000

> > There exist clients which send a non-extended LIST command and will

> > correctly display and interact with mailboxes usefully if their

> > special-uses are given in the response.

> >

> > Because of this, many servers are already replying with the special-use

> > attributes, and there are no known reports of clients being broken by

> > that behaviour.  Because of this, the MAY should be raised to a SHOULD,

> > and server implementations should default to turning this on.

> That may (ahem) be true now, but the document says exactly what we intended
> it to say when it was written.

> Alexey, please mark this report REJECTED.

The existence of such clients is not really the issue, although it's what makes
the issue a pressing matter. Rather, the issue is that the semantics provided by
the specification provide no reliable way to obtain special use information,
and thus cannot be said to provide a minimum level of interoperability. In

(1) SPECIAL-USE does not require LIST-EXTENDED be implemented.

(2) The MAY on returning special use attributes as part of unextended LIST
    means that there's no way to distinguish between the (common) case of
    no special use attributes being set and LIST not supporting returning
    such attributes.

(3) The METADATA approach of deteching special use attributes is also

Now, I'm all for supporting existing implementations, but IMO this goes
too far. And the simplest way to fix it is to change the MAY.

It's also easy to see why clients are simply assuming unextended LIST returns
this information regardless of what the standard says. As a client implementer
myself in this case (since I'm implementing the Sieve specialuse extension
using IMAP) I'm going to assume LIST-EXTENDED is available and fail if it
isn't, but I can't say what I'm doing is really any better.