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