From nobody Tue May 1 00:11:10 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0740A12E8A6 for ; Tue, 1 May 2018 00:11:09 -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=fnwArJyC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nRcyQ0nK 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 gmEokUFgI_P4 for ; Tue, 1 May 2018 00:11:07 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673FA12E8A3 for ; Tue, 1 May 2018 00:11:07 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 99BAF22BC9; Tue, 1 May 2018 03:11:06 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 01 May 2018 03:11:06 -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=fm2; bh=m+dB7O I5s8cIZax49dN6bW4z/S9Vh2ICnZ/l+rA7Czs=; b=fnwArJyCFRSl4H0eqc/Nta djotaDaMbAyL6d82+BX6rnFF9kIDUAhf2/WCuuKPqsBTRMMA25KV4CmOOrWDifw0 5hIAXK5KrkwTBupMfVEWJtnJgWE7s0gsOZVh7et0wBMFlb9prADjeQlUlJtMhVf9 EK8JWv8OLA18/J+M35hIptqsX2RhvbW+EG/4U7Rs/9FEnzDiM1kt6yYPVV1W15ni rEkGXatJv8OHnUUqE3gbU9KLUxXODtgKDZFT8ZNUa7vZc5oe/+KwrV0oO/1ps/L5 nvr+RMxbbj0VeDeCiBAKe2pIaN0ML6F21FUJQCGUGV8PjlDCSVPQbwnbGkjLBKdg == 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=fm2; bh=m+dB7O I5s8cIZax49dN6bW4z/S9Vh2ICnZ/l+rA7Czs=; b=nRcyQ0nKW4ZiFOaV7A1qVp uJZx0hTjGouyqEn96IwO8v2NPi5/Pze54ce/B+qsKG6ec7IQjWyJtyGADX2yYQwe 2iB9drLe6KfbZRYj3HLJdMUtIxUPRaN18JogcONFHgSS9XiY/scYli9l2fkFLKrE YcAPR7Nx4+XpwdL80nIB3VkCrNrO1Es4MEBeAWeVO3eyED5UnHop9EgBWatkmGSH G8vHzp6Rfnf+spgcNo15inltJ6X/Cx/0nQD88OyNjogYNHv6WAmbIgOfpfsopRDu izxR5bw345kRa/TWuNcKjHPNib0SnB6fX1rHpyz1H1Z1dmUVjV562AmLiqqDoLjw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4C139E2122; Tue, 1 May 2018 03:11:06 -0400 (EDT) Message-Id: <1525158666.2389818.1356559416.235763DA@webmail.messagingengine.com> From: Neil Jenkins To: Barry Leiba , Alexey Melnikov Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152515866623898180" X-Mailer: MessagingEngine.com Webmail Interface - ajax-08ca0473 In-Reply-To: References: <5AE72EAD.9050307@isode.com> Date: Tue, 01 May 2018 17:11:06 +1000 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-specialuse-important-02 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 07:11:09 -0000 This is a multi-part message in MIME format. --_----------=_152515866623898180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue, 1 May 2018, at 2:09 PM, Barry Leiba wrote: > Neil, please make sure that the "not used by JMAP" asterisks are still> a= ccurate with the addition of the three new attributes. I think Subscribed also needs an asterisk =E2=80=93 this is not a concept in JMAP. Other than that, looks good. Cheers, Neil. --_----------=_152515866623898180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Tue, 1 May 2018, at 2:09 PM, Barry Leiba wrote:
Neil, please make sure that the "not used by= JMAP" asterisks are still
accurate with the addition of the three new attributes.

I think Subscribed also needs an asterisk =E2=80=93 this is not a= concept in JMAP. Other than that, looks good.

Cheers,
Neil.
--_----------=_152515866623898180-- From nobody Tue May 1 06:22:52 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1512E8C4 for ; Tue, 1 May 2018 06:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4bMBqVfmUjEi for ; Tue, 1 May 2018 06:22:49 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 1378912E8AE for ; Tue, 1 May 2018 06:22:49 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id c3-v6so13061375itj.4 for ; Tue, 01 May 2018 06:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=AtGwizaDaE4squNYHLbQ8t0xdd1XSVqQpmSwlmS6+bE=; b=AAKfNI0ZVzScizGgFZEcGJQ1wJGx2tbwKnvURsSpjBQYtIH0gsUCY3VyJdDwiIYaNH ItQDcl8wxXWnvDAbxorpQUaazOJfyuUPFKv5dzltcBLgkLtuc9osPzjgIGNSHlTStoCk 9DXdNfoBzaalZt06Sey0ajIVCZx3YH0M2TI+8uCMfaUoM5zm1sFCVYyDhwhtW99APeR4 zV/c+qQhkJ2xmrg6SfLEF43lX/cZwhhKIuH/Wn+ArQ9blPyfR+jgmnFXO3WLsK3czhwz zknTIbNg5mpr8LIdGZETV3xkjiQkCIS1EshT8Ep+RULXC5HY8HymT35/ux18yhYljZIH vvUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=AtGwizaDaE4squNYHLbQ8t0xdd1XSVqQpmSwlmS6+bE=; b=IvSRdfDF+E96jMhnZ8PM9VJ+sIMKmm4Xrzzq2RpVGSeT1d5B7bFJZYS3Df6pmBHd9M iQ4Zi5CoxpXnK8ny4ML6KG/Qxb8WsTq//PTsYnD7f/+G5O7+HoDcrRlFHsoyzrHirxZb 4VK4kJdqa5qkz1P9Wt7W9hmspHkoAKBNi1kaJCTIBRgIZcyCCPVGhF8rj/VEYSAdJ4mN 5oA5wkyDBoT7eoEMbPLf5JY+9LEhGAh1JVRXuCJdb1UcWkRPLgENgMASRvqMdISAXqpu ot/pmVAptN3+RK9sVVFqKUSveCxkoJXVoADDRIAVw3wHsh7bnaUwCzZKLidzdIuK4cTk j/Ww== X-Gm-Message-State: ALQs6tAnBIq90do/FKN4U0nCimYB+vK+HqnQMp43c8yvi8RiEc1qYx8o 2GqTZzrbl+7hjdHLnBXECzGzOJSW1SX/ZbOP4MQKPQ== X-Google-Smtp-Source: AB8JxZpd1qH46EOeVh+m+ThtommM1rUoK24UwCca0w8T8ss3F9ImMg+dq1ITQ8xqFoHfuf2Vw6Vh0EbBwb7YhmS+zBQ= X-Received: by 2002:a24:3344:: with SMTP id k65-v6mr11195235itk.15.1525180968203; Tue, 01 May 2018 06:22:48 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.192.142.169 with HTTP; Tue, 1 May 2018 06:22:47 -0700 (PDT) In-Reply-To: <1525158666.2389818.1356559416.235763DA@webmail.messagingengine.com> References: <5AE72EAD.9050307@isode.com> <1525158666.2389818.1356559416.235763DA@webmail.messagingengine.com> From: Barry Leiba Date: Tue, 1 May 2018 09:22:47 -0400 X-Google-Sender-Auth: 1Z3k7fjj0rz0AF9UZhmbIwws0-c Message-ID: To: Neil Jenkins Cc: extra@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-specialuse-important-02 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 13:22:50 -0000 >> Neil, please make sure that the "not used by JMAP" asterisks are still >> accurate with the addition of the three new attributes. > > I think Subscribed also needs an asterisk =E2=80=93 this is not a concept= in JMAP. How does JMAP handle situations where it's used to access things like IETF mailing lists or usenet news groups, where there can be tens or hundreds of thousands of mailboxes, and the user is only interested in a few of them? b From nobody Thu May 3 15:32:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71E12DA29 for ; Thu, 3 May 2018 15:32:02 -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 D7ykrYCgyvgo for ; Thu, 3 May 2018 15:32:00 -0700 (PDT) Received: from smtp.dovecot.fi (smtp.dovecot.fi [193.209.119.8]) (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 24D2D12DA26 for ; Thu, 3 May 2018 15:31:59 -0700 (PDT) Received: from [10.168.3.2] (unknown [130.89.162.218]) by smtp.dovecot.fi (Halon) with ESMTPSA id c0ca41fe-4f21-11e8-a588-61aa5bb8fead; Fri, 04 May 2018 01:31:48 +0300 (EEST) To: Alexey Melnikov , extra@ietf.org References: <5AE207FD.8020203@isode.com> From: Stephan Bosch Message-ID: <501da8fd-efbe-26a0-e88e-b6c17432fce4@dovecot.fi> Date: Fri, 4 May 2018 00:31:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5AE207FD.8020203@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 22:32:02 -0000 Op 26/04/2018 om 19:10 schreef Alexey Melnikov: > Hi, > > I've been following discussions on this document and it is ready for > IETF Last Call, which I just initiated. > > One nit: I believe the following reference is now Normative, due to > added SHOULD level requirement: > > [QUOTA] > > Please update the document to reflect this next time the document is > revised. Applied in Git: https://github.com/ietfextra/draft-ietf-extra-imap-status-size/commit/0bbbfb5c25b3cec18b16e4c58f3aaa11208a3c10 Regards, Stephan. > > Best Regards, > Alexey, as AD. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu May 3 23:32:53 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68773127078; Thu, 3 May 2018 23:32:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-list-myrights.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152541556631.11734.11664621461529219097@ietfa.amsl.com> Date: Thu, 03 May 2018 23:32:46 -0700 Archived-At: Subject: [Extra] Secdir last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 06:32:46 -0000 Reviewer: Yaron Sheffer Review result: Has Nits The document defines a simple extension to the IMAP LIST command. - LSUB is mentioned in the Introduction, but then never mentioned again. Is the extension applicable to it? - The document does not formally define the syntax of the MYRIGHTS response. Presumably it is exactly as in RFC 4314. - The document should refer to the security considerations of RFC 4314. Specifically, does the first paragraph of those security considerations also apply here? From nobody Fri May 4 01:00:37 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DACA12785F; Fri, 4 May 2018 01:00:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152542082701.11725.13035424163340973100@ietfa.amsl.com> Date: Fri, 04 May 2018 01:00:27 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-savedate-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 08:00:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Internet Message Access Protocol (IMAP) - SAVEDATE Extension Author : Stephan Bosch Filename : draft-ietf-extra-imap-savedate-01.txt Pages : 6 Date : 2018-05-04 Abstract: This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called 'save date' that, unlike the existing 'internal date' attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and it extends the SEARCH command to allow using that attribute in searching criteria. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-savedate-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-savedate-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-savedate-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 4 01:04:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D12127201 for ; Fri, 4 May 2018 01:04:11 -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 AP9YXtQNVwNc for ; Fri, 4 May 2018 01:04:08 -0700 (PDT) Received: from smtp.dovecot.fi (smtp.dovecot.fi [193.209.119.8]) (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 5AB231241FC for ; Fri, 4 May 2018 01:04:08 -0700 (PDT) Received: from [10.168.3.2] (unknown [130.89.162.218]) by smtp.dovecot.fi (Halon) with ESMTPSA id b1adf87e-4f71-11e8-a588-61aa5bb8fead; Fri, 04 May 2018 11:03:57 +0300 (EEST) To: extra@ietf.org References: <152542082701.11725.13035424163340973100@ietfa.amsl.com> From: Stephan Bosch Message-ID: <4fe2ff37-46a7-6da0-8fee-ea735e212269@dovecot.fi> Date: Fri, 4 May 2018 10:03:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152542082701.11725.13035424163340973100@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap-savedate-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 08:04:12 -0000 Hi, This new draft should address the remaining issue about how to handle the lack of support for the save date attribute. See the git repository for details about the changes performed: https://github.com/ietfextra/draft-ietf-extra-imap-savedate Regards, Stephan. Op 04/05/2018 om 10:00 schreef internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Internet Message Access Protocol (IMAP) - SAVEDATE Extension > Author : Stephan Bosch > Filename : draft-ietf-extra-imap-savedate-01.txt > Pages : 6 > Date : 2018-05-04 > > Abstract: > This document adds a new capability called "SAVEDATE" to the Internet > Message Access Protocol (IMAP). It defines a new IMAP message > attribute called 'save date' that, unlike the existing 'internal > date' attribute, always indicates the moment at which the message was > saved in its current mailbox. The SAVEDATE capability extends the > FETCH command with the means to retrieve the save date attribute and > it extends the SEARCH command to allow using that attribute in > searching criteria. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-savedate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap-savedate-01 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-savedate-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-savedate-01 From nobody Fri May 4 08:49:32 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5712D7EC; Fri, 4 May 2018 08:49:31 -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, FREEMAIL_FROM=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=fastmail.fm header.b=SI0chm2A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nRa4iGtA 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 7jPcteMsO2CN; Fri, 4 May 2018 08:49:29 -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 90ECF127136; Fri, 4 May 2018 08:49:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E3063217B2; Fri, 4 May 2018 11:49:25 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 04 May 2018 11:49:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; 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=q/72lhqG6r8khFZs5WiVuNsJG8+zC cMKVFe/CqG+X/c=; b=SI0chm2AUM/H3bbFJaYmAJTf/gARKsulk3ssNHGsVJgCX c/CUFopC7ew+VuvZ9UT/7wY+bsqzy8b3GLDa6oB0GTUlyd4PwFk2gmwrwxCtzORs vpWGlCH4cj0XqTd5+GGu0nqD1ewS87K7p31VzqFPncL67AKVVqHhmzcFsU6906jx eVtgwlLxavYdInW7mtEEg9MJqXua6bl7o5S3a30D1YraXfsHSfI6HgQ78Shr+vHE 9xSk5MCHP4hjH7JNXSC0yz4z7cr1c6cwHgx45Ygczkg9/KxngOHs9XPyvIHrOuCu aEO94unzd2BZm22kWqfy5jMb5V9Pp45SBQ6DkbQ2w== 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=fm2; bh=q/72lh qG6r8khFZs5WiVuNsJG8+zCcMKVFe/CqG+X/c=; b=nRa4iGtA63/vEaOUHRY08l pWcFgS6roBq2mER04/Hnfljsbl9kDDX1Bo4yu6K3G9W7/XH22Y+YQy0oSenyKXeD vAHjQFwYG2x/XYxg8EWPNTfNmLBotlSFtR6EQFmbAZ4clOtwDZweCQ0sDmw5Rwmb JmXzVsL70FqeGxC6sEMw/mhmiUD8C29gVgvHAYxpoJmYBigo82VUJSAfBg9mLe4M AGlVF9I462QsJBZdssekMSt0GxrmIPpMMuvQVrh5CRrlsRC3TPanezFcEREiddXi I3dLbeC+coaL9lapHU9UuOsqycHcCFc4GSByuhgm87izwQc3xEHi4mwwMmpio65A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BB68D9E0F7; Fri, 4 May 2018 11:49:25 -0400 (EDT) Message-Id: <1525448965.3201091.1361023856.2CDEF98E@webmail.messagingengine.com> From: Alexey Melnikov To: Yaron Sheffer , secdir@ietf.org Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-list-myrights.all@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 References: <152541556631.11734.11664621461529219097@ietfa.amsl.com> In-Reply-To: <152541556631.11734.11664621461529219097@ietfa.amsl.com> Date: Fri, 04 May 2018 16:49:25 +0100 Archived-At: Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:49:31 -0000 Hi Yaron, On Fri, May 4, 2018, at 7:32 AM, Yaron Sheffer wrote: > Reviewer: Yaron Sheffer > Review result: Has Nits > > The document defines a simple extension to the IMAP LIST command. > > - LSUB is mentioned in the Introduction, but then never mentioned again. Is the > extension applicable to it? No, LSUB is a non extensible version, which was replaced by extended LIST. > - The document does not formally define the syntax of the MYRIGHTS response. > Presumably it is exactly as in RFC 4314. Correct. > - The document should refer to the security considerations of RFC 4314. > Specifically, does the first paragraph of those security considerations also > apply here? Good point, it does. Best Regards, Alexey From nobody Fri May 4 16:42:08 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8562B12DA16 for ; Fri, 4 May 2018 16:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 eh5_bKKS06wh for ; Fri, 4 May 2018 16:42:04 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 97FC6120721 for ; Fri, 4 May 2018 16:42:04 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w44NfDpH157376 for ; Fri, 4 May 2018 23:42:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=tr0Ky29MoPRPnT6AcVDXGOgpxNvfltMLhOmWWjRQzRk=; b=REU86iSVzdfq8MQEer0UBsImRprQHrPBHnAuNf+HO9rpfe63gu83DvHfaAnv1GbQmx+n pvbBBYNalSOhmDYGKiX/UmlP6c0vN8WjvHTopYLU0v63oNk6IUFipZRMAZ2BoEvUBTYf LDbUu9NXYcYJRQ4IUVsRqF5fyyJ7GFDTAzz54Kpl7CXfVKYSF6sq//BIvBKG8rC2vi9z 4ECtD64aLbBsR3OH25SFO6UrVJKyBSCXFw189zcTMMYI8mwDl1BvW0p6rouv7KAUPik1 qtCsOhWQkwTVtwCQv7qUicbKAF7qxTJYn246OPSDhadYwKGfUFqkOCxC8FASgB08E09K Mw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2hmeg6892v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 04 May 2018 23:42:03 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w44Ng2uK026577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 4 May 2018 23:42:03 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w44Ng2ux031805 for ; Fri, 4 May 2018 23:42:02 GMT Received: from [10.159.137.103] (/10.159.137.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2018 16:42:02 -0700 From: "Chris Newman" To: extra@ietf.org Date: Fri, 04 May 2018 16:42:00 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> In-Reply-To: <5AE207FD.8020203@isode.com> References: <5AE207FD.8020203@isode.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8883 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=12 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805040211 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 23:42:06 -0000 I just noticed we implemented this in 2005 (under the "X-SUN-IMAP" = capability). Looking at the implementation, there's a significant bug in = the specification. Mailbox sizes can easily exceed 4GB; so the ABNF for = status-att-list needs to be replaced as follows: status-att-list =3D status-att SP number63 *(SP status-att SP = number63) ;; number63 is only permitted with extension status attributes ;; that explicitly allow it; such as SIZE number63 =3D 1*DIGIT ;; Positive unsigned 63-bit integer ;; (0 <=3D n <=3D 9,223,372,036,854,775,807). - Chris On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: > Hi, > > I've been following discussions on this document and it is ready for > IETF Last Call, which I just initiated. > > One nit: I believe the following reference is now Normative, due to > added SHOULD level requirement: > > [QUOTA] > > Please update the document to reflect this next time the document is > revised. > > Best Regards, > Alexey, as AD. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DB73C8TOrpzVRz_O= 5v_4esOIRwnbdcZoZaulZWKyZwBY&s=3DAv_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6tFZ= mmM&e=3D From nobody Fri May 4 16:46:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE51D120721 for ; Fri, 4 May 2018 16:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 ENhdvAWKxjtQ for ; Fri, 4 May 2018 16:46:21 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 9DE771201FA for ; Fri, 4 May 2018 16:46:21 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w44Nk96w089091 for ; Fri, 4 May 2018 23:46:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=ESPpYvh2R6RZPDsMKrdPyUrJ0F0gL3xrYpSXmCuvGrY=; b=uem3OAm7HDJvCaS+g9pCkwXGy/6Ipt4SDDuQWRkiTf/Axe90/1pYdP96y6u8KSMuF7JA hb1yccigt4lYJm3MLgixELy5P9SnVvgA3ooZpbAVwOhD9RfydkiyhjOoLeTIvJWY3fgN 95gzSAAHXqZRR9/XC49a2FrOfZVoSY9qKZj7U12rH6B5X5A1MBh4b8Ea22f6FopfHqLZ YnrUwMdFRukM7l7kAT9SdE5fgJS59lqz+sip/YOFAcsMro059JWD/zrkeu6dzMJp1njW pyMZ0dP3rXxMMwh+TLrGPjf4MfUB2CCkx9RHq3QKdf3M71FT6ZlQUHyId+Hp1r7YgiUy rQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2hmgxg85ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 04 May 2018 23:46:20 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w44NkJ96002748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 4 May 2018 23:46:20 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w44NkJ9A000705 for ; Fri, 4 May 2018 23:46:19 GMT Received: from [10.159.137.103] (/10.159.137.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2018 16:46:19 -0700 From: "Chris Newman" To: extra@ietf.org Date: Fri, 04 May 2018 16:46:17 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8883 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=12 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805040212 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 23:46:24 -0000 On 4 May 2018, at 16:42, Chris Newman wrote: > I just noticed we implemented this in 2005 (under the "X-SUN-IMAP" = > capability). Looking at the implementation, there's a significant bug = > in the specification. Mailbox sizes can easily exceed 4GB; so the ABNF = > for status-att-list needs to be replaced as follows: > > status-att-list =3D status-att SP number63 *(SP status-att SP = > number63) > ;; number63 is only permitted with extension status attributes > ;; that explicitly allow it; such as SIZE Oh, just noticed RFC 4466 redefines that, so you instead need a = normative reference to RFC 4466 and then do: status-att-val /=3D "SIZE" SP number63 - Chris > number63 =3D 1*DIGIT > ;; Positive unsigned 63-bit integer > ;; (0 <=3D n <=3D 9,223,372,036,854,775,807).= > > - Chris > > On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: > >> Hi, >> >> I've been following discussions on this document and it is ready for >> IETF Last Call, which I just initiated. >> >> One nit: I believe the following reference is now Normative, due to >> added SHOULD level requirement: >> >> [QUOTA] >> >> Please update the document to reflect this next time the document is >> revised. >> >> Best Regards, >> Alexey, as AD. >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DB73C8TOrpzVRz_= O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=3DAv_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6tF= ZmmM&e=3D > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DErU-4WHaHwqAH1n= ltCBHaf7zbhatpz2gGlB_BH0n3uI&s=3DHPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmCx6_Z= Cvo&e=3D From nobody Sat May 5 19:52:24 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3AC127337; Sat, 5 May 2018 19:52:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose To: Cc: extra@ietf.org, draft-ietf-extra-imap-status-size.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152557514304.26644.17260351667976658025@ietfa.amsl.com> Date: Sat, 05 May 2018 19:52:23 -0700 Archived-At: Subject: [Extra] Secdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 02:52:23 -0000 Reviewer: Kyle Rose Review result: Ready There are no non-trivial security implications of this protocol change. From nobody Sun May 6 12:53:34 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D57A912D7E6; Sun, 6 May 2018 12:53:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-list-myrights.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152563640684.26784.16524702453597873690@ietfa.amsl.com> Date: Sun, 06 May 2018 12:53:26 -0700 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 19:53:27 -0000 Reviewer: Dale Worley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-imap-list-myrights-05 Reviewer: Dale R. Worley Review Date: 2018-05-06 IETF LC End Date: 2018-05-14 IESG Telechat date: [not scheduled] Summary: This draft is ready for publication as a standards-track RFC, with some very minor (AUTH48-level) wording nits. 3. MYRIGHTS Return Option to LIST Command The ordering of the responses is significant only in that the server MUST NOT send a MYRIGHTS response for a given mailbox before it sends the LIST response for that mailbox. It's clear what this means, but I think the wording is not quite correct. Perhaps: The ordering of the responses is constrained only in that ... or The ordering of the responses is not significant and is constrained only in that ... (In regard to the substance of this constraint, it's not clear to me why it exists, but I assume that the authors know of a reason for it.) -- Clients SHOULD use a suitable match pattern and/or selection option to limit the set of mailboxes returned to only those whose rights in which they are interested. I *think* the syntax of the final clause is not quite correct, and I *think* this is the corrected version: Clients SHOULD use a suitable match pattern and/or selection option to limit the set of mailboxes returned to only those in whose rights they are interested. But you may want to check with the RFC Editor. 4. Examples In this example the LIST reply for the "foo" mailbox is returned ... This should start "In the following example..." or "In the next example...", because if the screen cuts off the text just below this paragraph, the description appears to apply to the preceding example, which does not match this text. [END] From nobody Mon May 7 05:52:54 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7264F1200B9 for ; Mon, 7 May 2018 05:52:52 -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=PJfpEI1f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kd6GzwJN 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 RDUuSzNR-gQ8 for ; Mon, 7 May 2018 05:52:50 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE1A127342 for ; Mon, 7 May 2018 05:52:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 95A6521315 for ; Mon, 7 May 2018 08:52:49 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 07 May 2018 08:52:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=5TgpmquWuznBTpe1cNMvzEJe4YH5Oe2rC0K9Uxdz3 lY=; b=PJfpEI1fxp/JHWK+qILt75jzRIghKsF07v0oOMoyrCNkTwx9+vquzT8AR CkYt7XDGaOVXkDskW/VDdkC81bcRc2bbLp7W/77SWwH3j3rmpcU5jYFP7vc3l86b +BuhLyRUA1GPwj3WuUw+4/0d7tc/yOIFDiigXcljJnzzRfMM4py9+b2mKNjl0uSZ IkQXUEsLvJIunAuxzQVQHXk5TW51rIUR46JUIx4AUkYMv32Zdlnj4EWmwyzkzMpF p0pfkQI/DpTh56Mh8Uy09RZI9zGCtfaW+1r+8QqIE0bTcHhYPAffudWc9rxeQ9Q3 wXZmc7R9HssP/frAAOtk60NhByOZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=5TgpmquWuznBTpe1cNMvzEJe4YH5O e2rC0K9Uxdz3lY=; b=kd6GzwJN3Z7exWekJHKOjsD/S0B9FYlgANJs16pv5aNux b5/RXCCDKjPpuEpuTv0nNCxq5LPmHQ3Al9SP87UuSQZ9/k5wCK/6YXRNqu2GLgYV QFeasxC9PmhRVArwGfsxVjaDRO2nuYsSKW4ZAYd81yJNGyx/rKbknUiiSIXpSrGy d5E/HpXz1ia//dIc2EbmXoNkTU+sbu01yrCy0GX2Hq63VxgpDmbJCLOenHia1nCv pqg3VWVZXQWYEsjgdEzQ2sA5E08FWh5reDOkR2eftox4m/hIV7OSg1FG8zF9X0yQ aJQ+ddBi0HwEcP8eoGw3xJBGx7HLvO9JFeeuO2SOQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5E508621DC; Mon, 7 May 2018 08:52:48 -0400 (EDT) Message-Id: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15256975686994190" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 Date: Mon, 07 May 2018 22:52:48 +1000 Archived-At: Subject: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 12:52:52 -0000 This is a multi-part message in MIME format. --_----------=_15256975686994190 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, There's two documents which I believe are nearly ready for last call. fcc and objectid https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ Ken uploaded this version a week ago. It would be great to have feedback (I'll go write my own too) https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ I uploaded this one a couple of weeks ago, which resolved all the feedback I've had. More feedback here would be great too. I've already implemented it in Cyrus IMAPd master, but that's no surprise since I knew what was required when I wrote the spec! I'd like to progress these to working group last call fairly soon so there's time for them to get some good attention and be published before Montreal. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15256975686994190 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

There's two documents which I believe are nearly ready for last call.  fcc and objectid

https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/

