From nobody Mon Jul 20 00:29:44 2015 Return-Path: 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 8B9851A0173 for ; Mon, 20 Jul 2015 00:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 esx7FG6CkE6f for ; Mon, 20 Jul 2015 00:29:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0882C1A0430 for ; Mon, 20 Jul 2015 00:29:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6923F18020A; Mon, 20 Jul 2015 00:25:30 -0700 (PDT) To: barryleiba@computer.org, nicolson@google.com, barryleiba@computer.org, rg+ietf@qualcomm.com, barryleiba@computer.org, tss@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150720072530.6923F18020A@rfc-editor.org> Date: Mon, 20 Jul 2015 00:25:30 -0700 (PDT) Archived-At: Cc: morg@ietf.org, rfc-editor@rfc-editor.org Subject: [MORG] [Technical Errata Reported] RFC6154 (4422) X-BeenThere: morg@ietf.org 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 07:29:33 -0000 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 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 From nobody Mon Jul 20 00:34:22 2015 Return-Path: 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 DA4A11A0102; Mon, 20 Jul 2015 00:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 16iJfuvHJ8lV; Mon, 20 Jul 2015 00:34:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 723BE1A00CF; Mon, 20 Jul 2015 00:34:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D0AD9180471; Mon, 20 Jul 2015 00:30:31 -0700 (PDT) To: chris.newman@oracle.com, barryleiba@computer.org, nicolson@google.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150720073031.D0AD9180471@rfc-editor.org> Date: Mon, 20 Jul 2015 00:30:31 -0700 (PDT) Archived-At: Cc: morg@ietf.org, barryleiba@computer.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [MORG] [Errata Held for Document Update] RFC6154 (4422) X-BeenThere: morg@ietf.org 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 07:34:21 -0000 The following errata report has been held for document update 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 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Chris Newman Date Reported: 2015-07-20 Held by: Barry Leiba (IESG) 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. -------------------------------------- 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 From nobody Mon Jul 20 13:47:25 2015 Return-Path: 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 D6D611B31BB for ; Mon, 20 Jul 2015 13:47:23 -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 BCIJ7PGcQbI6 for ; Mon, 20 Jul 2015 13:47:21 -0700 (PDT) Received: from mail-vn0-x22a.google.com (mail-vn0-x22a.google.com [IPv6:2607:f8b0:400c:c0f::22a]) (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 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; d=google.com; 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; 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=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 10.52.110.135 with SMTP id ia7mr39104259vdb.69.1437425240205; Mon, 20 Jul 2015 13:47:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.204 with HTTP; Mon, 20 Jul 2015 13:46:50 -0700 (PDT) In-Reply-To: <20150720072530.6923F18020A@rfc-editor.org> References: <20150720072530.6923F18020A@rfc-editor.org> 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:47:24 -0000 --bcaec5486072d5acee051b54a462 Content-Type: text/plain; charset=UTF-8 [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? 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 > > 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 > > --bcaec5486072d5acee051b54a462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[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 i= s vague on the point of who creates special-use folders. If the server supp= orts CREATE-SPECIAL-USE (presumably that was the case in your example), the= n either the server or client can create them. In this case the client soft= ware could have seen that 1) the special-use folders were missing but 2) th= e server supported CREATE-SPECIAL-USE, and then decided to create the folde= rs 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 speci= al-use attributes?

It seems to me that, even witho= ut this spec, someone (client or server) would be creating these folders. W= ith the spec, the same entity should create the folders with the appropriat= e special-use tag, but first check to see if a folder already exists with t= hat tag and, if so, use it instead. So, a client that needs to put Drafts s= omewhere 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 su= pports CREATE-SPECIAL-USE. Similarly, if the server does automatic junk mai= l 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 cor= ollary, the server can create any needed special-use folders at account ini= tialization, 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 ra= ise 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/err= ata_search.php?rfc=3D6154&eid=3D4422

--------------------------------------
Type: Technical
Reported by: Chris Newman <ch= ris.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 implementat= ions on 2015-07-19. This is assumed to be a "hold for document update&= quot; 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 requiremen= t to do so and clients may use the CREATE-SPECIAL-USE or METADATA extension= s to bootstrap but there is no requirement to use those mechanisms if the s= erver offers them. This resulted in a server implementation assuming the cl= ient would bootstrap these attributes and a client assuming the server woul= d 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 bootstrappin= g special use mailboxes. This means if clients create a mailbox intended fo= r special use (e.g., drafts, sent, junk, trash, etc), and the CREATE-SPECIA= L-USE extension is offered, then clients need to provide the USE extension = to improve interoperability.=C2=A0 Servers that are provisioned with an end= -user's locale or language need to pre-create appropriate special-use m= ailboxes to improve interoperability of this extension. For existing accoun= ts where the server is upgraded to support this feature, the server can loo= k for mailboxes with names that imply special use and add the attribute to = those mailboxes (especially if the server has locale/language awareness pro= visioned 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 us= e based on its name can use the
=C2=A0METADATA extension, if offered, to label that mailbox appropriately.<= br>
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IMAP LIST Ext= ension for Special-Use Mailboxes
Publication Date=C2=A0 =C2=A0 : March 2011
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Leiba, J. Nicolson Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Message Organizati= on
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Applications<= br> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--bcaec5486072d5acee051b54a462-- From nobody Mon Jul 20 15:17:45 2015 Return-Path: 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 EFD881A8771 for ; Mon, 20 Jul 2015 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 jS3ChzqBLrTu for ; Mon, 20 Jul 2015 15:17:42 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 E7F171A876F for ; Mon, 20 Jul 2015 15:17:41 -0700 (PDT) Received: by vnk197 with SMTP id 197so28502495vnk.3 for ; Mon, 20 Jul 2015 15:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BxIwdAbRB1DWZ75fFDhVq4dM35ruFuabNoMv+Mqd3/g=; b=siKZDsXU0FsPdGP+/sBFxLsyAuSfsYRXE/DDwIdNxWeFRwfPNKqwTCgncxe9EpGuP5 ywCheJ6IqcW7Iu2V4sn7UiyENbqAzqNrZrOYK16dGVon/EIH4o4/TKMSzUYHaLo3G5Ju QQu/gez+p4lCTuCHRqugm1QYRJ6puw4aIDJEAfluw9v+fWEN9v9BqRbF+Gd7rYWxVOOz j0GaUu3V4M7tJhsJUUTDNnRmsBwOpFePIL8bXh6X06Eti1c3io4dWkYuJldwhOZmV21L xXeDcIh5SiNbxN+Dta5Ryk5iI57gYZCnq0eEuIImVPAk0eYv51Q6NUpvCyveSraHCSWA yPzw== MIME-Version: 1.0 X-Received: by 10.52.100.167 with SMTP id ez7mr39446093vdb.80.1437430661198; Mon, 20 Jul 2015 15:17:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Mon, 20 Jul 2015 15:17:41 -0700 (PDT) In-Reply-To: References: <20150720072530.6923F18020A@rfc-editor.org> Date: Mon, 20 Jul 2015 18:17:41 -0400 X-Google-Sender-Auth: OerJXDMtyJ-dFVZdtYLIXRG_Ync Message-ID: From: Barry Leiba To: Jamie Nicolson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Timo Sirainen , Randall Gellens , morg , RFC Errata System 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 22:17:44 -0000 > [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 > 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 >> >> 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 >> > From nobody Mon Jul 20 15:21:07 2015 Return-Path: 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 ; 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 ; 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 ; Mon, 20 Jul 2015 15:21:00 -0700 (PDT) Received: by vnk197 with SMTP id 197so28528211vnk.3 for ; 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: References: <20150720072530.6923F18020A@rfc-editor.org> From: Jamie Nicolson Date: Mon, 20 Jul 2015 15:20:30 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b5d5d32ca7c3b051b55f380 Archived-At: Cc: Timo Sirainen , Randall Gellens , morg , RFC Errata System 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 22:21:03 -0000 --047d7b5d5d32ca7c3b051b55f380 Content-Type: text/plain; charset=UTF-8 Perfect, thanks for the explanation. On Mon, Jul 20, 2015 at 3:17 PM, Barry Leiba 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 > > 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 > >> > >> 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 > >> > > > --047d7b5d5d32ca7c3b051b55f380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 pro= cedure 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.=C2=A0 He said up front that he expected this to be "he= ld
for document update", which means that the "error" he raised= is too
involved for a simple fix that might be "verified", and that it n= eeds
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.=C2=A0 And I think we should consider it if we<= br> ever revise it.

Unfortunately, I think it's likely that we won't ever revise it, so=
the point may be moot.=C2=A0 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 fo= lders.
> If the server supports CREATE-SPECIAL-USE (presumably that was the cas= e in
> your example), then either the server or client can create them. In th= is
> case the client software could have seen that 1) the special-use folde= rs
> were missing but 2) the server supported CREATE-SPECIAL-USE, and then<= br> > decided to create the folders itself. There's nothing in the spec = to
> counterindicate this behavior--i.e. nothing that requires the server t= o
> create the special use folders. What happened next--did the client cre= ate
> 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 che= ck to
> see if a folder already exists with that tag and, if so, use it instea= d. So,
> a client that needs to put Drafts somewhere should 1) look for an exis= ting
> folder with \Drafts and 2) if that doesn't exist, create one and a= nnotate 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 does= n't
> exist create one. (As a corollary, the server can create any needed > special-use folders at account initialization, since it knows there wi= ll 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@ie= tf.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=3D6154&eid=3D4422
>>
>> --------------------------------------
>> 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 interope= rability
>> 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 at= tributes
>> are bootstrapped. Servers may pre-create them but there's no r= equirement to
>> do so and clients may use the CREATE-SPECIAL-USE or METADATA exten= sions to
>> bootstrap but there is no requirement to use those mechanisms if t= he 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 pro= blem
>> 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), a= nd the
>> CREATE-SPECIAL-USE extension is offered, then clients need to prov= ide the
>> USE extension to improve interoperability.=C2=A0 Servers that are = provisioned
>> with an end-user's locale or language need to pre-create appro= priate
>> special-use mailboxes to improve interoperability of this extensio= n. For
>> existing accounts where the server is upgraded to support this fea= ture, the
>> server can look for mailboxes with names that imply special use an= d add the
>> attribute to those mailboxes (especially if the server has locale/= language
>> awareness provisioned for users). Clients that implement a name-ba= sed search
>> if special use attributes are not present and decide to use a mail= box for a
>> special use based on its name can use the
>>=C2=A0 METADATA extension, if offered, to label that mailbox approp= riately.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If neces= sary, 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IMAP= LIST Extension for Special-Use Mailboxes
>> Publication Date=C2=A0 =C2=A0 : March 2011
>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Leiba, J. N= icolson
>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAND= ARD
>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Message O= rganization
>> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Appl= ications
>> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
>> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>>
>

