From nobody Thu Jul 19 14:43:23 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F911271FF for ; Thu, 19 Jul 2018 14:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0mPoE1uWgxIO for ; Thu, 19 Jul 2018 14:43:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CB812F18C for ; Thu, 19 Jul 2018 14:43:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8571CB819EE; Thu, 19 Jul 2018 14:43:12 -0700 (PDT) To: barryleiba@computer.org, nicolson@google.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, rg+ietf@qualcomm.com, barryleiba@computer.org, tss@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: brong@fastmailteam.com, morg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180719214312.8571CB819EE@rfc-editor.org> Date: Thu, 19 Jul 2018 14:43:12 -0700 (PDT) Archived-At: Subject: [MORG] [Editorial Errata Reported] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:43:21 -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/eid5431 -------------------------------------- Type: Editorial Reported by: Bron Gondwana Section: 2 Original Text ------------- An IMAP server that supports this extension MAY include any or all of the following attributes in responses to the non-extended IMAP LIST command. Corrected Text -------------- An IMAP server that supports this extension SHOULD include any or all of the following attributes in responses to the non-extended IMAP LIST command. Notes ----- There exist clients which send a non-extended LIST command and will correctly display and interact with mailboxes usefully if their special-uses are given in the response. Because of this, many servers are already replying with the special-use attributes, and there are no known reports of clients being broken by that behaviour. Because of this, the MAY should be raised to a SHOULD, and server implementations should default to turning this on. 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 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 Thu Jul 19 15:26:19 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34587130E14 for ; Thu, 19 Jul 2018 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=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 1m5zO7BKwd-M for ; Thu, 19 Jul 2018 15:26:15 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (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 A5107130E59 for ; Thu, 19 Jul 2018 15:26:15 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id p4-v6so12097239itf.2 for ; Thu, 19 Jul 2018 15:26:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TCrB07Megp268vMtA5fqoN4XEfHM8aavplN2Wlg6YPw=; b=C63YTsiuQIpcTBcgpA0oBTfoAeeAWiia26UP8gO0nSlHTRrHRqFdKPXjhJx1io0n2W 2hcx8wPZDvt/9rYMYYi9cAMHSOcA0N98JUqm5ymoMBBj9C4od8j1jSjM3LSW2gaI+EeL UC8tUTF/ALSiMltZ4hpZyiGxBimTFyW4upFt53Z2nFXtLLRjgc5JFxOiXfooKeWr7krX ptYm35ABa3pYjzJSQceQ9Cqgs8sIw1Y1FukI0SHk+HOaMKsWT77KjvFoJ4IegMgf4NZ0 pFBEexNK0r3x1bUi0JhtXjHRnarlPVmzUMOdlSjFHE8+AFYFgkcXzCWiVLxzmkAtOZsk +pWw== X-Gm-Message-State: AOUpUlH83TMaQRz4lR3ML/peiNk2X2cAnVMEPo3Sk04ZdU34iGk51J4f r3YjWhj5imh6zhxSexikW+4GZnxe9/VBTXfvYdg= X-Google-Smtp-Source: AAOMgpfkzsYBfLzWJ9lBN3PulL34a+yvAE0z7/ItgvfXNLlwQVK8f0SPlIuf4y3W9ZFqg5UnquW13W0CgC1Ua2gDHfc= X-Received: by 2002:a24:684d:: with SMTP id v74-v6mr7414780itb.88.1532039174879; Thu, 19 Jul 2018 15:26:14 -0700 (PDT) MIME-Version: 1.0 References: <20180719214312.8571CB819EE@rfc-editor.org> In-Reply-To: <20180719214312.8571CB819EE@rfc-editor.org> From: Barry Leiba Date: Thu, 19 Jul 2018 18:26:03 -0400 Message-ID: To: RFC Errata System Cc: aamelnikov@fastmail.fm, adam@nostrum.com, ben@nostrum.com, brong@fastmailteam.com, morg@ietf.org, nicolson@google.com, rg+ietf@qualcomm.com, tss@iki.fi Content-Type: multipart/alternative; boundary="000000000000cd00ec057161aa17" Archived-At: Subject: Re: [MORG] [Editorial Errata Reported] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:26:18 -0000 --000000000000cd00ec057161aa17 Content-Type: text/plain; charset="UTF-8" > There exist clients which send a non-extended LIST command and will > correctly display and interact with mailboxes usefully if their > special-uses are given in the response. > > Because of this, many servers are already replying with the special-use > attributes, and there are no known reports of clients being broken by > that behaviour. Because of this, the MAY should be raised to a SHOULD, > and server implementations should default to turning this on. That may (ahem) be true now, but the document says exactly what we intended it to say when it was written. Alexey, please mark this report REJECTED. Barry On Thu, Jul 19, 2018 at 5:51 PM 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/eid5431 > > -------------------------------------- > Type: Editorial > Reported by: Bron Gondwana > > Section: 2 > > Original Text > ------------- > An IMAP server that supports this extension MAY include any or all of > the following attributes in responses to the non-extended IMAP LIST > command. > > Corrected Text > -------------- > An IMAP server that supports this extension SHOULD include any or all of > the following attributes in responses to the non-extended IMAP LIST > command. > > Notes > ----- > There exist clients which send a non-extended LIST command and will > correctly display and interact with mailboxes usefully if their > special-uses are given in the response. > > Because of this, many servers are already replying with the special-use > attributes, and there are no known reports of clients being broken by that > behaviour. Because of this, the MAY should be raised to a SHOULD, and > server implementations should default to turning this on. > > 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 > 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 > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --000000000000cd00ec057161aa17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> There exi= st clients which send a non-extended LIST command and will

> correctly disp= lay and interact with mailboxes usefully if their

> special-uses a= re given in the response.

>

> Because of thi= s, many servers are already replying with the special-use

> attributes, an= d there are no known reports of clients being broken by

> that behaviour= .=C2=A0 Because of this, the MAY should be raised to a SHOULD,

> and server imp= lementations should default to turning this on.

<= /span>

That may (ahem) be = true now, but the document says exactly what we intended it to say when it = was written.

<= /span>

Alexey, please mark= this report REJECTED.

<= /span>

Barry


On Thu, Jul 19, 2018 at 5:51 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
=
The following errata report has been submitt= ed for RFC6154,
"IMAP LIST Extension for Special-Use Mailboxes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5431

--------------------------------------
Type: Editorial
Reported by: Bron Gondwana <brong@fastmailteam.com>

Section: 2

Original Text
-------------
An IMAP server that supports this extension MAY include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

Corrected Text
--------------
An IMAP server that supports this extension SHOULD include any or all of the following attributes in responses to the non-extended IMAP LIST
command.

Notes
-----
There exist clients which send a non-extended LIST command and will correct= ly display and interact with mailboxes usefully if their special-uses are g= iven in the response.

Because of this, many servers are already replying with the special-use att= ributes, and there are no known reports of clients being broken by that beh= aviour.=C2=A0 Because of this, the MAY should be raised to a SHOULD, and se= rver implementations should default to turning this on.

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=C2=A0
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
--
Barry
--
Barry Leiba =C2=A0(barryleiba@computer.= org)
http://internetmessagingtechnology.org/
--000000000000cd00ec057161aa17-- From nobody Thu Jul 19 15:33:36 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E73130EA7 for ; Thu, 19 Jul 2018 15:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JJGoOqlP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HX2VueBC 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 itIwJySX-clM for ; Thu, 19 Jul 2018 15:33:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B5B130E66 for ; Thu, 19 Jul 2018 15:33:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5C25621B6A; Thu, 19 Jul 2018 18:33:30 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 19 Jul 2018 18:33:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bnJpHS sp/BXDuMdN05bMfkoUplSuSmrX5KLGShKrG4A=; b=JJGoOqlP6Ayn/c+U5/wrgy NvMgVXjo10Wa/6e3I1UCmRIYbSWI0ouC1GszFnGYojB3RJzix3QLV5f8TDeoExaU Fr/gRt/ZXz3Xbuu4i9HAw5M9dtJWgX3XbRVFLhaJp0hI3X7UTNoNaLDumISUUj2y anfVi2iz5KNo3CVbaqva0QJnnnrc23ZadDHoBlM8MJiHSG5NhtrbsTwZo0/Gyi/I 6NUs89BDNgTP2svGaWTJfHSqcaKBm+I89Nd6avgW3tJs47ySSsr+ryZJeFN9IPhQ JSKN9QrzqbMZEqVyRrpC1ba96Nc4jMB8pth9bEeC+aMFq+EMCYhFbdr26DCnIyVA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bnJpHS sp/BXDuMdN05bMfkoUplSuSmrX5KLGShKrG4A=; b=HX2VueBCsnZD0xrExUoXRB UqGgesLYzAY66w4tbNQPRjFd2TRExXo4j1DBYnAYnE3Ljo1AYGouR71SzcKffv5v mrKeVLQf/Al/BMjB/m3QV6PVdiNFYxt4Qw0LYwsVTErzskyw7cIcnCY+rZhxD9C4 1xeKTfKT8PyfvQMBJzE9bdgG/prG4oHWTGONzOOvTmK4BMRon+Rg0ab7jvkuDLAt HlMspAKMDA4eYERAXGSkC5J86fQiymeCKB+I+4F0EsBoENq8MtzMrugadQVOWkpY ph7mFnscvJ6ip2tfPtRjtD4hvpzX+wOdG666tzGwvv5R4W3mQdTmrOYWMCyp/8bQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87ED39E102; Thu, 19 Jul 2018 18:33:29 -0400 (EDT) Message-Id: <1532039609.216542.1446679184.57EA6E86@webmail.messagingengine.com> From: Bron Gondwana To: Barry Leiba , RFC Errata System Cc: aamelnikov@fastmail.fm, adam@nostrum.com, ben@nostrum.com, morg@ietf.org, nicolson@google.com, rg+ietf@qualcomm.com, tss@iki.fi MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15320396092165422" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e74bb3a0 Date: Fri, 20 Jul 2018 08:33:29 +1000 In-Reply-To: References: <20180719214312.8571CB819EE@rfc-editor.org> Archived-At: Subject: Re: [MORG] [Editorial Errata Reported] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:33:35 -0000 This is a multi-part message in MIME format. --_----------=_15320396092165422 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Fair enough! Is there a better way to say "if you're implementing now, please do this to get best interop"? On Fri, Jul 20, 2018, at 08:26, Barry Leiba wrote: > > There exist clients which send a non-extended LIST command and will> > correctly display and interact with mailboxes usefully if their > > special-uses are given in the response. > > > > Because of this, many servers are already replying with the > > special-use> > attributes, and there are no known reports of clients being > > broken by> > that behaviour. Because of this, the MAY should be raised to a > > SHOULD,> > and server implementations should default to turning this on. > > That may (ahem) be true now, but the document says exactly what we > intended it to say when it was written.> > Alexey, please mark this report REJECTED. > > Barry > > > On Thu, Jul 19, 2018 at 5:51 PM RFC Errata System 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/eid5431 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Bron Gondwana >> >> Section: 2 >> >> Original Text >> ------------- >> An IMAP server that supports this extension MAY include any or >> all of>> the following attributes in responses to the non-extended IMAP LIST>> command. >> >> Corrected Text >> -------------- >> An IMAP server that supports this extension SHOULD include any or >> all of>> the following attributes in responses to the non-extended IMAP LIST>> command. >> >> Notes >> ----- >> There exist clients which send a non-extended LIST command and will >> correctly display and interact with mailboxes usefully if their special- >> uses are given in the response.>> >> Because of this, many servers are already replying with the special- >> use attributes, and there are no known reports of clients being >> broken by that behaviour. Because of this, the MAY should be raised >> to a SHOULD, and server implementations should default to turning >> this on.>> >> 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 >> 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 > -- > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15320396092165422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Fair enough! Is there a better way = to say "if you're implementing now, please do this to get best interop"?


On Fri, Jul 20, 2018, at 08:26, Barry Leiba wrote:

> There exist clients which send a non-extended LIST= command and will

> correctly display and interact with= mailboxes usefully if their

= > special-uses are given i= n the response.

>

> Because of = this, many servers are already replying with the special-use<= /span>

> attributes, and there are no known reports of clients being broken = by

> that behaviour.  Because of this, the MAY sho= uld be raised to a SHOULD,

> and server implementations= should default to turning this on.


<= span class=3D"size" style=3D"font-size:12px">That may (ahem) be true now, but the document says exactly = what we intended it to say when it was written.


Alexey, please mark this report REJECTED.


Barry



On Thu, Jul 19, 2= 018 at 5:51 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitt= ed for RFC6154,
"IMAP LIST Extension for Special-Use Mai= lboxes".

--------------------------------------
You may review the report below and at:<= br>

--------------------------------------
Type: Editorial
Reported by: Bron Gondwana <brong@fastmailteam.com>

Section: 2

Original Text
-------------
An IMAP server that supports this extens= ion MAY include any or all of
the following attributes in responses to= the non-extended IMAP LIST
command.

Corrected Text
--------------
An IMAP server that supports this extens= ion SHOULD include any or all of
the following attributes in responses to= the non-extended IMAP LIST
command.

Notes
-----
There exist clients which send a non-ext= ended LIST command and will correctly display and interact with mailboxes u= sefully if their special-uses are given in the response.

Because of this, many servers are alread= y replying with the special-use attributes, and there are no known reports = of clients being broken by that behaviour.  Because of this, the MAY s= hould be raised to a SHOULD, and server implementations should default to t= urning this on.

Instructions:
-------------
This erratum is currently posted as "Rep= orted". If necessary, please
use "Reply All" to discuss whether it sh= ould be verified or
rejected. When a decision is reached, th= e verifying party 
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 20= 11
Author(s)        &nb= sp;  : B. Leiba, J. Nicolson
Category        &nbs= p;   : PROPOSED STANDARD
Source         =     : Message Organization
Area          &= nbsp;     : Applications
Stream         =     : IETF
Verifying Party     : IES= G
--

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_15320396092165422-- From nobody Thu Jul 19 15:40:32 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B72E130E59 for ; Thu, 19 Jul 2018 15:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=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 xzL7C9Gp15Ke for ; Thu, 19 Jul 2018 15:40:29 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (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 E593A130E3A for ; Thu, 19 Jul 2018 15:40:28 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id q20-v6so12164170ith.0 for ; Thu, 19 Jul 2018 15:40:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vb1e4t2/tPkg+SXzaYvS+CxZ8ebl/HnvjAsGOhTt+o4=; b=a685jMI+A6VykXBm1Li67MWputPPz1meNzs0c4SjegjGl0tyrio5rs01i9sorq/IYd HmQ3P2K3GTpd5BztlVJzsYVidvJk0y5uGtKTW6FFOpT4vAjDkIdN7ZMQuM59aQ9Ixv2m R0dKmv4gzjWAn/hRyU50PQrfTCt9bx+HNlg8fpe2CjpPlMLtybDcgm24leYzkNkCdTkd W0qRElZyCl+kedbk6fUJoAsCojmEhWZVKFVDIzX0cNjmoCCVmx+6KzwQp48nZuJwqoZO B73oTRjgWATEYTxr/YglB442tbx+64/P6fJZsgRnroa1VAy7XQPaxeHkSihi55gCPl3z /b1Q== X-Gm-Message-State: AOUpUlERHOdbzmyvLeeXCngli2fdx5CMGqSp/ywIQLtHTO8BKXKL8M9r TvI+cOuUtaylKg6pS3mHHBgRhUpbjcOrhkzC8Z7jAEf5 X-Google-Smtp-Source: AAOMgpd+fA5oEo+p+bsPGsqEG9igLuTkXNcKViQsNmlZxHnn/tr7U+hyi54QrBcm91tV6EoFD9Qjm+VL3n6dS3QOlw4= X-Received: by 2002:a24:ad45:: with SMTP id a5-v6mr7278390itj.0.1532040028151; Thu, 19 Jul 2018 15:40:28 -0700 (PDT) MIME-Version: 1.0 References: <20180719214312.8571CB819EE@rfc-editor.org> <1532039609.216542.1446679184.57EA6E86@webmail.messagingengine.com> In-Reply-To: <1532039609.216542.1446679184.57EA6E86@webmail.messagingengine.com> From: Barry Leiba Date: Thu, 19 Jul 2018 18:40:17 -0400 Message-ID: To: Bron Gondwana Cc: RFC Errata System , aamelnikov@fastmail.fm, adam@nostrum.com, ben@nostrum.com, morg@ietf.org, nicolson@google.com, rg+ietf@qualcomm.com, tss@iki.fi Content-Type: multipart/alternative; boundary="000000000000a8e4c2057161dd4f" Archived-At: Subject: Re: [MORG] [Editorial Errata Reported] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:40:31 -0000 --000000000000a8e4c2057161dd4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Write an update RFC. Or we=E2=80=99ll put it into rev4.2 On Thu, Jul 19, 2018 at 6:33 PM Bron Gondwana wrote: > Fair enough! Is there a better way to say "if you're implementing now, > please do this to get best interop"? > > > On Fri, Jul 20, 2018, at 08:26, Barry Leiba wrote: > > > There exist clients which send a non-extended LIST command and will > > > correctly display and interact with mailboxes usefully if their > > > special-uses are given in the response. > > > > > > Because of this, many servers are already replying with the special-use > > > attributes, and there are no known reports of clients being broken by > > > that behaviour. Because of this, the MAY should be raised to a SHOULD, > > > and server implementations should default to turning this on. > > > That may (ahem) be true now, but the document says exactly what we > intended it to say when it was written. > > > Alexey, please mark this report REJECTED. > > > Barry > > > > On Thu, Jul 19, 2018 at 5:51 PM 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/eid5431 > > -------------------------------------- > Type: Editorial > Reported by: Bron Gondwana > > Section: 2 > > Original Text > ------------- > An IMAP server that supports this extension MAY include any or all of > the following attributes in responses to the non-extended IMAP LIST > command. > > Corrected Text > -------------- > An IMAP server that supports this extension SHOULD include any or all of > the following attributes in responses to the non-extended IMAP LIST > command. > > Notes > ----- > There exist clients which send a non-extended LIST command and will > correctly display and interact with mailboxes usefully if their > special-uses are given in the response. > > Because of this, many servers are already replying with the special-use > attributes, and there are no known reports of clients being broken by tha= t > behaviour. Because of this, the MAY should be raised to a SHOULD, and > server implementations should default to turning this on. > > 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 > 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 > > -- > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --000000000000a8e4c2057161dd4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Write an update RFC.=C2=A0 Or we=E2=80=99ll put it i= nto rev4.2

= On Thu, Jul 19, 2018 at 6:33 PM Bron Gondwana <brong@fastmailteam.com> wrote:
Fair enough! Is there a better way to= say "if you're implementing now, please do this to get best inter= op"?


On Fri, Jul 20, 2018, at 08:26, Barry Leiba wrote:

> There exist clients which send a non-extended LIST command and will<= /span>

&= gt; correctly display and interact with mailboxes usefully if their<= /span>

= > spe= cial-uses are given in the response.

>

> Because of this, many server= s are already replying with the special-use

> attributes, and there are n= o known reports of clients being broken by

> that behaviour.=C2=A0 Becaus= e of this, the MAY should be raised to a SHOULD,

> and server implementat= ions should default to turning this on.

<= span class=3D"m_7920524885204155585font" style=3D"font-family:Helvetica">

<= span class=3D"m_7920524885204155585font" style=3D"font-family:Helvetica">That may (ahem) be= true now, but the document says exactly what we intended it to say when it= was written.


Alexey, please mark this report REJECTED.


Barry



On Thu, Jul 19, 2018 at 5:51 PM RFC Errata Syste= m <rfc-ed= itor@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:

--------------------------------------
Type: Editorial
Reported by: Bron Gondwana <brong@fastmailteam.com>

Section: 2

Original Text
-------------
An IMAP server that supports this extensi= on MAY include any or all of
the following attributes in responses to = the non-extended IMAP LIST
command.

Corrected Text
--------------
An IMAP server that supports this extensi= on SHOULD include any or all of
the following attributes in responses to = the non-extended IMAP LIST
command.

Notes
-----
There exist clients which send a non-exte= nded LIST command and will correctly display and interact with mailboxes us= efully if their special-uses are given in the response.

Because of this, many servers are already= replying with the special-use attributes, and there are no known reports o= f clients being broken by that behaviour.=C2=A0 Because of this, the MAY sh= ould be raised to a SHOULD, and server implementations should default to tu= rning this on.

Instructions:
-------------
This erratum is currently posted as "= ;Reported". If necessary, please
use "Reply All" to discuss whet= her it should be verified or
rejected. When a decision is reached, the= verifying party=C2=A0
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 201= 1
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 Organization
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : Applications
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=
--

--
=C2=A0 Bron Gondwana, CEO, Fa= stMail Pty Ltd
=C2=A0 brong@fastmailteam.com

--
Barry
--
Barry Leiba =C2=A0(barryleiba@computer.= org)
http://internetmessagingtechnology.org/
--000000000000a8e4c2057161dd4f-- From nobody Thu Jul 19 15:57:01 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3BF130EE8 for ; Thu, 19 Jul 2018 15:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 FyOUMes7MPHQ for ; Thu, 19 Jul 2018 15:56:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EEE130DD2 for ; Thu, 19 Jul 2018 15:56:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV287NZDFK007X6I@mauve.mrochek.com> for morg@ietf.org; Thu, 19 Jul 2018 15:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532040708; bh=DHwddQiXbtg1GCkbUZ/8DJa60QTIAkIU15PGvML26/Q=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=esUqQP6Q/i/Lh7oOKeEsAoT1gjzR1beMXI3Lc7cLMhIx+rZssdDEkqUknugVn5UMJ KivY5vxhbK6vip/fzdLN2R9UaE8FN/C0bTF/Wg5FUOwC56TQNPKd1UObSZJlfaA2Ix jIvRVFCqXSlOtxLkhGT9Z6T/+nq+43SzcVHO/Uds= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QUCIBNY1B4000051@mauve.mrochek.com>; Thu, 19 Jul 2018 15:51:44 -0700 (PDT) Cc: RFC Errata System , ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, brong@fastmailteam.com, morg@ietf.org, rg+ietf@qualcomm.com, tss@iki.fi Message-id: <01QV287IKNBI000051@mauve.mrochek.com> Date: Thu, 19 Jul 2018 15:36:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Jul 2018 18:26:03 -0400" References: <20180719214312.8571CB819EE@rfc-editor.org> To: Barry Leiba Archived-At: Subject: Re: [MORG] [Editorial Errata Reported] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:56:58 -0000 > > There exist clients which send a non-extended LIST command and will > > correctly display and interact with mailboxes usefully if their > > special-uses are given in the response. > > > > Because of this, many servers are already replying with the special-use > > attributes, and there are no known reports of clients being broken by > > that behaviour. Because of this, the MAY should be raised to a SHOULD, > > and server implementations should default to turning this on. > That may (ahem) be true now, but the document says exactly what we intended > it to say when it was written. > Alexey, please mark this report REJECTED. The existence of such clients is not really the issue, although it's what makes the issue a pressing matter. Rather, the issue is that the semantics provided by the specification provide no reliable way to obtain special use information, and thus cannot be said to provide a minimum level of interoperability. In particular: (1) SPECIAL-USE does not require LIST-EXTENDED be implemented. (2) The MAY on returning special use attributes as part of unextended LIST means that there's no way to distinguish between the (common) case of no special use attributes being set and LIST not supporting returning such attributes. (3) The METADATA approach of deteching special use attributes is also optional. Now, I'm all for supporting existing implementations, but IMO this goes too far. And the simplest way to fix it is to change the MAY. It's also easy to see why clients are simply assuming unextended LIST returns this information regardless of what the standard says. As a client implementer myself in this case (since I'm implementing the Sieve specialuse extension using IMAP) I'm going to assume LIST-EXTENDED is available and fail if it isn't, but I can't say what I'm doing is really any better. Ned From nobody Thu Jul 26 07:31:35 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF032131170; Thu, 26 Jul 2018 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5HPy4watTi_d; Thu, 26 Jul 2018 07:31:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C9C13116A; Thu, 26 Jul 2018 07:31:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 09995B80CC0; Thu, 26 Jul 2018 07:31:22 -0700 (PDT) To: brong@fastmailteam.com, barryleiba@computer.org, nicolson@google.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, morg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180726143122.09995B80CC0@rfc-editor.org> Date: Thu, 26 Jul 2018 07:31:22 -0700 (PDT) Archived-At: Subject: [MORG] [Errata Rejected] RFC6154 (5431) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 14:31:33 -0000 The following errata report has been rejected for RFC6154, "IMAP LIST Extension for Special-Use Mailboxes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5431 -------------------------------------- Status: Rejected Type: Editorial Reported by: Bron Gondwana Date Reported: 2018-07-19 Rejected by: Alexey Melnikov (IESG) Section: 2 Original Text ------------- An IMAP server that supports this extension MAY include any or all of the following attributes in responses to the non-extended IMAP LIST command. Corrected Text -------------- An IMAP server that supports this extension SHOULD include any or all of the following attributes in responses to the non-extended IMAP LIST command. Notes ----- There exist clients which send a non-extended LIST command and will correctly display and interact with mailboxes usefully if their special-uses are given in the response. Because of this, many servers are already replying with the special-use attributes, and there are no known reports of clients being broken by that behaviour. Because of this, the MAY should be raised to a SHOULD, and server implementations should default to turning this on. --VERIFIER NOTES-- The right way to make this change is to revise the document. MAY was intended at the time of publication. -------------------------------------- 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