Ken uploaded this version a week ago.  It would be great to have feedback (I'll go write my own too)

https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/

I uploaded this one a couple of weeks ago, which resolved all the feedback I've had.  More feedback here would be great too.  I've already implemented it in Cyrus IMAPd master, but that's no surprise since I knew what was required when I wrote the spec!

I'd like to progress these to working group last call fairly soon so there's time for them to get some good attention and be published before Montreal.

Cheers,

Bron.

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


--_----------=_15256975686994190-- From nobody Mon May 7 06:07:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93CB1200F1 for ; Mon, 7 May 2018 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 ZDpWnNbRRgj9 for ; Mon, 7 May 2018 06:07:23 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9631200B9 for ; Mon, 7 May 2018 06:07:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 16F52FA007C; Mon, 7 May 2018 13:07:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1525698441; bh=WaBZQ/rNtD3W8kF0m7WCy+3uEPR/ohVguCGTdkUuPT0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Tcnsx4MNKrfUJIv1BOYWmb76nGAO4UxHz3asvlV/PeX3BKDqk2cdHOfM6iEmuTGuR V47DQFzxzSX3hhwZcxGhS2wa3G5XHlz+qzNlZlr2gD0wW+PhxrArd41a1iFIm/B26y X51l8bzZUpEGe8qF7Zw5blGC8MUJHLERr2aSpiVI= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1525698440-32234-19769/11/6; Mon, 7 May 2018 13:07:20 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Mon, 7 May 2018 14:07:20 +0100 Mime-Version: 1.0 Message-Id: <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> In-Reply-To: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 13:07:24 -0000 On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ > > I uploaded this one a couple of weeks ago, which resolved all > the feedback I've had. More feedback here would be great too. Maybe... "Servers that implement both RFC 6154 and this specification SHOULD optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID 4321. Clients may assume that searching the all-mail mailbox using OR/EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen." Or not. Your call. Arnt From nobody Mon May 7 06:16:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC51200B9 for ; Mon, 7 May 2018 06:16:26 -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=CDBeliqs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YwCzaPR+ 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 sSFUcxqOZruO for ; Mon, 7 May 2018 06:16:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93661120047 for ; Mon, 7 May 2018 06:16:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 03A8F227FA for ; Mon, 7 May 2018 09:16:24 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 07 May 2018 09:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=WtXNRtqbd+imQVclQ aVe//WYDF3G4LtjHAwCBzPvwXM=; b=CDBeliqsIUGxgmJca5BbiOswvKN4s9Osu XVYyhZ5TylC0b3CA2MNBdhc1GGLjxpSQ83o9im4Lb/i6gqFeU9dz6X1a2b5FZMsP kNoDznDrZPm50Cq35hNydH6EUeJdmvR8nm6TdHcrA04yx2fAKfMsfgvHkjkSfQDe IHQ7nERDW4g+n9rbo5kFfKZoiahvR9eztAFsWPtNMG6BSTuMaBYfs1q352SLITaZ eXATISvmVb5FVr+lt2rris/wHrb+OPIosGhB+WoHAisE4KOHg8v7hDv5pxyLk+OD YRVbbGWXVDTPs3aVR/Z/6EPoSAZT6TLvb2mQLZuew0l7/ezFqI4fw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=WtXNRt qbd+imQVclQaVe//WYDF3G4LtjHAwCBzPvwXM=; b=YwCzaPR+SUOR/9g3FrXaGc GDoIEqB47mOfxao+EEGuf80Bd1BNJvnuA+2EN4wF7wDZ3mudsm9BEuKqnPUhvp8R uyiwjG7pZ6f2axGnnCeUdTfj7TcOCWRuN5vEu/dRa2HwgLFEWZADsvHqKgaGmWLF dc8rExa9s/AxSRRQdCaua6sMoldX7np3L6hw3aKShpTp9iXNb9YO+g3trtYG+KS9 EwQS/mD8J5kzVAGeO6qT5Izm2Wr6VfRMxVNISGiE+TVhM4uaDjP2ZRtFYALTIfYK Siz7oNXtF6TZ0wpAGFP3cN8v50w5o68o4UmtKWuQSe8jcKSaoYSfzKdgXwPWBvGw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5334621DC; Mon, 7 May 2018 09:16:23 -0400 (EDT) Message-Id: <1525698983.706694.1363432064.71DB8800@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15256989837066940" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 In-Reply-To: <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> Date: Mon, 07 May 2018 23:16:23 +1000 Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 13:16:26 -0000 This is a multi-part message in MIME format. --_----------=_15256989837066940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 7 May 2018, at 23:07, Arnt Gulbrandsen wrote: > On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote: >> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ >> >> I uploaded this one a couple of weeks ago, which resolved all >> the feedback I've had. More feedback here would be great too. > > Maybe... > > "Servers that implement both RFC 6154 and this specification SHOULD > optimize their execution of command like UID SEARCH OR EMAILID > 1234 EMAILID> 4321. Clients may assume that searching the all-mail mailbox using > OR/EMAILID or OR/THREADID is a fast way to find messages again if some> other client has moved them out of the mailbox where they were > previously> seen." > > Or not. Your call. It's definitely not normative advice, but that definitely looks like something to put in the appendix area. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15256989837066940 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 7 May 2018, at 23:07, Arnt Gulbrandsen wrote:
On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote:

I uploaded this one a couple of weeks ago, which resolved all
the feedback I've had.  More feedback here would be great too.

Maybe...

"Servers that implement both RFC 6154 and this specification SHOULD
optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID
4321. Clients may assume that searching the all-mail mailbox using
OR/EMAILID or OR/THREADID is a fast way to find messages again if some
other client has moved them out of the mailbox where they were previously
seen."

Or not. Your call.

It's definitely not normative advice, but that definitely looks like something to put in the appendix area.

Thanks,

Bron.

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


--_----------=_15256989837066940-- From nobody Mon May 7 06:23:50 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6591241F8 for ; Mon, 7 May 2018 06:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 EYFXGEQg80FI for ; Mon, 7 May 2018 06:23:46 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93918120047 for ; Mon, 7 May 2018 06:23:46 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3F934FA007C; Mon, 7 May 2018 13:23:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1525699425; bh=4K/EJ/ra5jrVZhfne/vxORdNg1QOslDJ9RLwn4Awbk4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aQh6SiiAM1udY7vAm4cT6Z1WHUZ8MKvFeccwAuUJCiOUZu7M4Zg7ccfOFHzmL0UZp 5wQDMCMU5LOc7G7RMEQVuUFpiLZ7eaUhdhGDwV4D4uf+YRHAoMDRopCS83ncS1KuG6 Lb0FANV+4hQnP5hjeesUjRfXpnvNoT5XmwghE20I= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1525699424-19771-19769/11/10; Mon, 7 May 2018 13:23:44 +0000 From: Arnt Gulbrandsen To: Bron Gondwana Cc: extra@ietf.org Date: Mon, 7 May 2018 14:23:43 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: <1525698983.706694.1363432064.71DB8800@webmail.messagingengine.com> References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> <1525698983.706694.1363432064.71DB8800@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 13:23:48 -0000 On Monday 7 May 2018 14:16:23 IST, Bron Gondwana wrote: > It's definitely not normative advice, but that definitely looks > like something to put in the appendix area. Normative advice. What a spiffing phrase. What a spiffffing phrase. Time to update RFC 2119 ;) Arnt From nobody Mon May 7 10:35:25 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B18126DD9; Mon, 7 May 2018 10:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-extra-imap-unauth@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152571451770.1326.3490889423770330773.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2018 10:35:17 -0700 Archived-At: Subject: [Extra] Last Call: (IMAP UNAUTHENTICATE for Connection Reuse) to Proposed Standard X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:35:18 -0000 The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'IMAP UNAUTHENTICATE for Connection Reuse' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 7 13:52:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326A512AF84 for ; Mon, 7 May 2018 13:52:11 -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=WNpNqKmo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nYV5I7lL 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 Jov3VrLFabjO for ; Mon, 7 May 2018 13:52:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54416129C6C for ; Mon, 7 May 2018 13:52:09 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 42D4B2293B for ; Mon, 7 May 2018 16:52:07 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Mon, 07 May 2018 16:52:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=hlbj/5vWuXOKpRr4Q B3QdCBb2vfbFDhkKKT0fwASuk0=; b=WNpNqKmoERK4LXXyTliv0Wm2b5pdFi6No GjytzFLzlKRduAszYfLagbTJCilLIY6HpgUxEaF374cO4EWOoyxmTcGwwFBnYZuw RmTI+YVbo9FXGln05Z45zJGGr+lDPS3RM5xaW2E7z0exth9MJ9lYqJD2hntAX7Oq dKJxbaXz7ExfqF832NHU0Js3c/zY1qV9Otgd4WNd00KVK2cOCaxgEpYK8d1e64+w mnrlNuq6sObIqBpAvDXPR/XArSU9pfnn4JEvBzB8DwVBIDNBjo8o2y8Dz5okjoJc hg/gG7zL6xa/kfcJ1eXn4SpiGpIky/bq6A8EDf9J+LIaycJKzLoyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=hlbj/5 vWuXOKpRr4QB3QdCBb2vfbFDhkKKT0fwASuk0=; b=nYV5I7lL+A6DgK+usjBPRW PRVrsYjwWs8rridfGqUcgdpAv5NSgnJp08jKengddEkjvVHuDmZuF1AicIFmAOIJ gfWYwPabYyMEQHC/E1gHTSnTczqheIPzmz9Kp6k4ZMjXrauReJZRkx8MBzFB7c0a Yw0NC3SPSCVd7yUloY+riZHzPJ+csLgkCU/87dWYfu1fHPO3I8KI4twripgstJZ6 dXLW5ZFFvSQvll0TuOXRv0zE2NS5wMxoT9Pz+1EDcUINfDtUUvDvMxtHwyH9j26G CF9Pw7bCJDPPyEpqZKnTrq69PvnqqS98bhIITdoVz0th7L1/iv/qmuClpo0Ap4cw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E63029E3D4; Mon, 7 May 2018 16:52:06 -0400 (EDT) Message-Id: <1525726326.87782.1363969528.07A12034@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1525726326877824" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 In-Reply-To: References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> <1525698983.706694.1363432064.71DB8800@webmail.messagingengine.com> Date: Tue, 08 May 2018 06:52:06 +1000 Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 20:52:11 -0000 This is a multi-part message in MIME format. --_----------=_1525726326877824 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 7 May 2018, at 23:23, Arnt Gulbrandsen wrote: > On Monday 7 May 2018 14:16:23 IST, Bron Gondwana wrote: >> It's definitely not normative advice, but that definitely looks >> like something to put in the appendix area. > > Normative advice. What a spiffing phrase. What a spiffffing > phrase. Time to> update RFC 2119 ;) In my defense, I was tired and typing random words, random words. spifffff. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1525726326877824 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 7 May 2018, at 23:23, Arnt Gulbrandsen wrote:
On Monday 7 May 2018 14:16:23 IST, Bron Gondwana wrote:
It's definitely not normative advice, but that definitely looks
like something to put in the appendix area.

Normative advice. What a spiffing phrase. What a spiffffing phrase. Time to
update RFC 2119 ;)

In my defense, I was tired and typing random words, random words. spifffff.

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


--_----------=_1525726326877824-- From nobody Thu May 10 10:40:17 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C4212EB4D for ; Thu, 10 May 2018 10:40:14 -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 917XZrBWjKcU for ; Thu, 10 May 2018 10:40:13 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id D48DC12EB47 for ; Thu, 10 May 2018 10:40:12 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 6427B2B3CE0; Thu, 10 May 2018 20:30:46 +0300 (EEST) To: Chris Newman , extra@ietf.org References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> Cc: Alexey Melnikov From: Stephan Bosch Message-ID: <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> Date: Thu, 10 May 2018 19:30:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:40:15 -0000 Op 05/05/2018 om 01:46 schreef Chris Newman: > On 4 May 2018, at 16:42, Chris Newman wrote: > >> I just noticed we implemented this in 2005 (under the "X-SUN-IMAP" >> capability). Looking at the implementation, there's a significant bug >> in the specification. Mailbox sizes can easily exceed 4GB; so the >> ABNF for status-att-list needs to be replaced as follows: >> >>    status-att-list = status-att SP number63 *(SP status-att SP number63) >>         ;; number63 is only permitted with extension status attributes >>         ;; that explicitly allow it; such as SIZE > > Oh, just noticed RFC 4466 redefines that, so you instead need a > normative reference to RFC 4466 and then do: > >    status-att-val /= "SIZE" SP number63 A 4Gb mailbox is still quite huge these days, but you're right. The QUOTA capability has the same problem: how did you address that? That would have been solved by the 64BIT capability, but that one's on hold now Bron, Alexey, opinions? Regards, Stephan > >         - Chris > >>    number63  = 1*DIGIT >>                           ;; Positive unsigned 63-bit integer >>                           ;; (0 <= n <= 9,223,372,036,854,775,807). >> >>         - Chris >> >> On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: >> >>> Hi, >>> >>> I've been following discussions on this document and it is ready for >>> IETF Last Call, which I just initiated. >>> >>> One nit: I believe the following reference is now Normative, due to >>> added SHOULD level requirement: >>> >>>  [QUOTA] >>> >>> Please update the document to reflect this next time the document is >>> revised. >>> >>> Best Regards, >>> Alexey, as AD. >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=B73C8TOrpzVRz_O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=Av_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6tFZmmM&e= >>> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=ErU-4WHaHwqAH1nltCBHaf7zbhatpz2gGlB_BH0n3uI&s=HPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmCx6_ZCvo&e= >> > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Thu May 10 15:40:51 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7B112EBAD for ; Thu, 10 May 2018 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 dwnzJpnHmCex for ; Thu, 10 May 2018 15:40:47 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 76E1B12EB97 for ; Thu, 10 May 2018 15:40:47 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4AMeeI2168811; Thu, 10 May 2018 22:40:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=RoR9bLDWMUlzR6Uv4zVnqL3Hm7xgtlPMoVW0cJKA/jY=; b=pFRb/yabzeja2p7uc0PcF2Rw+G1vnCzrjrKRF2M4H0sKDDOfPjuoTc41weZqwNWOPkiO TH4Q57KcKf1NK95i3o+pSVniwoQTE9tnFKuDbV6wJa1Dr4AlOnnpSS98/nIEK4KGNYXi JFXxR/yz/xZeg7w/682NqIDxf1Z7jnUpUurlwQ7l6iH6+DoNSi0i/JeOy3BlinImBq+A JhWO/wDRjUmgBFwM1FqU+surozt9GMTxsoTnD9e9JRYecNQsVCjv2BsiWMdMeWoKF2qf 2hPrcZ9OB/KbWnYc5HmuerT0YbTptHHLn798OZdjVkryMMmUDC/QHzuTg/fGDsoFoCbN kA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2hvth99b7d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 May 2018 22:40:40 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4AMeciM004464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 May 2018 22:40:39 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4AMec7n011551; Thu, 10 May 2018 22:40:38 GMT Received: from [10.145.183.91] (/10.145.183.91) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2018 15:40:38 -0700 From: "Chris Newman" To: "Stephan Bosch" Cc: extra@ietf.org, "Alexey Melnikov" Date: Thu, 10 May 2018 15:40:31 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> In-Reply-To: <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8889 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805100208 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 22:40:49 -0000 On 10 May 2018, at 10:30, Stephan Bosch wrote: > Op 05/05/2018 om 01:46 schreef Chris Newman: >> On 4 May 2018, at 16:42, Chris Newman wrote: >> >>> I just noticed we implemented this in 2005 (under the "X-SUN-IMAP" = >>> capability). Looking at the implementation, there's a significant = >>> bug in the specification. Mailbox sizes can easily exceed 4GB; so = >>> the ABNF for status-att-list needs to be replaced as follows: >>> >>> =C2=A0=C2=A0 status-att-list =3D status-att SP number63 *(SP status-a= tt SP = >>> number63) >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; number63 is only permit= ted with extension status = >>> attributes >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; that explicitly allow i= t; such as SIZE >> >> Oh, just noticed RFC 4466 redefines that, so you instead need a = >> normative reference to RFC 4466 and then do: >> >> =C2=A0=C2=A0 status-att-val /=3D "SIZE" SP number63 > > A 4Gb mailbox is still quite huge these days, but you're right. The = > QUOTA capability has the same problem: how did you address that? Quota Storage partially dodges the problem by using 1K rather than 1 = byte units. However, the fact it doesn't allow 63-bit storage numbers is = a specification bug (due to proof-by-example: the IMAP data model allows = a mailbox with 4G messages each of 4G size). Implementations should = ignore specification bugs like that (ours does). However, the 32-bit = limit on UIDs, message size, and message sequence numbers is part of the = fundamental IMAP data model. Changes to those values require an = incompatible change to the IMAP data model that can break previously = standards-compliant implementations. The IETF generally doesn't make = that sort of change without a negotiated extension and implementations = that ignore fundamental data models in the standards without negotiation = are usually bad Internet citizens. > That would have been solved by the 64BIT capability, but that one's on = > hold now There's no reason we can't have this spec use a 63-bit number at the = time we write it. Clients won't get this data unless they ask for it and = servers won't send it unless they've advertised it. This requires no = change to the IMAP data model so no separate negotiation is needed to = use 63-bit numbers here. It's just an extra line of ABNF and with no = impact on data model and very little impact on implementations. A = normative dependency on a draft that changes the IMAP data model is a = change to SIZE that I would oppose. But use of a 32-bit integer is a bug = in the SIZE draft (again via proof-by-example). - Chris > Bron, Alexey, opinions? > > Regards, > > Stephan > >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Chris >> >>> =C2=A0=C2=A0 number63=C2=A0 =3D 1*DIGIT >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ;; Positive = >>> unsigned 63-bit integer >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ;; (0 <=3D n <=3D = >>> 9,223,372,036,854,775,807). >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Chris >>> >>> On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: >>> >>>> Hi, >>>> >>>> I've been following discussions on this document and it is ready = >>>> for >>>> IETF Last Call, which I just initiated. >>>> >>>> One nit: I believe the following reference is now Normative, due to >>>> added SHOULD level requirement: >>>> >>>> =C2=A0[QUOTA] >>>> >>>> Please update the document to reflect this next time the document = >>>> is >>>> revised. >>>> >>>> Best Regards, >>>> Alexey, as AD. >>>> >>>> _______________________________________________ >>>> Extra mailing list >>>> Extra@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DB73C8TOrpzVR= z_O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=3DAv_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6= tFZmmM&e=3D >>> >>> _______________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DErU-4WHaHwqAH= 1nltCBHaf7zbhatpz2gGlB_BH0n3uI&s=3DHPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmCx6= _ZCvo&e=3D >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwIDaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D5HJofT5ocTAB71= bioSeN2ztVNEW92Tx14L2kdo_8_PQ&s=3DVsTTjiVSxN0fQkrv_AoqVm9VLp5Rw5qTjsqJJEO= DbT4&e=3D From nobody Thu May 10 19:01:10 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D489B12D82F for ; Thu, 10 May 2018 19:01:07 -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=KK2ZRzgN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NXjgB2M1 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 j7bSJvrJX715 for ; Thu, 10 May 2018 19:01:05 -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 2322012D7F1 for ; Thu, 10 May 2018 19:01:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8CC1224CE for ; Thu, 10 May 2018 22:01:03 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 10 May 2018 22:01:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=DwvGAsrBomQzi+hCx X9j1OEwQAuxUWNwJn/ii7UEbLY=; b=KK2ZRzgNiO4npvXFsEIdCUWekWqv2yWx1 Jn2Ipm7ASzDX8j2UBFjOTfxkUWWBFfQ7I6mmEOFTm9cRO4V521GN2/QOZQkYE4US A1N/cfWioYz2goMDzk55y3ZuT7Sa5vgZEmxOJidvbXJoh3MSR68y5AsVaDQjCRDT f01/cWV0m+7l+qAzfVjfOfTXvw2JXSv/6g5p6P3M/yzJ4XO2p4cuyKLMYxSuxToT g2lympb6hvOxMdCfjFdOvKwkoagFABYO+98uZYJNb1jNPs3eas8l2hGI6vKPvhZ2 AyYlI4hwUUWJ4BrZgHeFiJkJNYLZB6VFxsPYn8D9xHGiTC09phtQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=DwvGAs rBomQzi+hCxX9j1OEwQAuxUWNwJn/ii7UEbLY=; b=NXjgB2M102/QfVJE78AwdZ ZfMyJ2lavYg90O7KGarSGhvu0niFd3udVs4IhkzAKyu6BqBn5liOo20txhovU5W6 +8awFSpp7U0mQF8HOql4e4AIBEFn6dVKglKkSY3C9WjbAFGjqwbkXTb3sIxE+RHI HIBcCNAaK/45Qxg9QqLxXnmp/MhiO9JFU036atD8/Ta3i0gGilqbgwWujNrDLnZY ezGI0hrycsHiM37hKjy9jw5TZ0z8Ill+Q2wJXRVEisUCj8FDaKQIASK5PKoJ+Od5 tQrgph9D1lCgwPZvIZP1/JoycNQkHIdJoWI9TW9wqfCmm6QDkqE+yPeUEXgJ/5fg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 821F59E085; Thu, 10 May 2018 22:01:03 -0400 (EDT) Message-Id: <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152600406333729040" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> Date: Fri, 11 May 2018 12:01:03 +1000 In-Reply-To: <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 02:01:08 -0000 This is a multi-part message in MIME format. --_----------=_152600406333729040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" My opinion is - just define this response as a 63 bit number. Crappy thing here with RFC4466 is: tagged-ext-simple = sequence-set / number And "number" is defined in RFC3501: number = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < 4,294,967,296) Which means that the response SHOULD be: "SIZE" SP "(" number63 ")" rather than "SIZE" SP number63 to be tagged-ext. Bron. On Fri, 11 May 2018, at 08:40, Chris Newman wrote: > On 10 May 2018, at 10:30, Stephan Bosch wrote: >> Op 05/05/2018 om 01:46 schreef Chris Newman: >>> On 4 May 2018, at 16:42, Chris Newman wrote: >>> >>>> I just noticed we implemented this in 2005 (under the "X-SUN-IMAP">>>> capability). Looking at the implementation, there's a significant >>>> bug in the specification. Mailbox sizes can easily exceed 4GB; so >>>> the ABNF for status-att-list needs to be replaced as follows: >>>> >>>> status-att-list = status-att SP number63 *(SP status-att SP >>>> number63) >>>> ;; number63 is only permitted with extension status >>>> attributes >>>> ;; that explicitly allow it; such as SIZE >>> >>> Oh, just noticed RFC 4466 redefines that, so you instead need a >>> normative reference to RFC 4466 and then do: >>> >>> status-att-val /= "SIZE" SP number63 >> >> A 4Gb mailbox is still quite huge these days, but you're right. The >> QUOTA capability has the same problem: how did you address that? > > Quota Storage partially dodges the problem by using 1K rather than 1 > byte units. However, the fact it doesn't allow 63-bit storage > numbers is> a specification bug (due to proof-by-example: the IMAP data > model allows> a mailbox with 4G messages each of 4G size). Implementations should > ignore specification bugs like that (ours does). However, the 32-bit > limit on UIDs, message size, and message sequence numbers is > part of the> fundamental IMAP data model. Changes to those values require an > incompatible change to the IMAP data model that can break previously > standards-compliant implementations. The IETF generally doesn't make > that sort of change without a negotiated extension and implementations> that ignore fundamental data models in the standards without > negotiation> are usually bad Internet citizens. > >> That would have been solved by the 64BIT capability, but that >> one's on>> hold now > > There's no reason we can't have this spec use a 63-bit number at the > time we write it. Clients won't get this data unless they ask > for it and> servers won't send it unless they've advertised it. This requires no > change to the IMAP data model so no separate negotiation is needed to> use 63-bit numbers here. It's just an extra line of ABNF and with no > impact on data model and very little impact on implementations. A > normative dependency on a draft that changes the IMAP data model is a> change to SIZE that I would oppose. But use of a 32-bit integer > is a bug> in the SIZE draft (again via proof-by-example). > > - Chris > >> Bron, Alexey, opinions? >> >> Regards, >> >> Stephan >> >>> >>> - Chris >>> >>>> number63 = 1*DIGIT >>>> ;; Positive >>>> unsigned 63-bit integer >>>> ;; (0 <= n <= >>>> 9,223,372,036,854,775,807). >>>> >>>> - Chris >>>> >>>> On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: >>>> >>>>> Hi, >>>>> >>>>> I've been following discussions on this document and it is ready >>>>> for >>>>> IETF Last Call, which I just initiated. >>>>> >>>>> One nit: I believe the following reference is now Normative, >>>>> due to>>>>> added SHOULD level requirement: >>>>> >>>>> [QUOTA] >>>>> >>>>> Please update the document to reflect this next time the document>>>>> is >>>>> revised. >>>>> >>>>> Best Regards, >>>>> Alexey, as AD. >>>>> >>>>> _________________________________________________ >>>>> Extra mailing list >>>>> Extra@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=B73C8TOrpzVRz_O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=Av_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6tFZmmM&e=>>>> >>>> _________________________________________________ >>>> Extra mailing list >>>> Extra@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=ErU-4WHaHwqAH1nltCBHaf7zbhatpz2gGlB_BH0n3uI&s=HPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmCx6_ZCvo&e=>>> >>> _________________________________________________ >>> Extra mailing list >>> Extra@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=5HJofT5ocTAB71bioSeN2ztVNEW92Tx14L2kdo_8_PQ&s=VsTTjiVSxN0fQkrv_AoqVm9VLp5Rw5qTjsqJJEODbT4&e=> > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152600406333729040 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
My opinion is - just define this response as a 63 bit number.

Crappy thing here with RFC4466 is:

   tagged-ext-simple   = sequence-set / number

And "number" is defined in RFC3501:

number          = 1*DIGIT
                    ; Unsigned 32-bit integer
                    ; (0 <= n < 4,294,967,296)


Which means that the response SHOULD be:

"SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be tagged-ext.

Bron.


On Fri, 11 May 2018, at 08:40, Chris Newman wrote:
On 10 May 2018, at 10:30, Stephan Bosch wrote:
Op 05/05/2018 om 01:46 schreef Chris Newman:
On 4 May 2018, at 16:42, Chris Newman wrote:

I just noticed we implemented this in 2005 (under the "X-SUN-IMAP"
capability). Looking at the implementation, there's a significant
bug in the specification. Mailbox sizes can easily exceed 4GB; so
the ABNF for status-att-list needs to be replaced as follows:

   status-att-list = status-att SP number63 *(SP status-att SP
number63)
        ;; number63 is only permitted with extension status
attributes
        ;; that explicitly allow it; such as SIZE

Oh, just noticed RFC 4466 redefines that, so you instead need a
normative reference to RFC 4466 and then do:

   status-att-val /= "SIZE" SP number63

A 4Gb mailbox is still quite huge these days, but you're right. The
QUOTA capability has the same problem: how did you address that?

Quota Storage partially dodges the problem by using 1K rather than 1
byte units. However, the fact it doesn't allow 63-bit storage numbers is
a specification bug (due to proof-by-example: the IMAP data model allows
a mailbox with 4G messages each of 4G size). Implementations should
ignore specification bugs like that (ours does). However, the 32-bit
limit on UIDs, message size, and message sequence numbers is part of the
fundamental IMAP data model. Changes to those values require an
incompatible change to the IMAP data model that can break previously
standards-compliant implementations. The IETF generally doesn't make
that sort of change without a negotiated extension and implementations
that ignore fundamental data models in the standards without negotiation
are usually bad Internet citizens.

That would have been solved by the 64BIT capability, but that one's on
hold now

There's no reason we can't have this spec use a 63-bit number at the
time we write it. Clients won't get this data unless they ask for it and
servers won't send it unless they've advertised it. This requires no
change to the IMAP data model so no separate negotiation is needed to
use 63-bit numbers here. It's just an extra line of ABNF and with no
impact on data model and very little impact on implementations. A
normative dependency on a draft that changes the IMAP data model is a
change to SIZE that I would oppose. But use of a 32-bit integer is a bug
in the SIZE draft (again via proof-by-example).

- Chris

Bron, Alexey, opinions?

Regards,

Stephan


        - Chris

   number63  = 1*DIGIT
                          ;; Positive
unsigned 63-bit integer
                          ;; (0 <= n <=
9,223,372,036,854,775,807).

        - Chris

On 26 Apr 2018, at 10:10, Alexey Melnikov wrote:

