Re: [MORG] [Technical Errata Reported] RFC6154 (4422)
Jamie Nicolson <nicolson@google.com> Mon, 20 July 2015 22:21 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 96F141A87A7 for <morg@ietfa.amsl.com>; Mon, 20 Jul 2015 15:21:03 -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 fSRsWE41XT7I for <morg@ietfa.amsl.com>; Mon, 20 Jul 2015 15:21:01 -0700 (PDT)
Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::230]) (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 A84C11A879E for <morg@ietf.org>; Mon, 20 Jul 2015 15:21:00 -0700 (PDT)
Received: by vnk197 with SMTP id 197so28528211vnk.3 for <morg@ietf.org>; Mon, 20 Jul 2015 15:21:00 -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=bebkzcBrlg9nip6Qz1nrAzU5NcVmSkXu1o8rh6JXbPM=; b=KOIguqpIiLrSX1FR8UkSb6oDWIn+G3kX7IfyKqEeubL95guSxl/iZ810eMxyaPndKb r3BLjWk2To+vhkTBrhf3lzRGCQ5kdY4s3kGongdQaJHDpbg7vW401VhjvS7SFXhsgbHU FgZvXQoV21yklb/z+EK4aEABjB+uuIF8q+k4zeFJzp+XD+ymg8S+hqw7JTgpccdo0Ipc Xo//aksCWrah3voxiVsKYKXHFYC1QVlPTWMMSs2JuiBFtjt4rYLPfrg6voGxQnMNphZk 8/amaW3oHKSKBXmAeRn/t5hlm6y9TlRo/2xE7iqommoFgB7Ug2iQl5gK5dDwLd8stFDN yFgA==
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=bebkzcBrlg9nip6Qz1nrAzU5NcVmSkXu1o8rh6JXbPM=; b=WTcMchMh7pvsMFUin4t7BXHlVSMrP4oCoW0bQYVtpxCPCMAZQ56aEEMZusmV3WChQ0 wjY4g3+rTk5ReWOILkB9STaXc4skuZ8TGQ2xOm4hi6kWZnwvk9qxbCl+acHvimr3F+tr rBk5rrE8lfFIrCyW8DQja9ayxzC508uw6tdBhvmVFuUjHasJMitms+Y2Kkb/OaS+Fmb3 rTSdjvyW4HeFlKEd/L0VhQ9J/e5qLX9ux0oWt4xW5DHnZNg2llHZco1eNpmR6S8042Wl dwIaS+9tbszV/RwM0bBxnYbYQ2ipMpNOWAk8jSdt/szO1VatwFVmimGQBGVBreWrtUh0 SG5A==
X-Gm-Message-State: ALoCoQmxYXtIMm6Hk5gEHLYtJO05DrPl1yx74DnbR4Tl2mz50RcWC5fmUtmSGXDpfLmK8BMPTXvF
X-Received: by 10.53.5.37 with SMTP id cj5mr40640223vdd.34.1437430859842; Mon, 20 Jul 2015 15:20:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.191.204 with HTTP; Mon, 20 Jul 2015 15:20:30 -0700 (PDT)
In-Reply-To: <CALaySJKpeoNc14K9wqrJ+uZ4o4ny1HGcyFL_CwjasyvNA+3XJA@mail.gmail.com>
References: <20150720072530.6923F18020A@rfc-editor.org> <CACU8CfThP70461QZUwcjdB_icX7bbE79KS+fHnSh5MTsW4w2Lw@mail.gmail.com> <CALaySJKpeoNc14K9wqrJ+uZ4o4ny1HGcyFL_CwjasyvNA+3XJA@mail.gmail.com>
From: Jamie Nicolson <nicolson@google.com>
Date: Mon, 20 Jul 2015 15:20:30 -0700
Message-ID: <CACU8CfTqOnnpYJofNDbR-NYDOwx5e2krmS3H_ungZrs8tm0R6A@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: multipart/alternative; boundary="047d7b5d5d32ca7c3b051b55f380"
Archived-At: <http://mailarchive.ietf.org/arch/msg/morg/gV8Rd6XTlhIecX3HjKz_oX-uIrc>
Cc: Timo Sirainen <tss@iki.fi>, Randall Gellens <rg+ietf@qualcomm.com>, morg <morg@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.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: Mon, 20 Jul 2015 22:21:03 -0000
Perfect, thanks for the explanation. On Mon, Jul 20, 2015 at 3:17 PM, Barry Leiba <barryleiba@computer.org> wrote: > > [I'm not sure of the procedure for discussing errata, but here's my > > thinking.] > > Thanks for that, Jamie -- responding with your thoughts is exactly > what you should do. > > Normally, errata should not be used for issue tracking, which is what > Chris did here. He said up front that he expected this to be "held > for document update", which means that the "error" he raised is too > involved for a simple fix that might be "verified", and that it needs > to be discussed further if the document is ever revised. > > In fact, you're right that this wasn't an error in the document: we > never intended to specify how special-use folders are bootstrapped. > The reason I agreed with Chris and marked it HFDU is that I think any > revision of the spec *should* address that issue, and that, while it > wasn't, strictly speaking, an error in the spec, it was an error on > our part not to consider it. And I think we should consider it if we > ever revise it. > > Unfortunately, I think it's likely that we won't ever revise it, so > the point may be moot. Maybe the best way to handle this is for > someone (Chris?) to write a separate document that updates this one, > which specifies how the special-use mailboxes should be set up in the > first place. > > Barry > > > 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 > > imapext@ietf.org? > > > > > > > > On Mon, Jul 20, 2015 at 12:25 AM, RFC Errata System > > <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> > >> > >> 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] [Technical Errata Reported] RFC6154 (4422) RFC Errata System
- [MORG] [Errata Held for Document Update] RFC6154 … RFC Errata System
- Re: [MORG] [Technical Errata Reported] RFC6154 (4… Jamie Nicolson
- Re: [MORG] [Technical Errata Reported] RFC6154 (4… Barry Leiba
- Re: [MORG] [Technical Errata Reported] RFC6154 (4… Jamie Nicolson
- Re: [MORG] [Technical Errata Reported] RFC6154 (4… Alexey Melnikov
- Re: [MORG] [Technical Errata Reported] RFC6154 (4… Jamie Nicolson