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

Jamie Nicolson <> Mon, 20 July 2015 20:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D6D611B31BB for <>; Mon, 20 Jul 2015 13:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BCIJ7PGcQbI6 for <>; Mon, 20 Jul 2015 13:47:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 496A21B3194 for <>; Mon, 20 Jul 2015 13:47:21 -0700 (PDT)
Received: by vnds125 with SMTP id s125so27707595vnd.1 for <>; Mon, 20 Jul 2015 13:47:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t3xweycgbpTDNYJu/vl4EyeVNZr+a+6W3dTUtbm8h+E=; b=OJ02B8WZjH9DWz9GgSCyMycZ5QXOPO+R3VsAGfECFDewq4lPgQaC+6E7P2BScXuMq0 p8Pia9G3KWbgFEGqjHSEG9fhbdwAO/Lm63dBtQO28lTMzdTrpBBGoDYuHSCmQ8hcCdn7 sir6gGag2ChvDbNT2Jin8KUiFJPHZ7IvaivYE8YH985Udyrr5PD3mLw+c4PmN05Fi7Na 28aELgpirJ9n5fdyvODlpuO6TsvVJLaUQrQaU0sKG/CXpdcNujs8H7qg8AKVEVxY2BZL u3iGOAMWejOWyg/vtDQCV6tfxvC8izmZ7Mks9Z110lFOA9mOaFQ1wIc4UD4u4VGZRa0K j+NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t3xweycgbpTDNYJu/vl4EyeVNZr+a+6W3dTUtbm8h+E=; b=A5hvDbR1hfVUc3sdqfOIq2EoASZC9WlOZ/G/sYUfrKCsNRqzMKM2OWqAQmX6xoPqi+ zC6EmwkbNJ770BmQEZU3mOmaaFCQHRcUCMu0Ln/80vb/tisx9381y2kYLmi9tydpOeg7 k1wuislLs1kn0Az0SS11jmvNr9g9DqwSC9dFQxet3ZBrNjK19v561uTjabObTYlerEwj lyZtL0eAUsgiTcRVOFHkatFws/YgNCyBEpMi9u6Xd0WVzkCicNuKsGZ4CehPYTCk6x3P DwTfl8/4xU/WIKUpghtVoEa/z01/eeCVtLhBOf/iLpuqCfJbQEr6OW0oLOeHwGvA2QOt fTKg==
X-Gm-Message-State: ALoCoQlvLUhyV2tvlc9PvOWis2jYgskiFHb6MZnFZpHOXnefnetIff3UBCA8TyS6Hib1JDoRD3a6
X-Received: by with SMTP id ia7mr39104259vdb.69.1437425240205; Mon, 20 Jul 2015 13:47:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jul 2015 13:46:50 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Jamie Nicolson <>
Date: Mon, 20 Jul 2015 13:46:50 -0700
Message-ID: <>
To: RFC Errata System <>
Content-Type: multipart/alternative; boundary=bcaec5486072d5acee051b54a462
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: Mon, 20 Jul 2015 20:47:24 -0000

[I'm not sure of the procedure for discussing errata, but here's my

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?

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