Hi,

I've been following discussions on this document and it is ready
for
IETF Last Call, which I just initiated.

One nit: I believe the following reference is now Normative, due to
added SHOULD level requirement:

 [QUOTA]

Please update the document to reflect this next time the document
is
revised.

Best Regards,
Alexey, as AD.

_______________________________________________
Extra mailing list

_______________________________________________
Extra mailing list

_______________________________________________
Extra mailing list

_______________________________________________
Extra mailing list

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


--_----------=_152600406333729040-- From nobody Thu May 10 22:30:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC97D12DB71 for ; Thu, 10 May 2018 22:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 3eQBe383JZHr for ; Thu, 10 May 2018 22:30:36 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C41312420B for ; Thu, 10 May 2018 22:30:36 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id D0D1A13F2; Fri, 11 May 2018 01:30:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id B9C1ACA1CA; Fri, 11 May 2018 01:30:34 -0400 (EDT) Message-Id: <799439eb-8593-4c9c-befd-a6fa0ea76447@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-565-g1e559eb-next x-jmap-identity-id: 64588216 In-Reply-To: References: <5AE72EAD.9050307@isode.com> <1525158666.2389818.1356559416.235763DA@webmail.messagingengine.com> Date: Fri, 11 May 2018 01:30:34 -0400 From: Neil Jenkins To: Barry Leiba Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=00eae7d33129411cb054128eb20bbc0d Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-specialuse-important-02 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 05:30:38 -0000 --00eae7d33129411cb054128eb20bbc0d Content-Type: multipart/related; boundary=f787dd61f5c9492fad45c16d77fc2ff6 --f787dd61f5c9492fad45c16d77fc2ff6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 1 May 2= 018, at 11:22 PM, Barry Leiba wrote:
How does JMAP handle situations where it's u= sed to access things like
IETF mailing lists or usenet new= s groups, where there can be tens or
hundreds of thousands= of mailboxes, and the user is only interested in
a few of= them?

Sorry for the late repl= y to this. The answer in the current spec is it was presumed individual = clients would keep track of which mailboxes they are interested in. Howe= ver, we can easily add an isSubscribed: Boolean = property to the JMAP Mailbox object, as a direct equivalent to the \Subs= cribed IMAP attribute, so this can be synchronised between clients. This= could then be used with Mailbox/query to just return subscribed mailbox= es etc. in much the same was as you can with various LIST options in IMA= P. I've created a = GitHub issue for this.

This does highli= ght the slight weirdness of sharing this registry between IMAP and JMAP.= The mailbox attributes in IMAP are a mix of things that are analogous t= o individual properties on the JMAP object (so need to be marked as not = relevant), and mailbox roles (which is what we do want to reuse). Hence = the need to mark quite a few as not relevant.

Neil. --f787dd61f5c9492fad45c16d77fc2ff6-- --00eae7d33129411cb054128eb20bbc0d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 1 May 2018, at 11:22 PM, Barry Leiba wrote: > How does JMAP handle situations where it's used to access things like > IETF mailing lists or usenet news groups, where there can be tens or > hundreds of thousands of mailboxes, and the user is only interested in= > a few of them? Sorry for the late reply to this. The answer in the current spec is it w= as presumed individual clients would keep track of which mailboxes they = are interested in. However, we can easily add an isSubscribed: Boolean=C2= =A0property to the JMAP Mailbox object, as a direct equivalent to the \S= ubscribed IMAP attribute, so this can be synchronised between clients. T= his could then be used with Mailbox/query to just return subscribed mail= boxes etc. in much the same was as you can with various LIST options in = IMAP. I've created a GitHub issue for this. This does highlight the slight weirdness of sharing this registry betwee= n IMAP and JMAP. The mailbox attributes in IMAP are a mix of things that= are analogous to individual properties on the JMAP object (so need to b= e marked as not relevant), and mailbox roles (which is what we do want t= o reuse). Hence the need to mark quite a few as not relevant. Neil. --00eae7d33129411cb054128eb20bbc0d-- From nobody Sat May 12 14:14:38 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3812EAD1; Sat, 12 May 2018 14:14:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: extra@ietf.org, draft-ietf-extra-specialuse-important.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152615967552.26371.13965440440763504881@ietfa.amsl.com> Date: Sat, 12 May 2018 14:14:35 -0700 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 21:14:35 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-extra-specialuse-important-03 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-specialuse-important-03.txt Reviewer: Brian Carpenter Review Date: 2018-05-13 IETF LC End Date: 2018-05-14 IESG Telechat date: 2018-06-07 Summary: Ready -------- Comments: Thanks for making the reviewer's life so easy. --------- Nits: ----- I wonder whether the special characters in the title will break some bibliographic software. Both $ and \ can have unexpected effects. From nobody Sat May 12 17:34:58 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9B129C6E; Sat, 12 May 2018 17:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u1nbhm_Ji6o1; Sat, 12 May 2018 17:34:49 -0700 (PDT) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (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 620F4129C6C; Sat, 12 May 2018 17:34:46 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id e20-v6so6598226itc.1; Sat, 12 May 2018 17:34:46 -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=thzOfEtpbHefGxOLYOCdg5YVpjK465zjICmRCSZDnGw=; b=TBp7YipnzCUSbNZg0mddxYVuaNB6/saP/jIH2uUM9JbNHeq0j2fyTaYm6qmHxaCoET V/uOyqtrPY2f2zkn9M380awHt7Oaf0bxLhCagioPRAoGZYXCZAVpVsAXdvYvRKB/m2UD cZDBMavlRHyOmpUGoxd+qkx3mkGm4tGyxrOg/AOW7qDRWSHRPi+QH08EVXtjkhkbQBFG czn5UAlzIemjUri4WgU/9g1AQMh5sv0bC7vSwDPe/whbSVWyW1gvBwGJ1eXrRAg6QIK8 JwUWDwBoSmbxuSVcU/hWm4k0doXQTKT0jvWLvbGTEMoq6zddnbSsAsmSIjYjQgaoikCn z1ZA== X-Gm-Message-State: ALKqPweLWZSIQUu6ymbElz9oIGfZ1y7JZMW0dE6ouUcmbj1iC+MLRgwT Et0xFOdi1iF6Reb0hJ96wQG6vQbKyk3L0A/DPR4= X-Google-Smtp-Source: AB8JxZr9ifkvFjr/hAQU0QWbtMkWhgsdZwX++q82LLJAdQJvbOeKPeNG6PLGFCALEnRBPs3RzJZvt5y8lY1Wy486JYk= X-Received: by 2002:a24:e3c7:: with SMTP id d190-v6mr4000598ith.22.1526171685503; Sat, 12 May 2018 17:34:45 -0700 (PDT) MIME-Version: 1.0 References: <152615967552.26371.13965440440763504881@ietfa.amsl.com> In-Reply-To: <152615967552.26371.13965440440763504881@ietfa.amsl.com> From: Barry Leiba Date: Sat, 12 May 2018 20:34:33 -0400 Message-ID: To: Brian Carpenter Cc: draft-ietf-extra-specialuse-important.all@ietf.org, extra@ietf.org, gen-art@ietf.org Content-Type: multipart/alternative; boundary="0000000000002e487b056c0b8930" Archived-At: Subject: Re: [Extra] Genart last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 00:34:51 -0000 --0000000000002e487b056c0b8930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Brian. > Thanks for making the reviewer's life so easy. My pleasure. > I wonder whether the special characters in the title will break > some bibliographic software. Both $ and \ can have unexpected effects. I think we have others with such characters, but I didn=E2=80=99t check. I= n any case, the RFC Editor staff will know, and we=E2=80=99ll deal with it in AUT= H48. Barry --=20 Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --0000000000002e487b056c0b8930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Brian.

=
> Thanks for making the reviewer's life so e= asy.

My pleasure.
<= div dir=3D"auto">
> I wonder whether the spec= ial characters in the title will break
> some bib= liographic software.=C2=A0Both $ and \ can have unexpected effects.

I think we have others with= such characters, but I didn=E2=80=99t check.=C2=A0 In any case, the RFC Ed= itor staff will know, and we=E2=80=99ll deal with it in AUTH48.

Barry


--
Barry
--
Barry Leiba =C2=A0= (barryleiba@co= mputer.org)
http://internetmessagingtechnology.org/
--0000000000002e487b056c0b8930-- From nobody Sun May 13 18:57:54 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC199127863; Sun, 13 May 2018 18:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Linda Dunbar To: Cc: extra@ietf.org, draft-ietf-extra-imap-status-size.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152626307291.10130.11253794031353526719@ietfa.amsl.com> Date: Sun, 13 May 2018 18:57:52 -0700 Archived-At: Subject: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 01:57:53 -0000 Reviewer: Linda Dunbar Review result: Not Ready Reviewer: Linda Dunbar Review result: need more complete description After reading through the document, I find the description is not very clear. For example: Section 1 Introduction: Is the “mailbox” referring to the IMAP client’s mailbox or the server mailbox where all emails are stored? Why do Webmail clients need to know the server side mailbox size? Does the “mailbox size” change overtime? Thanks. Linda Dunbar From nobody Sun May 13 19:20:24 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C776127909 for ; Sun, 13 May 2018 19:20:23 -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=lFWQI1zQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V/56hECk 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 Sm7OJPsENigx for ; Sun, 13 May 2018 19:20:20 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE3112778E for ; Sun, 13 May 2018 19:20:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A80EB25AD2; Sun, 13 May 2018 22:20:19 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 13 May 2018 22:20:19 -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=fm2; bh=Ptqg1c SCKGxHK9XLkU2gKtMFSKxe6J6vvEvmg2PttkI=; b=lFWQI1zQcrAgICr3xm04kQ NhJ0w3nGgQYLj9k9XKHRuSP2m95jqzxBRvVwpQ7fa8H1ZVrqchljc9R21xAUYEZT W+gBpH+8cXriP1FZBU3QoU3R4L7/2qIqprOKta2aWWmvoy/OcpfXA/C5vzZbAa6c WRIzhBPEqH0nHLmSOwq0iSifoKjHC2qkkBED/dR4xOCoO2JYMnEppG1Cr9BMayBi GArEnV+BTYcOn3CgTzFfOyz6ARGY472Vj1yfu5/f4OkXVwm6ZDpDnW65y1Vo5RTD 1Hz//ACc2SPr1rQxb2k878MzGQIyDQ4OM1sICRcW0irMCUR+uDYsQ+0A1IkdHuVA == 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=fm2; bh=Ptqg1c SCKGxHK9XLkU2gKtMFSKxe6J6vvEvmg2PttkI=; b=V/56hECk6MCQnMvRYTEp0W qqaxV3qGda5GNl8zBpbIWJij9GBc7NC1VaF4UKY4oEahFkwIgXBx+N6D351YSVoE 7863RWs8reKDPm9X8YIuWVxh+l31nSGlJxeL+Vv3VjVOBVNvHtlPTFKZpDdFXLJ1 OHBIowNkrTE4/cTCg6QcvM8dKZl7rCkttjWZQr5C+5kExxkU93tAvjcWuEBkFngN 1FhmBTwNHh5xVFoWrpYlkWFrU/baKmxr2StGSQVqQ9gpwN4ZlXwAmUQObhIURbsq osopSVInzcLzTDEeQtLPgl7OqjANv7Bn8L2kPlfd4C6aIej+8aI1kqhz+Oq+0XCQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 579979E09E; Sun, 13 May 2018 22:20:19 -0400 (EDT) Message-Id: <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: Linda Dunbar MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152626441939221530" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> Date: Mon, 14 May 2018 12:20:19 +1000 In-Reply-To: <152626307291.10130.11253794031353526719@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:20:23 -0000 This is a multi-part message in MIME format. --_----------=_152626441939221530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: > Reviewer: Linda Dunbar > Review result: Not Ready >=20 > Reviewer: Linda Dunbar > Review result: need more complete description >=20 > After reading through the document, I find the description is not > very clear.> For example: > Section 1 Introduction: > Is the =E2=80=9Cmailbox=E2=80=9D referring to the IMAP client=E2=80=99s m= ailbox or the > server mailbox> where all emails are stored? >=20 >=20 > Why do Webmail clients need to know the server side mailbox size? >=20 > Does the =E2=80=9Cmailbox size=E2=80=9D change overtime? >=20 > Thanks. Linda Dunbar Thanks Linda. I admit that none of these questions occurred to me, clearly I'm too embedded in the IMAP world already, so I would say that the answers to your questions are: 1) like all STATUS responses, this is the state of the mailbox on the server. 2) any clients which don't keep a full copy of the IMAP mailbox may still wish to be able to quickly identify the mailboxes using the most amount of storage - for example to allow the the user to remove large messages when they are approaching their storage quota. 3) as defined in this document, "mailbox size" is based on the storage used by the messages in the mailbox, so it will naturally change if the set of messages in the mailbox change, either through adding new messages, or expunging existing messages. I will send this back to the author and request clarifying language be added to address these three questions. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152626441939221530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Mon, 14 May 2018, at 11:57, Lind= a Dunbar wrote:
Reviewer: Linda Dunbar
Review result: Not Ready

Reviewer: Linda Dunbar
Review result: need more complete description

After reading through the document, I find the description is not very= clear.
For example:
Section 1 Introduction:
Is the =E2=80=9Cmailbox=E2=80=9D referring to the IMAP client=E2=80=99= s mailbox or the server mailbox
where all emails are stored?


Why do Webmail clients need to know the server side mailbox size?
<= /div>

Does the =E2=80=9Cmailbox size=E2=80=9D change overtime?

Thanks. Linda Dunbar

Thanks Linda.  I admit that none of = these questions occurred to me, clearly I'm too embedded in the IMAP world = already, so I would say that the answers to your questions are:

1) like all STATUS responses, this is the= state of the mailbox on the server.

2) any clients which don't keep a full co= py of the IMAP mailbox may still wish to be able to quickly identify the ma= ilboxes using the most amount of storage - for example to allow the the use= r to remove large messages when they are approaching their storage quota.

3) as defined in this document, "mailbox = size" is based on the storage used by the messages in the mailbox, so it wi= ll naturally change if the set of messages in the mailbox change, either th= rough adding new messages, or expunging existing messages.

I will send this back to the author and r= equest clarifying language be added to address these three questions.

Regards,

Bron.

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


--_----------=_152626441939221530-- From nobody Sun May 13 19:22:56 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7490129515 for ; Sun, 13 May 2018 19:22:55 -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=jOC/5PeM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZRxT0LbB 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 Ci2d-17DR4AE for ; Sun, 13 May 2018 19:22:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF461289B0 for ; Sun, 13 May 2018 19:22:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E997825B61 for ; Sun, 13 May 2018 22:22:52 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 13 May 2018 22:22:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=n3774v1DgzbvRsnEf jMT82Oh9yTbNYCC0OCkPdOveGU=; b=jOC/5PeMZVjkAH/oFSpeLFlbOU7hQR6uT syQJzAdcAjEKrVp3lTgUHVONRLaDTIAnP7AYbGnfKXFjmbi1dYKdXcRWXLuTb5/g LN7MLAAyxsUYk4+tmGTwcU0aCSE3RTt4lMEDw9UO0/f80E/0Uj0eVlHgOMa/xveG dGAULzCn1p5vcgNZxgCD/BRDPo0xCLE1qeqOiXYszjyM/zMFdM3ABkTj+hKh8avi IXkkWdOs7krq3AKocuAAsSk1Yg140ID0cgFaoVf+jikjcX+4tPRzHPrp6JwE0N1k wfZDJtUbPLK+Ndqarpm6lIhgyptDWBR7iv3sCD8a25EKu5hkbx6XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=n3774v 1DgzbvRsnEfjMT82Oh9yTbNYCC0OCkPdOveGU=; b=ZRxT0LbBhXOxbL3crYRnZT v8g7OpEUqnWL0+bPYQVwDK49I5z6TFyVq+SpvFSUQvVEyFiSzjgyXwKGtCNDBXdi iEhUc9tab5G3R4Wy8ja/J/eFLavB8ezMd/n6YhLMrsQfQZUpXSTEzmbbYeKTOKlp InEF+qi3Q9ovdWGmuLg87AC+IqMHTuPSQv4KuOo9sFNb6LS5aBN1u3FjOsJe5xaY tgdPxOExG4pDrFEifd+SY1jb6u7HyRDmgpdTJVSHKMD34ep3xqKgOswFokCOA7GH XM3zpuq6JC+KvK9YZsxvtCT7ci7E/6j8a2HkaKI5+kWBepVZble4yIBggb1SChQg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AD91A9E09E; Sun, 13 May 2018 22:22:52 -0400 (EDT) Message-Id: <1526264572.3923998.1370817320.1ED44F01@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152626457239239980" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 In-Reply-To: <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> Date: Mon, 14 May 2018 12:22:52 +1000 Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:22:56 -0000 This is a multi-part message in MIME format. --_----------=_152626457239239980 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" > I will send this back to the author and request clarifying language be > added to address these three questions. Tracking as https://github.com/ietfextra/tracking/issues/31 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152626457239239980 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

I will send this back to the author and request clarifying language be added to address these three questions.

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


--_----------=_152626457239239980-- From nobody Mon May 14 07:10:15 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEB71271DF for ; Mon, 14 May 2018 07:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 scbTfEYH4cc7 for ; Mon, 14 May 2018 07:10:12 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F412D87D for ; Mon, 14 May 2018 07:10:11 -0700 (PDT) Received: from [192.168.1.108] (lab.inertia-technology.com [217.119.239.130]) by mail.dovecot.fi (Postfix) with ESMTPSA id 797BC2AEF58; Mon, 14 May 2018 17:03:16 +0300 (EEST) To: Bron Gondwana , extra@ietf.org References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1526264572.3923998.1370817320.1ED44F01@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <830205ad-756a-28a6-ad43-d2f4ac6baebe@dovecot.fi> Date: Mon, 14 May 2018 16:03:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526264572.3923998.1370817320.1ED44F01@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:10:14 -0000 Op 14-5-2018 om 4:22 schreef Bron Gondwana: > >> I will send this back to the author and request clarifying language >> be added to address these three questions. > > Tracking as https://github.com/ietfextra/tracking/issues/31 > Ok, will do that in the next few days. Regards, Stephan. -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kenttä Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Mon May 14 07:33:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472FF12D94C for ; Mon, 14 May 2018 07:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 EAntJ-ImKmdj for ; Mon, 14 May 2018 07:33:36 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6518312D940 for ; Mon, 14 May 2018 07:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1526308415; d=isode.com; s=june2016; i=@isode.com; bh=YDkEifPuYKGAKPBzqDMCiginb/+cpH7Dw74bQT2fiAY=; 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=wun10Jh+ujX6kW81RGMrzd6nMQgsKJc5/1eLi8P3Svc2PtbftaVAymrROeM3PZrgkTSNFE 4gML5Dc0sCw6nMKi0PsXmRVkp9cEblJD8ZTnirMPys8jSAlP8S0NwbFV3K2JiA76W9W5AB oC0x+W8h4/Ir2m0wujBY44vCCcM2Sv4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 May 2018 15:33:35 +0100 To: Linda Dunbar Cc: Bron Gondwana , extra@ietf.org References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <9f6f8f3e-5988-1c97-b424-c6ba63681b94@isode.com> Date: Mon, 14 May 2018 15:33:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------325F2AFFB8FB8B961F6664BB" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 14:33:38 -0000 --------------325F2AFFB8FB8B961F6664BB Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Linda, On 14/05/2018 03:20, Bron Gondwana wrote: > On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: >> Reviewer: Linda Dunbar >> Review result: Not Ready >> >> Reviewer: Linda Dunbar >> Review result: need more complete description >> >> After reading through the document, I find the description is not=20 >> very clear. >> For example: >> Section 1 Introduction: >> Is the =E2=80=9Cmailbox=E2=80=9D referring to the IMAP client=E2=80=99s m= ailbox or the server=20 >> mailbox >> where all emails are stored? >> >> >> Why do Webmail clients need to know the server side mailbox size? >> >> Does the =E2=80=9Cmailbox size=E2=80=9D change overtime? >> >> Thanks. Linda Dunbar > > Thanks Linda.=C2=A0 I admit that none of these questions occurred to me,= =20 > clearly I'm too embedded in the IMAP world already, so I would say=20 > that the answers to your questions are: > > 1) like all STATUS responses, this is the state of the mailbox on the=20 > server. There might be some terminology issue here. The term "mailbox" has a=20 special meaning in IMAP. It is also frequently called "folder" in other=20 context. An IMAP user has at least one mailbox called "INBOX" (where=20 mail arrives), but will typically have multiple other mailboxes, like=20 "Trash", "Sent", "Drafts", as well as the one explicitly created by the=20 user. An IMAP client is only caching a representation of server's state. So=20 this extension is concerned with server state only. > 2) any clients which don't keep a full copy of the IMAP mailbox may=20 > still wish to be able to quickly identify the mailboxes using the most=20 > amount of storage - for example to allow the the user to remove large=20 > messages when they are approaching their storage quota. Right. Many clients are able to show quota, but when they need to=20 calculate how much of the quota is used, they need to calculate mailbox=20 size. That is what this extension provides. > 3) as defined in this document, "mailbox size" is based on the storage=20 > used by the messages in the mailbox, so it will naturally change if=20 > the set of messages in the mailbox change, either through adding new=20 > messages, or expunging existing messages. > > I will send this back to the author and request clarifying language be=20 > added to address these three questions. > > Regards, > > Bron. > --------------325F2AFFB8FB8B961F6664BB Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Linda,

On 14/05/2018 03:20, Bron Gondwana wrote:

On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote:
Reviewer: Linda Dunbar
Review result: Not Ready

Reviewer: Linda Dunbar
Review result: need more complete description

After reading through the document, I find the description is not very clear.
For example:
Section 1 Introduction:
Is the =E2=80=9Cmailbox=E2=80=9D referring to the IMAP client= =E2=80=99s mailbox or the server mailbox
where all emails are stored?


Why do Webmail clients need to know the server side mailbox size?

Does the =E2=80=9Cmailbox size=E2=80=9D change overtime?

Thanks. Linda Dunbar

Thanks Linda.=C2=A0 I admit that non= e of these questions occurred to me, clearly I'm too embedded in the IMAP world already, so I would say that the answers to your questions are:

1) like all STATUS responses, this is the state of the mailbox on the server.

There might be some terminology issue here. The term "mailbox" has a special meaning in IMAP. It is also frequently called "folder" in other context. An IMAP user has at least one mailbox called "INBOX" (where mail arrives), but will typically have multiple other mailboxes, like "Trash", "Sent", "Drafts", as well as the one explicitly created by the user.
An IMAP client is only caching a representation of server's state. So this extension is concerned with server state only.

2) any clients which don't keep a full copy of the IMAP mailbox may still wish to be able to quickly identify the mailboxes using the most amount of storage - for example to allow the the user to remove large messages when they are approaching their storage quota.

Right. Many clients are able to show quota, but when they need to calculate how much of the quota is used, they need to calculate mailbox size. That is what this extension provides.

3) as defined in this document, "mailbox size" is based on the storage used by the messages in the mailbox, so it will naturally change if the set of messages in the mailbox change, either through adding new messages, or expunging existing messages.

I will send this back to the author and request clarifying language be added to address these three questions.

Regards,

Bron.


--------------325F2AFFB8FB8B961F6664BB-- From nobody Mon May 14 09:00:46 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97012E87D for ; Mon, 14 May 2018 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aUqo8HNHYlVz for ; Mon, 14 May 2018 09:00:44 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 5CB9912E88C for ; Mon, 14 May 2018 09:00:21 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m9-v6so16784957qtb.5 for ; Mon, 14 May 2018 09:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=9Bb9lr2DZxYOJlUgsnT8HzAmIjoCAJwjTaK8jw0ScT8=; b=sXngazUjUGnjw11TKuJQgAsQgtwezD3QJ4382s6MxfjK6VK0oQ5z3WjyGPGlSy5gCc 1xMmloMvHpF/8sx4R+kGTNa2MP6QKmaf9Skq/ffKALUbw+PzvF1F8F3kqm4qjT/8UoCb CEOMRsDcBV+d6zsrXZceFTWzzWbkh6ioAlkjxrbnxMMRpgaVUjOc6T+qS5GeclhfHu/q k149tdgEWPdAwiwTYMexz5NmVWMcUrGnXllNIH6uQqKTnEiNGsbICE7SbRTd4Ndwg2Pt O+GH1ZL7JGXJ8AciM0QnzHqr4Q7HoiMRMj47YZwE2ddM14OK+OhcxNHBWR1mJJojQShP KTaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=9Bb9lr2DZxYOJlUgsnT8HzAmIjoCAJwjTaK8jw0ScT8=; b=resePVq2PkZ6lnwTIAZ5KxSo5M6yBlu9G5Dy2xNPHIpL7A+ZArpEOwkpEBOKJ693P5 Zp5WasQUpW4h1kyKja7qHLCJB9SkuCSGllNV+5JAyvwF4zaygMfkww7U2Ud3bxw0SMz3 yxzue6YYl7bEJgc/DlIJGUNX3O3p7eAoGsAZIB8i28FqT1oFYZhovqod1NkKxBCQJk0R 2zb1EjLM/UU4qgNxSjcP+NCvJpzFnet1HhcQcMipfZfc1x7GOjAm3D/MR4HUKzF3ZGpE kgc5YlG4RrVAehIV8nGNW9DeuEXMyDbjkziGJ/AaTiMNC+yxsY8rSXGJjCWX0X2fa/nM aKOg== X-Gm-Message-State: ALKqPwe6bBETWyTqJnEAilRVmkAa9uWJpqdHF2nM8jeN6kAwP+/OQoJT A6yilE9SCCZyxnt7+wK2956Hdx0G2YgRU5VIOJY= X-Google-Smtp-Source: AB8JxZrnh/7qBiHEyBJUMKidB/1gwdsW6ZttKIjkv5zk5Nf31bJfV8/koevCGZZ0okdyu4k0xDaqY3vjBCBXTgzJWAg= X-Received: by 2002:ac8:1a8e:: with SMTP id x14-v6mr9544090qtj.288.1526313620346; Mon, 14 May 2018 09:00:20 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.50.122 with HTTP; Mon, 14 May 2018 09:00:19 -0700 (PDT) In-Reply-To: <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> From: Barry Leiba Date: Mon, 14 May 2018 12:00:19 -0400 X-Google-Sender-Auth: gZIBwtEt7dgHEv8l8OlRjrNenPo Message-ID: To: Bron Gondwana Cc: extra@ietf.org, Linda Dunbar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 16:00:45 -0000 > On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: > > Reviewer: Linda Dunbar > Review result: Not Ready > > Reviewer: Linda Dunbar > Review result: need more complete description > > After reading through the document, I find the description is not very > clear. > For example: > Section 1 Introduction: > Is the =E2=80=9Cmailbox=E2=80=9D referring to the IMAP client=E2=80=99s m= ailbox or the server > mailbox > where all emails are stored? > > > Why do Webmail clients need to know the server side mailbox size? > > Does the =E2=80=9Cmailbox size=E2=80=9D change overtime? > > Thanks. Linda Dunbar > > > Thanks Linda. I admit that none of these questions occurred to me, clear= ly > I'm too embedded in the IMAP world already, so I would say that the answe= rs > to your questions are: > > 1) like all STATUS responses, this is the state of the mailbox on the > server. > > 2) any clients which don't keep a full copy of the IMAP mailbox may still > wish to be able to quickly identify the mailboxes using the most amount o= f > storage - for example to allow the the user to remove large messages when > they are approaching their storage quota. > > 3) as defined in this document, "mailbox size" is based on the storage us= ed > by the messages in the mailbox, so it will naturally change if the set of > messages in the mailbox change, either through adding new messages, or > expunging existing messages. > > I will send this back to the author and request clarifying language be ad= ded > to address these three questions. Really? I don't think there's anything the author needs to do: all of this is clear to people familiar with the relevant IMAP specs, and people implementing this have to be familiar with the relevant IMAP specs. It doesn't hurt to have a look and see whether there are reasonable clarifications to make, but I don't think we should spend too much time on that for these issues. Barry From nobody Mon May 14 16:55:09 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1C12E957 for ; Mon, 14 May 2018 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 QJHu40kw8K-G for ; Mon, 14 May 2018 16:55:05 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 25D0D12E8DD for ; Mon, 14 May 2018 16:55:05 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4ENpvc6051480; Mon, 14 May 2018 23:55:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=wYtNjqnljIIuMizLSLme293MfWMk0ZyheduqBURU9sE=; b=QB/ayvBb4Th12pVBOkzqmEp//3y14wkx5VWQ+S4wuNN1JSAeBdI4cMxPoiVqOp+Pevnn bT9UUWTZ9eVq1LjYk9LgVIpBDYhO3RJQWPYw/GUK3+lT3DMJdC3qqCChzY4MoC1q/JRZ 52tlfCTVhbo+fYljlv6NjmxebZoo1qvHPDD3ai8p+1hQ3opY5RrDExuq2Ynmf079i2Tz TFF8kYx8JDC6XYEW68i/9/tdYI8OBq5LKazDEJEtgAEDe3DWSqFjKm097B/qT/863gzK Y9nZ28HwjcC2QoCc5vfRMIEnJKFagh3uC8d9HV6BdlfC+05f4rn5Cf8Vk34FzuFm0NIc pw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2hx29vx5rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 May 2018 23:55:00 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4ENsxbS000706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 May 2018 23:55:00 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4ENsxXj029963; Mon, 14 May 2018 23:54:59 GMT Received: from [10.145.183.150] (/10.145.183.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 May 2018 16:54:59 -0700 From: "Chris Newman" To: "Bron Gondwana" Cc: extra@ietf.org Date: Mon, 14 May 2018 16:54:56 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8893 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140234 Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 23:55:07 -0000 On 10 May 2018, at 19:01, Bron Gondwana wrote: > My opinion is - just define this response as a 63 bit number. > > Crappy thing here with RFC4466 is: > > tagged-ext-simple =3D sequence-set / number > > And "number" is defined in RFC3501: > > number =3D 1*DIGIT ; Unsigned 32-bit integer ; (0 <=3D n < > 4,294,967,296) > > Which means that the response SHOULD be: > > "SIZE" SP "(" number63 ")" rather than "SIZE" SP number63 to be > tagged-ext. Clients have a parser. That parser will either support 32-bit numbers or = 63-bit numbers. Clients implementing SIZE should just support 63-bit = numbers; that's less client code than supporting 32-bit numbers outside = parens and 63-bit numbers inside parens; thus less risk of bugs. The = extra parentheses make the parser more complex for no good reason. The = extra parentheses make the extension incompatible with an already = implemented extension in my server for no good reason (yes, I'm willing = to make incompatible changes to private extensions, but only if there is = a technical reason to do so). I object to adding the extra parentheses = for those two reasons. - Chris > Bron. > > > On Fri, 11 May 2018, at 08:40, Chris Newman wrote: >> On 10 May 2018, at 10:30, Stephan Bosch wrote: >>> Op 05/05/2018 om 01:46 schreef Chris Newman: >>>> On 4 May 2018, at 16:42, Chris Newman wrote: >>>> >>>>> I just noticed we implemented this in 2005 (under the = >>>>> "X-SUN-IMAP">>>> capability). Looking at the implementation, = >>>>> there's a significant >>>>> bug in the specification. Mailbox sizes can easily exceed 4GB; so >>>>> the ABNF for status-att-list needs to be replaced as follows: >>>>> >>>>> status-att-list =3D status-att SP number63 *(SP status-att SP >>>>> number63) >>>>> ;; number63 is only permitted with extension status >>>>> attributes >>>>> ;; that explicitly allow it; such as SIZE >>>> >>>> Oh, just noticed RFC 4466 redefines that, so you instead need a >>>> normative reference to RFC 4466 and then do: >>>> >>>> status-att-val /=3D "SIZE" SP number63 >>> >>> A 4Gb mailbox is still quite huge these days, but you're right. The >>> QUOTA capability has the same problem: how did you address that? >> >> Quota Storage partially dodges the problem by using 1K rather than 1 >> byte units. However, the fact it doesn't allow 63-bit storage >> numbers is> a specification bug (due to proof-by-example: the IMAP = >> data >> model allows> a mailbox with 4G messages each of 4G size). = >> Implementations should >> ignore specification bugs like that (ours does). However, the 32-bit >> limit on UIDs, message size, and message sequence numbers is >> part of the> fundamental IMAP data model. Changes to those values = >> require an >> incompatible change to the IMAP data model that can break previously >> standards-compliant implementations. The IETF generally doesn't make >> that sort of change without a negotiated extension and = >> implementations> that ignore fundamental data models in the standards = >> without >> negotiation> are usually bad Internet citizens. >> >>> That would have been solved by the 64BIT capability, but that >>> one's on>> hold now >> >> There's no reason we can't have this spec use a 63-bit number at the >> time we write it. Clients won't get this data unless they ask >> for it and> servers won't send it unless they've advertised it. This = >> requires no >> change to the IMAP data model so no separate negotiation is needed = >> to> use 63-bit numbers here. It's just an extra line of ABNF and with = >> no >> impact on data model and very little impact on implementations. A >> normative dependency on a draft that changes the IMAP data model is = >> a> change to SIZE that I would oppose. But use of a 32-bit integer >> is a bug> in the SIZE draft (again via proof-by-example). >> >> - Chris >> >>> Bron, Alexey, opinions? >>> >>> Regards, >>> >>> Stephan >>> >>>> >>>> - Chris >>>> >>>>> number63 =3D 1*DIGIT >>>>> ;; Positive >>>>> unsigned 63-bit integer >>>>> ;; (0 <=3D n <=3D >>>>> 9,223,372,036,854,775,807). >>>>> >>>>> - Chris >>>>> >>>>> On 26 Apr 2018, at 10:10, Alexey Melnikov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've been following discussions on this document and it is ready >>>>>> for >>>>>> IETF Last Call, which I just initiated. >>>>>> >>>>>> One nit: I believe the following reference is now Normative, >>>>>> due to>>>>> added SHOULD level requirement: >>>>>> >>>>>> [QUOTA] >>>>>> >>>>>> Please update the document to reflect this next time the = >>>>>> document>>>>> is >>>>>> revised. >>>>>> >>>>>> Best Regards, >>>>>> Alexey, as AD. >>>>>> >>>>>> _________________________________________________ >>>>>> Extra mailing list >>>>>> Extra@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_mailman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB= 65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DB73C8TOrpz= VRz_O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=3DAv_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHoh= Z6tFZmmM&e=3D>>>> >>>>> _________________________________________________ >>>>> Extra mailing list >>>>> Extra@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB6= 5eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DErU-4WHaHwq= AH1nltCBHaf7zbhatpz2gGlB_BH0n3uI&s=3DHPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmC= x6_ZCvo&e=3D>>> >>>> _________________________________________________ >>>> Extra mailing list >>>> Extra@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_extra&d=3DDwIDaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D5HJofT5ocTAB= 71bioSeN2ztVNEW92Tx14L2kdo_8_PQ&s=3DVsTTjiVSxN0fQkrv_AoqVm9VLp5Rw5qTjsqJJ= EODbT4&e=3D> >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwICaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DiuOZ5F20PkM5wd= QEwZxEPtbn6Zkqct206gpiSREDRcM&s=3DtFJXEAphLbOeNohg_H0fX9hOKWGsxGtr8rozXS6= 87OA&e=3D > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DiuOZ5F20PkM5wdQ= EwZxEPtbn6Zkqct206gpiSREDRcM&s=3DtFJXEAphLbOeNohg_H0fX9hOKWGsxGtr8rozXS68= 7OA&e=3D From nobody Mon May 14 18:14:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AFB1270A3 for ; Mon, 14 May 2018 18:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=Rfpo2Hcq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KHD2NdbP 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 L-lwyqJudfSJ for ; Mon, 14 May 2018 18:14:20 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C49B124B18 for ; Mon, 14 May 2018 18:14:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 66E2E22477 for ; Mon, 14 May 2018 21:14:19 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 May 2018 21:14:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=ioMB4N+z98vkrpYx1 svw3w2nkYe9bTRR016eoWNF/ds=; b=Rfpo2HcqYd2uVh8+h3EvEpIGEKDtzYH2V v7LXQNuTY/Frq8NZGM8eV+PHWrqnx0LxF3D6bGVYPqRZfoqkfFTg5MX99yXeuvKx AQxGFi3dwxepsNiOyYIXdN0V7ANlJZxYKGyzgJnQDEAZNzLMrYeTT2gfw6tSY6OD B/+YGPpLZbf0bfJLwXVRkIROJp816I84ZKyHJstrV7slSPV43UZM41arWw+KuPwu L+4LhOwwKFZ3gmD1ErWjPHh27VcD4sCLLYu+5AQeWTP7e9OrYCrRUD+aQaHD4OuR ZkTtWHnnj/CNjCbyG1smxqW9+F2WwOVCNfhx7IEL1gwzNGUa/VB3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=ioMB4N +z98vkrpYx1svw3w2nkYe9bTRR016eoWNF/ds=; b=KHD2NdbPTLYWLhd958tnIR sQHu3Z9bV/NT9MzIGz7eu2vD+g0bBS2/c/8vzRyiaSACFoRCrcXfRdH2PXXgpUzj milfTYDbOHxeCWnn4xfRksnNuAp3XO4oYzinoiF1yAW6KkscNbvc0iFossqlxGmL RC50e7Xlh0O9KGOMKGpFFfcV2Qk3q7Rhpc6ZHK8LwOYSDa1eYSmLLUcKquJL10Ri 7XWm0mPw5A2ql1BznQtLcdW/pU7ymaXq8wEej8K/i2Odbkuo23CbwT2aINSZI0Wk BQ7BYwmqiFfIGY7VXHBUfsOBF4UylskrUjuLIqE8x2UVsTrWu2g3Yo6j2PSF9xcQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EAFF09E0E4; Mon, 14 May 2018 21:14:18 -0400 (EDT) Message-Id: <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152634685819194760" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Tue, 15 May 2018 11:14:18 +1000 References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 01:14:21 -0000 This is a multi-part message in MIME format. --_----------=_152634685819194760 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, May 15, 2018, at 09:54, Chris Newman wrote: > On 10 May 2018, at 19:01, Bron Gondwana wrote: >> My opinion is - just define this response as a 63 bit number. >> >> Crappy thing here with RFC4466 is: >> >> tagged-ext-simple = sequence-set / number >> >> And "number" is defined in RFC3501: >> >> number = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < >> 4,294,967,296) >> >> Which means that the response SHOULD be: >> >> "SIZE" SP "(" number63 ")" rather than "SIZE" SP number63 to be >> tagged-ext. > > Clients have a parser. That parser will either support 32-bit > numbers or> 63-bit numbers. Clients implementing SIZE should just support 63-bit > numbers; that's less client code than supporting 32-bit numbers > outside> parens and 63-bit numbers inside parens; thus less risk of bugs. The > extra parentheses make the parser more complex for no good reason. The> extra parentheses make the extension incompatible with an already > implemented extension in my server for no good reason (yes, I'm > willing> to make incompatible changes to private extensions, but only if > there is> a technical reason to do so). I object to adding the extra parentheses> for those two reasons. I'm totally fine with all those reasons. Do we need to do a 4466bis for this, or do we let that get folded with the 64bit extension work in general and IMAP4rev2? I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant things like this, but I think it's good to have the discussion and have a clear answer for why we're going with a number without parens - particularly since OBJECTID is doing parans everywhere. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152634685819194760 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, May 15, 2018, at 09:54, Chris Newman wrote:
On 10 May 2018, at 19:01, Bron Gondwana wrote:
My opinion is - just define this response as a 63 bit number.

Crappy thing here with RFC4466 is:

  tagged-ext-simple   = sequence-set / number

And "number" is defined in RFC3501:

number          = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n <
4,294,967,296)

Which means that the response SHOULD be:

"SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be
tagged-ext.

Clients have a parser. That parser will either support 32-bit numbers or
63-bit numbers. Clients implementing SIZE should just support 63-bit
numbers; that's less client code than supporting 32-bit numbers outside
parens and 63-bit numbers inside parens; thus less risk of bugs. The
extra parentheses make the parser more complex for no good reason. The
extra parentheses make the extension incompatible with an already
implemented extension in my server for no good reason (yes, I'm willing
to make incompatible changes to private extensions, but only if there is
a technical reason to do so). I object to adding the extra parentheses
for those two reasons.

I'm totally fine with all those reasons.  Do we need to do a 4466bis for this, or do we let that get folded with the 64bit extension work in general and IMAP4rev2?

I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant things like this, but I think it's good to have the discussion and have a clear answer for why we're going with a number without parens - particularly since OBJECTID is doing parans everywhere.

Bron.


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


--_----------=_152634685819194760-- From nobody Tue May 15 02:46:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4388D12D7F9 for ; Tue, 15 May 2018 02:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 XHvZp_0VtiO9 for ; Tue, 15 May 2018 02:46:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1646012D883 for ; Tue, 15 May 2018 02:46:23 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 64A9CCEC001; Tue, 15 May 2018 09:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1526377581; bh=oUt7khnFF/yDADltiHAkuHuN1PtY5paraLedftAchP8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qyPvFl8vVHkahHeifgodSv+fTTXzfoRlWMmJ8qzyI1As3UnFbdu6RNNZMh3B5ia85 fHAexQd6+Lj6uJbZGCKu+RLnSC4C6AJaa6RWuk50oEQY67N/Mx9Vja8UP9fi1vzrFW qmjssQnG9/OXjzw4CyP9YgGfCdwo8qgoo+raviKE= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1526377580-15100-19769/11/9; Tue, 15 May 2018 09:46:20 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Tue, 15 May 2018 11:46:19 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:46:27 -0000 On Tuesday 15 May 2018 03:14:18 CEST, Bron Gondwana wrote: > I'm totally fine with all those reasons. Do we need to do a > 4466bis for this, or do we let that get folded with the 64bit > extension work in general and IMAP4rev2? > > I'm pretty keen to say that "IMAP4rev2 will fix it" about > irrelevant things like this, but I think it's good to have the > discussion and have a clear answer for why we're going with a > number without parens - particularly since OBJECTID is doing > parans everywhere. Try this: If this extension uses 63-bit unsigned numbers, then that complicates the grammar, which needs an additional sentence to say that the number production comes from RFCxxx instead of 3501, and the RFC, which needs to explain that the size is potentially big. But it simplifies the clients, which only need to parse and handle one case instead of two, and which only need to test one thing instead of two, and breaks nothing. This is similar to the history of "" for UTF8=ACCEPT. There was separate syntax for quoting, it was dropped because it seemed to offer no advantages, and instead the "" was extended to allow UTF8. A success. As far as I know, none of the implementations have reported problems with that. IMHO (note the H, that's h for humble) objectid doesn't have the same problem. The parens aren't necessary. They have no function, they're just there because some other parens add clarity in some other cases. But my personal opinion is that if unnecessary syntax is mandatory, then it adds no unit tests, and the required number of unit tests are an effective proxy for simplicity and reliability. Arnt From nobody Tue May 15 03:05:12 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E4B12D88A for ; Tue, 15 May 2018 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 5gD7TXydYCPG for ; Tue, 15 May 2018 03:05:07 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 97BED12D868 for ; Tue, 15 May 2018 03:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1526378706; d=isode.com; s=june2016; i=@isode.com; bh=TWQ1+DaxRpisqrFHQ5Ld4Ss/NYme2FU3/Ra0Hvban0w=; 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=fKrZHZOAoyfqk/XwFgHaH6O+QEoyh3cYEN3qo0U2dtmEwbUonJqmHeh8rPRVCLXITj1u0Z fOSJt6xyFovF8IHFMbbUT1ZQ2JLcLdxX7n9kQDeuFnl4wbJA1u+GrwbdRwk+haePXtiRJ7 AXXDpr4F4j1KyMGr1o+O7YQZsSx7EWs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 15 May 2018 11:05:06 +0100 To: Bron Gondwana , extra@ietf.org References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: Date: Tue, 15 May 2018 11:04:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------768E7987AB2F571B336A4403" Content-Language: en-GB Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 10:05:09 -0000 --------------768E7987AB2F571B336A4403 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 15/05/2018 02:14, Bron Gondwana wrote: > On Tue, May 15, 2018, at 09:54, Chris Newman wrote: >> On 10 May 2018, at 19:01, Bron Gondwana wrote: >> >> My opinion is - just define this response as a 63 bit number. >> >> Crappy thing here with RFC4466 is: >> >> =C2=A0 tagged-ext-simple =C2=A0 =3D sequence-set / number >> >> And "number" is defined in RFC3501: >> >> number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1*DIGIT ; Unsigned 32-bi= t integer ; (0 <=3D n < >> 4,294,967,296) >> >> Which means that the response SHOULD be: >> >> "SIZE" SP "(" number63 ")"=C2=A0 rather than "SIZE" SP number63 to be >> tagged-ext. >> >> >> Clients have a parser. That parser will either support 32-bit numbers or >> 63-bit numbers. Clients implementing SIZE should just support 63-bit >> numbers; that's less client code than supporting 32-bit numbers outside >> parens and 63-bit numbers inside parens; thus less risk of bugs. The >> extra parentheses make the parser more complex for no good reason. The >> extra parentheses make the extension incompatible with an already >> implemented extension in my server for no good reason (yes, I'm willing >> to make incompatible changes to private extensions, but only if there is >> a technical reason to do so). I object to adding the extra parentheses >> for those two reasons. > > I'm totally fine with all those reasons. I am fine with increasing the numeric range for "tagged-ext-simple". > =C2=A0 Do we need to do a 4466bis for this, Maybe :-). > or do we let that get folded with the 64bit extension work in general=20 > and IMAP4rev2? I am happy to do this in IMAP4rev2. If people also want to have=20 rfc4466bis, this can be done as well. > I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant=20 > things like this, but I think it's good to have the discussion and=20 > have a clear answer for why we're going with a number without parens -=20 > particularly since OBJECTID is doing parans everywhere. --------------768E7987AB2F571B336A4403 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable



On 15/05/2018 02:14, Bron Gondwana wrote:
On Tue, May 15, 2018, at 09:54, Chris Newman wrote:
On 10 May 2018, at 19:01, Bron Gondwana wrote:
My opinion is - just define this response as a 63 bit number.

Crappy thing here with RFC4466 is:

=C2=A0 tagged-ext-simple =C2=A0 =3D sequence-set / number

And "number" is defined in RFC3501:

number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1*DIGIT ; Unsign= ed 32-bit integer ; (0 <=3D n <
4,294,967,296)

Which means that the response SHOULD be:

"SIZE" SP "(" number63 ")"=C2=A0 rather than "SIZE" SP number63 to be
tagged-ext.

Clients have a parser. That parser will either support 32-bit numbers or
63-bit numbers. Clients implementing SIZE should just support 63-bit
numbers; that's less client code than supporting 32-bit numbers outside
parens and 63-bit numbers inside parens; thus less risk of bugs. The
extra parentheses make the parser more complex for no good reason. The
extra parentheses make the extension incompatible with an already
implemented extension in my server for no good reason (yes, I'm willing
to make incompatible changes to private extensions, but only if there is
a technical reason to do so). I object to adding the extra parentheses
for those two reasons.

I'm totally fine with all those reasons.

I am fine with increasing the numeric range for "tagged-ext-simple".

=C2=A0 Do we need to do a 4466bis fo= r this,

Maybe :-).

or do we let that get folded with the 64bit extension work in general and IMAP4rev2?

I am happy to do this in IMAP4rev2. If people also want to have rfc4466bis, this can be done as well.

I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant things like this, but I think it's good to have the discussion and have a clear answer for why we're going with a number without parens - particularly since OBJECTID is doing parans everywhere.

--------------768E7987AB2F571B336A4403-- From nobody Thu May 17 06:42:48 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7893120713; Thu, 17 May 2018 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 cU5Yb_ql_o2G; Thu, 17 May 2018 06:42:39 -0700 (PDT) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) (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 65D6912D86F; Thu, 17 May 2018 06:42:39 -0700 (PDT) Received: by mail-qt0-f176.google.com with SMTP id m16-v6so5744027qtg.13; Thu, 17 May 2018 06:42:39 -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=7cUQ3mwLnAbzGtkp1MP+Nq2rZyvA71/DGY0x92u9r6M=; b=oeSWZ3gHfh9StTa1b9n1Tq85jrkMJ0TK/XirD6L/dblSUrpvkHsWRO0ymYDIqUFdm6 9qG4dGISyfxH3b1Zp3DAF/+bCz1t3hZ0HyJ5YvFpH2iJqJmkNIwsaEWQa+XrK0uV4mj+ hqDEgnZyF6+XLMPJcVd3Zq8TEAO/NugacvS0ITUQaMSq2vJB2K7j9ntZI+SdupHhNCO7 f7yk4phA4nxgUSWnI1taJ4lAxpSwPULTl7QEEOwa1fLgFY5YWJME5ob2ejPlRFwdCfEu JR93QzLX4f0UiCQnwh4Hc3UcAjNS1hf9r79jXdgyS32AVXT6aYdEyo/g5od0S64LePD+ C7Ug== X-Gm-Message-State: ALKqPwdrDgc02rxZn4FPjDtVmhgAj5YDUok2omVi3spNZ3avBUl8K9KP CcSCjJL+LlUkIx4X8yRWzcfiQ2bPRkFK/T1gzRs= X-Google-Smtp-Source: AB8JxZoAux4PfrXdZIm/uZXy469vpNKQiYr2tHkWWGRvbh09K79vFfxgkDu4zXjEaIMWRehBZXRtIraVmDIIZMOmhfk= X-Received: by 2002:a0c:bed1:: with SMTP id f17-v6mr5063243qvj.18.1526564558271; Thu, 17 May 2018 06:42:38 -0700 (PDT) MIME-Version: 1.0 References: <152563640684.26784.16524702453597873690@ietfa.amsl.com> In-Reply-To: <152563640684.26784.16524702453597873690@ietfa.amsl.com> From: Barry Leiba Date: Thu, 17 May 2018 14:42:26 +0100 Message-ID: To: Dale Worley Cc: draft-ietf-extra-imap-list-myrights.all@ietf.org, extra@ietf.org, gen-art@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="00000000000038fc21056c6702a7" Archived-At: Subject: Re: [Extra] Genart last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:42:41 -0000 --00000000000038fc21056c6702a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 3. MYRIGHTS Return Option to LIST Command > > The ordering of the responses is significant only in that > the server MUST NOT send a MYRIGHTS response for a given mailbox > before it sends the LIST response for that mailbox. > > It's clear what this means, but I think the wording is not quite > correct. I don=E2=80=99t understand why you think it=E2=80=99s wrong as it is. I th= ink it=E2=80=99s fine (well, it=E2=80=99s my text, actually, so of course I do) and don=E2=80=99t= see the problem. While your suggestions are also OK, I don=E2=80=99t think any is = better. > (In regard to the substance of this constraint, it's not clear to me > why it exists, but I assume that the authors know of a reason for it.) The reason is that the client will be building a data structure of mailboxes, and it=E2=80=99s possible that clients won=E2=80=99t be able to = handle a MYRIGHTS response when they have not built the mailbox entry from the corresponding LIST response. Another way to handle this would be to say that clients MUST be able to do that, it=E2=80=99s very unlikely that a ser= ver implementation would want to send them in the other order anyway, so it=E2= =80=99s easier to set the restriction there. Barry --00000000000038fc21056c6702a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> 3.=C2=A0 MYRIG= HTS Return Option to LIST Command

>

>=C2=A0 =C2=A0 T= he ordering of the responses is significant only in that

>=C2=A0 =C2=A0 t= he server MUST NOT send a MYRIGHTS response for a given mailbox

>=C2=A0 =C2=A0 b= efore it sends the LIST response for that mailbox.

>

> It's clear= what this means, but I think the wording is not quite

> correct.

<= /span>

I don=E2=80=99t und= erstand why you think it=E2=80=99s wrong as it is.=C2=A0 I think it=E2=80= =99s fine (well, it=E2=80=99s my text, actually, so of course I do) and don= =E2=80=99t see the problem.=C2=A0 While your suggestions are also OK, I don= =E2=80=99t think any is better.

<= /span>

> (In regard to = the substance of this constraint, it's not clear to me

> why it exists,= but I assume that the authors know of a reason for it.)

<= /span>

The reason is that = the client will be building a data structure of mailboxes, and it=E2=80=99s= possible that clients won=E2=80=99t be able to handle a MYRIGHTS response = when they have not built the mailbox entry from the corresponding LIST resp= onse.=C2=A0 Another way to handle this would be to say that clients MUST be= able to do that, it=E2=80=99s very unlikely that a server implementation w= ould want to send them in the other order anyway, so it=E2=80=99s easier to= set the restriction there.


Barry
--00000000000038fc21056c6702a7-- From nobody Thu May 17 11:01:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA60712D95C for ; Thu, 17 May 2018 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 NbKarJigLnCe for ; Thu, 17 May 2018 11:00:58 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E4A124207 for ; Thu, 17 May 2018 11:00:58 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 434A9FA006C; Thu, 17 May 2018 18:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1526580056; bh=cVJDOpEMr/HfdojzNCd1ONuzvMCiD4SiivapNLAz6iI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KrqSBs1epJMd1vRMcW8zOryqpE/Bc4224xpmpm7wrs8B0drLc6jqM4gRqToSHXTXo P14Ynbjl3NwLNiCUqnzUt9ULYWKegwiazFw0XGOJLFGS1hIozOZG0fUVNZFysvt+bH 5yrnQ0yFxNQJwOfxaA9HntTCQeqq1249L+KZ8ZiE= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1526580055-15100-19769/11/12; Thu, 17 May 2018 18:00:55 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 17 May 2018 20:00:54 +0200 Mime-Version: 1.0 Message-Id: <987ead98-73d8-4299-a747-4d93e3c46a1b@gulbrandsen.priv.no> In-Reply-To: References: <152563640684.26784.16524702453597873690@ietfa.amsl.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Genart last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 18:01:01 -0000 Hi Barry, I like this one better when the problems are the client's to deal with. Rationale: Modern clients use several connections, either concurrent or sequential, and do things like reconnect from another IP address if move in/out of WLAN coverage. Therefore, it's not easy for the server to know what it has sent the client. The current wording seems to take good care of order within the processing of a single IMAP command, but does nothing for several-command sequences or clients that base their commands on cached memories of yesterday's commands and responses. If a client decides that it doesn't need to rerun LIST because it ran that only yesterday, etc. So, I suggest saying "Clients SHOULD be aware that a MYRIGHTS response may name a mailbox that the client has not been told about" and requiring nothing particular of the server. Arnt From nobody Thu May 17 12:43:52 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD1126C0F for ; Thu, 17 May 2018 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 eGi0LCBHOEAI for ; Thu, 17 May 2018 12:43:49 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0C12025C for ; Thu, 17 May 2018 12:43:48 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7D92D2A6900; Thu, 17 May 2018 22:43:38 +0300 (EEST) To: Alexey Melnikov , Bron Gondwana , extra@ietf.org References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> From: Stephan Bosch Message-ID: <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi> Date: Thu, 17 May 2018 21:43:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4A096D4DCA4D667404093939" Content-Language: en-US Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 19:43:51 -0000 This is a multi-part message in MIME format. --------------4A096D4DCA4D667404093939 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, So, in summary, what should be done here for the draft? Regards, Stephan. Op 15/05/2018 om 12:04 schreef Alexey Melnikov: > > > > On 15/05/2018 02:14, Bron Gondwana wrote: >> On Tue, May 15, 2018, at 09:54, Chris Newman wrote: >>> On 10 May 2018, at 19:01, Bron Gondwana wrote: >>> >>> My opinion is - just define this response as a 63 bit number. >>> >>> Crappy thing here with RFC4466 is: >>> >>>   tagged-ext-simple   = sequence-set / number >>> >>> And "number" is defined in RFC3501: >>> >>> number          = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < >>> 4,294,967,296) >>> >>> Which means that the response SHOULD be: >>> >>> "SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be >>> tagged-ext. >>> >>> >>> Clients have a parser. That parser will either support 32-bit numbers or >>> 63-bit numbers. Clients implementing SIZE should just support 63-bit >>> numbers; that's less client code than supporting 32-bit numbers outside >>> parens and 63-bit numbers inside parens; thus less risk of bugs. The >>> extra parentheses make the parser more complex for no good reason. The >>> extra parentheses make the extension incompatible with an already >>> implemented extension in my server for no good reason (yes, I'm willing >>> to make incompatible changes to private extensions, but only if there is >>> a technical reason to do so). I object to adding the extra parentheses >>> for those two reasons. >> >> I'm totally fine with all those reasons. > > I am fine with increasing the numeric range for "tagged-ext-simple". > >>   Do we need to do a 4466bis for this, > > Maybe :-). > >> or do we let that get folded with the 64bit extension work in general >> and IMAP4rev2? > > I am happy to do this in IMAP4rev2. If people also want to have > rfc4466bis, this can be done as well. > >> I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant >> things like this, but I think it's good to have the discussion and >> have a clear answer for why we're going with a number without parens >> - particularly since OBJECTID is doing parans everywhere. > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --------------4A096D4DCA4D667404093939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

