Re: [MORG] [Technical Errata Reported] RFC6154 (4422)

Alexey Melnikov <> Tue, 21 July 2015 06:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9750E1AD062 for <>; Mon, 20 Jul 2015 23:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1yEslb9kAgh for <>; Mon, 20 Jul 2015 23:26:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF0EB1AD065 for <>; Mon, 20 Jul 2015 23:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1437459962;; s=selector;; bh=6owWXM1P11e9MTgiLdJSpWXjKhBOYEOos5M4tktqTJ8=; 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=bjG4ZJ6BelTo3+7CIitq6phNfP4GdqgNMqxYXAFMbbwJQRkvrt2gR7/OPASzzoyUirR264 E/jHmlA3u8Pm62NhTrrTH14Y2PWb2V6ZuDOBcpGqN1QrEbnaguRL1mRLOJfn22x4FvLB38 zcb3Vw9risT1wGLfqO+VMhWg+9yKWB0=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 21 Jul 2015 07:26:01 +0100
To: Jamie Nicolson <>
References: <> <>
From: Alexey Melnikov <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 21 Jul 2015 07:25:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable
Archived-At: <>
Cc: Timo Sirainen <>, Barry Leiba <>,,
Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (4422)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Messaging Organization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2015 06:26:07 -0000

Hi Jamie,

On 20/07/2015 21:46, Jamie Nicolson wrote:
> [I'm not sure of the procedure for discussing errata, but here's my
> thinking.]
> Thanks for implementing the spec and providing feedback.
> Certainly the spec is vague on the point of who creates special-use
> folders. If the server supports CREATE-SPECIAL-USE (presumably that was
> the case in your example), then either the server or client can create
> them. In this case the client software could have seen that 1) the
> special-use folders were missing but 2) the server supported
> CREATE-SPECIAL-USE, and then decided to create the folders itself.
> There's nothing in the spec to counterindicate this behavior--i.e.
> nothing that requires the server to create the special use folders. What
> happened next--did the client create new folders but not add the
> special-use attributes?

Yes, because CREATE-SPECIAL-USE capability is optional to implement.

Additionally, if a client that doesn't support SPECIAL-USE logs in
first, it will create Drafts, Sent, etc folders without special use
attributes. When a SPECIAL-USE aware client logs in, it can't create
these folders with special use attributes, as they are already created.
So it is either forced to create new folders with special use attributes
(which is annoying) or it has to use yet another extension to add these
attributes to existing folders.

> It seems to me that, even without this spec, someone (client or server)
> would be creating these folders. With the spec, the same entity should
> create the folders with the appropriate special-use tag, but first check
> to see if a folder already exists with that tag and, if so, use it
> instead. So, a client that needs to put Drafts somewhere should 1) look
> for an existing folder with \Drafts and 2) if that doesn't exist, create
> one and annotate it with \Drafts if the server supports
> CREATE-SPECIAL-USE. Similarly, if the server does automatic junk mail
> classification and needs a folder for junk mail, it should 1) look for
> an existing \Junk folder and 2) if it doesn't exist create one. (As a
> corollary, the server can create any needed special-use folders at
> account initialization, since it knows there will not yet be any
> existing folders.)
> Anyway, this seems like a good topic for discussion, but is not (yet) a
> clear error in the specification. Perhaps you should raise it on
> <>?
> On Mon, Jul 20, 2015 at 12:25 AM, RFC Errata System
> < <>> wrote:
>     The following errata report has been submitted for RFC6154,
>     "IMAP LIST Extension for Special-Use Mailboxes".
>     --------------------------------------
>     You may review the report below and at:
>     --------------------------------------
>     Type: Technical
>     Reported by: Chris Newman <
>     <>>
>     Section: GLOBAL
>     Original Text
>     -------------
>     N/A
>     Corrected Text
>     --------------
>     N/A
>     Notes
>     -----
>     There is missing information in this RFC that resulted in
>     interoperability problems when we performed an informal interop test
>     of multiple implementations on 2015-07-19. This is assumed to be a
>     "hold for document update" errata.
>     There is no guidance in the document related to how special-use
>     attributes are bootstrapped. Servers may pre-create them but there's
>     no requirement to do so and clients may use the CREATE-SPECIAL-USE
>     or METADATA extensions to bootstrap but there is no requirement to
>     use those mechanisms if the server offers them. This resulted in a
>     server implementation assuming the client would bootstrap these
>     attributes and a client assuming the server would do so, thus
>     interoperability failed.
>     Given this experience, the fastest way to resolve this interop
>     problem over time is for both client and server to take
>     responsibility for bootstrapping special use mailboxes. This means
>     if clients create a mailbox intended for special use (e.g., drafts,
>     sent, junk, trash, etc), and the CREATE-SPECIAL-USE extension is
>     offered, then clients need to provide the USE extension to improve
>     interoperability.  Servers that are provisioned with an end-user's
>     locale or language need to pre-create appropriate special-use
>     mailboxes to improve interoperability of this extension. For
>     existing accounts where the server is upgraded to support this
>     feature, the server can look for mailboxes with names that imply
>     special use and add the attribute to those mailboxes (especially if
>     the server has locale/language awareness provisioned for users).
>     Clients that implement a name-based search if special use attributes
>     are not present and decide to use a mailbox for a special use based
>     on its name can use the
>      METADATA extension, if offered, to label that mailbox appropriately.
>     Instructions:
>     -------------
>     This erratum is currently posted as "Reported". If necessary, please
>     use "Reply All" to discuss whether it should be verified or
>     rejected. When a decision is reached, the verifying party (IESG)
>     can log in to change the status and edit the report, if necessary.
>     --------------------------------------
>     RFC6154 (draft-ietf-morg-list-specialuse-06)
>     --------------------------------------
>     Title               : IMAP LIST Extension for Special-Use Mailboxes
>     Publication Date    : March 2011
>     Author(s)           : B. Leiba, J. Nicolson
>     Category            : PROPOSED STANDARD
>     Source              : Message Organization
>     Area                : Applications
>     Stream              : IETF
>     Verifying Party     : IESG
> _______________________________________________
> MORG mailing list
> Note Well: