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

Jamie Nicolson <nicolson@google.com> Tue, 21 July 2015 17:30 UTC

Return-Path: <nicolson@google.com>
X-Original-To: morg@ietfa.amsl.com
Delivered-To: morg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A131D1A700B for <morg@ietfa.amsl.com>; Tue, 21 Jul 2015 10:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lizoNwByKjvM for <morg@ietfa.amsl.com>; Tue, 21 Jul 2015 10:29:59 -0700 (PDT)
Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A2C1A6FFC for <morg@ietf.org>; Tue, 21 Jul 2015 10:29:58 -0700 (PDT)
Received: by vnaa140 with SMTP id a140so38572598vna.2 for <morg@ietf.org>; Tue, 21 Jul 2015 10:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NjiVZRRIYrsTM2k4wUwz8qv4E1hlGPbJttFOFYkJA/4=; b=NoJjqcxpJQ2bAOyM6jsoipL6P43dfm/ea16+6w1ZsZ+554npvLEZE9BTfT5Z15mZtD b/vbfXU2YQ2E4yYwErFRIeKVva2NEnaH2ZF4G9OctPvCyZaBJtPpgjuvJCBd9WMgWgMl Id2dqzY4pniSpo+LN6Ny1/uhNiWyvYMiIfyG+qv+RsQtfP0DucyxFPakVqS0pBGJDyY6 3jMLfioeS3SFxfZTWlVTNMYhTlu6imPxRntAJbTkyXw/FyDMLZ9rVo4C2xwtdQFpELur JHXo3uBJkFYEMoJwoSQjsmovyeBEprfFj0q/5PiK3y8dcL/1qFo2XinvnuEkwZr5uOq+ 10Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NjiVZRRIYrsTM2k4wUwz8qv4E1hlGPbJttFOFYkJA/4=; b=KYSVeW1F2i9EssFO2Pl15Rk9dJnNruyeIF8MUI8bZLKXWh1VHqj1m6g+RFsOWYm2Vp otEf2U6G8ixyPzMRP4r8NdSsli6vefFpRd68/xQvkoy4dVGY3b8SDm+KZKmtAYzWIhCb XcSJGcMLT+KNdkWRN8dmIO0yCMfpWFKN4BY8IXtOE74EPyUTKSbrUaIR6EHlm3VqgC7q 1gWcT6c6m70dGfyiZgnhGIU16cBw+/+muWMLV+NZ0uqLi0gFBruK4KnEgtyMxGfdp+4U 5jLzWxzaQT60IIkC6a69IuUez5CHr5HKhZw7bFXn8WkXRkfJ7jhLtET87Y9b3O0zrBiC LvKg==
X-Gm-Message-State: ALoCoQkWs9e6RMaC5/4PepXebLJ53npW387aXzlBRHW6Ktvkjm/Sf1dDf/Fsud4jARCLs5kHShqK
X-Received: by 10.52.249.36 with SMTP id yr4mr5694401vdc.40.1437499797865; Tue, 21 Jul 2015 10:29:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.191.204 with HTTP; Tue, 21 Jul 2015 10:29:28 -0700 (PDT)
In-Reply-To: <55ADE5E3.4000501@isode.com>
References: <20150720072530.6923F18020A@rfc-editor.org> <CACU8CfThP70461QZUwcjdB_icX7bbE79KS+fHnSh5MTsW4w2Lw@mail.gmail.com> <55ADE5E3.4000501@isode.com>
From: Jamie Nicolson <nicolson@google.com>
Date: Tue, 21 Jul 2015 10:29:28 -0700
Message-ID: <CACU8CfQDGDLTwH7BrCbuo=OnJPbREFArp6OQ7n2D7pD7PG_K8Q@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary=089e0153800ad14cec051b6600aa
Archived-At: <http://mailarchive.ietf.org/arch/msg/morg/LsgPREhGNBXGuNxH9GAkLQycNYg>
Cc: Timo Sirainen <tss@iki.fi>, Barry Leiba <barryleiba@computer.org>, rg+ietf@qualcomm.com, morg@ietf.org
Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (4422)
X-BeenThere: morg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Messaging Organization <morg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/morg>, <mailto:morg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/morg/>
List-Post: <mailto:morg@ietf.org>
List-Help: <mailto:morg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 17:30:01 -0000

On Mon, Jul 20, 2015 at 11:25 PM, Alexey Melnikov <alexey.melnikov@isode.com
> wrote:

> 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.
>

Sure, but in this case I assume the server supported CREATE-SPECIAL-USE
because it expected the client to create the folders.

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.
>

OK, agreed that is a bit of a mess. With the current spec, if a server
doesn't prepopulate the special-use folders, it should support
CREATE-SPECIAL-USE and METADATA in order to be useful to clients. (Gmail
doesn't support either one, but it prepopulates the 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
> > imapext@ietf.org <mailto:imapext@ietf.org>?
> >
> >
> >
> > On Mon, Jul 20, 2015 at 12:25 AM, RFC Errata System
> > <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> 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:
> >     http://www.rfc-editor.org/errata_search.php?rfc=6154&eid=4422
> >
> >     --------------------------------------
> >     Type: Technical
> >     Reported by: Chris Newman <chris.newman@oracle.com
> >     <mailto:chris.newman@oracle.com>>
> >
> >     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
> > MORG@ietf.org
> > https://www.ietf.org/mailman/listinfo/morg
> > Note Well: http://www.ietf.org/maillist.html
> >
>
>