So, in summary, what should be done here for the draft?


Regards,

Stephan.


Op 15/05/2018 om 12:04 schreef Alexey Melnikov:



On 15/05/2018 02:14, Bron Gondwana wrote:
On Tue, May 15, 2018, at 09:54, Chris Newman wrote:
On 10 May 2018, at 19:01, Bron Gondwana wrote:
My opinion is - just define this response as a 63 bit number.

Crappy thing here with RFC4466 is:

  tagged-ext-simple   = sequence-set / number

And "number" is defined in RFC3501:

number          = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n <
4,294,967,296)

Which means that the response SHOULD be:

"SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be
tagged-ext.

Clients have a parser. That parser will either support 32-bit numbers or
63-bit numbers. Clients implementing SIZE should just support 63-bit
numbers; that's less client code than supporting 32-bit numbers outside
parens and 63-bit numbers inside parens; thus less risk of bugs. The
extra parentheses make the parser more complex for no good reason. The
extra parentheses make the extension incompatible with an already
implemented extension in my server for no good reason (yes, I'm willing
to make incompatible changes to private extensions, but only if there is
a technical reason to do so). I object to adding the extra parentheses
for those two reasons.

I'm totally fine with all those reasons.

I am fine with increasing the numeric range for "tagged-ext-simple".

  Do we need to do a 4466bis for this,

Maybe :-).

or do we let that get folded with the 64bit extension work in general and IMAP4rev2?

I am happy to do this in IMAP4rev2. If people also want to have rfc4466bis, this can be done as well.

I'm pretty keen to say that "IMAP4rev2 will fix it" about irrelevant things like this, but I think it's good to have the discussion and have a clear answer for why we're going with a number without parens - particularly since OBJECTID is doing parans everywhere.



_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra

--------------4A096D4DCA4D667404093939-- From nobody Thu May 17 23:51:53 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 636D8127599; Thu, 17 May 2018 23:51:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson To: Cc: extra@ietf.org, draft-ietf-extra-specialuse-important.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152662631099.1578.5728747702102631057@ietfa.amsl.com> Date: Thu, 17 May 2018 23:51:51 -0700 Archived-At: Subject: [Extra] Secdir last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 06:51:52 -0000 Reviewer: Stefan Santesson Review result: Ready This document seems good to go from a security perspective. The security considerations section seems appropriate for this document. From nobody Fri May 18 00:17:39 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F13127369; Fri, 18 May 2018 00:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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=gmail.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 z2iZ3b4eb3Yj; Fri, 18 May 2018 00:17:34 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 C2249127275; Fri, 18 May 2018 00:17:34 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id n202-v6so11999914ita.1; Fri, 18 May 2018 00:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1YIznKFma79tdd/LMorh1p5c8gEIQRI7t3X6sNt1Nvk=; b=A9IjMXtVZreQXjP+EPgb3O30cx4r4x8mU7RfmFbqxsxtOIbc/B9sD16hUKAEUlz7EM ANmyATuNRqgMuOan7w1pfoCwVUkQkDQvKamk5AhOLFOHTLPFFgeqwbrscZ/6AZ730xsR v6A+DtwfBg96CsI0sacDFCPtrHi+34qKBetxpKBfTdSwHBFaVz+Adx8RPAhxz0mL14DK DoSGtSQiPxOtFQ1pi712X3TqmHOy+gyVKnsesdqCiUo8Kd3xQyczFSSJX6Tjbl/gCYGK Y2PTyH0IvpkfT5GqnHiJKhKxUWNxJqDQlLtvGBxq10IFwyZvGQa1T0kqHT7bC1hhP/zE gxbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1YIznKFma79tdd/LMorh1p5c8gEIQRI7t3X6sNt1Nvk=; b=NPpKAC0jEdGsenKh+zmznMNQE4GrB2frcZqllGdsYKdkEHKyWpwsWJTaIr7pdlBxs9 5CdYj7FXNQfGrVhX3D2BK0kBIVPc+DxX+q4j+Pg91YSa1VjXa7bzki0aHaFWdrJqsmqr XRDelr3B1YvrDX75EkoqYg53oGLdDXnNZnF/WxOLL97MDRz+CBljyHvfP4y4ik46oUpj ILdo/2yo61C27RNulu6wPt8PxhLpfmMN719eDrq+0/N1xUmXBlaXp+prh7JyU4BDu5qN fJRJn0Seb5hIKRJl8ZeBsN7GOPTJVlrzyUWGagt8zA5clLIP9teaofrRVHdhist10acM D/ZA== X-Gm-Message-State: ALKqPwe70gJsiqP+iHq+D8Q2/ObsKPpLR+20QvYqxx/N+6FX4z8UOhRG wOb3AGvG4CEOwGoMsDNwiiJvpXebp7xX7AMvAhuAWg== X-Google-Smtp-Source: AB8JxZodEgGgWN0CTmpqjErbajHWPvzb3dAhGDyFUDxbl/y90CuED56LzkNs8Vl4L6mKIV2oE5zpnXAIi41nZqfFhac= X-Received: by 2002:a24:4e8e:: with SMTP id r136-v6mr5779748ita.83.1526627853851; Fri, 18 May 2018 00:17:33 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.192.142.169 with HTTP; Fri, 18 May 2018 00:17:33 -0700 (PDT) In-Reply-To: <152662631099.1578.5728747702102631057@ietfa.amsl.com> References: <152662631099.1578.5728747702102631057@ietfa.amsl.com> From: Barry Leiba Date: Fri, 18 May 2018 08:17:33 +0100 X-Google-Sender-Auth: jFJAegxlyBTVN6kg9L-dj-G5rTI Message-ID: To: Stefan Santesson Cc: secdir@ietf.org, extra@ietf.org, draft-ietf-extra-specialuse-important.all@ietf.org, IETF discussion list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 07:17:37 -0000 Thanks for the review, Stefan. Barry On Fri, May 18, 2018 at 7:51 AM, Stefan Santesson wrote: > Reviewer: Stefan Santesson > Review result: Ready > > This document seems good to go from a security perspective. > > The security considerations section seems appropriate for this document. > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Mon May 21 05:55:52 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8DC1270A3; Mon, 21 May 2018 05:55:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: extra@ietf.org, draft-ietf-extra-specialuse-important.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152690734520.23133.2796970876282674801@ietfa.amsl.com> Date: Mon, 21 May 2018 05:55:45 -0700 Archived-At: Subject: [Extra] Opsdir last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 12:55:46 -0000 Reviewer: Joe Clarke Review result: Ready I have been asked to review draft-ietf-extra-specialuse-important on behalf of the ops directorate. I apologize for the tardiness of the review. This document describes a new IMAP message keyword, $Important and a new \Important attribute to designate a mailbox to hold such "important" messages. The rules of what is "important" are external to this document. This document also defines a registry with which to hold IMAP attributes (and includes \Important in this registry). On the whole, this document is ready. My only ops-related comment relates to interoperability with services like Google's GMail that offer an "Important" mailbox today. How will this standardization interoperate with existing implementations? And is it worth explaining that in some text herein? In terms of nits, I found just one readability item. Section 2: s/While the keyword also can/While the keyword can also/ From nobody Mon May 21 06:05:34 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FD312708C for ; Mon, 21 May 2018 06:05:32 -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 7qfHJ7x2DYsF for ; Mon, 21 May 2018 06:05:31 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id F1194127076 for ; Mon, 21 May 2018 06:05:30 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id C90EB2A6900; Mon, 21 May 2018 16:05:17 +0300 (EEST) To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> From: Stephan Bosch Message-ID: <077c4304-cdec-7721-6999-979d1a7ff057@dovecot.fi> Date: Mon, 21 May 2018 15:05:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <01QNLYA7BLVQ000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 13:05:32 -0000 Hi Ned, Op 08/01/2018 om 17:50 schreef Ned Freed: > The text and examples showing the interaction of :specialuse with :create seem > to assume that mailboxes won't be created without :create. This assumption is > incorrect; the sieve base specification is quite clear that an implementation > MAY create the specified mailbox if it doesn't exist even if :create isn't > specified. (Our implementation is one that always creates missing mailboxes > specified in fileinto; :create is therefore a no-op.) > > I think an implementation that creates by default SHOULD also assign the > special use attribute by default if it able to do so. This should be covered in > the text. A reference to the text about fileinto in RFC 5228 is probably in > order here. > > The first example should probably be changed to note that what happens in the > event there's no mailbox with the \Junk attribute and a mailbox named "Spam" > doesn't exist is implementation-dependent. > > The second example should be tweaked a bit to make it clear that the effect of > :create is to make the creation of the mailbox unconditional. I forgot to address this one before. This change should fix that: https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/29528572c2f0c13bf550679672dd54150cf7a8f7 Regards, Stephan. From nobody Mon May 21 06:14:00 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638B1270A7 for ; Mon, 21 May 2018 06:13:57 -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 ZYxz9Cp0Vl5f for ; Mon, 21 May 2018 06:13:56 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3E1270A3 for ; Mon, 21 May 2018 06:13:56 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 4E9DB2A6900; Mon, 21 May 2018 16:13:55 +0300 (EEST) To: Ned Freed Cc: extra@ietf.org References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> From: Stephan Bosch Message-ID: <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> Date: Mon, 21 May 2018 15:13:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <01QNLYA7BLVQ000051@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 13:13:58 -0000 Hi Ned, Op 08/01/2018 om 17:50 schreef Ned Freed: > I have a few observations and comments on this draft. > > The sieve language is designed not to be specific to IMAP. However, this > extension seems to specifically tied to IMAP in general and to RFC 6154 > in particular. This means there's really no reason not to tighten the > association - in particular, would it not make sense to provide sample > IMAP command sequences to implement the various things in this specification? > > This would be quite helpful to implementors, who might otherwise overlook an > important step. [...] > I'm pretty sure you don't intend this to cover shared folders, so I suggest > changing the text to say something like: > > a. at least one mailbox exists in the user's personal namespace > [NAMESPACE] that has that particular special-use flag assigned, and > > And add the [NAMESPACE] reference pointing at RFC 2342. > > This, incidentially, is one of those places where providing the actual IMAP > commands will be especially valuable: Pointing out that you should use the > NAMESPACE extension and if it isn't present, fallback to LIST "" would be very > helpful. Here's my initial attempt at addressing this point (separate branch in Github): https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda This adds an IMAP example for specialuse_exists. What do you think? Regards, Stephan. From nobody Tue May 22 00:33:39 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6547F126BF0; Tue, 22 May 2018 00:33:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-unauth.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152697441137.8058.2828450475336330038@ietfa.amsl.com> Date: Tue, 22 May 2018 00:33:31 -0700 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-imap-unauth-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 07:33:31 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-imap-unauth-?? Reviewer: Roni Even Review Date: 2018-05-22 IETF LC End Date: 2018-05-21 IESG Telechat date: 2018-06-07 Summary: The document is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: From nobody Sat May 26 05:12:33 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FB712426E for ; Sat, 26 May 2018 05:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=mpdae7du; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HI0PfEyz 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 XrwyiPG4x1dT for ; Sat, 26 May 2018 05:12:30 -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 0A8101241FC for ; Sat, 26 May 2018 05:12:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7408721A85 for ; Sat, 26 May 2018 08:12:29 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 26 May 2018 08:12:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WBCk1YcUta8MbuV0wKlt9AekECB+lZ01nMNnHPTC4 oA=; b=mpdae7duL27Aqfp60/9iSuxhxj5hO0RFHuhi5Lp9w0MFdFzteYzKb7xpu ykFc1IFLI23LpN1g2eYYZueFw6EQm7Aiv6YAHWsgDNIrMzV8OhcZmiwIi90D+Gxh oDNwJ8334lXP1o5XkoLfk3gvUnX0ztw/upgqMbUB76MNNhk3jpwH5psuUri0kwZE MMOnlc7l/UzzPnzEnXZutCoQbE6i7wy77uylfjVLI+Qo8vNzoUDKfMktvSn31v0I 0hl+YqHnl5J346cNVYEZf5eLthx2bMP/GfWdBwJ4Ucr+KTjrRvKD6PDdYiCCt9Pq wlf1yP0Idy/nosjNp0t4f2S+cT0NA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=WBCk1YcUta8MbuV0wKlt9AekECB+l Z01nMNnHPTC4oA=; b=HI0PfEyzRfG1EQmT/PdRGD5FoGaGflPs2A0RSbpfyVPjy ccGOWb3YglRT7tyybuF9eHbDk3YM41vK+tKt8kc70WjSRShB7VYASstvNSnquwGe FjxaNFKPQYGtb8Ww2Bg03BgWDq0gN0CGpYQ18V5Ht6tWr+3m/GLp1pZNbet0KZW2 Q2mgmrZOg4MAaYpSjA50gKzuHxsDr8vOxG4sKpdRn+8QfQlmSl3FQnPL30Da/yq6 aHB3kqOisr5m7l2Jhh+zEiwRh5CtLYH4tgSp1ix4SqA/iP5QiMySi2TAdQmN2Vb0 f+SqA5w2Mry2Q7YBD3qq54wDhVzkUEGolMB3CwupQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 349FA621DC; Sat, 26 May 2018 08:12:29 -0400 (EDT) Message-Id: <1527336749.794062.1386438264.433FF55D@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15273367497940620" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 Date: Sat, 26 May 2018 22:12:29 +1000 Archived-At: Subject: [Extra] Session in Monreal X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 12:12:32 -0000 This is a multi-part message in MIME format. --_----------=_15273367497940620 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've just submitted the session request for Montreal. I asked for 2 hours this time! We still have 6 documents in progress inside the group, and at least one request has come in to talk about another one! Let me know if you think that time isn't going to be enough, or if you have any specific conflicts you want added to the request. We've got about a week until the requests have to be in. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15273367497940620 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've just submitted the session request for Montreal.  I asked for 2 hours this time!  We still have 6 documents in progress inside the group, and at least one request has come in to talk about another one!

Let me know if you think that time isn't going to be enough, or if you have any specific conflicts you want added to the request.  We've got about a week until the requests have to be in.

Cheers,

Bron.

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


--_----------=_15273367497940620-- From nobody Sat May 26 05:17:21 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78068126C19 for ; Sat, 26 May 2018 05:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=N5bS1ZLl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TkmKuYF6 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 TQ_MGSPUFZlM for ; Sat, 26 May 2018 05:17:18 -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 637DB120047 for ; Sat, 26 May 2018 05:17:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A64B0219E6; Sat, 26 May 2018 08:17:17 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 26 May 2018 08:17:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=Yj0zpBbPM+JQwxDne Ob1H40RMY40FeDjF4Y0ifmx0hM=; b=N5bS1ZLlg9ek56BWI7dlLJ6XqOurKGA1l PCrp+BNIz+JcK52fHxovf9M5peUDyac8Kuu9GEX5hCtUCMjVvwO5cWpjVAD9Lcht sQbVFU1y+titU/ul3CkYT66l17JQN17jMZsgOiw1y8uRK9hENEI7kTeL28i5THob lCfhv1T6faBZMIZDRDF84i8O+w0Ap28FzSpb3r3Az8nZKK3wldd/4ovc8p4K0vDL 0Q0dJWFI1bbV1qs7m7fFrfpr9zb1SIlooKEi17HlfHokn+lGJFGsrsHnu9VAeaRe ty9OpWz6IMb768PGJch7CNT7pm48mLAO5S1Ky+W3x0i1uUH4EZYJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=Yj0zpB bPM+JQwxDneOb1H40RMY40FeDjF4Y0ifmx0hM=; b=TkmKuYF6u/F7/x5UDarHLi zk0wi4MoSzMn2p1pWA1jX5GsabWQWx9UERvwEOswbYBDeTEsA87pP7kuFJzFBOaW vYR7fVCIHQI4ZvaNTdd2JCzhipwSj9/EzIheFmrHn/LzmO0R2O3ozJif/uLmjhbU r3qhRRKrsHNWfBXbnVinZjpedV3A9if2IPkzvXnKEyiJHcLigouCGPKNEBfbOQgz JHfBQsSNHBeWMubb/NuzUabvk3UsXK3WFAckTMH/9Mwli2RQWaqzNm6sgm8O+H8v /2NsJFWe0VO4so5YtO0VA7MUg3cEPxqKBxZ1QKlatTCYwHh/aG1UniRSKML4zVZA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 327B3621DC; Sat, 26 May 2018 08:17:17 -0400 (EDT) Message-Id: <1527337037.796675.1386441480.5239144D@webmail.messagingengine.com> From: Bron Gondwana To: Stephan Bosch , Alexey Melnikov , extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15273370377966751" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 Date: Sat, 26 May 2018 22:17:17 +1000 References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi> In-Reply-To: <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi> Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 12:17:21 -0000 This is a multi-part message in MIME format. --_----------=_15273370377966751 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, May 18, 2018, at 05:43, Stephan Bosch wrote: > Hi, > So, in summary, what should be done here for the draft? Use number64 for the SIZE. You'll probably have to define it as well, since 64bit hasn't been standardised and we don't want to have to wait on it: number64 = 1*DIGIT ; Unsigned 63-bit integer ; (0 <= n <= 9,223,372,036,854,775,807) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15273370377966751 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, May 18, 2018, at 05:43, Stephan Bosch wrote:

Hi,

So, in summary, what should be done here for the draft?


Use number64 for the SIZE.  You'll probably have to define it as well, since 64bit hasn't been standardised and we don't want to have to wait on it:

  number64    = 1*DIGIT
                ; Unsigned 63-bit integer
                ; (0 <= n <= 9,223,372,036,854,775,807)

Bron.



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


--_----------=_15273370377966751-- From nobody Sat May 26 05:47:37 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C37A12426E; Sat, 26 May 2018 05:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152733884935.25546.17021324417713674040@ietfa.amsl.com> Date: Sat, 26 May 2018 05:47:29 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-02.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 12:47:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-02.txt Pages : 16 Date : 2018-05-26 Abstract: This document adds new properties to IMAP mailboxes and messages to allow clients to more efficiently re-use cached data for resources which have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-02 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 26 05:51:41 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D64126C26 for ; Sat, 26 May 2018 05:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=WsGyX/Hq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xz/uFpwi 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 C8p46B9kONdF for ; Sat, 26 May 2018 05:51:38 -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 2FEB112426E for ; Sat, 26 May 2018 05:51:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8069B21AAF for ; Sat, 26 May 2018 08:51:37 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 26 May 2018 08:51:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=rZhwIY/QDwMp2Yf35 BFf6ozn7XoHbVZEHGrDWyH5Aio=; b=WsGyX/Hqbzkb/4Kd4EErK7N5OJ3GjWfOT q7pg8M9FhNhFZU5amSzNMNjzRd7HXUZoJz4WIah6lef7lTC+yHxCWc0l4nefweXg GVQheWdRXEvftNJOqp9odV5J0oohLMRc0iGeFR2Zak3yChIu0Ec8utVuElBdX6xU 6rA9wNS7zxm9Wcep7u/JPfsPKCCym8dbOxgFqKmDRD7cnYp9BUL84R255kMwadBQ G+X2LpoZPErvaHl4h+uyrqbwquNUt88Cl3XVYoTX3dWg9UeyrUiS9GYWGqp7DvY2 dmcaR50K9vWcPc7nP3yriBv2/YMYuu4WdI9bOJmHuW2AnjtM36Yvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=rZhwIY /QDwMp2Yf35BFf6ozn7XoHbVZEHGrDWyH5Aio=; b=Xz/uFpwi8KmLvXfW0FM2LD mww3WKlHkTdSCOGGuk9bnR779T8lsv8aPYJ+JaUaTI+BuB6BpgfsMkhWCfU22Mlg mq3b6e9U24vsUaDkBOsmZPhWtGDNTBsM2KDBuecsEJFZfLcMutXf+UMY7a9/VuKr gNvY3GmnLwiUeTG5+Okvjc6EJxw6aqOin62Dus7rmvQpQhCXSsLFJIwAOupwC/Tx Hf0c9Z0KU9Bz3ptRnABvQe+i8LmuKag8yLn6iSnCjoLrNcA6J8ANMgpCnL5kRzBk QrAdbgZ8Ht1woYmS7zJFPfLfqvapq1ssNLcAjyD32wTRpcOg3Vvv61CR6RhgtYrA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 28322621DC; Sat, 26 May 2018 08:51:37 -0400 (EDT) Message-Id: <1527339097.807504.1386460208.2B324414@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15273390978075040" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 In-Reply-To: <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> Date: Sat, 26 May 2018 22:51:37 +1000 Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 12:51:40 -0000 This is a multi-part message in MIME format. --_----------=_15273390978075040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Non smartass version created and uploaded as -02. I'm going to ask Jiankang to progress this document to Working Group Last Call. There's been no substantive feedback on the last couple of rounds except for this, and it's implemented and working at FastMail now - we're using MAILBOXID internally. Bron. On Mon, May 7, 2018, at 23:07, Arnt Gulbrandsen wrote: > On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote: >> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ >> >> I uploaded this one a couple of weeks ago, which resolved all >> the feedback I've had. More feedback here would be great too. > > Maybe... > > "Servers that implement both RFC 6154 and this specification SHOULD > optimize their execution of command like UID SEARCH OR EMAILID > 1234 EMAILID> 4321. Clients may assume that searching the all-mail mailbox using > OR/EMAILID or OR/THREADID is a fast way to find messages again if some> other client has moved them out of the mailbox where they were > previously> seen." > > Or not. Your call. > > Arnt > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15273390978075040 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Non smartass version created and uploaded as -02.

I'm going to ask Jiankang to progress this document to Working Group Last Call.  There's been no substantive feedback on the last couple of rounds except for this, and it's implemented and working at FastMail now - we're using MAILBOXID internally.

Bron.


On Mon, May 7, 2018, at 23:07, Arnt Gulbrandsen wrote:
On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote:

I uploaded this one a couple of weeks ago, which resolved all
the feedback I've had.  More feedback here would be great too.

Maybe...

"Servers that implement both RFC 6154 and this specification SHOULD
optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID
4321. Clients may assume that searching the all-mail mailbox using
OR/EMAILID or OR/THREADID is a fast way to find messages again if some
other client has moved them out of the mailbox where they were previously
seen."

Or not. Your call.

Arnt

_______________________________________________
Extra mailing list

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


--_----------=_15273390978075040-- From nobody Sat May 26 06:00:18 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC1126C3D for ; Sat, 26 May 2018 06:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=CotMYSGv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l2yY8El/ 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 q1bBEbAE8aKx for ; Sat, 26 May 2018 06:00:14 -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 4E1C9120047 for ; Sat, 26 May 2018 06:00:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AFF41219DA for ; Sat, 26 May 2018 09:00:13 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 26 May 2018 09:00:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=jXQnHHbosx043cBh9wrFtMBivRQ5fNftFoX4OjTOj Vg=; b=CotMYSGvuMFMxsVzuQauPNpPrX98dXJPZ+cxgFSdvYmOMH0a9ahlqGzGG G6P+sn1IPwfPQm4j6vG5ZwEum8d5a8LRgwFmXFmPJdzOYuzfEUdVqOyC8RFPnSOA DCsZTHafWzGTxTn/YXen/7kMwvFjhfCpUxe37SwC0KBrQlHlKpiM/Nnf7ErtV4TB U4zhvZnZf7R/cqNKK+XncR9ucD93foJrvddTDPnGs6Sz1/PskuW1PntT5Rd77b4R hlReonpcw1g/ClBllfiJah1ORHP4kOZ8dtbwhJ0EwycaCIHsp9RNIVttjdo/wuK9 9VfvVEeN2UQZJvlNnbCCpK0bLF6Fw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=jXQnHHbosx043cBh9wrFtMBivRQ5f NftFoX4OjTOjVg=; b=l2yY8El/mVIGXnZXNHcLaHvWx1YK6xuL4aV/GUxM6hmbO fL3QEVx/Vr+PrI0+s4gDSsH2PMh5VrEdAe4Tgp+MvhkAunOE+cLamQVF0kgZR+Mj nNxkFSfAnFfIms4bbSwk8zI88mXID2XaUBan2QFi/avjV9N4IdUdq5C6G6b1Eefh JvRYLW1gqis5Am4Qw1UuxHJZUu5lx94L3/uDAmbiiW7OhAHV8gQhEP7TDFjGElCX i8ph35TK1D9mY5CIMCJVBPaL765W94QSJNjh1gEhlHNGFGVnBSbXCn+T2JEKPo1z zu6MqKVUxaewMIYfdA9XXL1ssx7GIMpUya9TKIi1w== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 524B1621E6; Sat, 26 May 2018 09:00:13 -0400 (EDT) Message-Id: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15273396138103250" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 Date: Sat, 26 May 2018 23:00:13 +1000 Archived-At: Subject: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 13:00:16 -0000 This is a multi-part message in MIME format. --_----------=_15273396138103250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I asked a few weeks ago about progressing both objectid and sieve-fcc. Since objectid is pretty polished now, I'm ready for that to move on. Sieve-fcc has two outstanding questions though: * what to do about message format for notify/enotify fcc * do we need separate capabilities, or just "fcc"? I am soliciting opinions, either "I agree with you, Bron, sounds great" - or suggestions for better ideas! I have no strong attachment to any particular choice, but I would like to get this document progressed... * Regarding message format for notify - I'm happy to say "it's up to the server to serialise something in MESSAGE/RFC822 which is readable and contains the details of the notification. Since notify can be arbitrary data formats, the alternative of trying to specify a particular behaviour beyond that is either very complex, or very limiting. I see no need to lock down the format, since this feature will be either for a human to read, or for audit/compliance reasons, so requirements will vary by site. * Regarding capability: I'm happy with just fcc - it should be easy to implement across all types in our server, and I assume in other servers too. Please let us know what you think. I'll ask Ken to get it written up and maybe we can get this one processed before Montreal as well. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15273396138103250 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I asked a few weeks ago about progressing both objectid and sieve-fcc.  Since objectid is pretty polished now, I'm ready for that to move on.