--047d7b5d5d32ca7c3b051b55f380-- From nobody Mon Jul 20 23:26:09 2015 Return-Path: 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 9750E1AD062 for ; Mon, 20 Jul 2015 23:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1yEslb9kAgh for ; Mon, 20 Jul 2015 23:26:05 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (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; d=isode.com; s=selector; i=@isode.com; 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 [192.168.1.76] (58.33.broadband15.iol.cz [90.182.33.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 21 Jul 2015 07:26:01 +0100 To: Jamie Nicolson References: <20150720072530.6923F18020A@rfc-editor.org> From: Alexey Melnikov X-Enigmail-Draft-Status: N1110 Message-ID: <55ADE5E3.4000501@isode.com> 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 , 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 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.] >=20 > Thanks for implementing the spec and providing feedback. >=20 > 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.) >=20 > 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 ? >=20 >=20 >=20 > On Mon, Jul 20, 2015 at 12:25 AM, RFC Errata System > > wrote: >=20 > The following errata report has been submitted for RFC6154, > "IMAP LIST Extension for Special-Use Mailboxes". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6154&eid=3D4422 >=20 > -------------------------------------- > Type: Technical > Reported by: Chris Newman > >=20 > Section: GLOBAL >=20 > Original Text > ------------- > N/A >=20 > Corrected Text > -------------- > N/A >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -------------------------------------- > 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 >=20 >=20 >=20 >=20 > _______________________________________________ > MORG mailing list > MORG@ietf.org > https://www.ietf.org/mailman/listinfo/morg > Note Well: http://www.ietf.org/maillist.html >=20 From nobody Tue Jul 21 10:30:03 2015 Return-Path: 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 ; 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 ; 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 ; Tue, 21 Jul 2015 10:29:58 -0700 (PDT) Received: by vnaa140 with SMTP id a140so38572598vna.2 for ; 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> <55ADE5E3.4000501@isode.com> From: Jamie Nicolson Date: Tue, 21 Jul 2015 10:29:28 -0700 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e0153800ad14cec051b6600aa Archived-At: Cc: Timo Sirainen , Barry Leiba , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 17:30:01 -0000 --089e0153800ad14cec051b6600aa Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 11:25 PM, Alexey Melnikov 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 ? > > > > > > > > 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: > > http://www.rfc-editor.org/errata_search.php?rfc=6154&eid=4422 > > > > -------------------------------------- > > 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 > > MORG@ietf.org > > https://www.ietf.org/mailman/listinfo/morg > > Note Well: http://www.ietf.org/maillist.html > > > > --089e0153800ad14cec051b6600aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20, 2015 at 11:25 PM, Alexey Melnikov <= ;alexey.meln= ikov@isode.com> wrote:
Hi J= amie,

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 wa= s
> 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. Wh= at
> 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 se= rver supported CREATE-SPECIAL-USE because it expected the client to create = the folders.

Additionall= y, 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, agr= eed 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 e= ither one, but it prepopulates the folders.)
=C2=A0
> It seems to me that, even with= out 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 che= ck
> 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) loo= k
> 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<= br> > 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. (A= s 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 <ma= ilto: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:
>
>=C2=A0 =C2=A0 =C2=A0The following errata report has been submitted for = RFC6154,
>=C2=A0 =C2=A0 =C2=A0"IMAP LIST Extension for Special-Use Mailboxes= ".
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0You may review the report below and at:
>=C2=A0 =C2=A0 =C2=A0http://= www.rfc-editor.org/errata_search.php?rfc=3D6154&eid=3D4422
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0Type: Technical
>=C2=A0 =C2=A0 =C2=A0Reported by: Chris Newman <chris.newman@oracle.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chris.newman@oracle.com>>
>
>=C2=A0 =C2=A0 =C2=A0Section: GLOBAL
>
>=C2=A0 =C2=A0 =C2=A0Original Text
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 =C2=A0 =C2=A0N/A
>
>=C2=A0 =C2=A0 =C2=A0Corrected Text
>=C2=A0 =C2=A0 =C2=A0--------------
>=C2=A0 =C2=A0 =C2=A0N/A
>
>=C2=A0 =C2=A0 =C2=A0Notes
>=C2=A0 =C2=A0 =C2=A0-----
>=C2=A0 =C2=A0 =C2=A0There is missing information in this RFC that resul= ted in
>=C2=A0 =C2=A0 =C2=A0interoperability problems when we performed an info= rmal interop test
>=C2=A0 =C2=A0 =C2=A0of multiple implementations on 2015-07-19. This is = assumed to be a
>=C2=A0 =C2=A0 =C2=A0"hold for document update" errata.
>
>=C2=A0 =C2=A0 =C2=A0There is no guidance in the document related to how= special-use
>=C2=A0 =C2=A0 =C2=A0attributes are bootstrapped. Servers may pre-create= them but there's
>=C2=A0 =C2=A0 =C2=A0no requirement to do so and clients may use the CRE= ATE-SPECIAL-USE
>=C2=A0 =C2=A0 =C2=A0or METADATA extensions to bootstrap but there is no= requirement to
>=C2=A0 =C2=A0 =C2=A0use those mechanisms if the server offers them. Thi= s resulted in a
>=C2=A0 =C2=A0 =C2=A0server implementation assuming the client would boo= tstrap these
>=C2=A0 =C2=A0 =C2=A0attributes and a client assuming the server would d= o so, thus
>=C2=A0 =C2=A0 =C2=A0interoperability failed.
>
>=C2=A0 =C2=A0 =C2=A0Given this experience, the fastest way to resolve t= his interop
>=C2=A0 =C2=A0 =C2=A0problem over time is for both client and server to = take
>=C2=A0 =C2=A0 =C2=A0responsibility for bootstrapping special use mailbo= xes. This means
>=C2=A0 =C2=A0 =C2=A0if clients create a mailbox intended for special us= e (e.g., drafts,
>=C2=A0 =C2=A0 =C2=A0sent, junk, trash, etc), and the CREATE-SPECIAL-USE= extension is
>=C2=A0 =C2=A0 =C2=A0offered, then clients need to provide the USE exten= sion to improve
>=C2=A0 =C2=A0 =C2=A0interoperability.=C2=A0 Servers that are provisione= d with an end-user's
>=C2=A0 =C2=A0 =C2=A0locale or language need to pre-create appropriate s= pecial-use
>=C2=A0 =C2=A0 =C2=A0mailboxes to improve interoperability of this exten= sion. For
>=C2=A0 =C2=A0 =C2=A0existing accounts where the server is upgraded to s= upport this
>=C2=A0 =C2=A0 =C2=A0feature, the server can look for mailboxes with nam= es that imply
>=C2=A0 =C2=A0 =C2=A0special use and add the attribute to those mailboxe= s (especially if
>=C2=A0 =C2=A0 =C2=A0the server has locale/language awareness provisione= d for users).
>=C2=A0 =C2=A0 =C2=A0Clients that implement a name-based search if speci= al use attributes
>=C2=A0 =C2=A0 =C2=A0are not present and decide to use a mailbox for a s= pecial use based
>=C2=A0 =C2=A0 =C2=A0on its name can use the
>=C2=A0 =C2=A0 =C2=A0 METADATA extension, if offered, to label that mail= box appropriately.
>
>=C2=A0 =C2=A0 =C2=A0Instructions:
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 =C2=A0 =C2=A0This erratum is currently posted as "Reported&= quot;. If necessary, please
>=C2=A0 =C2=A0 =C2=A0use "Reply All" to discuss whether it sho= uld be verified or
>=C2=A0 =C2=A0 =C2=A0rejected. When a decision is reached, the verifying= party (IESG)
>=C2=A0 =C2=A0 =C2=A0can log in to change the status and edit the report= , if necessary.
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0RFC6154 (draft-ietf-morg-list-specialuse-06)
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: IMAP LIST Extension for Special-Use Mailboxes
>=C2=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : March 2011
>=C2=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= B. Leiba, J. Nicolson
>=C2=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := PROPOSED STANDARD
>=C2=A0 =C2=A0 =C2=A0Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Message Organization
>=C2=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Applications
>=C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : IETF
>=C2=A0 =C2=A0 =C2=A0Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
>
>
>
> _______________________________________________
> MORG mailing list
> MORG@ietf.org
> https://www.ietf.org/mailman/listinfo/morg
> Note Well: http://www.ietf.org/maillist.html
>


--089e0153800ad14cec051b6600aa--