Sieve-fcc has two outstanding questions though:

* what to do about message format for notify/enotify fcc
* do we need separate capabilities, or just "fcc"?

I am soliciting opinions, either "I agree with you, Bron, sounds great" - or suggestions for better ideas!  I have no strong attachment to any particular choice, but I would like to get this document progressed...

* Regarding message format for notify - I'm happy to say "it's up to the server to serialise something in MESSAGE/RFC822 which is readable and contains the details of the notification.  Since notify can be arbitrary data formats, the alternative of trying to specify a particular behaviour beyond that is either very complex, or very limiting.  I see no need to lock down the format, since this feature will be either for a human to read, or for audit/compliance reasons, so requirements will vary by site.

* Regarding capability: I'm happy with just fcc - it should be easy to implement across all types in our server, and I assume in other servers too.

Please let us know what you think.  I'll ask Ken to get it written up and maybe we can get this one processed before Montreal as well.

Cheers,

Bron.

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


--_----------=_15273396138103250-- From nobody Mon May 28 00:28:36 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176E8120047 for ; Mon, 28 May 2018 00:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kZ_Ui5lo62Yw for ; Mon, 28 May 2018 00:28:31 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7612420B for ; Mon, 28 May 2018 00:28:29 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5qSCSrwtbAKn8AA--.2095S2; Mon, 28 May 2018 15:28:18 +0800 (CST) Date: Mon, 28 May 2018 15:28:13 +0800 From: "Jiankang Yao" To: "Bron Gondwana" Cc: extra Reply-To: yaojk References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no>, <1527339097.807504.1386460208.2B324414@webmail.messagingengine.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018052815271140448322@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart632667378330_=----" X-CM-TRANSID: AQAAf0B5qSCSrwtbAKn8AA--.2095S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWryDWw18Gw1ftr18tryftFb_yoW5try5pF 43Jr17Gr1UJr1xJw18Gr1DZr1UAr1UJryUJr15Jry8Jry5Aw18tr18tr1rXryUJryrtr15 Jr1UKr15Xr1UJrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Eb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAqx4xG6I8vx48I62xC7I0kMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67 AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAx ZF0Ew4CEw7xC0wCY02Avz4vE14v_GF4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7 v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF 1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIx AIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyU JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFc xC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5yKZtUUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 07:28:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart632667378330_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgIA0KICAgSSBoYXZlIHJlYWQgdGhyb3VnaCB0aGUgZG9jdW1lbnQuIEl0IGlz IGluIGdvb2Qgc3RhdGUuDQoNCiAgIEJlZm9yZSBXR0xDLCBjb3VsZCB5b3Uga2luZGx5IGNsZWFy IG9yIGNsYXJpZnkgdGhlIGZsbG93aW5nIGlzc3VlcyBpbg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWRuaXRzP3VybD1odHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZXh0 cmEtaW1hcC1vYmplY3RpZC0wMi50eHQgPw0KOioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZC1p bmZvL2NoZWNrbGlzdCA6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAtLSBUaGUgZHJhZnQg aGVhZGVyIGluZGljYXRlcyB0aGF0IHRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMzNTAxLCBidXQg dGhlDQogICAgIGFic3RyYWN0IGRvZXNuJ3Qgc2VlbSB0byBtZW50aW9uIHRoaXMsIHdoaWNoIGl0 IHNob3VsZC4NCg0KDQogIE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DQogIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KICAgICAoVXNpbmcgdGhlIGNyZWF0aW9uIGRhdGUgZnJvbSBSRkMzNTAxLCB1cGRh dGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGZvcg0KICAgICBSRkM1Mzc4IGNoZWNrczogMjAwMi0wOS0x NSkNCg0KICAtLSBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayBhIGRpc2NsYWltZXIgZm9yIHBy ZS1SRkM1Mzc4IHdvcmssIGJ1dCBtYXkNCiAgICAgaGF2ZSBjb250ZW50IHdoaWNoIHdhcyBmaXJz dCBzdWJtaXR0ZWQgYmVmb3JlIDEwIE5vdmVtYmVyIDIwMDguICBJZiB5b3UNCiAgICAgaGF2ZSBj b250YWN0ZWQgYWxsIHRoZSBvcmlnaW5hbCBhdXRob3JzIGFuZCB0aGV5IGFyZSBhbGwgd2lsbGlu ZyB0byBncmFudA0KICAgICB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJRVRGIFRydXN0LCB0aGVu IHRoaXMgaXMgZmluZSwgYW5kIHlvdSBjYW4gaWdub3JlDQogICAgIHRoaXMgY29tbWVudC4gIElm IG5vdCwgeW91IG1heSBuZWVkIHRvIGFkZCB0aGUgcHJlLVJGQzUzNzggZGlzY2xhaW1lci4gDQog ICAgIChTZWUgdGhlIExlZ2FsIFByb3Zpc2lvbnMgZG9jdW1lbnQgYXQNCiAgICAgaHR0cHM6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4pDQoNCg0K ICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6IFByb3Bvc2VkIFN0YW5k YXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAoU2VlIFJGQ3MgMzk2NyBhbmQgNDg5 NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMNCiAgICAg dG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpDQoNCiAgPT0gTWlzc2luZyBSZWZl cmVuY2U6ICdVSURWQUxJRElUWSAxNTI0MTk1Nzk3JyBpcyBtZW50aW9uZWQgb24gbGluZSAxOTMs DQogICAgIGJ1dCBub3QgZGVmaW5lZA0KDQogID09IE1pc3NpbmcgUmVmZXJlbmNlOiAnVEhJUyBS RkMnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDUyMiwgYnV0IG5vdCBkZWZpbmVkDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQpCZXN0IFJlZ2FyZHMN Cg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBCcm9uIEdvbmR3YW5hDQpEYXRlOiAyMDE4LTA1 LTI2IDIwOjUxDQpUbzogZXh0cmENClN1YmplY3Q6IFJlOiBbRXh0cmFdIFByb2dyZXNzaW5nIHRo ZSBmY2MgYW5kIG9iamVjdGlkIGRvY3VtZW50cw0KTm9uIHNtYXJ0YXNzIHZlcnNpb24gY3JlYXRl ZCBhbmQgdXBsb2FkZWQgYXMgLTAyLg0KDQoNCg0KSSdtIGdvaW5nIHRvIGFzayBKaWFua2FuZyB0 byBwcm9ncmVzcyB0aGlzIGRvY3VtZW50IHRvIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsLiAgVGhl cmUncyBiZWVuIG5vIHN1YnN0YW50aXZlIGZlZWRiYWNrIG9uIHRoZSBsYXN0IGNvdXBsZSBvZiBy b3VuZHMgZXhjZXB0IGZvciB0aGlzLCBhbmQgaXQncyBpbXBsZW1lbnRlZCBhbmQgd29ya2luZyBh dCBGYXN0TWFpbCBub3cgLSB3ZSdyZSB1c2luZyBNQUlMQk9YSUQgaW50ZXJuYWxseS4NCg0KDQoN CkJyb24uDQoNCg0KDQoNCg0KT24gTW9uLCBNYXkgNywgMjAxOCwgYXQgMjM6MDcsIEFybnQgR3Vs YnJhbmRzZW4gd3JvdGU6DQoNCk9uIE1vbmRheSA3IE1heSAyMDE4IDEzOjUyOjQ4IElTVCwgQnJv biBHb25kd2FuYSB3cm90ZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1leHRyYS1pbWFwLW9iamVjdGlkLw0KDQoNCg0KSSB1cGxvYWRlZCB0aGlzIG9uZSBh IGNvdXBsZSBvZiB3ZWVrcyBhZ28sIHdoaWNoIHJlc29sdmVkIGFsbA0KDQp0aGUgZmVlZGJhY2sg SSd2ZSBoYWQuICBNb3JlIGZlZWRiYWNrIGhlcmUgd291bGQgYmUgZ3JlYXQgdG9vLg0KDQoNCg0K TWF5YmUuLi4NCg0KDQoNCiJTZXJ2ZXJzIHRoYXQgaW1wbGVtZW50IGJvdGggUkZDIDYxNTQgYW5k IHRoaXMgc3BlY2lmaWNhdGlvbiBTSE9VTEQNCg0Kb3B0aW1pemUgdGhlaXIgZXhlY3V0aW9uIG9m IGNvbW1hbmQgbGlrZSBVSUQgU0VBUkNIIE9SIEVNQUlMSUQgMTIzNCBFTUFJTElEDQoNCjQzMjEu IENsaWVudHMgbWF5IGFzc3VtZSB0aGF0IHNlYXJjaGluZyB0aGUgYWxsLW1haWwgbWFpbGJveCB1 c2luZw0KDQpPUi9FTUFJTElEIG9yIE9SL1RIUkVBRElEIGlzIGEgZmFzdCB3YXkgdG8gZmluZCBt ZXNzYWdlcyBhZ2FpbiBpZiBzb21lDQoNCm90aGVyIGNsaWVudCBoYXMgbW92ZWQgdGhlbSBvdXQg b2YgdGhlIG1haWxib3ggd2hlcmUgdGhleSB3ZXJlIHByZXZpb3VzbHkNCg0Kc2Vlbi4iDQoNCg0K DQpPciBub3QuIFlvdXIgY2FsbC4NCg0KDQoNCkFybnQNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkV4dHJhIG1haWxpbmcgbGlzdA0KDQpF eHRyYUBpZXRmLm9yZw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2V4 dHJhDQoNCg0KDQotLQ0KDQogIEJyb24gR29uZHdhbmEsIENFTywgRmFzdE1haWwgUHR5IEx0ZA0K DQogIGJyb25nQGZhc3RtYWlsdGVhbS5jb20= ------=_001_NextPart632667378330_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hello,
 
  
   I have read through the document. It is in good state.
 
   Before WGLC, could you kindly clear or clarify the fllow= ing=20 issues in
    https://tools.ietf.org/idnits?url=3Dhtt= ps://tools.ietf.org/id/draft-ietf-extra-imap-objectid-02.txt=20 ?
:********************************************************************= ********
------------------------------------------------------------------
  Checking nits according to https://www.ietf.org/id-info/checkl= ist=20 :
 =20 --------------------------------------------------------------------------= --

 =20 -- The draft header indicates that this document updates RFC3501, but=20 the
     abstract doesn't seem to mention this, whi= ch it=20 should.


  Miscellaneous warnings:
 =20 --------------------------------------------------------------------------= --

    =20 (Using the creation date from RFC3501, updated by this document,=20 for
     RFC5378 checks: 2002-09-15)

  = -- The=20 document seems to lack a disclaimer for pre-RFC5378 work, but=20 may
     have content which was first submitted bef= ore 10=20 November 2008.  If you
     have contacted all= the=20 original authors and they are all willing to grant
   &n= bsp;=20 the BCP78 rights to the IETF Trust, then this is fine, and you can=20 ignore
     this comment.  If not, you may nee= d to=20 add the pre-RFC5378 disclaimer.
     (See the Lega= l=20 Provisions document at
    =20 https://trustee.ietf.org/license-info for more information.)


&n= bsp;=20 Checking references for intended status: Proposed Standard
 =20 --------------------------------------------------------------------------= --

    =20 (See RFCs 3967 and 4897 for information about using normative=20 references
     to lower-maturity documents in=20 RFCs)

  =3D=3D Missing Reference: 'UIDVALIDITY 1524195797' is = mentioned=20 on line 193,
     but not defined

  =3D= =3D=20 Missing Reference: 'THIS RFC' is mentioned on line 522, but not=20 defined

-----------------------------------------------------------= ---------------------------------
******************************************************************
 
 
Best Regards
Jiankang Yao
 
Date: 2018-05-26 20:51
To: extra
Subject: Re: [Extra] Progressing the fcc and objectid=20 documents
Non smartass version created and uploade= d as=20 -02.

I'm going to ask Jiankang to progress th= is=20 document to Working Group Last Call.  There's been no substantive fee= dback=20 on the last couple of rounds except for this, and it's implemented and wor= king=20 at FastMail now - we're using MAILBOXID internally.

Bron.


On Mon, May 7, 2018, at 23:07, Arnt Gulbrandsen wrote:
On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/

I uploaded this one a couple of weeks ago, which resolved all
=
the feedback I've had.  More feedback here would be great=20 too.

Maybe...

"Servers that implement both RFC 6154 and this specification=20 SHOULD
optimize their execution of command like UID SEARCH OR EMAILID 1234= =20 EMAILID
4321. Clients may assume that searching the all-mail mailbox=20 using
OR/EMAILID or OR/THREADID is a fast way to find messages again if=20 some
other client has moved them out of the mailbox where they were=20 previously
seen."

Or not. Your call.

Arnt

_______________________________________________
Extra mailing list
https://www.ietf.or= g/mailman/listinfo/extra

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


------=_001_NextPart632667378330_=------ From nobody Mon May 28 01:49:35 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC4127076 for ; Mon, 28 May 2018 01:49: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=n/TMW0+m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Djw4Ilq1 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 VXT2Qp03-G9K for ; Mon, 28 May 2018 01:49: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 310D01270A0 for ; Mon, 28 May 2018 01:49:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 76D932188C for ; Mon, 28 May 2018 04:49:31 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Mon, 28 May 2018 04:49:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=xQIS0UcM46CoNDJdl AHBK4LtANPiQvW09Qrs7bLfVYc=; b=n/TMW0+mAPtsOR1sd549kmrGpWMR17vjg IVinaCx7ZHmyG4bci8lnZYD5WCfnKAXw8GnoiZOKpjVpWKkk/EFM/N1n8yp6mwqW rPhcYrTrafde9SBC9yuXRF48ZbdpZIDgfUjB+eI8xH4nWnR8hPB9frc6ns+eMMib UkJ5ulbnPswh9m4/B56j1d2vlYxxvNzSYdydUsA0Re1Qt1OZQiWVk8LODSmDv5wG yL820pj74iY/q6lWGTx/XC/6Kz6edb6niv/3bAmLNobKYEVlSLHdaLhKW7nlvHzR hNnKN23X9PHJpfRWYT1OwROMnMAcjIqH9+gDhLgQmIjUnY8mnhN/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=xQIS0U cM46CoNDJdlAHBK4LtANPiQvW09Qrs7bLfVYc=; b=Djw4Ilq10C1oduoryiMwAo 5F18L9pfmGA4Fn535JXKCwE8jjptUWPgZovVTHrJbI3ey0+eloq6E5KH7FM2TqnR t4EEd9R0dbaX2gfcgdOoKy8SBY/P1aI4wxjg2FgkXIB+Gow5jvyABmVAuh6LlpBD 67o7o2kLXDyiM2vY62GF4M2LJqFloqa/3ft6dHwQ7O4s6if15QMHomNVk+gGk3rH kaEAk5DVMc/L0yq3BJHKR+Z6ZinV53jhBmxkCByLY7tXapkbO6NDh0uvgVV/Ne7q xKzArtmqOugOu9eaS5Cicp+jCzlWQ2U37Th8HPKutyMSTqVUSl03kDmpdyfPHL2A == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2B20E621DC; Mon, 28 May 2018 04:49:31 -0400 (EDT) Message-Id: <1527497371.2745409.1387753640.794CF036@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152749737127454092" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 References: <1525697568.699419.1363404160.643550D3@webmail.messagingengine.com> <2f057d79-40b6-4bf0-8ccb-323dbb86f92b@gulbrandsen.priv.no> <1527339097.807504.1386460208.2B324414@webmail.messagingengine.com> <2018052815271140448322@cnnic.cn> Date: Mon, 28 May 2018 18:49:31 +1000 In-Reply-To: <2018052815271140448322@cnnic.cn> Archived-At: Subject: Re: [Extra] Progressing the fcc and objectid documents X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:49:35 -0000 This is a multi-part message in MIME format. --_----------=_152749737127454092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, May 28, 2018, at 17:28, Jiankang Yao wrote: > =EF=BB=BF=20 > Hello, >=20=20 >=20=20=20 > I have read through the document. It is in good state. >=20=20 > Before WGLC, could you kindly clear or clarify the fllowing > issues in> https://tools.ietf.org/idnits?url=3D > https://tools.ietf.org/id/draft-ietf-extra-imap-objectid-02.txt ?> :*= *******************************************************************- > :********> --------------------------------------------------------------= ---- > Checking nits according to https://www.ietf.org/id-info/checklist :> = -------------------------------------------------------------------- > -------->=20 > -- The draft header indicates that this document updates RFC3501, > but the> abstract doesn't seem to mention this, which it should. Oh yeah, sorry - I missed this one. Fixed. >=20 > Miscellaneous warnings: > -------------------------------------------------------------------- > -------->=20 > (Using the creation date from RFC3501, updated by this document, > for> RFC5378 checks: 2002-09-15) >=20 > -- The document seems to lack a disclaimer for pre-RFC5378 work, > but may> have content which was first submitted before 10 November= 2008. > If you> have contacted all the original authors and they are al= l willing > to grant> the BCP78 rights to the IETF Trust, then this is fine= , and you > can ignore> this comment. If not, you may need to add the pre-= RFC5378 > disclaimer.> (See the Legal Provisions document at > https://trustee.ietf.org/license-info for more information.) This document has no pre-November 2008 content in it.=20=20 >=20 > Checking references for intended status: Proposed Standard > -------------------------------------------------------------------- > -------->=20 > (See RFCs 3967 and 4897 for information about using normative > references> to lower-maturity documents in RFCs) I'm not sure what they're talking about here - I guess JMAP? Everything else appears to be Proposed Standard or higher. We have a chicken/egg problem with JMAP, so I've changed that to an informative reference. It's only in "future considerations" section. Yep, it stopped complaining now :) > =3D=3D Missing Reference: 'UIDVALIDITY 1524195797' is mentioned on line > =3D=3D 193,> but not defined This looks like a parser issue. I don't know how to encode this (at least in the text version) such that the parser doesn't think it's a reference! I just removed it entirely, it's not really necessary. > =3D=3D Missing Reference: 'THIS RFC' is mentioned on line 522, but not > =3D=3D defined I'm not sure how to reference the current document. I'm trying [[THIS RFC]] now, which matches how it looks in the text version of the important draft. I'm using markdown and mmark to generate this. Version -03 uploaded :) -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152749737127454092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Mon, May 28, 2018, at 17:28, Jia= nkang Yao wrote:
=EF=BB=BF
Hello,
 
  
   I have read through the document. It is in good state.
 
   Before WGLC, could you kindly clear or clarify the fllowi= ng=20 issues in
:*********************************************************************= *******
------------------------------------------------------------------
=
  Checking nits according to ht= tps://www.ietf.org/id-info/checklist=20 :
 =20 ---------------------------------------------------------------------------= -

 =20 -- The draft header indicates that this document updates RFC3501, but=20 the
     abstract doesn't= seem to mention this, which it=20 should.

Oh yeah, sorry - I missed this one. = Fixed.



  Miscellaneous warnings:
 =20 ---------------------------------------------------------------------------= -

    =20 (Using the creation date from RFC3501, updated by this document,=20 for
     RFC5378 checks: = 2002-09-15)

  -- The=20 document seems to lack a disclaimer for pre-RFC5378 work, but=20 may
     have content whi= ch was first submitted before 10=20 November 2008.  If you
     have contacted a= ll the=20 original authors and they are all willing to grant
    =20 the BCP78 rights to the IETF Trust, then this is fine, and you can=20 ignore
     this comment.&nb= sp; If not, you may need to=20 add the pre-RFC5378 disclaimer.
     (See the Legal=20 Provisions document at
    =20 https://trustee.ietf.org/license-info for more information.)

This document has no pre-November 2008 co= ntent in it. 


 =20 Checking references for intended status: Proposed Standard
 =20 ---------------------------------------------------------------------------= -

    =20 (See RFCs 3967 and 4897 for information about using normative=20 references
     to lower-maturit= y documents in=20 RFCs)

I'm not sure what they're talking about h= ere - I guess JMAP?  Everything else appears to be Proposed Standard o= r higher.  We have a chicken/egg problem with JMAP, so I've changed th= at to an informative reference.  It's only in "future considerations" = section.

Yep, it stopped complaining now :)

  =3D=3D Missin= g Reference: 'UIDVALIDITY 1524195797' is mentioned=20 on line 193,
     but not defined<= br>

This looks like a parser issue.  I d= on't know how to encode this (at least in the text version) such that the p= arser doesn't think it's a reference!

I just removed it entirely, it's not real= ly necessary.

  =3D=3D=20 Missing Reference: 'THIS RFC' is mentioned on line 522, but not=20 defined

I'm not sure how to reference the current= document.  I'm trying [[THIS RFC]] now, which matches how it looks in= the text version of the important draft.  I'm using markdown and mmar= k to generate this. 

Version -03 uploaded :)

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


--_----------=_152749737127454092-- From nobody Mon May 28 01:50:26 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 157F2126D74; Mon, 28 May 2018 01:50:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152749742501.4778.7310627718881041122@ietfa.amsl.com> Date: Mon, 28 May 2018 01:50:25 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-objectid-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:50:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP Extension for object identifiers Author : Bron Gondwana Filename : draft-ietf-extra-imap-objectid-03.txt Pages : 16 Date : 2018-05-28 Abstract: This document updates RFC3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently re-use cached data when resources have changed location on the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-objectid-03 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-objectid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-objectid-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 28 19:27:34 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7724127337 for ; Mon, 28 May 2018 19:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=amJ7bZXk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b/YfhFMt 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 NhmMnZ-hjwU1 for ; Mon, 28 May 2018 19:27:31 -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 E06B9126DFB for ; Mon, 28 May 2018 19:27:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 443C021B62 for ; Mon, 28 May 2018 22:27:30 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 28 May 2018 22:27:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=PTxQGFXGOnNP9Eun6FAIBwGJ6blLHApHV+yO6883O 0k=; b=amJ7bZXkNBL0RoTKCgzAJ3nBJWCgK8iG73KK9t6F+BcFvfcDY84tWDGWj 9ihtx/5eZV5qu66eDGFn2APVOC7A8yFGi84op1KzZGRpwcibmIbKrVNNGyp/VJWn glJqyYTBeH6sVrjPV7G4F5A9uYF5/1uitRERng0TuPB7jMEv+160WL+wSr34/w5V 18SN45U40m9QvED7Ck4QjWxBvOmQ8pbnO/uOe+dWyoEETH5yeUjQYnELSlWbCNPK mKLcE+PUSqG+OIKMLjFPMG9N7RaZdy7dAtFg9qfpcz0mtyj4bG5PV+n/5P1cFqKs m6XKtH24Wf86XpE3DlVgJDaH5WaLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=PTxQGFXGOnNP9Eun6FAIBwGJ6blLH ApHV+yO6883O0k=; b=b/YfhFMtBP/YuifG6zGDdJnGyyy9nDmczO0WogGr7tGQK LMGik1KqsdMJxjOhHnWetgvGn3rJsp82fGMleQHkiPCCUsN6GmwK6XlkXggiP1np N1vrUJljJuCfgwWuQZoKqyG29Gx7PKsaU8JHKSyK4oRZ1uDxhS0hjmakp7v1Qnhn 8IFHD6kIo9kC7kg9E8vP4tXWxm3zOLVLKHuq+47JX794pJxRxkJLh28UkH2/UP2G qqtyJegJ5bm4OBbPnm24w1RmVHTjhn4ZQMLnQpUIQP3QVtxfckiAE8v17jKv1tl/ SE3hiKFfU/CM8fG0unJLrd0FFERMQkkwMz1LQfVkw== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D4ACE9E08A; Mon, 28 May 2018 22:27:29 -0400 (EDT) Message-Id: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152756084922194310" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 Date: Tue, 29 May 2018 12:27:29 +1000 Archived-At: Subject: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 02:27:33 -0000 This is a multi-part message in MIME format. --_----------=_152756084922194310 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Is there any interest in reviving this thing? (found by looking at an email thread from 5 years ago as I cleaned up pinned conversations in my email) http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/ It looks like it might have some IPR issues after a quick internet search... so maybe we don't want to go down that path... -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152756084922194310 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Is there any interest in reviving this thing?  (found by looking at an email thread from 5 years ago as I cleaned up pinned conversations in my email)


It looks like it might have some IPR issues after a quick internet search... so maybe we don't want to go down that path...

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


--_----------=_152756084922194310-- From nobody Mon May 28 20:43:56 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7812D93E for ; Mon, 28 May 2018 20:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RRZgemr6td2Q for ; Mon, 28 May 2018 20:43:52 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 217DC12704A for ; Mon, 28 May 2018 20:43:51 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZiSB1zAxb6+f8AA--.2236S2; Tue, 29 May 2018 11:43:49 +0800 (CST) Date: Tue, 29 May 2018 11:43:44 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018052911424216122334@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart187345077642_=----" X-CM-TRANSID: AQAAf0BZiSB1zAxb6+f8AA--.2236S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKryUGr48trW3XrW3WF4kZwb_yoWxCrX_Za yYgF48t3yUJ39Fkr4UCFZxt34xZFWavwsrAa95Jrs7CryrAwsrJF4S9393Zr1UJFyDuw4D GFsIq34fGr4agjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbVkYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lc2xSY4AK 67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2Kf nxnUUI43ZEXa7IU8pHq3UUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [Extra] Fw: IETF WG state changed for draft-ietf-extra-imap-objectid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 03:43:55 -0000 This is a multi-part message in MIME format. ------=_001_NextPart187345077642_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkdlbnRsZSByZW1pbmRlci4NClRoaXMgZHJhZnQgd2lsbCBiZSBpbiBXRyBs YXN0IGNhbGwgZm9yIDMgd2Vla3MsIHdoaWNoIGVuZHMgaW4gMTkgSnVuZS4NCkFueSBjb21tZW50 cyBhcmUgd2VsY29tZS4NClRoYW5rcyBhIGxvdC4NCg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0K RnJvbTogSUVURiBTZWNyZXRhcmlhdA0KRGF0ZTogMjAxOC0wNS0yOSAxMTozOA0KVG86IHlhb2pr QGNubmljLmNuOyBkcmFmdC1pZXRmLWV4dHJhLWltYXAtb2JqZWN0aWRAaWV0Zi5vcmc7IGV4dHJh LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogSUVURiBXRyBzdGF0ZSBjaGFuZ2VkIGZvciBkcmFm dC1pZXRmLWV4dHJhLWltYXAtb2JqZWN0aWQNCg0KVGhlIElFVEYgV0cgc3RhdGUgb2YgZHJhZnQt aWV0Zi1leHRyYS1pbWFwLW9iamVjdGlkIGhhcyBiZWVuIGNoYW5nZWQgdG8gIkluDQpXRyBMYXN0 IENhbGwiIGZyb20gIldHIERvY3VtZW50IiBieSBKaWFua2FuZyBZYW86DQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZXh0cmEtaW1hcC1vYmplY3RpZC8NCg0K Q29tbWVudDoNClRoZSBlZGl0b3Igb2YgdGhpcyBkcmFmdCBoYXMgdXBkYXRlZCB0aGUgc2V2ZXJh bCB2ZXJzaW9ucyB0byBhZGRyZXNzIHRoZQ0KaXNzdWVzIGZvdW5kLg== ------=_001_NextPart187345077642_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear all,
 
Gentle reminder.
This draft will be in WG last call for 3 weeks, which ends in 19=20 June.
Any comments are welcome.
Thanks a lot.
 
 
Jiankang Yao
 
Date: 2018-05-29 11:38
To: yaojk@cnnic.cn;= draft-ietf-extra-i= map-objectid@ietf.org;=20 extra-chairs@ietf.org
Subject: IETF WG state changed for=20 draft-ietf-extra-imap-objectid
 
The IETF WG state of draft-ietf-extra-imap-o= bjectid has been changed to "In
WG Last Call" from "WG Document" by&nbs= p;Jiankang Yao:
 
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/
 
Comment:
The editor of this draft has updated&nb= sp;the several versions to address the
issues found.
------=_001_NextPart187345077642_=------ From nobody Tue May 29 00:08:10 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6412DB72 for ; Tue, 29 May 2018 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 3WnBnP0xwDaa for ; Tue, 29 May 2018 00:08:07 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C73612DB6F for ; Tue, 29 May 2018 00:08:07 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 71519FA0065; Tue, 29 May 2018 07:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1527577684; bh=9SbIikBmI5kFFH4YQwNkj1pNUQU/w7iGM7gUhQEnWFA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0La0Oz5zvznv+xUPdwcWbScRCqr2rpITthIf80QCGfc6l+u14gQ5OKcs2MiYsvQV 67oDZVZIYISpS/bzc79JppT5DwBY0lfKdNmTXcDk3TWt1DbZKyB89M2Ohs9TM5hIOQ xz7WtxIkszEUit1gmQhyysYsN8P+SUDpNuWf5p9o= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1527577683-2601-19769/11/2; Tue, 29 May 2018 07:08:03 +0000 From: Arnt Gulbrandsen To: Bron Gondwana Cc: extra@ietf.org Date: Tue, 29 May 2018 09:08:02 +0200 Mime-Version: 1.0 Message-Id: <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> In-Reply-To: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> References: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 07:08:09 -0000 On Tuesday 29 May 2018 04:27:29 CEST, Bron Gondwana wrote: > Is there any interest in reviving this thing? (found by > looking at an email thread from 5 years ago as I cleaned up > pinned conversations in my email) It would be nice to have a flag or special-use mailbox defined such that if the client sets that flag or moves a message to that mailbox and the server has a webmail UI, then the server carries out the same action as the webmail UI's "this is spam" button, whatever that action may be. > http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/ > > It looks like it might have some IPR issues after a quick > internet search... so maybe we don't want to go down that > path... It has extra moving parts, which means extra opportunities for IPR. Sigh. I'd prefer to have no reporting. Just a capability from the server and a unilateral action from the client. Full freedom for the server to act now or later, in whatever manner seems suitable. Arnt From nobody Tue May 29 01:06:41 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371C312EA24 for ; Tue, 29 May 2018 01:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 WUbNa1HYdnQI for ; Tue, 29 May 2018 01:06:37 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B404A12E8EF for ; Tue, 29 May 2018 01:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1527581196; d=isode.com; s=june2016; i=@isode.com; bh=u3OhwEWTa43n2fA8Nm0iA5uk+kWs2bnDOaJPtvZqHRE=; 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=ZM0rR7oixeQZPYj+35aumg4S09pp9pZCKhjBxIQCqmNkYAQG8jDlSFg+n/LZZILRSCYY5/ i+9Z46FQCd34jx08GJK1H75eLq6lM5M4vYAUYP0Ee0VD9aotKv8pchRjPqWVPsnNo35FiQ 90kzUmHwVt1BK/qLWfDIPooV9aiIzSs=; Received: from [192.168.1.75] (ppp158-255-168-127.pppoe.spdop.ru [158.255.168.127]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 29 May 2018 09:06:36 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> Date: Tue, 29 May 2018 11:19:13 +0300 Cc: Bron Gondwana , extra@ietf.org Message-Id: References: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 08:06:40 -0000 (Speaking as a participant) > On 29 May 2018, at 10:08, Arnt Gulbrandsen wrot= e: >=20 >> On Tuesday 29 May 2018 04:27:29 CEST, Bron Gondwana wrote: >> Is there any interest in reviving this thing? (found by looking at an em= ail thread from 5 years ago as I cleaned up pinned conversations in my email= ) >=20 > It would be nice to have a flag or special-use mailbox defined such that i= f the client sets that flag or moves a message to that mailbox and the serve= r has a webmail UI, then the server carries out the same action as the webma= il UI's "this is spam" button, whatever that action may be. We already have \Junk, I think this is what you are asking for. >=20 >> http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/ >>=20 >> It looks like it might have some IPR issues after a quick internet search= ... so maybe we don't want to go down that path... >=20 > It has extra moving parts, which means extra opportunities for IPR. Sigh. >=20 > I'd prefer to have no reporting. Just a capability from the server and a u= nilateral action from the client. Full freedom for the server to act now or l= ater, in whatever manner seems suitable. I tend to agree. There are existing reporting formats, which might already b= e suitable or close enough. But it would be good to have a short document describing how the overall sys= tem should behave, listing some implementation options.= From nobody Tue May 29 10:50:19 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4280A12EAEC; Tue, 29 May 2018 10:50:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Waltermire To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-unauth.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152761621220.30011.11575332790456344157@ietfa.amsl.com> Date: Tue, 29 May 2018 10:50:12 -0700 Archived-At: Subject: [Extra] Secdir last call review of draft-ietf-extra-imap-unauth-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 17:50:13 -0000 Reviewer: David Waltermire Review result: Has Nits This standards track draft adds a new state transition to IMAP allowing the current authentication context to be reset to an non-authenticated state using the UNAUTHENTICATE command. This allows a client to issue the IMAP AUTHENTICATE command with administrative credentials to act on behalf of other users, without having to create a new connection for each user, providing for greater efficiency. This draft appears to be ready for publication, with some relatively minor nits to improve readability. Section 4.1: The requirements in this list go beyond the stated requirement to reset connection state. Some text should be added to make it clear that the list defines additional behavior to be followed. Something like the following could be used to address this: s/This lists some IMAP extensions that have connection state that/The connection state for the following list of IMAP extensions/ Append to the end of the paragraph "Additional requirements apply to specific extensions as follows:". From nobody Tue May 29 11:02:26 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86E612762F for ; Tue, 29 May 2018 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b2wIY7b6Ui4t for ; Tue, 29 May 2018 11:02:23 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F012DA27 for ; Tue, 29 May 2018 11:02:23 -0700 (PDT) Received: (qmail 32343 invoked from network); 29 May 2018 18:02:21 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (6f056d84-636a-11e8-8177-1f729f8983f7); Tue, 29 May 2018 11:02:21 -0700 To: extra@ietf.org References: <152761621220.30011.11575332790456344157@ietfa.amsl.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <195dac40-a21b-bbdc-ad95-fb7c3a235c49@linuxmagic.com> Date: Tue, 29 May 2018 11:02:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152761621220.30011.11575332790456344157@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 6f056d84-636a-11e8-8177-1f729f8983f7 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-imap-unauth-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:02:26 -0000 Does anyone have the thread for any previous discussions on this one? There are concerns I have, eg backwards compatability, and the increased risk of this being used as an attack vector (auth attacks, and the need for IMAP developers to address those attack vectors before implementing) On 18-05-29 10:50 AM, David Waltermire wrote: > Reviewer: David Waltermire > Review result: Has Nits > > This standards track draft adds a new state transition to IMAP allowing the > current authentication context to be reset to an non-authenticated state using > the UNAUTHENTICATE command. This allows a client to issue the IMAP AUTHENTICATE > command with administrative credentials to act on behalf of other users, > without having to create a new connection for each user, providing for greater > efficiency. > > This draft appears to be ready for publication, with some relatively minor nits > to improve readability. > > Section 4.1: The requirements in this list go beyond the stated requirement to > reset connection state. Some text should be added to make it clear that the > list defines additional behavior to be followed. > > Something like the following could be used to address this: > > s/This lists some IMAP extensions that have connection state that/The > connection state for the following list of IMAP extensions/ > > Append to the end of the paragraph "Additional requirements apply to specific > extensions as follows:". > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Tue May 29 11:59:04 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820A126B6D for ; Tue, 29 May 2018 11:59:01 -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=isode.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 qYkR5R5FTj3o for ; Tue, 29 May 2018 11:59:00 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 240E112704A for ; Tue, 29 May 2018 11:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1527620339; d=isode.com; s=june2016; i=@isode.com; bh=DtxakuTxyEkhFOuwSlYCavSW2jnJjNImZWXar4T0oyA=; 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=d7r9ZTNQ17As5VHz+VuEVDNptMJqKA7VI4LXc2Nv85I/QRocUHSMW60PDBPyTzXWRcEdjm u9v6QfYepTWQia5YNFII7T3Gb/YWZMoLeMMRQCdeqEBylFEXG4ysGP0Ru2QR24QNjDAAFo vN4GCM17JuDkjAbFmRnM4J3UGClLJkc=; Received: from [192.168.1.76] (ppp158-255-168-127.pppoe.spdop.ru [158.255.168.127]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 29 May 2018 19:58:59 +0100 To: Bron Gondwana , Stephan Bosch , extra@ietf.org References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi> <1527337037.796675.1386441480.5239144D@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <7ab3806c-36f2-bb23-aacd-a050d9e001eb@isode.com> Date: Tue, 29 May 2018 21:58:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <1527337037.796675.1386441480.5239144D@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:59:02 -0000 On 26/05/2018 15:17, Bron Gondwana wrote: > On Fri, May 18, 2018, at 05:43, Stephan Bosch wrote: >> >> Hi, >> >> So, in summary, what should be done here for the draft? >> > > Use number64 for the SIZE. You'll probably have to define it as well, > since 64bit hasn't been standardised and we don't want to have to wait > on it: > > number64 = 1*DIGIT > ; Unsigned 63-bit integer > ; (0 <= n <= 9,223,372,036,854,775,807) I will also add it to IMAP4rev2. From nobody Tue May 29 12:20:08 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE4A12EC96 for ; Tue, 29 May 2018 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SXhLQMM5NC6V for ; Tue, 29 May 2018 12:20:05 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED612EC80 for ; Tue, 29 May 2018 12:20:05 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 3029C2A6905; Tue, 29 May 2018 22:20:01 +0300 (EEST) To: Bron Gondwana , Alexey Melnikov , extra@ietf.org References: <5AE207FD.8020203@isode.com> <71D1116A-0D02-424B-9B22-58110DD8202D@oracle.com> <9e94523e-d12d-e61c-d63b-e54dea7fd33e@dovecot.fi> <84D7D0C7-B12B-4DF2-B059-010CCE8F8271@oracle.com> <1526004063.3372904.1368184696.34A255D8@webmail.messagingengine.com> <1526346858.1919476.1372147984.7BBDC9FC@webmail.messagingengine.com> <393ec97c-4e14-c5ba-e0e0-729e0189611d@dovecot.fi> <1527337037.796675.1386441480.5239144D@webmail.messagingengine.com> From: Stephan Bosch Message-ID: Date: Tue, 29 May 2018 21:19:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1527337037.796675.1386441480.5239144D@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------CCF98484397E680FF508D433" Content-Language: nl Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:20:07 -0000 This is a multi-part message in MIME format. --------------CCF98484397E680FF508D433 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Op 26/05/2018 om 14:17 schreef Bron Gondwana: > On Fri, May 18, 2018, at 05:43, Stephan Bosch wrote: >> >> Hi, >> >> So, in summary, what should be done here for the draft? >> > > Use number64 for the SIZE.  You'll probably have to define it as well, > since 64bit hasn't been standardised and we don't want to have to wait > on it: > > number64 = 1*DIGIT > ; Unsigned 63-bit integer > ; (0 <= n <= 9,223,372,036,854,775,807) Done: https://github.com/ietfextra/draft-ietf-extra-imap-status-size/commit/cab94c5a9216da5ac168b3fc6bbaff31ba6f940e Regards, Stephan. --------------CCF98484397E680FF508D433 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



Op 26/05/2018 om 14:17 schreef Bron Gondwana:
On Fri, May 18, 2018, at 05:43, Stephan Bosch wrote:

Hi,

So, in summary, what should be done here for the draft?


Use number64 for the SIZE.  You'll probably have to define it as well, since 64bit hasn't been standardised and we don't want to have to wait on it:

  number64    = 1*DIGIT
                ; Unsigned 63-bit integer
                ; (0 <= n <= 9,223,372,036,854,775,807)

Done:

https://github.com/ietfextra/draft-ietf-extra-imap-status-size/commit/cab94c5a9216da5ac168b3fc6bbaff31ba6f940e

Regards,

Stephan.
--------------CCF98484397E680FF508D433-- From nobody Tue May 29 12:45:24 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F5D12EC4D; Tue, 29 May 2018 12:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152762311630.29545.9134403669206070377@ietfa.amsl.com> Date: Tue, 29 May 2018 12:45:16 -0700 Archived-At: Subject: [Extra] I-D Action: draft-melnikov-imap4rev2-08.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:45:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Author : Alexey Melnikov Filename : draft-melnikov-imap4rev2-08.txt Pages : 125 Date : 2018-05-29 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-melnikov-imap4rev2-08 https://datatracker.ietf.org/doc/html/draft-melnikov-imap4rev2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-melnikov-imap4rev2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 29 14:17:06 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4112EC4F; Tue, 29 May 2018 14:17:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152762862405.29784.6321952989178283755@ietfa.amsl.com> Date: Tue, 29 May 2018 14:17:04 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-status-size-02.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 21:17:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension Author : Stephan Bosch Filename : draft-ietf-extra-imap-status-size-02.txt Pages : 6 Date : 2018-05-29 Abstract: This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-status-size-02 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-status-size-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-status-size-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 29 14:22:00 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCA812D86E for ; Tue, 29 May 2018 14:21:58 -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 la7OpFrErGay for ; Tue, 29 May 2018 14:21:56 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id B98B512EBE2 for ; Tue, 29 May 2018 14:21:56 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id E5CBA2A6905 for ; Wed, 30 May 2018 00:21:47 +0300 (EEST) To: extra@ietf.org References: <152762862405.29784.6321952989178283755@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Tue, 29 May 2018 23:21:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152762862405.29784.6321952989178283755@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap-status-size-02.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 21:21:59 -0000 Hi, Notable changes are: - Extend message size value range to 63 bits. - introduction: Clarified why it can be useful to obtain storage usage information for individual mailboxes. - Made QUOTA a normative reference. https://github.com/ietfextra/draft-ietf-extra-imap-status-size/commits/master Regards, Stephan. Op 29/05/2018 om 23:17 schreef internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension > Author : Stephan Bosch > Filename : draft-ietf-extra-imap-status-size-02.txt > Pages : 6 > Date : 2018-05-29 > > Abstract: > This document adds a new capability called "STATUS=SIZE" to the > Internet Message Access Protocol (IMAP). It allows retrieving the > total storage size of a mailbox with a single STATUS command rather > than retrieving and summing the sizes of all individual messages in > that mailbox. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap-status-size-02 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-status-size-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-status-size-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Wed May 30 00:10:44 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A312FAD6 for ; Wed, 30 May 2018 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 cwQa7Sn-fVWB for ; Wed, 30 May 2018 00:10:41 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 531ED12FACE for ; Wed, 30 May 2018 00:10:41 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4U76Vvs055052; Wed, 30 May 2018 07:10:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2017-10-26; bh=rSbH5P6V0/7MwuGrOtGiKpmVVKqsfMxGXl+IGfVm8EU=; b=VGweIKofaXc7qyq1EBpCCEqX6EioATZ5cib2sbhrP1bT4JDh/71cbu/9cRvUU+RqwZgH tAhrgjIYXoUs53kUeXITeyXUVnAW+tj6PIHopEXD9sc/8KIMlhwqsfZpimqXOvBWj78A jfJl8elnmSgVPIfyHlomMv+7M2mUhMHCtbPFoMgVqtmPUHsE7CrqP8fUdH0ZyhO5oXDT 0IsJQLm5Xzqy5HFA0ahvwsPmGA30K0O4SmEyglNhBk2ElFGg9ybs4vrDDd2csbwOQ5WE x8NIifFwM2sxiReg05HQl0RB0hUtV91terO03OzNvPhJ9pLeOqXHxP8UzuaYhwBi8NEW 3g== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2j9ev8123s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 07:10:39 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4U7AcF5028437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 07:10:39 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4U7Acq8001620; Wed, 30 May 2018 07:10:38 GMT Received: from [10.159.133.12] (/10.159.133.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2018 00:10:38 -0700 From: "Chris Newman" To: "Michael Peddemors" Cc: extra@ietf.org Date: Wed, 30 May 2018 00:10:36 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <258504D3-0A4B-496C-88DA-9C08A9B91946@oracle.com> In-Reply-To: <195dac40-a21b-bbdc-ad95-fb7c3a235c49@linuxmagic.com> References: <152761621220.30011.11575332790456344157@ietfa.amsl.com> <195dac40-a21b-bbdc-ad95-fb7c3a235c49@linuxmagic.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8908 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300082 Archived-At: Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-imap-unauth-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 07:10:43 -0000 On 29 May 2018, at 11:02, Michael Peddemors wrote: > Does anyone have the thread for any previous discussions on this one? Most discussions have been face-to-face or implementation experience. There was some discussion on the imapext list several years ago. > There are concerns I have, eg backwards compatability, I'm not aware of any backwards compatibility issues. If it's advertised, clients can use it. Otherwise clients can't use it and have to close the socket and open a new one to perform this operation. > and the increased risk of this being used as an attack vector (auth > attacks, and the need for IMAP developers to address those attack > vectors before implementing) It's not in-scope for this document to cover attacks on the authentication operation itself. SASL covers that reasonably well, by indirect reference. If you feel the document is missing an attack vector that's in-scope, I'd welcome additional text. The security considerations section is the primary reason I consider this worth the effort of standardization rather than living with the status quo deployed non-standard mechanism. FYI, this is primarily intended to enable interoperability between administrative IMAP clients and IMAP servers when those components come from different vendors and also to get those vendors thinking about security considerations they might miss when doing an ad-hoc solution (as has been necessary so far). The document is not targeted for end-user IMAP clients. - Chris > On 18-05-29 10:50 AM, David Waltermire wrote: >> Reviewer: David Waltermire >> Review result: Has Nits >> >> This standards track draft adds a new state transition to IMAP >> allowing the >> current authentication context to be reset to an non-authenticated >> state using >> the UNAUTHENTICATE command. This allows a client to issue the IMAP >> AUTHENTICATE >> command with administrative credentials to act on behalf of other >> users, >> without having to create a new connection for each user, providing >> for greater >> efficiency. >> >> This draft appears to be ready for publication, with some relatively >> minor nits >> to improve readability. >> >> Section 4.1: The requirements in this list go beyond the stated >> requirement to >> reset connection state. Some text should be added to make it clear >> that the >> list defines additional behavior to be followed. >> >> Something like the following could be used to address this: >> >> s/This lists some IMAP extensions that have connection state that/The >> connection state for the following list of IMAP extensions/ >> >> Append to the end of the paragraph "Additional requirements apply to >> specific >> extensions as follows:". >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org From nobody Wed May 30 05:20:54 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1860612D77C for ; Wed, 30 May 2018 05:20:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 2_ZbDepIH6gZ for ; Wed, 30 May 2018 05:20:50 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA312DDD2 for ; Wed, 30 May 2018 05:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1527682849; d=isode.com; s=june2016; i=@isode.com; bh=wnT4HZo1vT01Knc77jkNNHVrz+Ke1YnLPc1NeR+H8Bw=; 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=WkleZ7I5YVBAeRaZi6a17cX0yVRYPmAT0FDLSMndnGX4cyvV4ZIh4WaEbp11znH8tjQnX7 R/69CkeamPcy/K0dnud4pIMevoo3Trc/jS+aPWezD4tTCiBPpCcSc2b9bBNQM/y6X1jdCY dS2jpKphgeYhkwmccw7yFU/hq1Col2c=; Received: from [192.168.1.76] (ppp158-255-168-127.pppoe.spdop.ru [158.255.168.127]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2018 13:20:49 +0100 To: extra@ietf.org, Chris Newman From: Alexey Melnikov Message-ID: Date: Wed, 30 May 2018 15:20:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Extra] AD review of draft-ietf-extra-imap-unauth-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 12:20:52 -0000 Hi, This is my belated review of the document. As I only had 1 question, I didn't think it needed delaying IETF LC: 3. UNAUTHENTICATE Command Arguments: None Responses: no specific response for this command Result: OK - completed, now in not authenticated state BAD - command unknown or arguments invalid This command directs the server to reset all connection state, except for state at the TLS [RFC5465] layer. Upon completion, the server connection is placed in not authenticated state. This represents transition 7 in the State Machine Diagram (Section 5). If a mailbox was selected, the mailbox ceases to be selected but no expunge event is generated. If a SASL [RFC4422] security layer was active, it terminates immediately after the server sends the CRLF following the OK response. For the client, it terminates immediately after the CRLF following the UNAUTHENTICATE command. Does this mean that the SASL security layer ends for the client even if the server returns BAD? I understand that this is very unlikely. Maybe you should clarify that the server MUST NOT return BAD response to the client if it advertises this extension. From nobody Wed May 30 05:26:31 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3F512E88A for ; Wed, 30 May 2018 05:26:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 3NwUE_IYR5Iw for ; Wed, 30 May 2018 05:26:25 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B813512E87F for ; Wed, 30 May 2018 05:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1527683185; d=isode.com; s=june2016; i=@isode.com; bh=47JdZ9XBqJqyHI4TgfUHcG1kK4uy2k7Hzb/mD32BQLw=; 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=KIB8NgEJGtedOkfoK+VXmuX+T86RXl+QpumWheQLoVuBGh7d90NPus8ClDjVd+KwipF2vA U4sKPSh0v3xn4BhFQs1WeQbuWCARJU+sGw+5imZKNgbl1YP5XaIeuSpDJhUMKNXvf/xeBH pobdRn1sOAVvjQTKEszBgbLWAZc0VZY=; Received: from [192.168.1.76] (ppp158-255-168-127.pppoe.spdop.ru [158.255.168.127]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 May 2018 13:26:24 +0100 To: Bron Gondwana , Brandon Long References: <1521726212.1534780.1312293528.5114E8E7@webmail.messagingengine.com> <1521751994.3262203.1312821720.2F23D196@webmail.messagingengine.com> Cc: extra@ietf.org From: Alexey Melnikov Message-ID: <1ec3e093-0e71-1342-e035-10b5087dd066@isode.com> Date: Wed, 30 May 2018 15:26:24 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <1521751994.3262203.1312821720.2F23D196@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Call for adoption: draft-melnikov-imap4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 12:26:29 -0000 Hi, On 22/03/2018 23:53, Bron Gondwana wrote: > My apologies, I was so busy taking I forgot to minute that, but I also > suggested literal- in the meeting. 100% agree. Agreed. I've added to the To Do list. I've just posted a new draft under the EXTRA WG name. Can I ask WG Chairs to approve? Best Regards, Alexey > On Fri, 23 Mar 2018, at 07:47, Brandon Long wrote: >> A note on a quick review of the changes of that draft, it wants to >> incorporate LITERAL+... I'd recommend LITERAL- instead for the reasons we >> added that. >> >> Brandon >> >> >> On Thu, Mar 22, 2018 at 6:43 AM Bron Gondwana > > wrote: >> >> __ >> We had consensus in the meeting at IETF101 to adopt this large >> amount of work! Barry has volunteered to work with Alexey on the >> document. We expect much more discussion on the mailing list, and >> a slow burn for a while as we clear our decks. >> >> https://datatracker.ietf.org/doc/draft-melnikov-imap4rev2/ >> >> If you have any objections, speak before Monday 26th! >> >> Cheers, >> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >> >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Wed May 30 05:53:30 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A167F12420B; Wed, 30 May 2018 05:53:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152768480251.27847.13814264727957808518@ietfa.amsl.com> Date: Wed, 30 May 2018 05:53:22 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 12:53:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Author : Alexey Melnikov Filename : draft-ietf-extra-imap4rev2-00.txt Pages : 125 Date : 2018-05-30 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 30 05:53:49 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A3212D9FF for ; Wed, 30 May 2018 05:53:31 -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=PA0fmWaq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hPIbaRYJ 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 nsMXt666YQco for ; Wed, 30 May 2018 05:53:29 -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 87498127241 for ; Wed, 30 May 2018 05:53:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CCA6821B8D for ; Wed, 30 May 2018 08:53:28 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Wed, 30 May 2018 08:53:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=LATC3nB8ITz4X2FHy XuzuafRdmSJkvh0c8EjI15Jolw=; b=PA0fmWaq7kMNoOrkiRS1TxtRvFMWiyhLL jCAGi53YHKMM2FBSbj2O7ZJgMMk/EBMLgkT5VoenzbOiaMWvlpzeeT+NUrlL/YE5 9S48gi2IgHh2m7ehUl7wjExfLcP2TkSXk7+37c6PKLavDrFpr1VUQF1k5qGxH/2t pb95u8sPKm80VScuxkrEFrhgJ+QyrOwlY9/ScSuklkTUhjpF0XGUfLEIRVc9Jhvi WsFSUWtDg8cAxP5Gpz0vhvAJr+WHnXcXUyGd/3NH+OL+Az85urg/75F9J8C8ZjnK enuBCfkZM7h/8tRfQy6eDud/wZlJoE5Dtvk8CfT7CSxZGd3OmsrLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=LATC3n B8ITz4X2FHyXuzuafRdmSJkvh0c8EjI15Jolw=; b=hPIbaRYJj7PRdOs+5VPJ0f aPUHm8Q5Pvb9fwK/qTlwmFkkXlF8IhkfBpW3MWuhay8yi4pIpPHLyiyDyTJIGnQd ftuFvHnlFrTlc3Pqnmlq+vsKBjoWM3+HbbqBB+VnOim3QMatPwhQYFJF75SotM+x 3FwfFq/6YIIiD9PKBPaWzncFUdzsjA1I3iUgFO9o4LLPTtTMEm1t/OiPwJTlQQ8D b5zo+fIOPE2iYtEOyJYHbnRIWtW7Kn4WcpbEpdKqP/n4JjjUrPHQzBxTk5otJuru 7DSxhzqyvR8yUGcHT/FOM4YriOJmOW1eIqWYpgxHr8jf8s3Qo+ygyw6YdqFNdI9w == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 62AC7621DC; Wed, 30 May 2018 08:53:28 -0400 (EDT) Message-Id: <1527684808.209910.1390399704.79D8F839@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15276848082099101" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 In-Reply-To: <1ec3e093-0e71-1342-e035-10b5087dd066@isode.com> References: <1521726212.1534780.1312293528.5114E8E7@webmail.messagingengine.com> <1521751994.3262203.1312821720.2F23D196@webmail.messagingengine.com> <1ec3e093-0e71-1342-e035-10b5087dd066@isode.com> Date: Wed, 30 May 2018 22:53:28 +1000 Archived-At: Subject: Re: [Extra] Call for adoption: draft-melnikov-imap4rev2 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 12:53:48 -0000 This is a multi-part message in MIME format. --_----------=_15276848082099101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, May 30, 2018, at 22:26, Alexey Melnikov wrote: > Hi, > > On 22/03/2018 23:53, Bron Gondwana wrote: >> My apologies, I was so busy taking I forgot to minute that, >> but I also>> suggested literal- in the meeting. 100% agree. > > Agreed. I've added to the To Do list. > > I've just posted a new draft under the EXTRA WG name. Can I ask WG > Chairs to approve? Done. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15276848082099101 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, May 30, 2018, at 22:26, Alexey Melnikov wrote:
Hi,

On 22/03/2018 23:53, Bron Gondwana wrote:
My apologies, I was so busy taking I forgot to minute that, but I also
suggested literal- in the meeting. 100% agree.

Agreed. I've added to the To Do list.

I've just posted a new draft under the EXTRA WG name. Can I ask WG
Chairs to approve?

Done.

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

--_----------=_15276848082099101-- From nobody Wed May 30 12:03:40 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844412EAF6 for ; Wed, 30 May 2018 12:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 dxIAfLKcOP7d for ; Wed, 30 May 2018 12:03:28 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE5212EABC for ; Wed, 30 May 2018 12:03:15 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 0A8CD6A266 for ; Wed, 30 May 2018 21:03:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1527706994; bh=H2rSXKMjr1s025KLT8rvIHXKm7TyGvmmGSBoFkvjtiU=; h=Date:From:To:In-Reply-To:References:Subject:From; b=68vhG5uED9UilA6iGCoy3W3tSPkiIOZeiqyRuzQAh20f4dFG3zbnDRJMHBW2lgymp JHyI5Fg4FNLzWPYlsre5W1H+6x5agSJT5xtlYj0IYfJBpD4Gvs/TVrMU/x+X0kSpsm QjQ4ho//WjXmwNVPPpKB2EdCSXBTLDLdr0qau5epKaDn3974w8wAb3XcWybkrNcMyK hMVj97lt3uRWjqA1uhetx/O0A2ADUZV2xN3Yc7sFQE5NjBQDpdMeT1Q63KqMHfLIyn Wz0dF/Me6AQN3bNEqpCx4tHjH91hq5OA14zGJFt+fK7kFcBmW8O6k6BFUzVG8uIiHX HIAtr6j+xNWcw== Received: from null (appsuite-gw4.open-xchange.com [192.168.110.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id D6E1B3C0185 for ; Wed, 30 May 2018 21:03:13 +0200 (CEST) Date: Wed, 30 May 2018 13:03:12 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <156411865.17416.1527706993613@appsuite.open-xchange.com> In-Reply-To: References: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev5 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 19:03:39 -0000 > On May 29, 2018 at 2:19 AM Alexey Melnikov wrote: [snip] > > On 29 May 2018, at 10:08, Arnt Gulbrandsen wrote: [snip] > > I'd prefer to have no reporting. Just a capability from the server and a unilateral action from the client. Full freedom for the server to act now or later, in whatever manner seems suitable. > > I tend to agree. There are existing reporting formats, which might already be suitable or close enough. > But it would be good to have a short document describing how the overall system should behave, listing some implementation options. What about a simpler system/definition that simply informs a client (via CAPABILITY?) that messages moved into \Junk folder(s) by explicit user action will be reported as Spam and messages moved out will be reported as not spam? That gives a hint to the client that they do not need to do any re-classification themselves, and leaves the details of the reporting mechanism entirely up to the server. michael From nobody Wed May 30 12:54:52 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2012E035 for ; Wed, 30 May 2018 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 drdlnhfAccY0 for ; Wed, 30 May 2018 12:54:48 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1464A12D7FC for ; Wed, 30 May 2018 12:54:47 -0700 (PDT) Received: (qmail 30504 invoked from network); 30 May 2018 19:54:46 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (4d73e252-6443-11e8-b1d7-d77944a73df0); Wed, 30 May 2018 12:54:46 -0700 To: extra@ietf.org References: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> <156411865.17416.1527706993613@appsuite.open-xchange.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <4fcd24e1-af46-e200-a61f-0b7360ded3a9@linuxmagic.com> Date: Wed, 30 May 2018 12:54:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <156411865.17416.1527706993613@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 4d73e252-6443-11e8-b1d7-d77944a73df0 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 19:54:51 -0000 On 18-05-30 12:03 PM, Michael Slusarz wrote: >> On May 29, 2018 at 2:19 AM Alexey Melnikov wrote: > > [snip] > >>> On 29 May 2018, at 10:08, Arnt Gulbrandsen wrote: > > [snip] > >>> I'd prefer to have no reporting. Just a capability from the server and a unilateral action from the client. Full freedom for the server to act now or later, in whatever manner seems suitable. >> >> I tend to agree. There are existing reporting formats, which might already be suitable or close enough. >> But it would be good to have a short document describing how the overall system should behave, listing some implementation options. > > What about a simpler system/definition that simply informs a client (via CAPABILITY?) that messages moved into \Junk folder(s) by explicit user action will be reported as Spam and messages moved out will be reported as not spam? > > That gives a hint to the client that they do not need to do any re-classification themselves, and leaves the details of the reporting mechanism entirely up to the server. > > michael Given all the incorrect 'feedback' reports we see, where end users incorrectly use the 'This is spam' buttons, instead of delete, or the end user who thinks they are training what kind of email they like, say from an advertisors mailing list, hard to support any automatic 'response' mechanism, but in context, the end users generally intent is providing an indication about how they want future emails from the sender treated.. eg 'Allow Sender' or 'Block Sender', depending on the IMAP move from the 'Junk/Spam' folder to the inbox, and vice versa. It might be 'handy' that a structured way for that action to be reported to a backend service, but afraid that will result in a continual 'ask' to pass more information through. This seems to be really something that should be dealt with in the actual IMAP processor, rather than a a client/server interaction You would think that this is an administrative situation. What 'might' be in order, is a standardized mechanism for IMAP server implementations to be able to send a notice to a 'service', which includes a reference to the actual message it self, and the action performed.. eg... On Move, if destination is Inbox and Source is folder with Junk desigation, do callout(SPAM_TO_INBOX, msgid).. vice versa.. do callout(INBOX_TO_SPAM, msgid).. Get the community to write a standardized service model, which can listen for events, and then handle in a method best suited.. Service reads the msgid if it exists, plus the flag, and processes the actual email as it sees fit.. (Changing Headers, Contents, adding to personal blacklist, whitelist, or passing to a baysein analyzer, OR sending a 'report') Is there ANY reason to make the email client specifically send a flag that says it is okay to make this classification? Also, not to be the one mentions it *cough* GDPR, reporting by an end user, is there going to be privacy issues that an end user would not realize, eg the sender information is being possibly sent/shared to third parties with their knowledge? What about WHAT information is 'reported'. Personally, thinking you are opening a can of worms on this one, when we can already effectively do what you are describing, in IMAP code itself.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Wed May 30 16:02:35 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF712DFE0 for ; Wed, 30 May 2018 16:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.com header.b=pSVGOTfn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IBLsXnkI 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 k6F_wMs4LECv for ; Wed, 30 May 2018 16:02:31 -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 3150112DA26 for ; Wed, 30 May 2018 16:02:31 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 94CA321C1D for ; Wed, 30 May 2018 19:02:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 30 May 2018 19:02:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= 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=TgxaT6yl5GN017REQ6bUXb0jIGMGYp3aCAdBzRke7Ng=; b=pSVGOTfn xUQBejZGxuPaFoNThe6MuG6VtDDWEwnQGH5ExUBO9Y/I0l0o9cpnld86LFvAgzFL k0HsbrytwS/4KGSiroia5neYIJlPmjFoT3XYSy9Ke3NcColxNjov4kdsN90Y8VDA agiQCFCqXgKKFHu79o+etoNJuh6MqTVlrIS81h8a4Qkp/M0TcJEJwL8F5wNW8kGy SdyuOPRSS4ZjTPR+gzt2/qiMXscj74nEYXUn7OHOyHiPN3mJ8mjcuxIkdu0CEqlh NnOetfmLbDgQ1w3qH62NJueW4Z2kfRnWCPV31ScKsEMcp8ti+Tlm4ITsWynqvNlW 3xpdhU1VYKEsPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=TgxaT6yl5GN017REQ6bUXb0jIGMGY p3aCAdBzRke7Ng=; b=IBLsXnkIWLYdZ6TYbKsNMEoHE3zPuSSc9VTG88dcbVpYx TyI9Tl32NJboSL0wzx9yT01PEjOT8RN/iqPdTlfnVCnhO6+WUMdTRyZFDURpuLCH REp5vPSeA0KDjBlSS1vLT2YUlQXR4Pk8EfEV2o594i7MXFHlPlr6KK8NZQwDK9QZ EL93JgQ7Y/RiDVrkRQiAnk1WAVI5iN9Ge2rzoui5V/Fm5wvBvHaQSdqAP0mOoxoe eyaLuQQQzxGJ3hdWjBYrIr8otUTekhjW+UKewhSy4k1+kqpMQratWEJB0lpvdc+Q Xgs5piEBIOUv4GpS4mbgZDKVaEPFHascszzKt8yGg== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (202.sub-174-224-140.myvzw.com [174.224.140.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 3748210260 for ; Wed, 30 May 2018 19:02:30 -0400 (EDT) To: extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <05bfc6d3-8507-04df-316a-faf0708fab30@fastmail.com> Date: Wed, 30 May 2018 19:02:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> Content-Type: multipart/mixed; boundary="------------5E9C7180D24CB6F0CDF4FA9D" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 23:02:34 -0000 This is a multi-part message in MIME format. --------------5E9C7180D24CB6F0CDF4FA9D Content-Type: multipart/alternative; boundary="------------111FD393143D6231A790902E" --------------111FD393143D6231A790902E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/26/2018 09:00 AM, Bron Gondwana wrote: > I asked a few weeks ago about progressing both objectid and > sieve-fcc.  Since objectid is pretty polished now, I'm ready for that > to move on. > > Sieve-fcc has two outstanding questions though: > > * what to do about message format for notify/enotify fcc > * do we need separate capabilities, or just "fcc"? > > I am soliciting opinions, either "I agree with you, Bron, sounds > great" - or suggestions for better ideas!  I have no strong attachment > to any particular choice, but I would like to get this document > progressed... > > * Regarding message format for notify - I'm happy to say "it's up to > the server to serialise something in MESSAGE/RFC822 which is readable > and contains the details of the notification.  Since notify can be > arbitrary data formats, the alternative of trying to specify a > particular behaviour beyond that is either very complex, or very > limiting. I see no need to lock down the format, since this feature > will be either for a human to read, or for audit/compliance reasons, > so requirements will vary by site. > > * Regarding capability: I'm happy with just fcc - it should be easy to > implement across all types in our server, and I assume in other > servers too. > > Please let us know what you think.  I'll ask Ken to get it written up > and maybe we can get this one processed before Montreal as well. > https://www.ietf.org/mailman/listinfo/extra The latest draft has requirements as to what should appear in the FCC messsage: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-02#section-3.1 This is pretty much there for non-mailto: notifications, since both vacation responses and mailto; notifications can be stored in a mailbox as-is. I'd like feedback as whether this section is moving in the right direction, complete trash, or somewhere in between. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------111FD393143D6231A790902E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 05/26/2018 09:00 AM, Bron Gondwana wrote:
I asked a few weeks ago about progressing both objectid and sieve-fcc.  Since objectid is pretty polished now, I'm ready for that to move on.

Sieve-fcc has two outstanding questions though:

* what to do about message format for notify/enotify fcc
* do we need separate capabilities, or just "fcc"?

I am soliciting opinions, either "I agree with you, Bron, sounds great" - or suggestions for better ideas!  I have no strong attachment to any particular choice, but I would like to get this document progressed...

* Regarding message format for notify - I'm happy to say "it's up to the server to serialise something in MESSAGE/RFC822 which is readable and contains the details of the notification.  Since notify can be arbitrary data formats, the alternative of trying to specify a particular behaviour beyond that is either very complex, or very limiting.  I see no need to lock down the format, since this feature will be either for a human to read, or for audit/compliance reasons, so requirements will vary by site.

* Regarding capability: I'm happy with just fcc - it should be easy to implement across all types in our server, and I assume in other servers too.

Please let us know what you think.  I'll ask Ken to get it written up and maybe we can get this one processed before Montreal as well.
https://www.ietf.org/mailman/listinfo/extra


The latest draft has requirements as to what should appear in the FCC messsage: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-02#section-3.1

This is pretty much there for non-mailto: notifications, since both vacation responses and mailto; notifications can be stored in a mailbox as-is.

I'd like feedback as whether this section is moving in the right direction, complete trash, or somewhere in between.


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------111FD393143D6231A790902E-- --------------5E9C7180D24CB6F0CDF4FA9D Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------5E9C7180D24CB6F0CDF4FA9D-- From nobody Thu May 31 06:05:52 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406E12EBE1 for ; Thu, 31 May 2018 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 Jo4tqD3bqksp for ; Thu, 31 May 2018 06:05:49 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id D394A12EBC7 for ; Thu, 31 May 2018 06:05:48 -0700 (PDT) Received: from [10.217.110.205] (unknown [193.209.119.1]) by tss.iki.fi (Postfix) with ESMTPSA id B62C32B3CC9 for ; Thu, 31 May 2018 13:05:47 +0000 (UTC) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 31 May 2018 16:05:46 +0300 References: <152749742501.4778.7310627718881041122@ietfa.amsl.com> To: extra@ietf.org In-Reply-To: <152749742501.4778.7310627718881041122@ietfa.amsl.com> Message-Id: <27F0B121-BA01-4841-B93C-270DFD2E47FE@iki.fi> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap-objectid-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 13:05:51 -0000 Review: OK, but unlike MAILBOXID and EMAILID, it doesn't say if = THREADIDs can change. I suppose it should be the same that in disaster = recovery those might have to be rebuilt. But would that require having a = new MAILBOXID or UIDVALIDITY to the mailbox? Actually, the question = applies to EMAILIDs also. If clients see the same MAILBOXID and = UIDVALIDITY, they might become confused if EMAILIDs or THREADIDs change = under them. From nobody Thu May 31 06:29:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173312D95A for ; Thu, 31 May 2018 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=qftiq8vA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LZGig1s7 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 jC_q2AqIfzvl for ; Thu, 31 May 2018 06:29:08 -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 6792112E042 for ; Thu, 31 May 2018 06:29:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D0DA321D0F for ; Thu, 31 May 2018 09:28:59 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 31 May 2018 09:28:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fm2; bh=LLDzw7clQ05XMSN+7 sC0U8BiAl7S6TlHNn39HXzIZjE=; b=qftiq8vA7TpFdUz+u+1DWrnKYYIPWaFZk lRjqpiR2aC050HnjtbveNiJJdgYAX6b69MZqcLvkHu30nlRh8IVTqwXr4NwwT3Kt Tnir8DlpSLwOCGIHyc8Rw8VzpcrZw4WSNrRJrRg6SEwad6iM1b5J8f7W5xB9UFFT bs8EGLx8Vy6nYx8fdh0kDtKHoj4bluCmgOx2JPHdNZT9RE/z0IicasGPO9KJAQOn XkS9424q7Lb9YPPI/n5SQzK4miWaIyvIG5RXziQ/FtMwMHXG/rkHhUJBckVNpPdv B0ymSNbop3+Xe8QnDFC8m0wLfiDb2RP82m7Ks36x1doFGr8OWwmaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=LLDzw7 clQ05XMSN+7sC0U8BiAl7S6TlHNn39HXzIZjE=; b=LZGig1s7Kz/ULhfvAPwA7a iF8OCF/Y92qu6urfd5DQ0PMEI/1Hgh+OTNZSy/SHENpUJ+vS4dwGcYDXdjJjVILl 6hqowhTE4DB0iL5lO319FdD/T1vp1N4IJQCHrMZp0bm+OeUnnO1gdJqXUFKjvCQI oSDG8Q/ysCHg/IJjCunJEoE/5IXqFF/hXqnFAx6W9HrVY1TLITngOC5xzAEvCXaO 74ghvN3/IMu3BGgGJySRpubuKIO+/ePkg3/CYnnSC92NMd77j1ZCbB+t5AcG8Ufn xtqSFzEAoFp+/PuPwfeIClXU+7frsXNcnsYXb8zxohusqnxNg794xr6OAqtnS68A == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8C352621DC; Thu, 31 May 2018 09:28:59 -0400 (EDT) Message-Id: <1527773339.931650.1391763624.638E35D4@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15277733399316500" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 Date: Thu, 31 May 2018 23:28:59 +1000 References: <152749742501.4778.7310627718881041122@ietfa.amsl.com> <27F0B121-BA01-4841-B93C-270DFD2E47FE@iki.fi> In-Reply-To: <27F0B121-BA01-4841-B93C-270DFD2E47FE@iki.fi> Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap-objectid-03.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 13:29:11 -0000 This is a multi-part message in MIME format. --_----------=_15277733399316500 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hmm, yeah - good point. It's 11:30pm here now, so I'll look at it later. Have a reminder for myself here: https://github.com/ietfextra/tracking/issues/32 On Thu, May 31, 2018, at 23:05, Timo Sirainen wrote: > Review: OK, but unlike MAILBOXID and EMAILID, it doesn't say if > THREADIDs can change. I suppose it should be the same that in disaster > recovery those might have to be rebuilt. But would that require having > a new MAILBOXID or UIDVALIDITY to the mailbox? Actually, the question > applies to EMAILIDs also. If clients see the same MAILBOXID and > UIDVALIDITY, they might become confused if EMAILIDs or THREADIDs > change under them.> > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15277733399316500 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hmm, yeah - good point.  It's 11:30pm here now, so I'll look at it later.  Have a reminder for myself here:



On Thu, May 31, 2018, at 23:05, Timo Sirainen wrote:
Review: OK, but unlike MAILBOXID and EMAILID, it doesn't say if THREADIDs can change. I suppose it should be the same that in disaster recovery those might have to be rebuilt. But would that require having a new MAILBOXID or UIDVALIDITY to the mailbox? Actually, the question applies to EMAILIDs also. If clients see the same MAILBOXID and UIDVALIDITY, they might become confused if EMAILIDs or THREADIDs change under them.

_______________________________________________
Extra mailing list

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


--_----------=_15277733399316500-- From nobody Thu May 31 09:53:44 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EE612D7E5 for ; Thu, 31 May 2018 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 yDcpJEcDbzvx for ; Thu, 31 May 2018 09:53:41 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045EB126D45 for ; Thu, 31 May 2018 09:53:40 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 25222CEC001; Thu, 31 May 2018 16:53:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1527785618; bh=IWqLBUcWjZbR0oSTUDoIhrDcQtfM0BFBMdvGke6M1o4=; h=From:To:Subject:Date:References:From; b=Vuqsru0q/YfLdVsAttf/hBb+X66iJ1LDNmvDMswEVm84CGZg7sRD0q3/W30rS2Z0C hh7e1iwxMtn8qeTJWoVw/Mdd+0cvR8dRqGS/VMZ/rwF8RUd8nu0D7PPajODR4yuGvg 6MIzDPKKERjomIRGYVy1PUgTAafWs17EUOF0HLlM= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1527785617-21138-19769/11/1; Thu, 31 May 2018 16:53:37 +0000 From: Arnt Gulbrandsen To: extra@ietf.org, Michael Slusarz Date: Thu, 31 May 2018 18:53:36 +0200 Message-Id: References: <1527560849.2219431.1388559464.58495900@webmail.messagingengine.com> <7ac0a7d1-85f0-462e-b2d7-7d187c28b160@gulbrandsen.priv.no> <156411865.17416.1527706993613@appsuite.open-xchange.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Extra] Spam reporting via IMAP X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 16:53:43 -0000 That is what I too meant to suggest. Except that I do not really care whether it the junk mailbox or a flag. Either way is fine. Arnt From nobody Thu May 31 17:20:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D38120227 for ; Thu, 31 May 2018 17:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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=kwfkxDrT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ishLUNmh 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 v2Zx8j-Niudl for ; Thu, 31 May 2018 17:20:09 -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 54D8A12025C for ; Thu, 31 May 2018 17:20:09 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B057C21E06; Thu, 31 May 2018 20:20:08 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 31 May 2018 20:20:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=9vdZ0U2I7Di3p83MGoQA9rI85XO8t OTjmLUZXGeWn3A=; b=kwfkxDrTCEJPuttFzmI3KXdOBrtWAD5ybml3ZXmEZGrKY Rhm0EWaiQvbxRHhg6zL5tvCVgLxEyIkzinYlN2UpB07T6ci4nz9bFAi2rZgIjjhR KHa94dijN03L9otyBJKxKonlUyAULFpCE85QqFfCKgcfj2D1BVXI4rcuQ29dU6eR ymdehGnvAAlceH5AqZlhDqeohz7TcFKvHzZAB0BC12Xwc6avWLGLAWbE91SSBdk+ FcRzihTM4tCt55zgk0giTa6NFH0054T7UKG+xuqw54mNwUlNHA37gJKMCxG3MfiD 1HnxgSGE7OVR9hrIS0AuqrjtFa5au49Q2V5LqQpVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=9vdZ0U2I7Di3p83MGoQA9rI85XO8t OTjmLUZXGeWn3A=; b=ishLUNmhKUYTIJUNkDCjaLT/E1z4DqztDeoyl3pmQ9EP0 /sXnMtdD/ImIfwd3YYUgzW0X6l40TfAlvkCIY4x0YiXnsJBawlRlDeftcgDAgA1I mwMbltqSl7o17Uda0SI5jVo4NPhofFPFofo/U9+n/Beisgwa5/G5Ej95e9oUZTv5 fRILn2otE7MyGjGJ8r7lEM3T4g/7GLnLOqcxOOkRB/xOebhE4Bqz0qdjKg7CDXRy 80aHeWAuvgURzOVkCq8fiN8YCpMsKPY9LsS/Ze23Vsam0t0X874WQQfftilOrZIx 7WdHsUb3aJ6wY/A7GBD9Q98HyarVmMmp61nTerIHA== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 86D4C9E0C6; Thu, 31 May 2018 20:20:08 -0400 (EDT) Message-Id: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org Cc: Stuart Brandt MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152781240816246233" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 Date: Fri, 01 Jun 2018 10:20:08 +1000 Archived-At: Subject: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 00:20:12 -0000 This is a multi-part message in MIME format. --_----------=_152781240816246233 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've had an internal feature request at FastMail for something which requires us to implement the REPLACE extension first drafted by Stuart a few years ago: https://www.ietf.org/archive/id/draft-brandt-imap-replace-02.txt This work seems entirely in scope for the EXTRA effort, and I hereby propose that the EXTRA working group adopt this draft and continue to work on it. I'm happy to co-author the document if Stuart is unable to continue, or assign somebody at FastMail to work on it! Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152781240816246233 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've had an internal feature request at FastMail for something which requires us to implement the REPLACE extension first drafted by Stuart a few years ago:


This work seems entirely in scope for the EXTRA effort, and I hereby propose that the EXTRA working group adopt this draft and continue to work on it.  I'm happy to co-author the document if Stuart is unable to continue, or assign somebody at FastMail to work on it!

Cheers,

Bron.

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


--_----------=_152781240816246233-- From nobody Thu May 31 19:42:33 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C86126C22 for ; Thu, 31 May 2018 19:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 gTysg8-MocHk for ; Thu, 31 May 2018 19:42:29 -0700 (PDT) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.83]) (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 3944E126C0F for ; Thu, 31 May 2018 19:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527820948; bh=Qr3d3k305xUS+fIPw9KuIifs+0tVCSWAY2hkaPWmUCs=; h=From:Date:Subject:References:In-Reply-To:To:From:Subject; b=sVy5t218E0SPp3D/9r/onw5LwyjCg9oWgW4PpYjizN+Am9xmvUeQlP7dLld5fem0mXBbFcy9PndX9Pl5vEsBfbDSBYb9QGcj9te8j7zhEt+bKRCDl3wX+JA6lDiWnMo6TA1vkK10P2wP4x5X2kZp9wdyA9auAhYuQ8kS2FtrczHCsBGJ8nWjt/RP55aiIJ4O15/7L7IIaKLvoo0TQZSUKpMYwtg4trS55eUKk+QF1hwJ2xTwUDTMPwZAoGqzL+3BlQVWxPIY5D9mQW5wz++EDwMK7qYj2WQBQHcFqMw2MGGgys84iGx81igXG5hI0cy2/e+XcjHXaIXxvfY8fXIeLQ== X-YMail-OSG: A4I_MnUVM1n6QM_6jM.ssnUTOHMsdrYloHXs7H.7jOEtB6DMO4qStT_jlqHwEsX dueZxxvcAxUswKHsNoWRVOIt5R8wwueBnTxl3FKoMLqC7UE.7uQoZ61nkS0FUfbhTVDOw1cvXjpa zCrhdc1vK2.9EDRZdBHLoh.3AKJG32qIm9FbGsNcZbJu6IvXd8SISouj75YQJ5g_S92AVG20x32G _zCkCbarNkxxU43Mw2r3wkvRz4bvqGjEaoTXg_yfPld3gtD2vcOTI0BuZzr5eNaELtMpMp6Lw3et DWsX0EAW3lgy59qL_zW1yVtcoQOdE_ZoRj4eC0rscOSFKf.Mggr92ThXdi3ka_G78Cm1ikO2qA3L 74yRrDis8ugDFAbuDJoXGvyiHQ0GXQNALyzTpRm8oUnHlFkf7Gls1q82yaO34eg5B41.bBn0c7u4 bDEgrTKopgZnnU8ChlQSFliD46KfXmW.J2VrnKrOVlJun3rqSRwRj.JHSvLh7mdMGxmPcGdT8rfo DQs6ElCZtAngy4vVR_4ufCLjnpt6jvi42Nq5BG3zOAu1S97bCIGplPb9R3JABcy.aKWsmOFICh3g v6MwUGSvvM.giZPktTOZIxB6.VGMHPlXlaeI5_ENXA0P5LOu_CnTaFWz5dklVsKOeEih6YiBBpqD CKkV2Vl.i7VtjoDMp Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 02:42:28 +0000 Received: from 66.sub-174-204-19.myvzw.com (EHLO [100.102.199.206]) ([174.204.19.66]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 716f560b71f50f8791f6bb9c0c19ad8d for ; Fri, 01 Jun 2018 02:42:27 +0000 (UTC) From: Stu Content-Type: multipart/alternative; boundary=Apple-Mail-CD53A626-04D8-44CC-B194-6D5B049B50FD Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Thu, 31 May 2018 22:42:26 -0400 Message-Id: <4E7A41E7-4A1F-4248-B4E3-614F94CFC664@aol.com> References: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> In-Reply-To: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> To: extra@ietf.org X-Mailer: iPhone Mail (15E302) Archived-At: Subject: Re: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 02:42:31 -0000 --Apple-Mail-CD53A626-04D8-44CC-B194-6D5B049B50FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m happy to reincarnate REPLACE and/or take on a co-author. I=E2=80= =99ll work with Bron to clear up some of the inconsistencies in untagged res= ponses as they relate to Condstore/Qresync and submit a new draft version if= that=E2=80=99s ok with others. - Stuart > On May 31, 2018, at 8:20 PM, Bron Gondwana wrote:= >=20 > Hi All, >=20 > I've had an internal feature request at FastMail for something which requi= res us to implement the REPLACE extension first drafted by Stuart a few year= s ago: >=20 > https://www.ietf.org/archive/id/draft-brandt-imap-replace-02.txt >=20 > This work seems entirely in scope for the EXTRA effort, and I hereby propo= se that the EXTRA working group adopt this draft and continue to work on it.= I'm happy to co-author the document if Stuart is unable to continue, or as= sign somebody at FastMail to work on it! >=20 > Cheers, >=20 > Bron. >=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com >=20 >=20 --Apple-Mail-CD53A626-04D8-44CC-B194-6D5B049B50FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m happy to reincarnate REPLACE an= d/or take on a co-author. I=E2=80=99ll work with Bron to clear up some of th= e inconsistencies in untagged responses as they relate to Condstore/Qresync a= nd submit a new draft version if that=E2=80=99s ok with others.

- Stuart



On May 31, 2018, at 8:20 PM, B= ron Gondwana <brong@fastmailtea= m.com> wrote:

Hi All,

I've had an internal feature request at Fa= stMail for something which requires us to implement the REPLACE extension fi= rst drafted by Stuart a few years ago:


This work seems entirely in scope for the E= XTRA effort, and I hereby propose that the EXTRA working group adopt this dr= aft and continue to work on it.  I'm happy to co-author the document if= Stuart is unable to continue, or assign somebody at FastMail to work on it!=

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br= ong@fastmailteam.com


= --Apple-Mail-CD53A626-04D8-44CC-B194-6D5B049B50FD--