From nobody Fri Jun 1 07:43:30 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 A975D12D885 for ; Fri, 1 Jun 2018 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 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_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 Q8q7SQCLUSzD for ; Fri, 1 Jun 2018 07:43:27 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 2BA7612D883 for ; Fri, 1 Jun 2018 07:43:27 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id h5-v6so24423810qtm.13 for ; Fri, 01 Jun 2018 07:43:27 -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=/eSZUvnxJk3mSTlcJ7qbxiCmBv2ySznfbsw0vAzssBI=; b=aTLPzgSYGMY5ofocSIwdie7Q/TlWCFFzVKWwSLB8u/qNyCN2S81luXmft72VuIl+d9 kBAu9GDhltB/si0O9oO7QOCy/Of7t9AJdsymHXNBFaMSW0LpjkdbD+D8++oczxXlVYVh KQtDm9BwhIUjOqmEwLylq9/Y9CFmz9LVW9RO11y4CBah2nKXNCDS56U9+Z7mNNQLadKT BA8TrZUgdLKkPpTDL1wh7/O/VNgZkSVBtk8MYP5hKgFu73yRujNIzL3K5K+sMiQSnMj6 7dbzQVhI0WP3FJswx74N0zoz7LNrE/f9eypY/NscWUVhkF0BGR0sVuRLQUDY38cnOG4T Ja7g== 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=/eSZUvnxJk3mSTlcJ7qbxiCmBv2ySznfbsw0vAzssBI=; b=NdHW9IxzxHYKtcl+kamIFEoIIEhoPsirDBUlSLJ5VgthATBnukFctBkavh4szQpdZ5 UzQjxsU3jZijMb62w9vgaPvM8OwXvqmCZnXh2RLywLWdS4+UGkdaQ2Z8kCqRPRXWIFAz k+Ky11igXb8zgJIoIEr8a803oIdS3eMnzokCX04b39EbmvHXBmq2GJFc1TI5JbHzSNGi FuyNR/JOtCcMrjyWxwG3D7V//YZixed474Djsc80E9zSZfdwW5v+BQ6C/z/hTLmt+obU o/NNQLZLazpvGAlJWokhGlIn1WNgxR4nd1508Ps1MjBLu04+i6L4VUM9ccKFz0lTLTja sYwQ== X-Gm-Message-State: APt69E2pOOgHglbwbTts1oBgd6lEoc5RzN2mQzCOHZ30K0yMa7nITcXu dIZe99fmjDsoBCL23IBLOWa2LDCZTKZRe0qgX38= X-Google-Smtp-Source: ADUXVKK2TaMEwuxZPfK2aQ2bjrM8yXG/xp9jEOZ8Zu5FY/u8PjM8fwjpX2eGJYEbDw0d3gGHPpIUHWBsZHKlJfAQhkU= X-Received: by 2002:a0c:b665:: with SMTP id q37-v6mr10743196qvf.43.1527864205899; Fri, 01 Jun 2018 07:43:25 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 2002:aed:2a73:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 07:43:25 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Fri, 1 Jun 2018 10:43:25 -0400 X-Google-Sender-Auth: 602m8z5BnCF1zVCbpeZEErKkQgQ Message-ID: To: Alexey Melnikov Cc: extra@ietf.org, Chris Newman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [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: Fri, 01 Jun 2018 14:43:29 -0000 > 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. I don't think that's viable. If the client sends "UNAUTHENTICATE FLARB", the correct response is BAD. And a response of BAD in IMAP always means that the command was not done. On the other hand, according to general IMAP rules, if the command is properly formed, "UNAUTHENTICATE" with no bogus parameters, then BAD is never a proper response if support has been advertised. And this already says that NO isn't a valid response. I'm not sure what you're really looking for. Maybe this?: << BAD - command unknown or arguments invalid; nothing has been done and the session's state is unchanged >> Barry From nobody Fri Jun 1 13:01:53 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 C358B12DA49 for ; Fri, 1 Jun 2018 13:01:39 -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 mDUSNLRn0vRi for ; Fri, 1 Jun 2018 13:01:38 -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 D80FC12D94D for ; Fri, 1 Jun 2018 13:01:37 -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 w51K1ZHT142304; Fri, 1 Jun 2018 20:01:35 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=vQm0KEg45TGMZRtlxb9KskAwBm/fC8iEpv9GJRB/DVA=; b=Uoknh0JIcX/qLhuQLAzB7ioz+sDNzScK17HrMDqpIPj+aZ9KZP/Rjy+mPMf0VYxlLALf NSq3L056ZUwqfzBpK/7ENGZWdnxJIgASL/27ST68sCMNtedpPdCkdliVN+ZVxYquhPaM 1G4Asgs5A4W2ZP1bhr8iB+mwpqkkpiM2Maci6OwwvpH8UPFf3bAnrw9zwkVkAvi+k86n q2YhwRCMJB1Ya/GNgcdSei1DcFY5uqgJmIFK83UKYFVBzSXExM6fkH2DC0AEs1IsxITx bSzNA2GxxmK0LAOQL8FIgNO/XOOISLfMhWS4zkPPleJ6NGZ5RIPp5K7ds6L4/dFhTYfO Cg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2janje5xu8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Jun 2018 20:01:35 +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 w51K1YFl024884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Jun 2018 20:01:34 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 w51K1Xe8011163; Fri, 1 Jun 2018 20:01:33 GMT Received: from [10.145.183.96] (/10.145.183.96) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Jun 2018 20:01:33 +0000 From: "Chris Newman" To: "Barry Leiba" Cc: "Alexey Melnikov" , extra@ietf.org Date: Fri, 01 Jun 2018 10:33:58 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <11513B46-0BD2-44B1-8886-F0168A487F53@oracle.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8911 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=978 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806010231 Archived-At: Subject: Re: [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: Fri, 01 Jun 2018 20:01:44 -0000 There's already text about why "NO" is disallowed. I can add text to specify that a BAD response is only permitted if the command syntax is incorrect, the protocol is in the wrong state, or the extension is not advertised. - Chris On 1 Jun 2018, at 7:43, Barry Leiba wrote: >> 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. > > I don't think that's viable. If the client sends "UNAUTHENTICATE > FLARB", the correct response is BAD. And a response of BAD in IMAP > always means that the command was not done. > > On the other hand, according to general IMAP rules, if the command is > properly formed, "UNAUTHENTICATE" with no bogus parameters, then BAD > is never a proper response if support has been advertised. And this > already says that NO isn't a valid response. > > I'm not sure what you're really looking for. Maybe this?: > > << > BAD - command unknown or arguments invalid; nothing has been done and > the session's state is unchanged >>> > > Barry From nobody Mon Jun 4 08:57:35 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 AFCBE127422; Mon, 4 Jun 2018 08:57:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152812784871.27494.14679207696056136209.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2018 08:57:28 -0700 Archived-At: Subject: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-extra-imap-unauth-00=3A_=28with_COMMENT=29?= 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, 04 Jun 2018 15:57:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-extra-imap-unauth-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question, however, I really don't know much about IMAP: Would it already help to just use TLS1.3 0-RTT session resumption instead? From nobody Mon Jun 4 13:25: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 BDE82130DC0; Mon, 4 Jun 2018 13:25:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152814392277.30714.8638295088947635978.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2018 13:25:22 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jun 2018 20:25:23 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-unauth-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate; there seems to be at least one usage of a lowercase keyword. I do not remember seeing a response to the secdir review, which raises an issue that is probably worth addressing (even if it is largely editorial). I have a few other comments/questions, that happen by chance to all occur within Section 3. This command directs the server to reset all connection state, except for state at the TLS [RFC5465] layer. 5465 is IMAP NOTIFY, and a short Hamming distance from 5246 (TLS 1.2). Though I note that TLS 1.3 is in the RFC Editor's queue... 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. "terminate" applies only to outgoing messages, presumably? (Should this be made more explicit?) A similar thing applies to COMPRESS as enumerated in Section 4.1. Servers MAY choose to advertise the UNAUTHENTICATE capability only after authentication has completed. As a result, clients need to issue an IMAP CAPABILITY command after authentication in order to determine the availability of UNAUTHENTICATE. Is this because the ability to reset state may depend on the authentication mechanism used? From nobody Tue Jun 5 12:53:22 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 EBD2413114D; Tue, 5 Jun 2018 12:53:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152822840095.19429.13740626375220734458.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2018 12:53:20 -0700 Archived-At: Subject: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 19:53:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-extra-imap-status-size-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Just as an aside - all the EXTRA drafts I'm reading this week are great examples of protocol extensions. I'm glad I balloted Yes to create the group!) I was somewhat confused by the first couple of sentences. This document extends Internet Message Access Protocol (IMAP) [IMAP4rev1] with a new capability called "STATUS=SIZE". To determine the total storage size of a mailbox, an IMAP client currently needs to retrieve all message sizes individually using the FETCH command with the RFC822.SIZE data item. Is the "total storage size of a mailbox" the "total size of all messages stored in a message store"? "Total storage size of a mailbox" seems more like a capacity number than a usage number. I see "total size of the mailbox" used in more than one place, but I think just the clarification on first use would be enough. And my apologies if everyone who has ever worked on IMAP knows what was meant ;-) From nobody Tue Jun 5 13:52: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 5B3F8131179; Tue, 5 Jun 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, 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=ClkapDP5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mgX1bFzy 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 jHrb9dCElwop; Tue, 5 Jun 2018 13:52:10 -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 F3586131176; Tue, 5 Jun 2018 13:52:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B901921175; Tue, 5 Jun 2018 16:52:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 05 Jun 2018 16:52:05 -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=GeN2feaz42Ycj7vZuwuf7OVEjCpdu 817C7bK7He+Ab4=; b=ClkapDP5rw1jifx/LEopceydjT+yghmC6dTMPuSMuLf5o q52AsC+O8GE9XSl/6LLnzxW/gbr2g/Cw3QlnBVeqTi/Vs4UyATAyKrh14LqgPcu4 IMtTpHgYlBv19Lv8fa5zhMyrFsYMc9/Xg2KSJH6pezR1g5qYnv9qHvgN6cnjLM7C OOt+ougXCOuWF9PJaXE5L7FzavZxb0zOcZmm+SWrQ846M7mLlLG/Ocqx2VzyXHue ZfwQE/I9gHoFasqJ2uCiDQeFyDrmYtkJAzlFCFXZWhQ2M5iL9uHP77AFMFeXPZUr NwAswNSatkkW4Rhv9l6W6pCA0LinCu3CFcjUJd9ZA== 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=GeN2fe az42Ycj7vZuwuf7OVEjCpdu817C7bK7He+Ab4=; b=mgX1bFzyFgbKY/y45IRDsH J3ifD8FpYCQb7T4T2ydgJhwaLEHX3asA5k3frdnuHFFqAw6t0OIwiPOcT/7LztI3 5LFgOaDyzkOOMllzDYLqYddEHwfczbwyesMBYZCRAvDFUsyv35OLZwLluNxzQGWM id9oyhybQYJrPUX2R2UA5X5hHmE4ssiIh4N64cKKJW//VEXuQ5AlyL7a1M7dLQHq jt8Ux53hIW7MWXD9hpcjpq7osLuzvxQTqjegnWaoNYe9v9abXgrYePBud2MYq80d QaiKshzLS7CgaQ2Uwb06hMwhFAiX5p+7cQitu2f2W/lZmCgB4QJ3GiqJr33Pk/YQ == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from [10.239.108.55] (unknown [85.255.234.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E75110265; Tue, 5 Jun 2018 16:52:05 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (15D60) In-Reply-To: <152822840095.19429.13740626375220734458.idtracker@ietfa.amsl.com> Date: Tue, 5 Jun 2018 21:52:03 +0100 Cc: The IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4219A4CD-074D-4B3E-BD42-D74138A83CAD@fastmail.fm> References: <152822840095.19429.13740626375220734458.idtracker@ietfa.amsl.com> To: Spencer Dawkins Archived-At: Subject: Re: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 20:52:12 -0000 Hi Spencer, > On 5 Jun 2018, at 20:53, Spencer Dawkins w= rote: >=20 > Is the "total storage size of a mailbox" the "total size of all messages s= tored > in a message store"? No. In IMAP a user has access to multiple mailboxes and they may contain dif= ferent messages. So =E2=80=9Cmessage store=E2=80=9D !=3D =E2=80=9Cmailbox=E2= =80=9D. > "Total storage size of a mailbox" seems more like a > capacity number than a usage number. Hmm. Capacity is typically called =E2=80=9Cquota limit=E2=80=9D in IMAP (if Q= UOTA extension is supported) (*). (*) - oversimplification for the purpose of this conversation. Best Regards, Alexey From nobody Tue Jun 5 14:15:07 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 812A1131159; Tue, 5 Jun 2018 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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=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 FzF1O5-m6Jq0; Tue, 5 Jun 2018 14:15:00 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A946130DF0; Tue, 5 Jun 2018 14:15:00 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id v17-v6so1276175ybe.7; Tue, 05 Jun 2018 14:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6RWOx/IEutNY4VuNnFYgSeKKh3TS3mvc1hG3Gtcmz0=; b=HINL3vJ3+5b9klzkGm1mBNS20naGZ/uisWSr0j+WUlQdLP0PosdZAqbTBOAmlMWjrI h4o2M20TMHcpp5hNAr5RF7oN5ckoAJVgGVkKNtN6Vn8ornjWQdRvxx1JRIxSssg60MhT CASXCOKcP9kla2Ev3W8vcJNEP/yFIt7HaAwYnNmuiBQ2iD2/9dfKNnfyrWUheDB35Qg5 qU6V0TL8BE905gJ6dys1jBxNxoj2c5GZklWkSVp2v7Z4del3XwLr8BhEG5EUF97vZ86/ rGDhOCA20a4TRkI0MDCAJDtuIpkx+6C2V0e0OeIPY5sUUG/4OlmvcV53Fhg238XaQKmf qaiA== 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=E6RWOx/IEutNY4VuNnFYgSeKKh3TS3mvc1hG3Gtcmz0=; b=nPClGHS6LX3NOFQs8Hu+035BU9yf7AbZUaLXOYc9pLYppzflv7HeXASqwMbHbOovxh 1/2u6OmbSIgqBaSLlSMG25Bpnme9+i+JiKdjEm8F+az5mk9ADd2bIl2Uk7Z0NIZjZn2n K67RgQqkwql26PA+jlWDHFQoDJjdkPeSs/ViOmc8GW72SL5AntbGbCA3HfkXhpOKjJ6S QA8O46IPmsE310ybbHxc2bVHCLdobh2wwweUO940i90jNyH4b1Oo3U1gCbPC9fLezrBD foNwO0mS/nx3NoA+pP3DOigu6vgBYXTCloeMfutwhMuniLgBdwF8HhLqIZwHl2SOvRid gOCA== X-Gm-Message-State: APt69E2tRVKHAUTdCspQRRxlzPT3iG+bxi7x1h4gHuQlsfDONfftr2hb FrXmUbiFar79bdICHGC4dvxoYbbJLqiQW63CSV0= X-Google-Smtp-Source: ADUXVKLOqBlUgGy4rlO2FtK7t2Gqj8aLPf5BIWIgFe3E3BO4/WK8BZaDt9eXnmDggmGkUc+cTaeK27FUYyCP7KMh3f4= X-Received: by 2002:a25:ba48:: with SMTP id z8-v6mr164597ybj.110.1528233299207; Tue, 05 Jun 2018 14:14:59 -0700 (PDT) MIME-Version: 1.0 References: <152822840095.19429.13740626375220734458.idtracker@ietfa.amsl.com> <4219A4CD-074D-4B3E-BD42-D74138A83CAD@fastmail.fm> In-Reply-To: <4219A4CD-074D-4B3E-BD42-D74138A83CAD@fastmail.fm> From: Spencer Dawkins at IETF Date: Tue, 5 Jun 2018 16:14:46 -0500 Message-ID: To: Alexey Melnikov Cc: IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000eeec5b056deb8a39" Archived-At: Subject: Re: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 21:15:02 -0000 --000000000000eeec5b056deb8a39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Alexey, On Tue, Jun 5, 2018 at 3:52 PM Alexey Melnikov wrote: > Hi Spencer, > > > On 5 Jun 2018, at 20:53, Spencer Dawkins > wrote: > > > > Is the "total storage size of a mailbox" the "total size of all message= s > stored > > in a message store"? > > No. In IMAP a user has access to multiple mailboxes and they may contain > different messages. So =E2=80=9Cmessage store=E2=80=9D !=3D =E2=80=9Cmail= box=E2=80=9D. > OK (you mean there are things about IMAP I don't know? :-) I should have asked if the "total storage size of a mailbox" is the "total size of all messages stored in a mailbox"? > "Total storage size of a mailbox" seems more like a > > capacity number than a usage number. > > Hmm. Capacity is typically called =E2=80=9Cquota limit=E2=80=9D in IMAP (= if QUOTA > extension is supported) (*). > > (*) - oversimplification for the purpose of this conversation. > As noted above, oversimplification when replying to this ballot is entirely appropriate! Spencer > > Best Regards, > Alexey > > > --000000000000eeec5b056deb8a39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Alexey,

On Tue, Jun 5, 2018 at 3:52 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Spencer,

> On 5 Jun 2018, at 20:53, Spencer Dawkins <spencerdawkins.ietf@gmail.com= > wrote:
>
> Is the "total storage size of a mailbox" the "total siz= e of all messages stored
> in a message store"?

No. In IMAP a user has access to multiple mailboxes and they may contain di= fferent messages. So =E2=80=9Cmessage store=E2=80=9D !=3D =E2=80=9Cmailbox= =E2=80=9D.

OK (you mean there are thing= s about IMAP I don't know? :-)

I should have a= sked if the "total storage size of a mailbox" is the "total = size of all messages stored in a mailbox"?

> "Total storage size of= a mailbox" seems more like a
> capacity number than a usage number.

Hmm. Capacity is typically called =E2=80=9Cquota limit=E2=80=9D in IMAP (if= QUOTA extension is supported) (*).

(*) - oversimplification for the purpose of this conversation.

As noted above, oversimplification when replying to= this ballot is entirely appropriate!

Spencer=C2= =A0

Best Regards,
Alexey


--000000000000eeec5b056deb8a39-- From nobody Tue Jun 5 22:49:29 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 81EFD130EAA; Tue, 5 Jun 2018 22:49:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152826416552.19108.14728744876100973374.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2018 22:49:25 -0700 Archived-At: Subject: [Extra] Suresh Krishnan's No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 05:49:26 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-extra-imap-status-size-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am fine with the range being limited to the positive half of the signed 64 bit integer range, but I am not at all sure why this makes implementation any easier. Can you clarify? The message size is chosen to be at most 63 bits wide rather than 64 bits to make implementations on various platforms (such as Java) easier. From nobody Wed Jun 6 08:32: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 523D2130F5E; Wed, 6 Jun 2018 08:32:22 -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=cN/pWywu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GdBYGgmT 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 Jdxc0r6J7Eo2; Wed, 6 Jun 2018 08:32:19 -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 D0DFA130F5B; Wed, 6 Jun 2018 08:32:19 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2EEA421C35; Wed, 6 Jun 2018 11:32:19 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 06 Jun 2018 11:32:19 -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=Ox6n0lCeKkfEZqsd1hlFw+MJWTQqV C4k/yi8xlHelZU=; b=cN/pWywuCKaCwZgzEp1Qj/Zewd/MnLPfzzp/secvNREmH lQsNNsEmX+1XKpmluEhmnZA5P9NCviwINOesGBwrCiK6U/SR083R69WtcpVG6kO0 vUBQQE43o9UI2Qli9XDb8AQJN5kuYW+jwp6Pnlny5xFqMv2ezmNOk+vqc/JqpVUg ARsl/Tk75BFqcl9XpaF6CWiOkHOS3SsB/gx5sNnp2mcVfq6y0OW3bFcb/KR5yIu3 Ro2MdsV3vuI2ZB2ToAgTuRF3Yr0VGoVHDEISvBnsXitX2PxhX+/LBw6JJS8prXnj 4VOiwEtVl+2VLyFo83fDHKnjILtzRyp9UxwcE0pVg== 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=Ox6n0l CeKkfEZqsd1hlFw+MJWTQqVC4k/yi8xlHelZU=; b=GdBYGgmTmc43S1EfH+PGlK JEwd7KX9OvnPikuF5Ibl5i/eWQm7lGylMcfzHZlnLrxm48ByVo2Hgg8YHFjlcMKl 9cLH1N2VbDsww79TYrqv3KeX86j48nnA0S5Q3oleKocm+cb86BM4UytLRMWm9O7G PbKL4BuS66l0KTVDPcajW6BQOtEcFkoxqWJwV88jrEUAozeLa3WIBkWmQ1S3ZSQf wuUfwc22cVOq2H5GSb9hUiQzkBiHvahIU9vsaGjB5mDSSGvgOnrOD8jCpu9qoJzO bnBxhd5mEpa0MG02cCAjpXmD2kH8gHI87NlLRqNh7D/AdE6wHUbv1Ls6A3/dmmmg == 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 0430D9E105; Wed, 6 Jun 2018 11:32:18 -0400 (EDT) Message-Id: <1528299138.1196032.1398590392.27B3B88B@webmail.messagingengine.com> From: Alexey Melnikov To: Suresh Krishnan , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea In-Reply-To: <152826416552.19108.14728744876100973374.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 16:32:18 +0100 References: <152826416552.19108.14728744876100973374.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] Suresh Krishnan's No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 15:32:23 -0000 Hi Suresh, On Wed, Jun 6, 2018, at 6:49 AM, Suresh Krishnan wrote: > > I am fine with the range being limited to the positive half of the signed 64 > bit integer range, but I am not at all sure why this makes implementation any > easier. Can you clarify? > > The message size is chosen to be at most 63 bits wide rather than 64 > bits to make implementations on various platforms (such as Java) > easier. There are some client and server IMAP implementations in Java. Java doesn't have native unsigned 64 bit type, but it has signed 64 bit type, which can be used to store an unsigned 63-bit value. Best Regards, Alexey From nobody Wed Jun 6 08:35:07 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 CAFBA130F5B; Wed, 6 Jun 2018 08:34:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-extra-imap-list-myrights@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152829929682.6362.11349355679179770606.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 08:34:56 -0700 Archived-At: Subject: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-list-myrights-05=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 15:34:58 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-extra-imap-list-myrights-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Comment to the AD: All IMAP shepherd write-ups say "7. There have been no IPR disclosures for this spec.", however, questions 7 is about confirming that the authors are not aware of any IPR (that might not have been disclosed yet). Was that checked with the authors? Also sec 3: "This document extends the LIST command with a new return option [RFC5258], "MYRIGHTS", which allows the client to request all of the desired information in a single command. " The "which" clause is confusing to me... or should this also be attribute and "LIST-MYRIGHTS" here? From nobody Wed Jun 6 10:06:51 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 6A9F8130F83; Wed, 6 Jun 2018 10:06:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152830480442.6199.2704929407412846437.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 10:06:44 -0700 Archived-At: Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 17:06:45 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-extra-imap-unauth-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I was surprised to see normative language in this text in 4.2 since this behavior is specified elsewhere, not here: When a TLS [RFC5246] security layer is negotiated either via the STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY be configured to request a client certificate and IMAP clients MAY provide one. From nobody Wed Jun 6 10:08:57 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 624EF130F85; Wed, 6 Jun 2018 10:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Xo4u6lOQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NZc01S0w 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 lkFbb3zSjv71; Wed, 6 Jun 2018 10:08:46 -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 1F2BE130F7E; Wed, 6 Jun 2018 10:08:43 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5D7BF21E1C; Wed, 6 Jun 2018 13:08:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Jun 2018 13:08:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; 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=sXuwcyiokK/wJd50RLpOt9dWZTKeS XE+wYXTkF+3HDY=; b=Xo4u6lOQsWOKNs+guovO2IX4VJCigCwY5+pE6kKZPkQ7m e/5SQDsFJK0A/re9YpcTv7x21WgvnPCMtUJAQTG6UqbD0MNsDmV32y1R6NzTDjkw utL1K7cVUo1S5smqqnNM6T/UfpnIYEoC6paykgk9bxyF6ZeK9H2fHBWDNGCnhNRm VnXRMOkrNrgb1NLwff3PQtZwR2/KnF/x5yEdjavgRqex/GVDinkIHFH4JsN43qKE jOB5ZWrFv14y58KrSz4ORo73Q45dzjG0Re8Vjqrpbe8MLth1lJwyqyT2duD2GfiL mhkTfCWcrxCIz3S77/T+qkJHXK6j4khR5FHm4E6fw== 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=sXuwcy iokK/wJd50RLpOt9dWZTKeSXE+wYXTkF+3HDY=; b=NZc01S0w/5kH5lXbatb3kP oX6T8Pp2n7MRirr45YWtLLsCxcgiOfsOWR9c+HRThPDln1xR6I9UfANMbyj/O7q5 iNl+E3s+LEeYS02ShFbmYvE6F1Px7Ps5umEToJ2ELFAXfsPOrNUPlyHCGdGcAxzs NjVlthdb37sLpLozzWhM6SiWNCeFGiKJZ2M3UqzFzQBd9fokR6NgMkyHyi6o7vxt zqegWTD8iGfHyI+y5TjIsKBBPRG+fnRWOYcWrf/B6lQfWHH6IE2HQEPBDg7y4CEv ZmARJ3ft+bx6C7149ZhP1SlERG5dWejZD85LCdSKHhTnQv+wpdub+49YBhj6s0WA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id CAFE01025E; Wed, 6 Jun 2018 13:08:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <152697441137.8058.2828450475336330038@ietfa.amsl.com> Date: Wed, 6 Jun 2018 13:08:41 -0400 Cc: IETF Gen-ART , extra@ietf.org, draft-ietf-extra-imap-unauth.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <89B26768-E385-4472-A64B-1735B6C43AE6@cooperw.in> References: <152697441137.8058.2828450475336330038@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-imap-unauth-00 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 17:08:50 -0000 Roni, thanks for your review. I have entered a No Objection ballot. Alissa > On May 22, 2018, at 3:33 AM, Roni Even wrote: > > 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: > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jun 6 10:32: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 C56C0130FCD; Wed, 6 Jun 2018 10:31:43 -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=cooperw.in header.b=lOoHWcr0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VoCXHNXQ 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 s5ekOecWjNmQ; Wed, 6 Jun 2018 10:31:41 -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 32F01130FA8; Wed, 6 Jun 2018 10:31:41 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3DCB321DF2; Wed, 6 Jun 2018 13:31:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Jun 2018 13:31:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :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=Z8DJtnzC2gomzyEZ10UfYiFuSY+9Xo3jg7fLKLI85IU=; b=lOoHWcr0 Z55pcCD9ufvnDGknMmXr/v+WXL7oNwi+nd8sG2R+FY8lacZat1lmCN8sie16ZlLG vL7NFIoY9Zh7O9KA5OHVu9C38lCXFxdCqHKxBJTGxGZVry6dpI6QBX8pbuYTMgeF B++xaCGjfnUiSDWpMfy2czoyzsbtwjFoLJPOLgUC9N4d7O1qwiaD6k6FVtjWlHlw t3H39Li6xwM4MKebZaW+b8VXo36lhGfzscC1NpV9FFF6bDl1LqJ5j6IIqS8jhTqf TlCpTnVXIRW3+GolgtW21LPPZYkvf61tZdBrTdYXfaKluiJ7Vfhb6GzFMSfdnJlm e8sPUKJSxNs3pQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=Z8DJtnzC2gomzyEZ10UfYiFuSY+9X o3jg7fLKLI85IU=; b=VoCXHNXQPdNA/8ETZSIv85LLosa0QZq9vm3EWFAig30Yy N43dtFpLlEAna+ksQdjIbYIVo7f5hgTLNFEBeRzdaZ8IKDNFqsK8Wkkzi08d00G4 fVfvCTq8kQX4ntdBJjaJuVsN3b1WV8oLrD+AT/evNi0hm9DIwOSzq3k1CdCNh3AQ D2mg04tl8fhccKdv73uy1/3P7rot0rSJbfojiJVw0RvKQovdB53tYZ2IlCSwytAr gdrhJxTap3Y7va5p0gTlWV3bVepgxe34XHFlRGzR6+9kltCy3gUoQCmsdbV4qyW3 OmzR1aZtXTySXpRvqV/WgsvF0WZ6Re7gjLHzEnO2g== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D16010268; Wed, 6 Jun 2018 13:31:39 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A8754D5-6E9C-4A7A-9AF9-FF6DB28BBA35" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 6 Jun 2018 13:31:38 -0400 Cc: Brian Carpenter , extra@ietf.org, draft-ietf-extra-specialuse-important.all@ietf.org, gen-art@ietf.org Message-Id: <82FD3AA5-2AA3-44A9-8735-15922D6F5F70@cooperw.in> References: <152615967552.26371.13965440440763504881@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-specialuse-important-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 17:31:55 -0000 --Apple-Mail=_8A8754D5-6E9C-4A7A-9AF9-FF6DB28BBA35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, thanks for your review. Barry, thanks for your response. I=E2=80=99= ve entered a No Objection ballot. Alissa > On May 12, 2018, at 8:34 PM, Barry Leiba = wrote: >=20 > Thanks for the review, Brian. >=20 > > Thanks for making the reviewer's life so easy. >=20 > My pleasure. >=20 > > I wonder whether the special characters in the title will break > > some bibliographic software. Both $ and \ can have unexpected = effects. >=20 > I think we have others with such characters, but I didn=E2=80=99t = check. In any case, the RFC Editor staff will know, and we=E2=80=99ll = deal with it in AUTH48. >=20 > Barry >=20 >=20 > --=20 > Barry > -- > Barry Leiba (barryleiba@computer.org = ) > http://internetmessagingtechnology.org/ = _________________________________= ______________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_8A8754D5-6E9C-4A7A-9AF9-FF6DB28BBA35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Brian, thanks for your review. Barry, thanks = for your response. I=E2=80=99ve entered a No Objection ballot.

Alissa

On = May 12, 2018, at 8:34 PM, Barry Leiba <barryleiba@computer.org> wrote:

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.  In any case, the = RFC Editor staff will know, and we=E2=80=99ll deal with it in = AUTH48.

Barry


-- =
Barry
--
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/
_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_8A8754D5-6E9C-4A7A-9AF9-FF6DB28BBA35-- From nobody Wed Jun 6 12:11: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 D0DB412F1AB; Wed, 6 Jun 2018 12:11:48 -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=cooperw.in header.b=onfJYiRe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ck4nAhlo 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 mGNL3ADiVkxN; Wed, 6 Jun 2018 12:11:45 -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 CD5E312F1A2; Wed, 6 Jun 2018 12:11:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D487421CD0; Wed, 6 Jun 2018 15:11:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Jun 2018 15:11:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :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=0ZTzfAJWq6EmKPdzyXtYUlbb3lPsHmDd3Tko7ctJCeM=; b=onfJYiRe 3/GlKKzwyooUJtdm5rdFBbXQjE+6uA3MIlR4lW3MYX0brT7pyEoR+zQ8pf0Ix8za j+KYhmhEkQztX1FU6olA7b8ElMojGws4LkQ/eIxMEFnPvOYZNU3qs+laVO9tDBLI QKbNpuXFeqxRARVCwLdXlLbpIO1J4KcXI4QkaujqHwgTwqSbYDJE2wgfBSgPvR3o Ey+tS9MetHSgwXInpz/nCJzzvnLXQ5Sx0WCMYsdf/6ktcgcH/f6douYbX7CCnegb NKp8EZ3raN0gakjR3Inv6Pv3c+yobGdNl/bVV6nz6OVO4rwgdr018BxrcUQ+ujB7 k2Ue/v2C93Dyxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=0ZTzfAJWq6EmKPdzyXtYUlbb3lPsH mDd3Tko7ctJCeM=; b=Ck4nAhlo098jsqOyeYLsdE6VE1fcJj84Ia8oY5FLvGX9m /QgZqhDVGdRuk2QGXvtBWD/OhoYHnjObo7iP4h7wGBQUOCYqpst4+3lS2R0AMV6u 80X5bktn/ysVQ85kscZu/Wb6cXvk2wNruWgrrFcvIrzNmVujGor5BvZXgLPdKupt 2CPJ9sFD1sfwVshGuv7T++hAVXhClcS/LEqk9D5mMCId9MwZQpgw9UKlY7535kRd RTfSR1EzBrT5LUATY5GjRzAZw8fdQ87cSNa69kziE1vQPxkiKWnAwkll95zNek0L cfztLDAXjAQxg/0egJ5aKuXSIsSXrLTx0KsA/poqg== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id 3391910255; Wed, 6 Jun 2018 15:11:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_339EA94E-9A9A-4537-BC64-5F303151E8B1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 6 Jun 2018 15:11:42 -0400 Cc: Dale Worley , extra@ietf.org, IETF Gen-ART , draft-ietf-extra-imap-list-myrights.all@ietf.org Message-Id: <7C70023A-0993-49C8-A093-BB6C96E2CE64@cooperw.in> References: <152563640684.26784.16524702453597873690@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-imap-list-myrights-05 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 19:11:50 -0000 --Apple-Mail=_339EA94E-9A9A-4537-BC64-5F303151E8B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dale, thanks for your review. Barry, thanks for your response. Since the = comments are all editorial I think you can address them as you see fit. = I entered a No Objection ballot. Alissa > On May 17, 2018, at 9:42 AM, Barry Leiba = wrote: >=20 > > 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. >=20 > I don=E2=80=99t understand why you think it=E2=80=99s wrong as it is. = 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. While your suggestions = are also OK, I don=E2=80=99t think any is better. >=20 > > (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.) >=20 > 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 server implementation would want to send them in the = other order anyway, so it=E2=80=99s easier to set the restriction there. >=20 > Barry > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_339EA94E-9A9A-4537-BC64-5F303151E8B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dale, thanks for your review. Barry, thanks = for your response. Since the comments are all editorial I think you can = address them as you see fit. I entered a No Objection ballot.

Alissa

On = May 17, 2018, at 9:42 AM, Barry Leiba <barryleiba@computer.org> wrote:

> 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 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.  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 server = implementation would want to send them in the other order anyway, so = it=E2=80=99s easier to set the restriction there.

Barry
_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_339EA94E-9A9A-4537-BC64-5F303151E8B1-- From nobody Wed Jun 6 12:25:35 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 DD541130FBF; Wed, 6 Jun 2018 12:25:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-imap-status-size@ietf.org, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831312590.6354.842426932877743419.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 12:25:25 -0700 Archived-At: Subject: [Extra] Ben Campbell's No Objection on draft-ietf-extra-imap-status-size-02: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 19:25:26 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-imap-status-size-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §1, first sentence: Missing article before "Internet Message Access Protocol" From nobody Wed Jun 6 12:29:02 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 F06EE126F72; Wed, 6 Jun 2018 12:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831333298.6390.7794979021431498670.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 12:28:52 -0700 Archived-At: Subject: [Extra] Ben Campbell's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 19:28:54 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-imap-unauth-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §2: There are a few instances of lower case 2119 keywords. Please consider using the boilerplate from RFC 8174 instead. §4.2, first paragraph, 2nd sentence: The two MAYs seem more like statements of fact rather than new normative permissions. From nobody Wed Jun 6 12:32:32 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 24981120049; Wed, 6 Jun 2018 12:32:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-imap-list-myrights@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831354214.6394.13294871175987458322.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 12:32:22 -0700 Archived-At: Subject: [Extra] Ben Campbell's No Objection on draft-ietf-extra-imap-list-myrights-05: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 19:32:23 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-imap-list-myrights-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider using the boilerplate from RFC 8174 instead of 2119. The draft includes at least one lower case "may". That boilerplate also enables things like lower-case "should" rather than the more awkward "ought to", which has connotations of criticism or moral judgement in much of the US. From nobody Wed Jun 6 15:14: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 7FEA2130DE8; Wed, 6 Jun 2018 15:14:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152832328851.6185.16112395039757711940.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 15:14:48 -0700 Archived-At: Subject: [Extra] Martin Vigoureux's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 22:14:49 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-extra-imap-unauth-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, since you revise the state machine, shouldn't this Document update 3501? Thank you From nobody Wed Jun 6 17:17:58 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 20B78130E07; Wed, 6 Jun 2018 17:17:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152833067512.6390.5979669359099300361.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 17:17:55 -0700 Archived-At: Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 00:17:55 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-imap-unauth-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This mechanism seems useful. Thanks to the author for sticking with it. I support Martin's comment. I also have a tiny editorial nit: §8: > The original IMAP state machine was designed to allow a server > implementation approach where each IMAP authentication identity > matches an operating system identity and the server revokes all > administrative privilege onces authentication completes. Typo: "once" From nobody Wed Jun 6 19:13:11 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 BA90E130E14; Wed, 6 Jun 2018 19:13:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 19:13:08 -0700 Archived-At: Subject: [Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 02:13:09 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-specialuse-important-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work everyone has done on this document. I have a concern about an ambiguity that can potentially lead to interop issues between clients and servers that make different assumptions around \Important mailbox ordinality. The second example in section 3.2.2 and the use of the singular form "mailbox" in this passage from section 5 imply that only one mailbox is allowed to be tagged "\Important": > As noted in RFC 6154, it is wise to protect the IMAP channel from > passive eavesdropping, and to defend against unauthorized discernment > of the identity of a user's "\Important" mailbox... However, I find no normative text that indicates whether this is expected to be inherent to the mechanism, or whether servers can exercise discretion about allowing more than one mailbox to be tagged \Important. In particular, I want to ensure that no one develops a client that assumes that the server will prevent it from having multiple such mailboxes (relying on an error in the case that it tries to create a second one), and then chokes when it happens. Similar issues can arise with a permissive server and two clients with different notions about whether multiple \Important mailboxes are allowed. Please add normative language that either explicitly disallows this behavior, or explicitly allows this behavior. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract, Introduction, and Informative References section of this document all refer to the obsolete RFC 3348, while the table in section 6.3 refers to RFC 5258, which is the document that obsoleted RFC 3348. I think you want to make this consistent within the document (namely, I think this document should not mention RFC 3348 anywhere). --------------------------------------------------------------------------- §3.2.2: > C: t1 CREATE "Important Messages" (USE (\Important)) > S: t1 NO [USEATTR] Mailbox not created; an \Important mailbox already exists The server response in this example is too long for the RFC format; and, being a protocol element, I don't think the RFC editor can automatically fix it. Please consider either using a shorter message in the example, or introducing a documentation convention that allows wrapping of lines where the protocol does not. (It is common in SIP and SDP to add a line break and small indent, along with a note that such line breaks are to comply with the RFC format and do not appear on the wire). From nobody Wed Jun 6 21:23:43 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 7A5D0130E48; Wed, 6 Jun 2018 21:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-imap-list-myrights@ietf.org, Jiankang Yao , extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152834541249.6151.9563562789714333817.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 21:23:32 -0700 Archived-At: Subject: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-list-myrights-05: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 04:23:33 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-imap-list-myrights-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > 9. Acknowledgments > > This document is based largely on RFC5819. Please consider adding RFC 5819 as an informative reference. From nobody Wed Jun 6 23:54: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 DCAC5130E83; Wed, 6 Jun 2018 23:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 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.249, 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 Kjr8RuC_zuF1; Wed, 6 Jun 2018 23:54:19 -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 69D78130E82; Wed, 6 Jun 2018 23:54:19 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id k17-v6so1403358ita.0; Wed, 06 Jun 2018 23:54:19 -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=MQ2cZS0gAYV76liGbidHwlXRue99clvYIuTb0mSyuxQ=; b=vE+vYYykJNgLID04QWIlExc+tZ7WGBpS4Cg5v/LLKNPXJcP1nZqHeYQ9TxyJDRIaaL F1RsVCd2xebU9CoxD9zPQN/2h+4t+PhGm5LH1vyWa/dOU6yB+j+ltIqMpkEmpOVIZJ7g QFBlnl7DyA86Ga5WRjk/+VYS/6dLJI15P28XsGWtokYzy0+aRfEmLyz9qR8ylKkKACpN qa6FTPWrkmaoRvnF28Z25ecQCJc/ut9Ew6KJAFY2FIgXCigmj8r6yQ5ZE7TgPdyBFtC+ yNEAj5yniBrB3NILGOoimYFhsi73tT7rA9964KP5EiWM0ABYnAnUtAOo2EFctceH+gVp yXzQ== 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=MQ2cZS0gAYV76liGbidHwlXRue99clvYIuTb0mSyuxQ=; b=PfyVV263+X6a46uKUuFNCc6Ap90XH+0JKFq4n8YsKLu0pDsMb2SN4bkvq2/QOP4deq fHErt7vdxyihkWvRbgR53mBWhh8V6jv84sR7MNdpB0/onfWZre1f+4MPk+OghIfahnod M3q4T2exL3f8D/7VyoqJpNiY8oDy45QvdW0S3cAtpxQGXis1ZR+s5brqDqpYbxs3Pv0c 5rKgFbeIFpJVszOWiQuXAmD1wA6Mh5+GC/b1TFJZXwjJww6ppuoStonEzX3q0rLF9b4F 39ql+4w8mkVO27vPAOpJrTvG3xcUpO35kYr0EVpln4wTQM5mSBZ76h2tLVaMOPyBZn0I bA+Q== X-Gm-Message-State: APt69E3huGbBhvhPYOm7YJf6QhC8dZTkviqPjQCbpE09/b+SMS4SWCMy Qz8OdQIY3D5oFjYrrH12SxrCD0Wq9wZtBpHy9YYC21JY X-Google-Smtp-Source: ADUXVKLCv5fiGtD2XGB2csbGwLOB5gxKjnfGaTFNue5uTULPGfgTCPFDyOAkr71g66RKJXA9uKznrdEJ5/JFqK+eR20= X-Received: by 2002:a24:f007:: with SMTP id s7-v6mr873746ith.15.1528354458638; Wed, 06 Jun 2018 23:54:18 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:54:18 -0700 (PDT) In-Reply-To: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com> References: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Thu, 7 Jun 2018 02:54:18 -0400 X-Google-Sender-Auth: Jdoz54L2j2De-EQn9_ZkjClr15I Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 06:54:22 -0000 Thanks for the review, Adam. > Thanks for the work everyone has done on this document. I have a concern about > an ambiguity that can potentially lead to interop issues between clients and > servers that make different assumptions around \Important mailbox ordinality. It took me a bit to understand that you mean "cardinality". > The second example in section 3.2.2 and the use of the singular form "mailbox" > in this passage from section 5 imply that only one mailbox is allowed to be > tagged "\Important": ... > However, I find no normative text that indicates whether this is expected to be > inherent to the mechanism, or whether servers can exercise discretion about > allowing more than one mailbox to be tagged \Important. Look at RFC 6154 Section 2, and note the similar language throughout, then the penultimate paragraph: In most cases, there will likely be at most one mailbox with a given attribute for a given user, but in some server or message store implementations it might be possible for multiple mailboxes to have the same special-use attribute. That's intentional, and is as far as we want to go with it. I don't think we want to nor should say anything further in this document. > In particular, I want to ensure that no one develops a client that assumes that > the server will prevent it from having multiple such mailboxes (relying on an > error in the case that it tries to create a second one), and then chokes when it > happens. Similar issues can arise with a permissive server and two clients with > different notions about whether multiple \Important mailboxes are allowed. Please explain "chokes" in this context. I don't see what a client would do that would harm interoperability. The only effect I can envision if a server should allow multiple \Important mailboxes is that if a client gives a user a "move this to the 'Important' mailbox" function, the client will pick one, and different clients might pick a different one. The same situation exists with the other attributes (consider \Drafts, \Flagged, or \Junk), and we see no harm there. In practice, implementations do not allow multiple mailboxes with the same attribute, following the "in most cases" clause from RFC 6154. But if there turns out to be a good reason to allow it in some situation(s) or in some message store(s), we don't want to disallow it. > The Abstract, Introduction, and Informative References section of this document > all refer to the obsolete RFC 3348, while the table in section 6.3 refers to RFC > 5258, which is the document that obsoleted RFC 3348. I think you want to make > this consistent within the document (namely, I think this document should not > mention RFC 3348 anywhere). You're right: I changed the references in the registry and forgot to change them elsewhere; fixed now. The reason it didn't get caught is that the "obsoleted by" metadata is missing from RFC 3348 in the datatracker. I'll ask the tools team to fix that. >> C: t1 CREATE "Important Messages" (USE (\Important)) >> S: t1 NO [USEATTR] Mailbox not created; an \Important mailbox already exists > > The server response in this example is too long for the RFC format; and, being a > protocol element, I don't think the RFC editor can automatically fix it. Yes, I missed that too. Fixed (shortened). Barry From nobody Thu Jun 7 00:01: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 AA55A130E7E; Thu, 7 Jun 2018 00:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 n1I3io44qc0M; Thu, 7 Jun 2018 00:01:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AF611130E87; Thu, 7 Jun 2018 00:01:20 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5771Da8030126 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 02:01:14 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Barry Leiba Cc: The IESG , draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 7 Jun 2018 02:01:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 07:01:24 -0000 On 6/7/18 1:54 AM, Barry Leiba wrote: > Thanks for the review, Adam. > >> Thanks for the work everyone has done on this document. I have a concern about >> an ambiguity that can potentially lead to interop issues between clients and >> servers that make different assumptions around \Important mailbox ordinality. > It took me a bit to understand that you mean "cardinality". Ugh. Sorry, brain handed me the wrong word. > >> The second example in section 3.2.2 and the use of the singular form "mailbox" >> in this passage from section 5 imply that only one mailbox is allowed to be >> tagged "\Important": > ... >> However, I find no normative text that indicates whether this is expected to be >> inherent to the mechanism, or whether servers can exercise discretion about >> allowing more than one mailbox to be tagged \Important. > Look at RFC 6154 Section 2, and note the similar language throughout, > then the penultimate paragraph: > > In most cases, there will likely be at most one mailbox with > a given attribute for a given user, but in some server or message > store implementations it might be possible for multiple mailboxes to > have the same special-use attribute. > > That's intentional, and is as far as we want to go with it. I don't > think we want to nor should say anything further in this document. I did go looking for text that said something to this effect in the general sense, but didn't locate this. If you're comfortable that IMAP implementations will generally be aware of this, then the situation seems to be okay. I'll clear my DISCUSS. /a From nobody Thu Jun 7 00:02:40 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 82039130E82; Thu, 7 Jun 2018 00:02:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152835495652.30739.6520421102480081201.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2018 00:02:36 -0700 Archived-At: Subject: [Extra] Adam Roach's No Objection on draft-ietf-extra-specialuse-important-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 07:02:37 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-specialuse-important-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your explanation regarding my DISCUSS. From nobody Thu Jun 7 05:47:19 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 40933130EFA; Thu, 7 Jun 2018 05:47:15 -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=TA1YYc3W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lf98qqqE 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 g8QqssvdNrgw; Thu, 7 Jun 2018 05:47:13 -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 06CFE130EF8; Thu, 7 Jun 2018 05:47:10 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5231B21B8D; Thu, 7 Jun 2018 08:47:09 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 07 Jun 2018 08:47:09 -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=z/2vNnA7M3MgG3lwEvoZlGgd/BO10 UkPhM/FmQS0CvE=; b=TA1YYc3WsQQwo7Qxj5EWur9RV0hzna6rgjt4Y2S61WYRK CIUAjzkEmpqAM+lt3bH8lJ+WvsvjLEyHuBKxYEa55vY3u9q6SIDGp40HQ2mpGCQO ps66Q5BRpZabuBSoZZMSAjhUDdihLX7KcS2rpsS45RwBckRRak65Suj143RqVj69 qJFLxvEnjfKdRXPnCAivhHpaw0EIKZWP8xeYqyr2G1R9Y1Lwn3JpePjY1Jkcl0TV dUEotLNBKOSdKPWRnAwJZ3jsyBP9U1/lbeJJNcq4A0sF/cTA5I6zhtoxaqR3vowp rU1Zq1Yw1N9iY0QVQ3p7n4StWqYZpSOeSwlyaMRcA== 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=z/2vNn A7M3MgG3lwEvoZlGgd/BO10UkPhM/FmQS0CvE=; b=Lf98qqqEtHVcbCxyvnJbnF rSzcnilQqFjSKVgirNnaowzZUn0jYpdrobvGEk6tEP4/xPOGMILSafvcE10u9XI6 gDNSPrNVikLzBS7E32vRhaMnbM2xIYc4UKIO10lHxgrYOdT0nNWqcHS2lQSD/BNN XvNMak4FXJ7Ku9dqJFXnWIaoZvDsOyNMVPRFKIxCOAhlzWv1O7vU1yY2noQxlETy OQLG1WGgMkzUt8qnEYYlxKaPbKRx7470wFfmjuQ6+Q+A2hhYmcFk5yVTMZnlkco9 snFNe8es6St5VcY18zUuQtODRPgoPPlhXrnc6MbJ/U6bXYqakSZ2MRuhRrm4oU5A == 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 28BF89E0EB; Thu, 7 Jun 2018 08:47:09 -0400 (EDT) Message-Id: <1528375629.2527792.1399700384.33512155@webmail.messagingengine.com> From: Alexey Melnikov To: =?utf-8?Q?Mirja=20K=C3=BChlewind?= , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-unauth@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea In-Reply-To: <152812784871.27494.14679207696056136209.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2018 13:47:09 +0100 References: <152812784871.27494.14679207696056136209.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-unauth-00=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 12:47:16 -0000 Hi Mirja, On Mon, Jun 4, 2018, at 4:57 PM, Mirja K=C3=BChlewind wrote: > Quick question, however, I really don't know much about IMAP: Would it al= ready > help to just use TLS1.3 0-RTT session resumption instead? It would possibly speed-up reconnect, but it wouldn't eliminate the need to= have UNAUTHENTICATE, because TLS and authentication are separate steps in = IMAP. Best Regards, Alexey From nobody Thu Jun 7 06:09: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 A06B8130F14; Thu, 7 Jun 2018 06:09:51 -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: <152837699162.30727.17935874045270339163@ietfa.amsl.com> Date: Thu, 07 Jun 2018 06:09:51 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-list-myrights-06.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:09:52 -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 : IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-imap-list-myrights-06.txt Pages : 8 Date : 2018-06-07 Abstract: This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-list-myrights-06 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-list-myrights-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-list-myrights-06 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 Thu Jun 7 06:14: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 63064130EF1; Thu, 7 Jun 2018 06:14:32 -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: <152837727235.30691.12495553264707930451@ietfa.amsl.com> Date: Thu, 07 Jun 2018 06:14:32 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-list-myrights-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:14:39 -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 : IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-imap-list-myrights-07.txt Pages : 8 Date : 2018-06-07 Abstract: This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-list-myrights-07 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-list-myrights-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-list-myrights-07 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 Thu Jun 7 12:33:40 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 DA57212F1A2; Thu, 7 Jun 2018 12:33:32 -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: <152840001285.30919.15301982911298725120@ietfa.amsl.com> Date: Thu, 07 Jun 2018 12:33:32 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-specialuse-important-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 19:33:34 -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 $Important Keyword and \Important Special-Use Attribute Author : Barry Leiba Filename : draft-ietf-extra-specialuse-important-04.txt Pages : 10 Date : 2018-06-07 Abstract: RFC 6154 created an IMAP Special-Use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, registering the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-specialuse-important-04 https://datatracker.ietf.org/doc/html/draft-ietf-extra-specialuse-important-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-specialuse-important-04 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 Thu Jun 7 14:26:03 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 5C780130EC7; Thu, 7 Jun 2018 14:25:55 -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: <152840675535.30788.10068563347441733425@ietfa.amsl.com> Date: Thu, 07 Jun 2018 14:25:55 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-unauth-01.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 21:25:56 -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 UNAUTHENTICATE for Connection Reuse Author : Chris Newman Filename : draft-ietf-extra-imap-unauth-01.txt Pages : 11 Date : 2018-06-07 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-unauth-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-unauth-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-unauth-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 Thu Jun 7 14:33: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 BE16E130FD0; Thu, 7 Jun 2018 14:32:54 -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 3jTMPOPTbYjK; Thu, 7 Jun 2018 14:32:52 -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 127D2130DD6; Thu, 7 Jun 2018 14:32:52 -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 w57LVt7Q142272; Thu, 7 Jun 2018 21:32:47 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=Ak90x0jgsZrS/FGrdfaRgcJQw51ECDQFk1yhf1Jw1hI=; b=AcXmn3USDWbVCx+gF+Ue4RCTYjYDZjl4rGp4bES+xZoMpIhlGjdxMC3WcFRSpdS2wcpP 6MyAbkeGYjZbexVugZ7OQ4mSmEteVDkhZboPbvHfv5bGxG3ooVdbiWBExLN6dzTN7nUs xuXN8Pde/ui4yXQmKs1IeomQCfpLPHfElvVRcnDxvi8GX0UAET+fDei+wfSxr3WaKOew RKQt55Mj73Ql2GAFGRuMEW9ZPFJ003yp5hfMgtwDE2QU/lZevCguycHxxsRrusdBf4yd y0z3AMdELVsCw/FPfP59t+seLBfAsdwvpjPACFRDQTR88Fp5ELb8QyLb9YTGkkS6d3nO SA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2jbvypapnc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Jun 2018 21:32:47 +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 w57LWiVm020710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Jun 2018 21:32:44 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w57LWhaB005711; Thu, 7 Jun 2018 21:32:43 GMT Received: from [10.159.128.144] (/10.159.128.144) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Jun 2018 14:32:43 -0700 From: "Chris Newman" To: "Benjamin Kaduk" Cc: "The IESG" , draft-ietf-extra-imap-unauth@ietf.org, "Bron Gondwana" , extra-chairs@ietf.org, extra@ietf.org Date: Thu, 07 Jun 2018 14:32:41 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <5CCE5614-C76A-4913-B2F3-E50428DDCA84@oracle.com> In-Reply-To: <152814392277.30714.8638295088947635978.idtracker@ietfa.amsl.com> References: <152814392277.30714.8638295088947635978.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8917 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-1806070228 Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 21:32:56 -0000 On 4 Jun 2018, at 13:25, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-imap-unauth-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to for more information about IESG DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found here: > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please consider using the RFC 8174 boilerplate instead of the RFC 2119 > boilerplate; there > seems to be at least one usage of a lowercase keyword. Fixed in 01. > I do not remember seeing a response to the secdir review, which raises > an issue that is probably > worth addressing (even if it is largely editorial). Fixed in 01. > I have a few other comments/questions, that happen by chance to all > occur within Section 3. > > This command directs the server to reset all connection state, > except > for state at the TLS [RFC5465] layer. > > 5465 is IMAP NOTIFY, and a short Hamming distance from 5246 (TLS > 1.2). Fixed in 01. > Though I note that TLS 1.3 is in the RFC Editor's queue... > > 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. > > "terminate" applies only to outgoing messages, presumably? (Should > this be made more explicit?) A similar thing applies to COMPRESS as > enumerated in Section 4.1. I made an effort to clarify in 01. > Servers MAY choose to advertise the UNAUTHENTICATE capability only > after authentication has completed. As a result, clients need to > issue an IMAP CAPABILITY command after authentication in order to > determine the availability of UNAUTHENTICATE. > > Is this because the ability to reset state may depend on the > authentication mechanism used? That's permissible in the model, but the more likely reason is the server advertises a minimal set of capabilities prior to authentication (which simplifies implementation of a server-side application-layer proxy in larger deployment). - Chris From nobody Thu Jun 7 14:35: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 5D0CB130FDA; Thu, 7 Jun 2018 14:35:35 -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 3YPJL0K9bdSD; Thu, 7 Jun 2018 14:35:31 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 07F6D130DD6; Thu, 7 Jun 2018 14:35:30 -0700 (PDT) X-AuditID: 12074424-021ff700000064ca-f2-5b19a5217008 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 50.EC.25802.225A91B5; Thu, 7 Jun 2018 17:35:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w57LZRhm025358; Thu, 7 Jun 2018 17:35:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w57LZNrN013381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2018 17:35:25 -0400 Date: Thu, 7 Jun 2018 16:35:23 -0500 From: Benjamin Kaduk To: Chris Newman Cc: The IESG , draft-ietf-extra-imap-unauth@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org Message-ID: <20180607213523.GY72167@kduck.kaduk.org> References: <152814392277.30714.8638295088947635978.idtracker@ietfa.amsl.com> <5CCE5614-C76A-4913-B2F3-E50428DDCA84@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CCE5614-C76A-4913-B2F3-E50428DDCA84@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1lVaKhltsOsOm8WfM/NZLY43v2Ky 2HhgOaPFrJVtTBb/r/YwW8z4M5HZgc3j8vdWJo8lS34yeXx8eoslgDmKyyYlNSezLLVI3y6B K6N5wz22gp38FbcXvmFrYFzK08XIySEhYCJxadd99i5GLg4hgcVMEk+mXGSCcDYwSjR2HIDK XGGS6P++hRGkhUVAReJGy3Y2EJsNyG7ovswMYosIaEk0N+0C62YWWMIo0XCqgxUkISwQL/F4 6052EJsXaN+cqb+gpjYySkz4c48NIiEocXLmExYQmxlo0o1/L4EmcQDZ0hLL/3GAhDkF7CQm bbsLViIqoCyxt+8Q+wRGgVlIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrle bmaJXmpK6SZGUHCzu6jsYOzu8T7EKMDBqMTDm2AlGS3EmlhWXJl7iFGSg0lJlJc3FijEl5Sf UpmRWJwRX1Sak1p8iFGCg1lJhDfxkli0EG9KYmVValE+TEqag0VJnDd3EWO0kEB6Yklqdmpq QWoRTFaGg0NJgnfhYqChgkWp6akVaZk5JQhpJg5OkOE8QMPdQGp4iwsSc4sz0yHypxgVpcR5 r4EkBEASGaV5cL2g5CORvb/mFaM40CvCvK0gVTzAxAXX/QpoMBPQYA9msMEliQgpqQZGvq8l wcfK9k1pNjqxv2hq8oJZPe7Xv6z20ednX5To6vx1enTq/V9LKxkaRe9fsSmd5q/V2fhDNv7X bLffuxfy7iref+S6OMc2vsMTa/l93xtun/508iSOpS0nrDQWnXnHtWqNzUGl9V1xgc9n3JbU +cvQ67H86leRXUszU7684RQ6+s3opNj0FiWW4oxEQy3mouJEALeS2UgZAwAA Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 21:35:37 -0000 On Thu, Jun 07, 2018 at 02:32:41PM -0700, Chris Newman wrote: > On 4 Jun 2018, at 13:25, Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-extra-imap-unauth-00: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Though I note that TLS 1.3 is in the RFC Editor's queue... > > > > 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. > > > > "terminate" applies only to outgoing messages, presumably? (Should > > this be made more explicit?) A similar thing applies to COMPRESS as > > enumerated in Section 4.1. > > I made an effort to clarify in 01. Thanks! > > Servers MAY choose to advertise the UNAUTHENTICATE capability only > > after authentication has completed. As a result, clients need to > > issue an IMAP CAPABILITY command after authentication in order to > > determine the availability of UNAUTHENTICATE. > > > > Is this because the ability to reset state may depend on the > > authentication mechanism used? > > That's permissible in the model, but the more likely reason is the > server advertises a minimal set of capabilities prior to authentication > (which simplifies implementation of a server-side application-layer > proxy in larger deployment). Ah, that makes sense. (I think I did notice a bit about only advertising the unauthenticate capability after authenticating a trusted client, later in the document, but forgot to go back and change my notes -- sorry about that!) -Benjamin From nobody Fri Jun 8 09:36:50 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 5CFBF130F2A; Fri, 8 Jun 2018 09:36:48 -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.81.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-extra-imap-unauth@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152847580837.15420.2825829731628245995.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2018 09:36:48 -0700 Archived-At: Subject: [Extra] Protocol Action: 'IMAP UNAUTHENTICATE for Connection Reuse' to Proposed Standard (draft-ietf-extra-imap-unauth-01.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jun 2018 16:36:49 -0000 The IESG has approved the following document: - 'IMAP UNAUTHENTICATE for Connection Reuse' (draft-ietf-extra-imap-unauth-01.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ Technical Summary 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. Working Group Summary This spec was accepted at the IETF101 meeting. It has been around for years, but there was nowhere to submit it. Document Quality The specification has been in use in at least one site for multiple years. The integrations with various IMAP extensions have been very carefully specified. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Sat Jun 9 19:05: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 3CB7C130DE4 for ; Sat, 9 Jun 2018 19:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWmNxX4r50tl for ; Sat, 9 Jun 2018 19:05:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255071277C8 for ; Sat, 9 Jun 2018 19:05:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTIJ69RKGW010B7M@mauve.mrochek.com> for extra@ietf.org; Sat, 9 Jun 2018 19:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1528596100; bh=mU9kbOCGqzZeBsx893z5ymz7fOPo0fF1esX6Ya0Ydcw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=oXgg838DOeGL7E+K/jjL0LTr2QYLt22l0dzMTlcFU7m7hmwKQ3jU+vfWjl++KDSHG +J5NsEZkHiX3IDK7IS6H8+UqrM8BchohFf3g8wouoq56y0E0OGvmEr9IVPPGTVXUVk 0pz/E/H6/DBm8wvIx6VkJlBzy7jJCBASRra1gCN0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QSRDQV586O000051@mauve.mrochek.com>; Sat, 9 Jun 2018 19:01:36 -0700 (PDT) Cc: extra@ietf.org Message-id: <01QTIJ66FRSK000051@mauve.mrochek.com> Date: Sat, 09 Jun 2018 17:49:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 26 May 2018 23:00:13 +1000" <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 10 Jun 2018 02:05:47 -0000 I have now implemented the fcc extension and thus am in a position to comment further on the draft. I first want to note that this was *far* more difficult to implement than I expected. There are a number of issues, but the important one in regards to standardization is that the extension more less assumes direct mailbox access. This is arguably OK for a Sieve implementation that acts after final delivery, but that's not how all implementations work. And when you're talking about an implementation that operates as part of an SMTP server, you can't just blithely start up an IMAP session and do an APPEND. Even if that's technically feasible, what if there's an store availability issue or a timeout? Of course you can create a new queue to address this, but now you're talking about an additional thing that needs to be managed, and we like to avoid doing that if possible. The alternative is to use the same mechanism that's used for mailto: notifications and vacation messages. In effect, it's adding another recipient. But a special sort of recipient - one that has a regular mailbox and potentially a special use mailbox, set of IMAP flags, and create flag attached. Creating a new mechanism for this would have been a pain, but it occurred to me that we already have such a mechanism: Sieve. What :fcc effectively does is create a message with an associated sieve fileinto action. And that's how I ended up implementing it. And relevance of this to the standard is that thinking of :fcc in terms of it being a fileinto attached to the new message helps nail down the semantics. For example, nowhere does the current document define the syntax or semantics of the mailbox argument to :fcc. But RFC 5228 section 4.1 does all of this for the mailbox argument to fileinto, and I don't see any reason why we shouldn't say that the syntax and semantics have to be the same. Ditto for :specialuse, :flags, and :create. > 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 The specification of the enotify extension itself provides the tools you need for this. In particular, section 4 of RFC 5435 defines the valid_notify_method test, which can be used to check if a given notification method is supported. I see no reason why we can't add an :fcc parameter to this test to check and see if the method is both valid and supports :fcc. :fcc in this case could be defined to take an argument that would also be validated. Alternately, the argument could be omitted and the test could simply be for :fcc support, but I see no reason to do that. > * do we need separate capabilities, or just "fcc"? No. Again, the necessary capabilities are there in the extension; all you need to do is use them. > 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. Not sufficient IMO. I think that for standardized notification methods we need to specify the mapping to an email message. > * 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. Whereas I can readily envision implementing a notification method that doesn't translate well if at all to an email message. > 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, Here are some specific comments on the current document. Section 1. The decision to limit the extension to just vacation and notify needs to be reflected in the introduction. I suggest changing it to read: The Sieve Email Filtering Language [RFC5228] provides a number of action commands, some of which can generate additional messages on behalf of the user. It is sometimes desirable to have an archive of the messages generated by such commands. This extension defines a new optional tagged argument ":fcc" that can be specified on action commands which generate additional messages to allow a copy of the generated message to be filed into a target mailbox. The capability string associated with this extension is "fcc". Each action that generates additional messages will need to specify how it interfacts with :fcc. This document also specifies the interaction of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. Section 2. There's been pushback to use the updated keyword text in RFC 8174 rather than RFC 2119. Might as well make the change now. Section 3. This should state that the syntax and semantics MUST match those of the mailbox arugment to fileinto specified in RFC 5228 section 4.1. Section 3.3. I suggest that for now this be made specific to the mailto: method. If someone wants to write some requirements for tel: and xmpp: that's fine too. Section 3.4. Given that this document only specifies use of :fcc with vacation and notify, and given the content of 3.5, I'm not sure we really need this. I think it would be best to remove it. If we do retain it, it needs to be recast along the lines of "Implementations MUST NOT allow use of :fcc with ereject and reject. Section 3.6 needs to state that when fileinto arguments are used with :fcc they have the same syntax and semantics as they do with fileinto. That's it for now. Ned From nobody Sun Jun 10 14:48: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 AEE4412F295 for ; Sun, 10 Jun 2018 14:48:01 -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.com header.b=eoaoVR9u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VisnztMH 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 wh3G8wko17XF for ; Sun, 10 Jun 2018 14:47:59 -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 67837128BAC for ; Sun, 10 Jun 2018 14:47:59 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C1FE4213B6; Sun, 10 Jun 2018 17:47:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 10 Jun 2018 17:47:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc: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=nAaW6igee7QR+qiIubczxMqIcZPl+Grz/duiUJ3/ZSA=; b=eoaoVR9u nuLh58U7WgDL9kBu98gfygWGmlZMrcQxUxIY6gfhHo2Zc6dNQAYN1QdWq2jFMhj0 XYhqtUImHdhsenHmO5j0jjB7fY0VAMf3idPJSwkrzEbjVWjdjYNj2tOoc+8/BxER GNELJlhpfOHfd/HsBKsueZt50JARH8P4nrRbrYHASj//Jj33LiA1d4b0p6fal7Bq YkrTdNmUQz9fjxDHJJhuEZQ3Zevq3j2qSwwPqte9WgYZsww/saWpyzIN+7xV7c75 H8zZj2o0yKF5K4+ozmr2xyHFs2UOryLHNUbJ93lrc5vhngin7pdTrY5B37+VEeg2 eBmhWJtLJveZhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=nAaW6igee7QR+qiIubczxMqIcZPl+ Grz/duiUJ3/ZSA=; b=VisnztMHL3u4jqDfHeVnL9INqdYKSEGqKT8mzsFhyvey7 CkMvBYXhdFXrxzq7Fn8nT0MXujGNeTGbEjcuCkGCISZ5W82O6Z5AkQBSRog3Ezqp ahzXoiXp1GZRSWAgPKMUQznWJ/WZwmBUr4bu+undhK6AZOzK/8KHZBXed7JGxGg3 rqWCMkpzaf6yMe1cSQSLTXMeCXz/aIQ7kfDZN6WTJosFxoQ+I1JCOrvHYjUInKgm D8rOR4zGj8duG4euNceWjQf4RnQG+AEm+fuewvnNiChoNbP82ClQ/E2suZLqyRUJ 9PQHDGJERjjQ/0qq9mD0vVVcHwU3UDus6IdL6eZGw== 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 (178.sub-174-224-128.myvzw.com [174.224.128.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F855E425A; Sun, 10 Jun 2018 17:47:54 -0400 (EDT) To: Ned Freed , Bron Gondwana Cc: extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <0e7dbb71-e71b-5654-96f2-3cab405e776b@fastmail.com> Date: Sun, 10 Jun 2018 17:47:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <01QTIJ66FRSK000051@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------2140DB73AC4B82A94F854EAC" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 10 Jun 2018 21:48:02 -0000 This is a multi-part message in MIME format. --------------2140DB73AC4B82A94F854EAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the detailed review Ned.  I will make your suggested changes this week. (Also, thanks for the review of the application/tzif MIME registration). On 06/09/2018 08:49 PM, Ned Freed wrote: > I have now implemented the fcc extension and thus am in a position to > comment further on the draft. > > I first want to note that this was *far* more difficult to implement than I > expected. There are a number of issues, but the important one in regards to > standardization is that the extension more less assumes direct mailbox access. > This is arguably OK for a Sieve implementation that acts after final delivery, > but that's not how all implementations work. And when you're talking about an > implementation that operates as part of an SMTP server, you can't just blithely > start up an IMAP session and do an APPEND. Even if that's technically feasible, > what if there's an store availability issue or a timeout? > > Of course you can create a new queue to address this, but now you're talking > about an additional thing that needs to be managed, and we like to avoid doing > that if possible. > > The alternative is to use the same mechanism that's used for mailto: > notifications and vacation messages. In effect, it's adding another recipient. > But a special sort of recipient - one that has a regular mailbox and > potentially a special use mailbox, set of IMAP flags, and create flag attached. > > Creating a new mechanism for this would have been a pain, but it occurred to me > that we already have such a mechanism: Sieve. What :fcc effectively does is > create a message with an associated sieve fileinto action. And that's how > I ended up implementing it. > > And relevance of this to the standard is that thinking of :fcc in terms of it > being a fileinto attached to the new message helps nail down the semantics. > For example, nowhere does the current document define the syntax or semantics > of the mailbox argument to :fcc. But RFC 5228 section 4.1 does all of this for > the mailbox argument to fileinto, and I don't see any reason why we shouldn't > say that the syntax and semantics have to be the same. Ditto for :specialuse, > :flags, and :create. > >> 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 > The specification of the enotify extension itself provides the tools you need > for this. In particular, section 4 of RFC 5435 defines the valid_notify_method > test, which can be used to check if a given notification method is supported. I > see no reason why we can't add an :fcc parameter to this test to check and see > if the method is both valid and supports :fcc. > > :fcc in this case could be defined to take an argument that would also be > validated. Alternately, the argument could be omitted and the test could simply > be for :fcc support, but I see no reason to do that. > >> * do we need separate capabilities, or just "fcc"? > No. Again, the necessary capabilities are there in the extension; all you need > to do is use them. > >> 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. > Not sufficient IMO. I think that for standardized notification methods we need > to specify the mapping to an email message. > >> * 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. > Whereas I can readily envision implementing a notification method > that doesn't translate well if at all to an email message. > >> 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, > Here are some specific comments on the current document. > > Section 1. The decision to limit the extension to just vacation and > notify needs to be reflected in the introduction. I suggest changing it to > read: > > The Sieve Email Filtering Language [RFC5228] provides a number of > action commands, some of which can generate additional messages on > behalf of the user. It is sometimes desirable to have an archive of the > messages generated by such commands. > > This extension defines a new optional tagged argument ":fcc" that > can be specified on action commands which generate additional messages to > allow a copy of the generated message to be filed into a target mailbox. > > The capability string associated with this extension is "fcc". > > Each action that generates additional messages will need to specify > how it interfacts with :fcc. This document also specifies the interaction > of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. > > Section 2. There's been pushback to use the updated keyword text in RFC 8174 > rather than RFC 2119. Might as well make the change now. > > Section 3. This should state that the syntax and semantics MUST match those > of the mailbox arugment to fileinto specified in RFC 5228 section 4.1. > > Section 3.3. I suggest that for now this be made specific to the mailto: > method. If someone wants to write some requirements for tel: and xmpp: that's > fine too. > > Section 3.4. Given that this document only specifies use of :fcc with vacation > and notify, and given the content of 3.5, I'm not sure we really need this. I > think it would be best to remove it. If we do retain it, it needs to be recast > along the lines of "Implementations MUST NOT allow use of :fcc with ereject and > reject. > > Section 3.6 needs to state that when fileinto arguments are used with :fcc > they have the same syntax and semantics as they do with fileinto. > > That's it for now. > > Ned > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Ken Murchison Cyrus Development Team FastMail US LLC --------------2140DB73AC4B82A94F854EAC Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------2140DB73AC4B82A94F854EAC-- From nobody Sun Jun 10 15:34:47 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 C981F1277CC for ; Sun, 10 Jun 2018 15:34:44 -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.com header.b=PHHJrkpM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GkOxMJjR 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 4pn_lCE5Cdm6 for ; Sun, 10 Jun 2018 15:34:43 -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 9D939127332 for ; Sun, 10 Jun 2018 15:34:43 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D8C842185B; Sun, 10 Jun 2018 18:34:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 10 Jun 2018 18:34:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc: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=eTbmxazWTDl8CnFfrO8Yqx5tJjOAvTHHGeo7DJxeSe8=; b=PHHJrkpM uV/zH9V0KeGqg0vIBG2EB+g+VBhBBqFthVH+NP+6jCyo7xJhkEFU1ZbyMaPN/sSM DfrxQhdj5d12Dz/kCk8FYVE5twmnkld0fc84s2iHO/BrOOXv3VglYZbI9b579QlK N1Zq5peUYA/1zbeUZbGXUpU4FXZA4RxnZ3ryzv8eHK7UGUl4rQh0MT+zu/bIeuL4 AhUPoY3FDdc0dtycPy7gEnTJsaw3csobh9FvjHLgJAE4zgBv14W1e7zSwjGJJ1E/ qgp4aqqxhWMN45moQ3cs6k8eNmYSqu+eIXgZRu1DT2TDb33wwjnQayrcrsbk2j02 ErswFQ8z/wp6Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=eTbmxazWTDl8CnFfrO8Yqx5tJjOAv THHGeo7DJxeSe8=; b=GkOxMJjRwDt8vFThBSF06qi42ZIyM4ZnAVinUCesd+Z12 wFfo1Pe92rjBNGHtIR+Mz9k4a3/0U6s77uQW1KzJ5vtt74QlG95eckPk/aLk21TU M2itHtlPlUlaiLj61GKXWE5YQ7vHCSMGMab/oEhSfirs6x6GzvztVo2Xj69iDPhR XvI3Uo8sGq/cvmHt7IEgDoDLPXzuUf4+j+2Qv+f6fiVz6et4Evh/SPp2zqDUJT5U bY3nUyWwmHfTwbflBgOS7WSLubnSu+Yk9qZhHBvn9J/VWnAcTZaCNJiNXJQZrmqD Wq6l9Y7Rsp4pPJFpTB7CrAACY/PdmgZU66XtoVQjw== 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 (178.sub-174-224-128.myvzw.com [174.224.128.178]) by mail.messagingengine.com (Postfix) with ESMTPA id E5284E4853; Sun, 10 Jun 2018 18:34:40 -0400 (EDT) To: Ned Freed , Bron Gondwana Cc: extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> Date: Sun, 10 Jun 2018 18:34:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <01QTIJ66FRSK000051@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------E805869B5EA2A994AE753361" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 10 Jun 2018 22:34:45 -0000 This is a multi-part message in MIME format. --------------E805869B5EA2A994AE753361 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/09/2018 08:49 PM, Ned Freed wrote: > Section 3.3. I suggest that for now this be made specific to the mailto: > method. If someone wants to write some requirements for tel: and xmpp: that's > fine too. So, are you saying that I should remove Section 3.1 or just any mention of notification methods other than mailto: ? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------E805869B5EA2A994AE753361 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------E805869B5EA2A994AE753361-- From nobody Sun Jun 10 16:08:42 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 39DCF130EDE for ; Sun, 10 Jun 2018 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwUPo3JGCAZF for ; Sun, 10 Jun 2018 16:08:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9670E130D7A for ; Sun, 10 Jun 2018 16:08:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTJR8SQSI800YCT0@mauve.mrochek.com> for extra@ietf.org; Sun, 10 Jun 2018 16:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1528671813; bh=ozmJ1tZstEKrUhLHYfRxmkLCeSfee2KXi++giFpFycI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=InqJKbHTiXKeAwIkxVRXGg1JtfC1T5E3S8wNKf1Dha1JjR5IONcNHkScRITaf8H47 3Yd8HWI+dJZTMYX9CBg79uVaGlmQO1obTcBfGTS5BEqww4Z9soIssJgE7Qd8kVZacu TEkyP0deAtVo6TX1I6ON3GL8mA3pF0wLLWlHdCTQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QSRDQV586O000051@mauve.mrochek.com>; Sun, 10 Jun 2018 16:03:30 -0700 (PDT) Cc: Ned Freed , Bron Gondwana , extra@ietf.org Message-id: <01QTJR8Q97NK000051@mauve.mrochek.com> Date: Sun, 10 Jun 2018 16:01:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 10 Jun 2018 18:34:33 -0400" <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 10 Jun 2018 23:08:41 -0000 > On 06/09/2018 08:49 PM, Ned Freed wrote: > > Section 3.3. I suggest that for now this be made specific to the mailto: > > method. If someone wants to write some requirements for tel: and xmpp: that's > > fine too. > So, are you saying that I should remove Section 3.1 or just any mention > of notification methods other than mailto: ? 3.1 is fine as general guidelines for how to map something into a mail message. Ned From nobody Mon Jun 11 09:36: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 E2F20130FF7; Mon, 11 Jun 2018 09:36:50 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-extra-imap-status-size@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152873501092.2594.2724040316372707920.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2018 09:36:50 -0700 Archived-At: Subject: [Extra] Protocol Action: 'Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension' to Proposed Standard (draft-ietf-extra-imap-status-size-02.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 16:36:52 -0000 The IESG has approved the following document: - 'Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension' (draft-ietf-extra-imap-status-size-02.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-status-size/ Technical Summary This spec extends IMAP to provide a way for clients to access a piece of data that many servers already keep, the total size of a mailbox. Working Group Summary The only topic of debate was how tightly to define the method for calculating the size. Many servers already implement a non-standard way to access this information, and many clients want access to the information. Document Quality The Dovecot server already implements it. It was implemented on the day it was proposed in the Cyrus IMAPd server. Other vendors have stated their intention to implement. All the server and client authors said that they would be able to implement the standard easily and agreed it was the best way to do it. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Mon Jun 11 09:38:20 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 CBC33131022; Mon, 11 Jun 2018 09:38:09 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-specialuse-important@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152873508982.2717.11442870466580782527.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2018 09:38:09 -0700 Archived-At: Subject: [Extra] Protocol Action: 'IMAP $Important Keyword and \Important Special-Use Attribute' to Proposed Standard (draft-ietf-extra-specialuse-important-04.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 16:38:19 -0000 The IESG has approved the following document: - 'IMAP $Important Keyword and \Important Special-Use Attribute' (draft-ietf-extra-specialuse-important-04.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ Technical Summary This spec extends IMAP with an additional special-use [RFC6154] type for a mailbox (possibly virtual) which stores messages that may be important to the user. The document also creates a registry for mailbox uses to allow other uses to be defined in future. Working Group Summary The only topic of debate was how to make the the registry useful for JMAP and other non-IMAP specifications as well, which led to adding instructions to IANA for a free-form column with usage guidance. Document Quality An \Important special-use has been implemented by Gmail already, and all the other server implementations said it would be easy to add. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Mon Jun 11 09:39: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 AF58D131091; Mon, 11 Jun 2018 09:39:23 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-imap-list-myrights@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152873516371.2668.4837652488669934314.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2018 09:39:23 -0700 Archived-At: Subject: [Extra] Protocol Action: 'IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST' to Proposed Standard (draft-ietf-extra-imap-list-myrights-07.txt) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 11 Jun 2018 16:39:32 -0000 The IESG has approved the following document: - 'IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST' (draft-ietf-extra-imap-list-myrights-07.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/ Technical Summary This document defines an extension to IMAP LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. Working Group Summary The EXTRA WG meeting in IETF 101 identified two items, which were fixed. During working group last call, a couple of minor issues were identified and fixed in the new version. The WG as a whole made a thorough review of this document. Document Quality The document is in very good shape and is ready to be published. Some vendors have stated their intention to implement it. Some have stated that they have no objection to advancement although they do not plan to implement it right now. Personnel Document Shepherd - Jiankang Yao (EXTRA co-chair) Responsible Area Director - Alexey Melnikov From nobody Wed Jun 13 18:35:59 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 721A1130DC5 for ; Wed, 13 Jun 2018 18:35:57 -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 Hx4bNohpqL1Z for ; Wed, 13 Jun 2018 18:35:55 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 72B68130DFD for ; Wed, 13 Jun 2018 18:35:53 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEPB2xiFbhocKAQ--.22979S2; Thu, 14 Jun 2018 09:35:50 +0800 (CST) Date: Thu, 14 Jun 2018 09:35:41 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk References: <2018052911424216122334@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201806140935275544077@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart823617202845_=----" X-CM-TRANSID: AQAAf0AJEPB2xiFbhocKAQ--.22979S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtFyrZw1rAw17ArW5uw1rWFg_yoWfZFc_ua yYgF4Fq3y5Ja9F9r17CFZxt34xXayay39rZa95Jrs7CryrAanxJF4S9ws3Zr1UGFyDuw4D GrsIq3s3GrnI9jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbVAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I2 6xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wCY02Av z4vE14v_KwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_Jryl IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxh VjvjDU0xZFpf9x07j138nUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] Fw: IETF WG state changed for draft-ietf-extra-imap-objectid X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 01:35:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart823617202845_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgICAgV2FpdGluZyBmb3IgeW91ciBraW5kIHJldmlldy9jb21tZW50cyBmb3Ig dGhpcyBkb2N1bWVudC4gVGhlIGxhc3QgY2FsbCB3aWxsIGVuZCBpbiBhIHdlZWsuDQoNClRoYW5r cy4NCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBKaWFua2FuZyBZYW8NCkRhdGU6IDIwMTgt MDUtMjkgMTE6NDMNClRvOiBleHRyYQ0KU3ViamVjdDogW0V4dHJhXSBGdzogSUVURiBXRyBzdGF0 ZSBjaGFuZ2VkIGZvciBkcmFmdC1pZXRmLWV4dHJhLWltYXAtb2JqZWN0aWQNCkRlYXIgYWxsLA0K DQpHZW50bGUgcmVtaW5kZXIuDQpUaGlzIGRyYWZ0IHdpbGwgYmUgaW4gV0cgbGFzdCBjYWxsIGZv ciAzIHdlZWtzLCB3aGljaCBlbmRzIGluIDE5IEp1bmUuDQpBbnkgY29tbWVudHMgYXJlIHdlbGNv bWUuDQpUaGFua3MgYSBsb3QuDQoNCg0KDQoNCg0KSmlhbmthbmcgWWFvDQoNCkZyb206IElFVEYg U2VjcmV0YXJpYXQNCkRhdGU6IDIwMTgtMDUtMjkgMTE6MzgNClRvOiB5YW9qa0Bjbm5pYy5jbjsg ZHJhZnQtaWV0Zi1leHRyYS1pbWFwLW9iamVjdGlkQGlldGYub3JnOyBleHRyYS1jaGFpcnNAaWV0 Zi5vcmcNClN1YmplY3Q6IElFVEYgV0cgc3RhdGUgY2hhbmdlZCBmb3IgZHJhZnQtaWV0Zi1leHRy YS1pbWFwLW9iamVjdGlkDQoNClRoZSBJRVRGIFdHIHN0YXRlIG9mIGRyYWZ0LWlldGYtZXh0cmEt aW1hcC1vYmplY3RpZCBoYXMgYmVlbiBjaGFuZ2VkIHRvICJJbg0KV0cgTGFzdCBDYWxsIiBmcm9t ICJXRyBEb2N1bWVudCIgYnkgSmlhbmthbmcgWWFvOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWV4dHJhLWltYXAtb2JqZWN0aWQvDQoNCkNvbW1lbnQ6DQpU aGUgZWRpdG9yIG9mIHRoaXMgZHJhZnQgaGFzIHVwZGF0ZWQgdGhlIHNldmVyYWwgdmVyc2lvbnMg dG8gYWRkcmVzcyB0aGUNCmlzc3VlcyBmb3VuZC4= ------=_001_NextPart823617202845_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hello,
 
     Waiting for your kind review/comments for th= is=20 document. The last call will end in a week.
 
Thanks.
Jiankang Yao
 
From: Jiankang Yao<= /DIV>
Date: 2018-05-29 11:43
To: extra
Subject: [Extra] Fw: IETF WG state changed for=20 draft-ietf-extra-imap-objectid
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_NextPart823617202845_=------ From nobody Wed Jun 13 18:52: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 6F895130FAC for ; Wed, 13 Jun 2018 18:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VIAVZuGdMfo for ; Wed, 13 Jun 2018 18:52:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C6D1292AD for ; Wed, 13 Jun 2018 18:52:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTO3TNFWOW011NIB@mauve.mrochek.com> for extra@ietf.org; Wed, 13 Jun 2018 18:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1528940828; bh=KubdVcJ3CRo5YEPa5H+tN7f5y8E0zXnQbBbMYAMpwrk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=JHcktyL++IDHZOGYTsBRoSiAS+A+w+3zWgZORNbrupWYBJjG0Ui5XH0lBquE7wsrp wW0xF7ZmAwhNE823w+aV1FTfKnn6xKUQGUDNZT5II9S0Lkn91Uz0zE2wnEWoja+vt7 hmnnQxQSB+pb7VaSY0yhysycBk79RFTtzsalGBBE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTN94JXEB400AI1F@mauve.mrochek.com>; Wed, 13 Jun 2018 18:47:03 -0700 (PDT) Cc: Ned Freed , extra@ietf.org Message-id: <01QTO3THVZ5I00AI1F@mauve.mrochek.com> Date: Wed, 13 Jun 2018 08:40:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 21 May 2018 15:13:54 +0200" <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> References: <151533655607.10858.793231788332492256@ietfa.amsl.com> <01QNLYA7BLVQ000051@mauve.mrochek.com> <83ddcadc-b756-91c1-3664-81955cd8f0d8@dovecot.fi> To: Stephan Bosch 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.26 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, 14 Jun 2018 01:52:15 -0000 > > 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? The first step seems fine: C: A01 NAMESPACE S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) S: A01 OK NAMESPACE command completed In the next step: Subsequently, when no particular mailbox is of interest (i.e., the "specialuse_exists" test has no mailbox argument), the client lists all mailboxes with special-use flags in the two returned personal namespaces: C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN (SPECIAL-USE) S: * LIST (\Drafts) "/" INBOX/Drafts S: * LIST (\Trash) "/" INBOX/Trash S: * LIST (\Sent) "/" INBOX/Sent S: * LIST (\Archive) "/" Archive/Default It should be noted that this depends on extended list being available. The final step is: C: A03 SELECT Archive/Default S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] Flags permitted. S: * 11211 EXISTS S: * 3 RECENT S: * OK [UIDVALIDITY 1526903163] UIDs valid S: * OK [UIDNEXT 11278] Predicted next UID S: A03 OK [READ-WRITE] SELECT command completed There are several issues here. First, if you're going to use SELECT it's probably worth noting that since inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC 3501 while inclusion of [READ-ONLY] for non-writable is a MUST, a writability check really needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears incorrect to me in this regard - should I file an errata?) However, I think use of SELECT for this purpose is problematic: It's potentially expensive and worse, may cause undesireable state changes. Why not use the MYRIGHTS command to obtain the access rights (and check for "p" or "i") without having to select the mailbox? And as a bonus, if it's available you could use the just-standardized LIST-MYRIGHTS extension to piggyback getting the rights while getting the list of special-use mailboxes. More generally, this is why documenting the things necessary to implement the necessary semantics of an extension is helpful - there may be optimizations and concerns that should be called out lest implementors miss them. It also helps clarify overall implementation difficulty. And while this extension may be easy to implement in the Sieve-in-IMAP case, from the perspective of an MTA/MDA implementation, even if all of the steps can be done efficiently, there's still the question of IMAP server availability and the handling of temporary errors. All of which is roundabout way of saying I now think that we may want a capability for specialuse_exists that's separate from "special-use"/:specialuse. Or better still, since we already have the "mailbox" capability for "mailbox access stuff", I think we should require the presence of both "mailbox" and "special-use" capabilities in order to use specialuse_exists. I also reviewed the rest of the revised draft, and it's looking good. My one remaining concern is with the handling of multiple mailboxes having the same special-use flag assigned. The draft currently says: More than one mailbox in the user's personal namespace can have a particular special-use flag assigned. In case of such ambiguity, the mailbox that is chosen for delivery is implementation-defined. However, while the set of mailboxes to which the involved special-use flags are assigned remains unchanged, implementations MUST ensure that the mailbox choice is made consistently, so that the same mailbox is used every time. Conversely, the chosen mailbox MAY change once the special-use flag assignments that are relevant for the mailbox choice are changed (usually by user interaction). I don't see a way I can reasonably implement this MUST via IMAP unless the IMAP server always returns the list of special-use mailboxes in the same order. Sure, I can cache the user/special-use-attribute/actual-mailbox-list tuple somewhere, but caches can always be lost. And mailbox metadata is (a) Potentially much too expensive and (b) Subject to the vagarities of user actions. I'm not happy about it, but I think this needs to become a SHOULD. Another possibility is to use the default mailbox name as a means of disambiguating multiple mailboxes with the same special-use attribute: If the default mailbox is one of these deliver to it preferentially, otherwise the behavior is implementation-defined. Not perfect, but it provides a bit more consistent behavior that's easily achievable. Aside from these issues, this draft looks good to go to me. Ned From nobody Thu Jun 14 22:40: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 24899130DC2 for ; Thu, 14 Jun 2018 22:40: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=HplygIQ/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IfQK5zJ3 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 BaiCesorFEVh for ; Thu, 14 Jun 2018 22:40:21 -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 E4439126DBF for ; Thu, 14 Jun 2018 22:40:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4269C21BF6; Fri, 15 Jun 2018 01:40:20 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Fri, 15 Jun 2018 01:40:20 -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=M161g6 +8v7VYrhsSp+LkzAnSR9OFh2iKS5X+LmIyzWs=; b=HplygIQ/G2k9yB61VosXkY R/xKUB6oTpxGf8La6mxP9BUpT08wF2uK75PAlPf2XavuZjR3Z7YItffyIYOSP5Ib PBlS+oLGT55Gv2fVOugbI/jYbdIqerM5SSOJfc+ZfkdGg/a8T8VCMb1JdXdYV4E8 pUWFOP6XaAugA5ci0t7AEdqlkAyc3SPkOQY+ope3QUoYGEdNkRhd2OEUpqVSkFyN eiEDxt3ljMi7ijgQZFXeyHYfb+qoRuyKd/kHwBcVGXGcEoDurbtxPex+mTRRgQ7I FHJGJA1uQyjkKlinSViiddcclH7DhqD6Fb/1L+2cwLEWUcs1nZCegkbj4ixh30Dg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=M161g6 +8v7VYrhsSp+LkzAnSR9OFh2iKS5X+LmIyzWs=; b=IfQK5zJ39Iy3VH6BGdueUN 6uiW5rLEBpKQByy63D+d2R7SI9BV/EfVAWtpyEngnKxVv59HMYoMBOtPMCybbgSt xDP19fZDlcQkHZd7xF7UeTl2e9Gdi99BF4gmgoJXr+IDOlV0pFsLF34Auw9wjIJu ZBoPXeDfiOogm4dnkbPoX9CmkFcOgsoA/jhXAfW26CKt4NXnxCeOfUzoQ7pIxpW+ p2qflkBhO8l1uP2rsQqGCMxQn9HcXpahsmHknwfFNqhdggNeEkB/MWOWaLNJ240s 1UQBIduqotcem5lO9cm/wYM/XGW/08KuLHvutTfZRS+hdbCp74IfTdXRpRqKP2JQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E72869E0E8; Fri, 15 Jun 2018 01:40:19 -0400 (EDT) Message-Id: <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> From: Bron Gondwana To: Barry Leiba Cc: extra@ietf.org, Linda Dunbar MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152904121911273310" X-Mailer: MessagingEngine.com Webmail Interface - ajax-498d70f2 Date: Fri, 15 Jun 2018 15:40:19 +1000 References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> In-Reply-To: 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.26 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, 15 Jun 2018 05:40:24 -0000 This is a multi-part message in MIME format. --_----------=_152904121911273310 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue, May 15, 2018, at 02:00, Barry Leiba wrote: >> On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: >>=20 >> 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 = mailbox 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 >>=20 >>=20 >> 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 tha= t the >> answers>> to your questions are: >>=20 >> 1) like all STATUS responses, this is the state of the mailbox on the>> = server. >>=20 >> 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 m= ost >> amount of>> storage - for example to allow the the user to remove large >> messages when>> they are approaching their storage quota. >>=20 >> 3) as defined in this document, "mailbox size" is based on the >> storage used>> by the messages in the mailbox, so it will naturally c= hange if >> the set of>> messages in the mailbox change, either through adding new >> messages, or>> expunging existing messages. >>=20 >> I will send this back to the author and request clarifying language >> be added>> to address these three questions. >=20 > Really? I don't think there's anything the author needs to do: all of> t= his is clear to people familiar with the relevant IMAP specs, and > people implementing this have to be familiar with the relevant IMAP > specs. >=20 > 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. Following on from this - the document is currently held in "Waiting on Authors". The author made an update in -02 to clarify some wording for those who aren't familiar with the related specifications. Linda - can you please review -02 and see if it resolves your objections. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152904121911273310 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Tue, May 15, 2018, at 02:00, Bar= ry Leiba wrote:
On Mon, 14 May 2018, at 11:57, L= inda 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 m= e, clearly
I'm too embedded in the IMAP world already, so I would say that the an= swers
to your questions are:

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

2) any clients which don't keep a full copy of the IMAP mailbox may st= ill
wish to be able to quickly identify the mailboxes using the most amoun= t of
storage - for example to allow the the user to remove large messages w= hen
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.

Really?  I don't think there's anything the author needs to do: a= ll 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.

Following on from this - the document is = currently held in "Waiting on Authors".

The author made an update in -02 to clari= fy some wording for those who aren't familiar with the related specificatio= ns.

Linda - can you please review -02 and see= if it resolves your objections.

Thanks,

Bron.

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


--_----------=_152904121911273310-- From nobody Fri Jun 15 15:45:28 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 6964F130DF1 for ; Fri, 15 Jun 2018 15:45:25 -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.com header.b=Qc2OuHl5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z4Y9ytCM 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 AmeLcmH35n7n for ; Fri, 15 Jun 2018 15:45:22 -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 20C4F12D949 for ; Fri, 15 Jun 2018 15:45:22 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3B90721E52; Fri, 15 Jun 2018 18:45:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 15 Jun 2018 18:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc: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=VgK42pWpWw4j8b/0S2CI/QOa9msFI0HnS91SJdqW0Rk=; b=Qc2OuHl5 QXv72Bi/DobMuWmpovoT4lOy/J06Ju/skOURk0FvNpr+GJ5+1jAGB23jxJJQi5kc 4f97RGe6tNi8UPs7Q2bjjsu41yA0j+BiBQxp0eqJc/4zyxrQnqKjx5nd8sA9bt2W aEne0wh/HY55+RCIC+Xab3XfLFJ9+NBw57TLsM/TAje/OwdN+mamo6uaOWU8AkyK clBGlt8j47GbOHLisx/tDWwtyPlppZe6fvgWjzrznXN5XkyhhDehInjOvDXgmy0y msFVsAccTjNu9jMbzSlDaCJAZrll7dH06ypRj7gltuiB7lbXdDVb+/mJIvdCm5N2 nxOpec5k0GaMDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=VgK42pWpWw4j8b/0S2CI/QOa9msFI 0HnS91SJdqW0Rk=; b=Z4Y9ytCMsEuXo98HbncaZnNlSuGa7PUOgwcMuuoL5yBGs 6yoEJldSxtVhiYqsctS4kAZLzOnez4swXnqAF36QiTMMfolLOaJxGFn/tu6BulDO LSLA3WTc7SkysQFQl16nwRs93x/bKfDtLMKKmfgOWsHYWDPjA6OAf6h9P+2cSyoi EpGTGdl7H1tojNMu0EaeTCdXhmXzmM7gnvCEQRdixkD8ABdl6wv2Y3cohq4KoKoD pj3uvCkrGvS8lS0qphRtvDqL1YY/rv7RKmKpoJB+Z8SoKR2Lg2GakW4Y621a3LWr J7AFrv5zsz6d8JxBn8dXuPFMAU6C6tnWaFmiLHsIw== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (48.sub-174-224-143.myvzw.com [174.224.143.48]) by mail.messagingengine.com (Postfix) with ESMTPA id 96D48E4648; Fri, 15 Jun 2018 18:45:20 -0400 (EDT) To: Ned Freed Cc: Bron Gondwana , extra@ietf.org References: <1527339613.810325.1386461928.7A2775BA@webmail.messagingengine.com> <01QTIJ66FRSK000051@mauve.mrochek.com> <90322c67-3f2b-6322-12c0-6870e2a8b2ac@fastmail.com> <01QTJR8Q97NK000051@mauve.mrochek.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Fri, 15 Jun 2018 18:45:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <01QTJR8Q97NK000051@mauve.mrochek.com> Content-Type: multipart/mixed; boundary="------------848B36F5B2E9F821CAC19501" Content-Language: en-US Archived-At: Subject: Re: [Extra] sieve-fcc next steps X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 22:45:26 -0000 This is a multi-part message in MIME format. --------------848B36F5B2E9F821CAC19501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Nedx On 06/10/2018 07:01 PM, Ned Freed wrote: > >> On 06/09/2018 08:49 PM, Ned Freed wrote: >> > Section 3.3. I suggest that for now this be made specific to the >> mailto: >> > method. If someone wants to write some requirements for tel: and >> xmpp: that's >> > fine too. Do you have suggestions as to how you would like to see the existing text modified? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------848B36F5B2E9F821CAC19501 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------848B36F5B2E9F821CAC19501-- From nobody Fri Jun 15 20:13: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 0642A130F3B for ; Fri, 15 Jun 2018 20:13:27 -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=qXx9Z6v6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=McEFXKH5 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 dhRjReZPV_Op for ; Fri, 15 Jun 2018 20:13:25 -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 8675F130F39 for ; Fri, 15 Jun 2018 20:13:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DF5E121BD8 for ; Fri, 15 Jun 2018 23:13:24 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 15 Jun 2018 23:13:24 -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=tUdz8r+rOa706v4nw2Am08AeP6d8QiLxVMpHkNAtP Rk=; b=qXx9Z6v6P3nWDmqP2V0Gw+6uK3P3yQSrODTuaeg5LyapXS2sqNq43OOmo XOc3wdipLv/KVYV46zvlDMBVzxSUzh9ETA24KRSt15wua1AqdTdgO0lN5tvnT9si nvXtuh7NBMFBoqwpP2hnaKkNY6actSjhiAdzKzD/IffMImDgLbHyujUVO8mUaebo GhDSXdug7jBmg1UesfoyEa9iqzy6dZgqp/D+Hykbc2g4do0vhu3t2w1KGC8HFfLx ckEj7f6INy+3VE1n8bR8odYnBInOFr0A1QzslyPqyj8hjyNLyYeE6B2ejYAec3y7 tvfaQ0QCAH8XEWdvJkSuISvg/i/ww== 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=fm3; bh=tUdz8r+rOa706v4nw2Am08AeP6d8Q iLxVMpHkNAtPRk=; b=McEFXKH5uujw2xwi3SCCTXhjwDC1V3skib6cbRrTYfqXV UQq7nwVfydWdM9kEeCOapxXU9m/8G1a/PYh2OEmHcExXjyyXNyMBkqpqy0X5wPP4 BtTrO4pzOw+6VeIptQolBCNmp5TFvH/SoQsXNncTCt1Nnhnq2eid7nLaHp0GKgpZ sgBMnaPG2C2MNTS1+hVKR5qqyam5S1DUYvi0Gr0zN/PBdTVuJJkLr+ran55esHLR BeyIJR5PPVkrpSwoS7wx4TptYIQ8bomPEiyyv+C1JDYVJ+ySs3tsBZsJRBEigqRj CAAhHh+nsYEhAQjUou/PhlISQNG3ITEV2IxIXhI7A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A51AA621DC; Fri, 15 Jun 2018 23:13:24 -0400 (EDT) Message-Id: <1529118804.1211890.1409848072.26314C20@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152911880412118901" X-Mailer: MessagingEngine.com Webmail Interface - ajax-498d70f2 Date: Sat, 16 Jun 2018 13:13:24 +1000 Archived-At: Subject: [Extra] Session request X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 16 Jun 2018 03:13:28 -0000 This is a multi-part message in MIME format. --_----------=_152911880412118901 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi all, You may have noticed that we don't have a scheduled session at IETF102 yet. I swear I filled in the form, but looking through my email I can't see a confirmation. I've contacted the scheduling people to see if they can set up a session for us. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152911880412118901 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi all,

You may have noticed that we don't have a scheduled session at IETF102 yet.  I swear I filled in the form, but looking through my email I can't see a confirmation.  I've contacted the scheduling people to see if they can set up a session for us.

Regards,

Bron.

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


--_----------=_152911880412118901-- From nobody Mon Jun 18 15:27: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 6BE50129385; Mon, 18 Jun 2018 15:27:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, lflynn@amsl.com, extra-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152936085736.2726.10635538935756179777.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2018 15:27:37 -0700 Archived-At: Subject: [Extra] extra - New Meeting Session Request for IETF 102 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 22:27:38 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dmarc regext dispatch dcrup doh uta Second Priority: oauth saag tls ace dnsop calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Flipcharts: please specify number in Special Requests field Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: One flipchart please --------------------------------------------------------- From nobody Thu Jun 21 14:59: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 F075F130E1B for ; Thu, 21 Jun 2018 14:59:38 -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=DY/BWdFn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pshrAobZ 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 A1-Z0fz_F0G6 for ; Thu, 21 Jun 2018 14:59:36 -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 5CCA5130E30 for ; Thu, 21 Jun 2018 14:59:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 89A0521BFC; Thu, 21 Jun 2018 17:59:35 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 21 Jun 2018 17:59:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=77D1d1 Xb7IhdT8ap1gqT/3zy2ME5oodXZu9X8jqDmS0=; b=DY/BWdFndYG9v2WEJpeDhe 2LcquESKOtABYAKL4ZUpGjUNgLD5TTSzetH3wE/rmt8zhWxwJlwJW1w/QcGkH3RX 3FWGLo4u6gmXFek4RB7PQkXm9LzXtn5ZaZiKpAHRHsdMqQOyfQhV6E7bf+/m7eOE zMO/PBmu3BOBxtTouV2zNXH/rEhzKhDyF89RTM3wQaBDe55PQ9Bla2g3c9M586hl 01EOPtwhGNpWeyWCLBV75ByuPNdzMur8qUUKr+IIX/zYApjpRymmjU5or0r3m9En vElr6rfiq1jKh0vZXV6e8c7sjiMDmBRJhHl7721W7VZhXZ52H+iV1yQJKzdHF8dg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=77D1d1 Xb7IhdT8ap1gqT/3zy2ME5oodXZu9X8jqDmS0=; b=pshrAobZXSiLLCZelxCpxa OndJqNik4x6QjGYJhWM3BrIRivxVI9yDPlphlIYhRLNCZX9CYph80rHN57gDFidx AZeD43NPvZEVDAdNXRQL+p+vfNyzNSaiEvntcHxKd/SkyylhJxgGiMgJgiG0go5w nbK0xSffUxrhfUIFXBR8jhrnw95j1Vd7+iqXiB7Ry5r0KEVCgIgrzuhCvOxs33aG h9H9tLkN9aNKSNRFJrfS1e6pa8c5bHwE2UIKQ7QrHt3u/U9QzJ4A4LPwwR7/XUv2 QQ+ravU74y5nezfyxRFNU/OI1TNj5YtNgnPgXSwQruQ+EtJVWH9lZqa+Tmo6gRhw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4E89D9E1D2; Thu, 21 Jun 2018 17:59:35 -0400 (EDT) Message-Id: <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> From: Bron Gondwana To: Barry Leiba Cc: extra@ietf.org, Linda Dunbar MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152961837524362190" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Fri, 22 Jun 2018 07:59:35 +1000 In-Reply-To: <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.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.26 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, 21 Jun 2018 21:59:39 -0000 This is a multi-part message in MIME format. --_----------=_152961837524362190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The author has contacted me to see if I can figure out what's going on. As far as he's aware he made the changes in -02 which the working group agreed were necessary. What's the next step here? Thanks, Bron. On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote: > On Tue, May 15, 2018, at 02:00, Barry Leiba wrote: >>> On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: >>>=20 >>> 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= mailbox 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 >>>=20 >>>=20 >>> 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 t= hat the >>> answers>>> to your questions are: >>>=20 >>> 1) like all STATUS responses, this is the state of the mailbox on >>> the>>> server. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I will send this back to the author and request clarifying language >>> be added>>> to address these three questions. >>=20 >> 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 spe= cs, and >> people implementing this have to be familiar with the relevant IMAP >> specs. >>=20 >> 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. >=20 > Following on from this - the document is currently held in "Waiting > on Authors".>=20 > The author made an update in -02 to clarify some wording for those who > aren't familiar with the related specifications.>=20 > Linda - can you please review -02 and see if it resolves your > objections.>=20 > Thanks, >=20 > Bron. >=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152961837524362190 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
The author has contacted me to see = if I can figure out what's going on. As far as he's aware he made the chang= es in -02 which the working group agreed were necessary.

What's the next step here?

Thanks,

Bron.


On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote:
On Tue, May 15,= 2018, at 02:00, Barry Leiba wrote:
On Mon, 14 May 2018, at 11:57, L= inda 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 m= e, clearly
I'm too embedded in the IMAP world already, so I would say that the an= swers
to your questions are:

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

2) any clients which don't keep a full copy of the IMAP mailbox may st= ill
wish to be able to quickly identify the mailboxes using the most amoun= t of
storage - for example to allow the the user to remove large messages w= hen
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.

Really?  I don't think there's anything the author needs to do: a= ll 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.

Following on from this - the document is = currently held in "Waiting on Authors".

The author made an update in -02 to clari= fy some wording for those who aren't familiar with the related specificatio= ns.

Linda - can you please review -02 and see= if it resolves your objections.

Thanks,

Bron.

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


_______________________________________________
Extra mailing list

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


--_----------=_152961837524362190-- From nobody Thu Jun 21 15:07: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 7326C130E3A for ; Thu, 21 Jun 2018 15:07:23 -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 zwERRMpmDwaH for ; Thu, 21 Jun 2018 15:07:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 B65A31310EA for ; Thu, 21 Jun 2018 15:07:16 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4226A5D5A423F for ; Thu, 21 Jun 2018 23:07:13 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 21 Jun 2018 23:07:14 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.90]) by SJCEML703-CHM.china.huawei.com ([169.254.5.167]) with mapi id 14.03.0382.000; Thu, 21 Jun 2018 15:07:07 -0700 From: Linda Dunbar To: Bron Gondwana , Barry Leiba CC: "extra@ietf.org" Thread-Topic: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01 Thread-Index: AQHT6yom0FknvKApfUe3irZJ4Gs0gKRrgCAggAABwmA= Date: Thu, 21 Jun 2018 22:07:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0725B7@sjceml521-mbs.china.huawei.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> In-Reply-To: <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.89] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0725B7sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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.26 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, 21 Jun 2018 22:07:24 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B0725B7sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aG91Z2h0IEkgcmVzcG9uZGVkLiBUaGUgdXBkYXRlZCAwMiB2ZXJzaW9uIGlzIGNsZWFyLg0K DQpUaGFua3MsIGxpbmRhDQoNCkZyb206IEJyb24gR29uZHdhbmEgW21haWx0bzpicm9uZ0BmYXN0 bWFpbHRlYW0uY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bmUgMjEsIDIwMTggNTowMCBQTQ0KVG86 IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4NCkNjOiBleHRyYUBpZXRmLm9y ZzsgTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJlOiBb RXh0cmFdIE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZXh0cmEtaW1hcC1z dGF0dXMtc2l6ZS0wMQ0KDQpUaGUgYXV0aG9yIGhhcyBjb250YWN0ZWQgbWUgdG8gc2VlIGlmIEkg Y2FuIGZpZ3VyZSBvdXQgd2hhdCdzIGdvaW5nIG9uLiBBcyBmYXIgYXMgaGUncyBhd2FyZSBoZSBt YWRlIHRoZSBjaGFuZ2VzIGluIC0wMiB3aGljaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZWQgd2Vy ZSBuZWNlc3NhcnkuDQoNCldoYXQncyB0aGUgbmV4dCBzdGVwIGhlcmU/DQoNClRoYW5rcywNCg0K QnJvbi4NCg0KDQpPbiBGcmksIEp1biAxNSwgMjAxOCwgYXQgMTU6NDAsIEJyb24gR29uZHdhbmEg d3JvdGU6DQpPbiBUdWUsIE1heSAxNSwgMjAxOCwgYXQgMDI6MDAsIEJhcnJ5IExlaWJhIHdyb3Rl Og0KT24gTW9uLCAxNCBNYXkgMjAxOCwgYXQgMTE6NTcsIExpbmRhIER1bmJhciB3cm90ZToNCg0K UmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQoNClJldmll d2VyOiBMaW5kYSBEdW5iYXINClJldmlldyByZXN1bHQ6IG5lZWQgbW9yZSBjb21wbGV0ZSBkZXNj cmlwdGlvbg0KDQpBZnRlciByZWFkaW5nIHRocm91Z2ggdGhlIGRvY3VtZW50LCBJIGZpbmQgdGhl IGRlc2NyaXB0aW9uIGlzIG5vdCB2ZXJ5DQpjbGVhci4NCkZvciBleGFtcGxlOg0KU2VjdGlvbiAx IEludHJvZHVjdGlvbjoNCklzIHRoZSDigJxtYWlsYm944oCdIHJlZmVycmluZyB0byB0aGUgSU1B UCBjbGllbnTigJlzIG1haWxib3ggb3IgdGhlIHNlcnZlcg0KbWFpbGJveA0Kd2hlcmUgYWxsIGVt YWlscyBhcmUgc3RvcmVkPw0KDQoNCldoeSBkbyBXZWJtYWlsIGNsaWVudHMgbmVlZCB0byBrbm93 IHRoZSBzZXJ2ZXIgc2lkZSBtYWlsYm94IHNpemU/DQoNCkRvZXMgdGhlIOKAnG1haWxib3ggc2l6 ZeKAnSBjaGFuZ2Ugb3ZlcnRpbWU/DQoNClRoYW5rcy4gTGluZGEgRHVuYmFyDQoNCg0KVGhhbmtz IExpbmRhLiAgSSBhZG1pdCB0aGF0IG5vbmUgb2YgdGhlc2UgcXVlc3Rpb25zIG9jY3VycmVkIHRv IG1lLCBjbGVhcmx5DQpJJ20gdG9vIGVtYmVkZGVkIGluIHRoZSBJTUFQIHdvcmxkIGFscmVhZHks IHNvIEkgd291bGQgc2F5IHRoYXQgdGhlIGFuc3dlcnMNCnRvIHlvdXIgcXVlc3Rpb25zIGFyZToN Cg0KMSkgbGlrZSBhbGwgU1RBVFVTIHJlc3BvbnNlcywgdGhpcyBpcyB0aGUgc3RhdGUgb2YgdGhl IG1haWxib3ggb24gdGhlDQpzZXJ2ZXIuDQoNCjIpIGFueSBjbGllbnRzIHdoaWNoIGRvbid0IGtl ZXAgYSBmdWxsIGNvcHkgb2YgdGhlIElNQVAgbWFpbGJveCBtYXkgc3RpbGwNCndpc2ggdG8gYmUg YWJsZSB0byBxdWlja2x5IGlkZW50aWZ5IHRoZSBtYWlsYm94ZXMgdXNpbmcgdGhlIG1vc3QgYW1v dW50IG9mDQpzdG9yYWdlIC0gZm9yIGV4YW1wbGUgdG8gYWxsb3cgdGhlIHRoZSB1c2VyIHRvIHJl bW92ZSBsYXJnZSBtZXNzYWdlcyB3aGVuDQp0aGV5IGFyZSBhcHByb2FjaGluZyB0aGVpciBzdG9y YWdlIHF1b3RhLg0KDQozKSBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsICJtYWlsYm94IHNp emUiIGlzIGJhc2VkIG9uIHRoZSBzdG9yYWdlIHVzZWQNCmJ5IHRoZSBtZXNzYWdlcyBpbiB0aGUg bWFpbGJveCwgc28gaXQgd2lsbCBuYXR1cmFsbHkgY2hhbmdlIGlmIHRoZSBzZXQgb2YNCm1lc3Nh Z2VzIGluIHRoZSBtYWlsYm94IGNoYW5nZSwgZWl0aGVyIHRocm91Z2ggYWRkaW5nIG5ldyBtZXNz YWdlcywgb3INCmV4cHVuZ2luZyBleGlzdGluZyBtZXNzYWdlcy4NCg0KSSB3aWxsIHNlbmQgdGhp cyBiYWNrIHRvIHRoZSBhdXRob3IgYW5kIHJlcXVlc3QgY2xhcmlmeWluZyBsYW5ndWFnZSBiZSBh ZGRlZA0KdG8gYWRkcmVzcyB0aGVzZSB0aHJlZSBxdWVzdGlvbnMuDQoNClJlYWxseT8gIEkgZG9u J3QgdGhpbmsgdGhlcmUncyBhbnl0aGluZyB0aGUgYXV0aG9yIG5lZWRzIHRvIGRvOiBhbGwgb2YN CnRoaXMgaXMgY2xlYXIgdG8gcGVvcGxlIGZhbWlsaWFyIHdpdGggdGhlIHJlbGV2YW50IElNQVAg c3BlY3MsIGFuZA0KcGVvcGxlIGltcGxlbWVudGluZyB0aGlzIGhhdmUgdG8gYmUgZmFtaWxpYXIg d2l0aCB0aGUgcmVsZXZhbnQgSU1BUA0Kc3BlY3MuDQoNCkl0IGRvZXNuJ3QgaHVydCB0byBoYXZl IGEgbG9vayBhbmQgc2VlIHdoZXRoZXIgdGhlcmUgYXJlIHJlYXNvbmFibGUNCmNsYXJpZmljYXRp b25zIHRvIG1ha2UsIGJ1dCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBzcGVuZCB0b28gbXVjaA0K dGltZSBvbiB0aGF0IGZvciB0aGVzZSBpc3N1ZXMuDQoNCkZvbGxvd2luZyBvbiBmcm9tIHRoaXMg LSB0aGUgZG9jdW1lbnQgaXMgY3VycmVudGx5IGhlbGQgaW4gIldhaXRpbmcgb24gQXV0aG9ycyIu DQoNClRoZSBhdXRob3IgbWFkZSBhbiB1cGRhdGUgaW4gLTAyIHRvIGNsYXJpZnkgc29tZSB3b3Jk aW5nIGZvciB0aG9zZSB3aG8gYXJlbid0IGZhbWlsaWFyIHdpdGggdGhlIHJlbGF0ZWQgc3BlY2lm aWNhdGlvbnMuDQoNCkxpbmRhIC0gY2FuIHlvdSBwbGVhc2UgcmV2aWV3IC0wMiBhbmQgc2VlIGlm IGl0IHJlc29sdmVzIHlvdXIgb2JqZWN0aW9ucy4NCg0KVGhhbmtzLA0KDQpCcm9uLg0KDQotLQ0K ICBCcm9uIEdvbmR3YW5hLCBDRU8sIEZhc3RNYWlsIFB0eSBMdGQNCiAgYnJvbmdAZmFzdG1haWx0 ZWFtLmNvbTxtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbT4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0cmEgbWFpbGluZyBsaXN0DQpF eHRyYUBpZXRmLm9yZzxtYWlsdG86RXh0cmFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2V4dHJhDQoNCi0tDQogIEJyb24gR29uZHdhbmEsIENFTywgRmFz dE1haWwgUHR5IEx0ZA0KICBicm9uZ0BmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpicm9uZ0BmYXN0 bWFpbHRlYW0uY29tPg0KDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F66B0725B7sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aG91Z2h0IEkg cmVzcG9uZGVkLiBUaGUgdXBkYXRlZCAwMiB2ZXJzaW9uIGlzIGNsZWFyLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIGxpbmRhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBCcm9uIEdvbmR3YW5hIFttYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxOCA1OjAwIFBNPGJyPg0KPGI+VG86 PC9iPiBCYXJyeSBMZWliYSAmbHQ7YmFycnlsZWliYUBjb21wdXRlci5vcmcmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBleHRyYUBpZXRmLm9yZzsgTGluZGEgRHVuYmFyICZsdDtsaW5kYS5kdW5iYXJAaHVh d2VpLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFeHRyYV0gT3BzZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1leHRyYS1pbWFwLXN0YXR1cy1zaXplLTAxPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgYXV0aG9y IGhhcyBjb250YWN0ZWQgbWUgdG8gc2VlIGlmIEkgY2FuIGZpZ3VyZSBvdXQgd2hhdCdzIGdvaW5n IG9uLiBBcyBmYXIgYXMgaGUncyBhd2FyZSBoZSBtYWRlIHRoZSBjaGFuZ2VzIGluIC0wMiB3aGlj aCB0aGUgd29ya2luZyBncm91cCBhZ3JlZWQgd2VyZSBuZWNlc3NhcnkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaGF0J3Mg dGhlIG5leHQgc3RlcCBoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QnJvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBKdW4gMTUsIDIwMTgsIGF0IDE1OjQwLCBCcm9uIEdvbmR3YW5hIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBNYXkg MTUsIDIwMTgsIGF0IDAyOjAwLCBCYXJyeSBMZWliYSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCAxNCBN YXkgMjAxOCwgYXQgMTE6NTcsIExpbmRhIER1bmJhciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3ZXI6IExpbmRhIER1bmJh cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2 aWV3IHJlc3VsdDogTm90IFJlYWR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBMaW5kYSBEdW5iYXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlldyByZXN1bHQ6IG5lZWQg bW9yZSBjb21wbGV0ZSBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciByZWFkaW5nIHRocm91Z2ggdGhlIGRvY3VtZW50 LCBJIGZpbmQgdGhlIGRlc2NyaXB0aW9uIGlzIG5vdCB2ZXJ5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGVhci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAxIEludHJv ZHVjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklzIHRoZSDigJxtYWlsYm944oCdIHJlZmVycmluZyB0byB0aGUgSU1BUCBjbGllbnTigJlz IG1haWxib3ggb3IgdGhlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+bWFpbGJveDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlcmUgYWxsIGVtYWlscyBhcmUgc3RvcmVkPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBkbyBX ZWJtYWlsIGNsaWVudHMgbmVlZCB0byBrbm93IHRoZSBzZXJ2ZXIgc2lkZSBtYWlsYm94IHNpemU/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRv ZXMgdGhlIOKAnG1haWxib3ggc2l6ZeKAnSBjaGFuZ2Ugb3ZlcnRpbWU/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy4gTGluZGEgRHVu YmFyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmtzIExpbmRhLiZuYnNwOyBJIGFkbWl0IHRoYXQgbm9uZSBvZiB0aGVzZSBxdWVzdGlv bnMgb2NjdXJyZWQgdG8gbWUsIGNsZWFybHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSB0b28gZW1iZWRkZWQgaW4gdGhlIElNQVAgd29ybGQg YWxyZWFkeSwgc28gSSB3b3VsZCBzYXkgdGhhdCB0aGUgYW5zd2VyczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8geW91ciBxdWVzdGlvbnMgYXJl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4x KSBsaWtlIGFsbCBTVEFUVVMgcmVzcG9uc2VzLCB0aGlzIGlzIHRoZSBzdGF0ZSBvZiB0aGUgbWFp bGJveCBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MikgYW55IGNsaWVudHMgd2hpY2ggZG9uJ3Qga2VlcCBhIGZ1bGwgY29weSBv ZiB0aGUgSU1BUCBtYWlsYm94IG1heSBzdGlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2lzaCB0byBiZSBhYmxlIHRvIHF1aWNrbHkgaWRlbnRp ZnkgdGhlIG1haWxib3hlcyB1c2luZyB0aGUgbW9zdCBhbW91bnQgb2Y8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0b3JhZ2UgLSBmb3IgZXhhbXBs ZSB0byBhbGxvdyB0aGUgdGhlIHVzZXIgdG8gcmVtb3ZlIGxhcmdlIG1lc3NhZ2VzIHdoZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZXkgYXJl IGFwcHJvYWNoaW5nIHRoZWlyIHN0b3JhZ2UgcXVvdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1 bWVudCwgJnF1b3Q7bWFpbGJveCBzaXplJnF1b3Q7IGlzIGJhc2VkIG9uIHRoZSBzdG9yYWdlIHVz ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ5 IHRoZSBtZXNzYWdlcyBpbiB0aGUgbWFpbGJveCwgc28gaXQgd2lsbCBuYXR1cmFsbHkgY2hhbmdl IGlmIHRoZSBzZXQgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPm1lc3NhZ2VzIGluIHRoZSBtYWlsYm94IGNoYW5nZSwgZWl0aGVyIHRocm91Z2gg YWRkaW5nIG5ldyBtZXNzYWdlcywgb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmV4cHVuZ2luZyBleGlzdGluZyBtZXNzYWdlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aWxsIHNlbmQg dGhpcyBiYWNrIHRvIHRoZSBhdXRob3IgYW5kIHJlcXVlc3QgY2xhcmlmeWluZyBsYW5ndWFnZSBi ZSBhZGRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+dG8gYWRkcmVzcyB0aGVzZSB0aHJlZSBxdWVzdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWxseT8m bmJzcDsgSSBkb24ndCB0aGluayB0aGVyZSdzIGFueXRoaW5nIHRoZSBhdXRob3IgbmVlZHMgdG8g ZG86IGFsbCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dGhpcyBpcyBjbGVhciB0byBwZW9wbGUgZmFtaWxpYXIgd2l0aCB0aGUgcmVsZXZhbnQg SU1BUCBzcGVjcywgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5wZW9wbGUgaW1wbGVtZW50aW5nIHRoaXMgaGF2ZSB0byBiZSBmYW1pbGlhciB3 aXRoIHRoZSByZWxldmFudCBJTUFQPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5zcGVjcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgZG9lc24ndCBodXJ0IHRvIGhhdmUgYSBsb29rIGFuZCBz ZWUgd2hldGhlciB0aGVyZSBhcmUgcmVhc29uYWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2xhcmlmaWNhdGlvbnMgdG8gbWFrZSwgYnV0IEkg ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHNwZW5kIHRvbyBtdWNoPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aW1lIG9uIHRoYXQgZm9yIHRoZXNlIGlz c3Vlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+Rm9sbG93aW5nIG9uIGZyb20gdGhpcyAtIHRoZSBkb2N1bWVu dCBpcyBjdXJyZW50bHkgaGVsZCBpbiAmcXVvdDtXYWl0aW5nIG9uIEF1dGhvcnMmcXVvdDsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5UaGUgYXV0aG9yIG1hZGUgYW4gdXBkYXRlIGluIC0wMiB0byBjbGFyaWZ5IHNvbWUgd29y ZGluZyBmb3IgdGhvc2Ugd2hvIGFyZW4ndCBmYW1pbGlhciB3aXRoIHRoZSByZWxhdGVkIHNwZWNp ZmljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+TGluZGEgLSBjYW4geW91IHBsZWFzZSByZXZpZXcgLTAyIGFuZCBz ZWUgaWYgaXQgcmVzb2x2ZXMgeW91ciBvYmplY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJyb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg QnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0TWFpbCBQdHkgTHRkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmJy b25nQGZhc3RtYWlsdGVhbS5jb20iPmJyb25nQGZhc3RtYWlsdGVhbS5jb208L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjx1Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC91 PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXh0 cmEgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86RXh0cmFAaWV0Zi5vcmciPkV4dHJhQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9leHRyYSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9leHRyYTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9InNpZzU2NjI5NDE3Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEJyb24gR29uZHdhbmEsIENFTywgRmFz dE1haWwgUHR5IEx0ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tIj5i cm9uZ0BmYXN0bWFpbHRlYW0uY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F66B0725B7sjceml521mbschi_-- From nobody Thu Jun 21 15:09: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 7DC35130E3A for ; Thu, 21 Jun 2018 15:09:38 -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=ecI3NJzb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E4DgztF1 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 ynzyZg2Gj74A for ; Thu, 21 Jun 2018 15:09:36 -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 7BEC0130E1B for ; Thu, 21 Jun 2018 15:09:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CCFE92215C; Thu, 21 Jun 2018 18:09:35 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Thu, 21 Jun 2018 18:09:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=72KUnO OEERTQi/70Ud4kKtNDc702/8H4lib+kGTSMTk=; b=ecI3NJzb+/G5lXO9wMNPr9 SHwnS3nAvpCeWS5ebTVtApV8VNasBuAaGxxGBLU+1jLL1KWLfk6hAUnng+Fe8RDs Opf8SydbYiuBINN/05ccWHWPbNOY/27bceoQ8zEMBegsNc8n7mNZzEsMoBIBcxfG 5LZg7Y2SRA7WTN60G30o9wYzQMsvoE3M0H9FESERFkd/SjoSzJacKnk4ausUAFwd +WYJx16JOAzujStArJjCYBobtZ1ZIRRnE6Hpq5DHkwkWi7gWW9nEQUd+9+TPfT+o 3aYUeuwMRi/aSUEr4+rJQkmpnBfGng5XZ/SXKWTuXQtutwjpKGJpMGnuP4f/0JyA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=72KUnO OEERTQi/70Ud4kKtNDc702/8H4lib+kGTSMTk=; b=E4DgztF1RBW7KXrYKnAPM+ VX/c3FMWf/9y3YwaJuCEvt4LlLHpDqsbpuFKnIsZrKlre/v3pNeOQtv4KPgiubOJ nL3BK9Ci4aAamQNSfoZM6QnO7PyPYbZ11itsLmrU3jTgRfa2CsgarHEiId5TGIeD /8UarWHxEJfw2tUOkt7epr2BiNxgzvDYd5UzLC3lyEhDdka+kQOoWcCjtz3pk2LY x3nronRZ7xNbF6suDhHVqojsZZCZQteJB8/TY8tS/s8RqFBFwyotGl2DgAbp/46G Tbkgn3AM3j3NcP2GXNJo61f5kmh13PX8SQTGsBYAF7TwER7AWc5xii1rvc2Ll42Q == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7DD0CBA43D; Thu, 21 Jun 2018 18:09:35 -0400 (EDT) Message-Id: <1529618975.1243150.1416295016.17F403F5@webmail.messagingengine.com> From: Bron Gondwana To: Linda Dunbar , Barry Leiba Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152961897512431501" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0725B7@sjceml521-mbs.china.huawei.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> <4A95BA014132FF49AE685FAB4B9F17F66B0725B7@sjceml521-mbs.china.huawei.com> Date: Fri, 22 Jun 2018 08:09:35 +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.26 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, 21 Jun 2018 22:09:39 -0000 This is a multi-part message in MIME format. --_----------=_152961897512431501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Can you please clear the needs edit in data tracker. Ta, Bron. On Fri, Jun 22, 2018, at 08:07, Linda Dunbar wrote: > I thought I responded. The updated 02 version is clear. >=20=20 > Thanks, linda >=20=20 > *From:* Bron Gondwana [mailto:brong@fastmailteam.com] *Sent:* > Thursday, June 21, 2018 5:00 PM *To:* Barry Leiba > *Cc:* extra@ietf.org; Linda Dunbar > *Subject:* Re: [Extra] Opsdir last call > review of draft-ietf-extra-imap-status-size-01>=20=20 > The author has contacted me to see if I can figure out what's going > on. As far as he's aware he made the changes in -02 which the working > group agreed were necessary.>=20=20 > What's the next step here? >=20=20 > Thanks, >=20=20 > Bron. >=20=20 >=20=20 > On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote: >> On Tue, May 15, 2018, at 02:00, Barry Leiba wrote: >>>> On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: >>>>=20=20 >>>> Reviewer: Linda Dunbar >>>> Review result: Not Ready >>>>=20=20 >>>> Reviewer: Linda Dunbar >>>> Review result: need more complete description >>>>=20=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=99= s mailbox or the >>>> server>>>> mailbox >>>> where all emails are stored? >>>>=20=20 >>>>=20=20 >>>> Why do Webmail clients need to know the server side mailbox size?>>>>= =20=20 >>>> Does the =E2=80=9Cmailbox size=E2=80=9D change overtime? >>>>=20=20 >>>> Thanks. Linda Dunbar >>>>=20=20 >>>>=20=20 >>>> 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: >>>>=20=20 >>>> 1) like all STATUS responses, this is the state of the mailbox on >>>> the>>>> server. >>>>=20=20 >>>> 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 t= he most >>>> amount of>>>> storage - for example to allow the the user to remove la= rge >>>> messages when>>>> they are approaching their storage quota. >>>>=20=20 >>>> 3) as defined in this document, "mailbox size" is based on the >>>> storage used>>>> by the messages in the mailbox, so it will natural= ly change if the >>>> set of>>>> messages in the mailbox change, either through adding new >>>> messages, or>>>> expunging existing messages. >>>>=20=20 >>>> I will send this back to the author and request clarifying language >>>> be added>>>> to address these three questions. >>>=20=20 >>> 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 IMA= P>>> specs. >>>=20=20 >>> 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. >>=20=20 >> Following on from this - the document is currently held in "Waiting >> on Authors".>>=20=20 >> The author made an update in -02 to clarify some wording for those >> who aren't familiar with the related specifications.>>=20=20 >> Linda - can you please review -02 and see if it resolves your >> objections.>>=20=20 >> Thanks, >>=20=20 >> Bron. >>=20=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20=20 >>=20=20 >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >=20=20 > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com >=20=20 >=20=20 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152961897512431501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Can you please clear the needs edit= in data tracker.

Ta,

Bron.


On Fri, Jun 22, 2018, at 08:07, Linda Dunbar wrote:

I thought I resp= onded. The updated 02 version is clear.<= br>

 

Thanks, linda

=  

= From: Bron Gondwana [mailto:brong@fastmailteam.com] =
Sent: Thursday, June 21, 2018 5:00 PM
To: Barry Leib= a <barryleiba@computer.org>
Cc: extra@ietf.org; Linda Dunb= ar <linda.dunbar@huawei.com>
Subject: Re: [Extra] Opsdir l= ast call review of draft-ietf-extra-imap-status-size-01

 

The author has contacted me to= see if I can figure out what's going on. As far as he's aware he made the = changes in -02 which the working group agreed were necessary.=

 

What's the next step here?

 

Thanks,

 

Bron.

 

 

On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote:

<= span class=3D"font" style=3D"font-family:Arial, sans-serif">On Tue, May 15,= 2018, at 02:00, Barry Leiba wrote:

On Mon, 14 May 201= 8, 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 descript= ion 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 mai= lbox size?

 

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

 

Thanks. Linda Dunbar

 

 

Thanks Linda.  I admit that none of these question= s 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 l= arge 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 ch= ange if the set of

messages in the mailbox change, either through adding n= ew messages, or

expunging existing messages.

 

I will send this back to the author and request clarify= ing language be added

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 r= elevant IMAP

specs.

 

It doesn't hurt to have a look and see whether there ar= e reasonable

clarifications to make, but I don't think we should spe= nd too much

time on that for these issues.

 

Following on from this - the document is currently held in "Waiting o= n Authors".

 

The author made an update in -02 to clarify some wording for those wh= o aren't familiar with the related specifications.
=

 

Linda - can you please review -02 and see if it resolves your objecti= ons.

 

Thanks,

 

Bron.

 

--

  Bron Gondwana, CEO, FastMail Pty Ltd

 

 

_______________________________________________<= /span>

Extra mailing list

 

--

  Bron Gondwana, CEO, FastMail Pty Ltd

 

 


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

--_----------=_152961897512431501-- From nobody Thu Jun 21 15:18: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 5D366130EF9 for ; Thu, 21 Jun 2018 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Bm9gGR67qlZ9 for ; Thu, 21 Jun 2018 15:18:06 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 DDEC5130E48 for ; Thu, 21 Jun 2018 15:18:05 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id k17-v6so3804759ita.0 for ; Thu, 21 Jun 2018 15:18:05 -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=BzGnerbewHdXkrBIq0cOXDcb3avh5IL0LvXiceErS6w=; b=hagia7LjFjuN+zQ9A+q9eKAcDjndGoX3+wTjpKDI8OnSiW2M1/4kwdX9s43Raha2gg nZ9xqxB+IAY0qNAepxQilWXvo4masgqfh3kIIIYUHWNvNsUk44jmo2X8jf5UFK3QqTd1 I+/3xr8oRkSKq/2qTHG34xLnPOA+7D/XJMqOUYEzGu2tAU7qBa+5rrO6KoNAvE+YaDJq et+Fzr0853A5CLWJqlU7+rutu2Eg8DBT/WTV4VcRhp62gFonXAzVpLQcIkK9CkW6eyA2 Cd7upbiuiN8rw1ENOicyNG4JM7uS4FeTgN8p8bfpVJop4vs7mtVwipvEAL6g7YtlZl54 OBFA== 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=BzGnerbewHdXkrBIq0cOXDcb3avh5IL0LvXiceErS6w=; b=OdVO5TXkfOKNvnp0Q+/H2wOvX2A1WyjqMkDO7yCXsxQGT5dq0Uq+HkD3mS2fa0YQ5D dtl2LUp8mzAc7U2pqItudz9WG0Iup2R4pi7e2tpDvpQI7JKzfzV8nH3AsPCeqgeYBBfq TppYfgp1ZbTjWXzpK5U9lWNrITU7JopGtQt98nkGOv4CMA9FPVu2HuRGRutGxSf86Y28 GIrB9qpKCx3Fec7KsmwaGfOirCPGS588lP8XPM+dGKLJ6WXqTYwdWazeHDAGOwFOv098 SGMp3JXA9CgHddcOHZcehEawt+70Kgst2cAOdJWgAShHS+QuHV3f1pjRFX26oqMJghBn +HxA== X-Gm-Message-State: APt69E34uTpF5tctLBIluHyXSM0AuUumUfA9c9kPguWT/RY0ShtT+R7i FjkQ9mkZWLM5UUSWCicOVqKWTKwBqL0EBfzour6AIA== X-Google-Smtp-Source: AAOMgpfEZotmxsdxkFJbxOlsq6+FcqQsQ9+AP8Q69+Bg2TCuJalwRYOozXEcI55561nttkEANf3DRaf4uzKcwNnOQUk= X-Received: by 2002:a24:2e43:: with SMTP id i64-v6mr6770478ita.0.1529619485083; Thu, 21 Jun 2018 15:18:05 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 15:18:04 -0700 (PDT) In-Reply-To: <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> From: Barry Leiba Date: Thu, 21 Jun 2018 18:18:04 -0400 X-Google-Sender-Auth: 5LXGWogiRhCfodLv_PL9NjMnVqI 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.26 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, 21 Jun 2018 22:18:08 -0000 > The author has contacted me to see if I can figure out what's going on. A= s > far as he's aware he made the changes in -02 which the working group agre= ed > were necessary. > > What's the next step here? There's no next step: the document has been approved by the IESG and is in the RFC Editor queue. The directorate reviews are not blocking -- just as with other last-call comments, we need to consider the comments and make a reasonable effort to respond to them and to addres the ones that make sense to address. We think we did that, the IESG thinks we did that, and all is good. I wonder if the author was confused. He'd have gotten a note from IANA that required a response, and it seems like it took him a while to respond to it. But it looks like he did respond, and today the IANA status changed from "waiting on authors" to "waiting on RFC Editor". So, again: the document is approved and in the RFC Editor queue. Nothing needed now. Barry > On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote: > > On Tue, May 15, 2018, at 02:00, Barry Leiba 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 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. > > > Following on from this - the document is currently held in "Waiting on > Authors". > > The author made an update in -02 to clarify some wording for those who > aren't familiar with the related specifications. > > Linda - can you please review -02 and see if it resolves your objections. > > Thanks, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > --=20 Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Thu Jun 21 15:20: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 D3D8F130EF9 for ; Thu, 21 Jun 2018 15:20:41 -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=DzhjoO/l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bBN/hMXy 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 CCQgcXAbzDsB for ; Thu, 21 Jun 2018 15:20:39 -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 15654130E48 for ; Thu, 21 Jun 2018 15:20:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 653D421C5F; Thu, 21 Jun 2018 18:20:38 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Thu, 21 Jun 2018 18:20:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VaVaj0 kaVq9kWNHk0s645mM6ynykXEauN7/MCRgOVys=; b=DzhjoO/lpb1gkxxokuTlgS kzUWbNWVAoKD/c2z6e3GmvHYDcZbzl4yWu4/LybXcxlZF4Ov6CMDkWtiJ2MqiSI+ bXadYqe/mMLqqVjlqRxQbrZQRSc35q+25UToOwHu4CkHUcJdbZfVdPkwwkFT1EKk bq4w7qjhrSz9nvoYzjyQcpYCTllxXlFgNu64BU8Fg7mlFOCk/6Bfm0lTJcV0D7mS ugV6Qucy9P21J6lWiX4jOGHWWzutKQMDmg1B1/Um6iu0oqL9RXZwgfbBRm0M6Wd4 oRFhnxafLID8YEeABC7XTk5vySfjnDZAObzTAX3qTdqaa1mW5XRcqgQ4YAEjjxFw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VaVaj0 kaVq9kWNHk0s645mM6ynykXEauN7/MCRgOVys=; b=bBN/hMXyKvB9eA91aN8n5/ 3IUTa71O3FCDGiI0sOeOPgGhoG1h6Wgg8nioHsj/SK8l9HD52n5shtGhOKcHSy4M XALhYir/Z6idWGUiRXPUbQyToVwbC1ttTc427M/yOPnzJtUZ3O3cG5EEismYQQrk 6TYcX9LXP6mupjPmnXK+aEeQBf5S4ZdF46LNg9Gg91jyHYUG7IBizCIVI4Pik+JC CkDot2Nvizt1cUrzNkRjBORy3MREJkyunHm+dSfv7HBNQSY84pH9Jz3dTe2rBCFi 7+a+ujM0Zt6lOSjCHiOkB+Bsud5HE3rDfhIeUEM67HkJojtb05l0PucYmiCqKlmQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2610BBA43D; Thu, 21 Jun 2018 18:20:38 -0400 (EDT) Message-Id: <1529619637.1246410.1416300872.74CEBAD0@webmail.messagingengine.com> From: Bron Gondwana To: Barry Leiba Cc: extra@ietf.org, Linda Dunbar MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152961963812464100" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <152626307291.10130.11253794031353526719@ietfa.amsl.com> <1526264419.3922153.1370811224.77158013@webmail.messagingengine.com> <1529041219.1127331.1408811104.663D5579@webmail.messagingengine.com> <1529618375.2436219.1416284896.670717DD@webmail.messagingengine.com> In-Reply-To: Date: Fri, 22 Jun 2018 08:20:37 +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.26 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, 21 Jun 2018 22:20:42 -0000 This is a multi-part message in MIME format. --_----------=_152961963812464100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Ok great! Thanks Barry and Linda. Sorry, I'm still very new at this so that wasn't clear to me. Cheers, Bron. On Fri, Jun 22, 2018, at 08:18, Barry Leiba wrote: >> The author has contacted me to see if I can figure out what's >> going on. As>> far as he's aware he made the changes in -02 which the wo= rking >> group agreed>> were necessary. >>=20 >> What's the next step here? >=20 > There's no next step: the document has been approved by the IESG and > is in the RFC Editor queue. > The directorate reviews are not blocking -- just as with other > last-call comments, we need to consider the comments and make a > reasonable effort to respond to them and to addres the ones that make> se= nse to address. We think we did that, the IESG thinks we did that,> and al= l is good. >=20 > I wonder if the author was confused. He'd have gotten a note from > IANA that required a response, and it seems like it took him a while > to respond to it. But it looks like he did respond, and today the > IANA status changed from "waiting on authors" to "waiting on RFC > Editor". >=20 > So, again: the document is approved and in the RFC Editor queue. > Nothing needed now. >=20 > Barry >=20 >> On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote: >>=20 >> On Tue, May 15, 2018, at 02:00, Barry Leiba wrote: >>=20 >> On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote: >>=20 >> 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 = mailbox 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 >>=20 >>=20 >> 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 tha= t the >> answers>> to your questions are: >>=20 >> 1) like all STATUS responses, this is the state of the mailbox on the>> = server. >>=20 >> 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 m= ost >> amount of>> storage - for example to allow the the user to remove large >> messages when>> they are approaching their storage quota. >>=20 >> 3) as defined in this document, "mailbox size" is based on the >> storage used>> by the messages in the mailbox, so it will naturally c= hange if >> the set of>> messages in the mailbox change, either through adding new >> messages, or>> expunging existing messages. >>=20 >> I will send this back to the author and request clarifying language >> be added>> to address these three questions. >>=20 >>=20 >> 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 spe= cs, and >> people implementing this have to be familiar with the relevant IMAP >> specs. >>=20 >> 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. >>=20 >>=20 >> Following on from this - the document is currently held in >> "Waiting on>> Authors". >>=20 >> The author made an update in -02 to clarify some wording for >> those who>> aren't familiar with the related specifications. >>=20 >> Linda - can you please review -02 and see if it resolves your >> objections.>>=20 >> Thanks, >>=20 >> Bron. >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >> _________________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra >>=20 >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >=20 >=20 >=20 > -- > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152961963812464100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Ok great! Thanks Barry and Linda. S= orry, I'm still very new at this so that wasn't clear to me.

Cheers,

Bron.


On Fri, Jun 22, 2018, at 08:18, Barry Leiba wrote:
The author has contacted me to s= ee if I can figure out what's going on. As
far as he's aware he made the changes in -02 which the working group a= greed
were necessary.

What's the next step here?

There's no next step: the document has been approved by the IESG and
is in the RFC Editor queue.
The directorate reviews are not blocking -- just as with other
last-call comments, we need to consider the comments and make a
reasonable effort to respond to them and to addres the ones that make<= br>
sense to address.  We think we did that, the IESG thinks we did t= hat,
and all is good.

I wonder if the author was confused.  He'd have gotten a note fro= m
IANA that required a response, and it seems like it took him a while
to respond to it.  But it looks like he did respond, and today th= e
IANA status changed from "waiting on authors" to "waiting on RFC
Editor".

So, again: the document is approved and in the RFC Editor queue.
Nothing needed now.

Barry

On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote:

On Tue, May 15, 2018, at 02:00, Barry Leiba 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=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 m= e, clearly
I'm too embedded in the IMAP world already, so I would say that the an= swers
to your questions are:

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

2) any clients which don't keep a full copy of the IMAP mailbox may st= ill
wish to be able to quickly identify the mailboxes using the most amoun= t of
storage - for example to allow the the user to remove large messages w= hen
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.


Really?  I don't think there's anything the author needs to do: a= ll 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.


Following on from this - the document is currently held in "Waiting on=
Authors".

The author made an update in -02 to clarify some wording for those who=
aren't familiar with the related specifications.

Linda - can you please review -02 and see if it resolves your objectio= ns.

Thanks,

Bron.

--
Bron Gondwana, CEO, FastMail Pty Ltd


_______________________________________________
Extra mailing list


--
Bron Gondwana, CEO, FastMail Pty Ltd





--
Barry
--
Barry Leiba  (barryleiba@computer.org)

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

--_----------=_152961963812464100-- From nobody Thu Jun 21 18:25:16 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 082F4130DC8; Thu, 21 Jun 2018 18:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jiankang Yao To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Cc: extra@ietf.org, yaojk@cnnic.cn, iesg-secretary@ietf.org, Jiankang Yao , extra-chairs@ietf.org Message-ID: <152963071402.5749.10018244845260163865.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2018 18:25:14 -0700 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-imap-objectid-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 01:25:14 -0000 Jiankang Yao has requested publication of draft-ietf-extra-imap-objectid-03 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ From nobody Fri Jun 29 05:38:07 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 DFC95130ED6; Fri, 29 Jun 2018 05:37:48 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk CC: Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, alexey.melnikov@isode.com, draft-ietf-extra-imap-objectid@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153027586890.30302.12936524042446131356.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2018 05:37:48 -0700 Archived-At: Subject: [Extra] Last Call: (IMAP Extension for object identifiers) to Proposed Standard X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 12:38:00 -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 Extension for object identifiers' 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-07-13. 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 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jun 29 21:13: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 45A87130F1B for ; Fri, 29 Jun 2018 21:13:07 -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=XBeZ5DNj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lpl9zGo9 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 F_4AmgzyJzTH for ; Fri, 29 Jun 2018 21:13:04 -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 CACEE130F01 for ; Fri, 29 Jun 2018 21:13:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 47CFA21C2E for ; Sat, 30 Jun 2018 00:13:04 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 30 Jun 2018 00:13:04 -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=fm3; bh=Y7NtfBcyrbtIDlEZ0RL83Qnu11cqdJ9hUGnxhgmqi LA=; b=XBeZ5DNjpjlfbyAb/h+skgVZ6o5h6yQ7CygBz/ouSsRP7HgllbCl9GwEB VhM07GgXyaUIE2Mu8lTUuIYJAlgMe7/5YGBvE7tuSLaQk7TmhXqY1PI2fhf4J8hM iW326Me3UQzhGcw39uSkBomRRifx+ogfDJEc27jVYhY8okxrvtSdAKqya1rceYlu oUMyRgh01LtGLmaAoGDHx8Hpu390rqK8PBr7eqxbwLV6Ii9/leo/+VO/Nb+Vdpbt bO1tmHyoXUyyb2qgDdMa8z9ytNA0bHDbe93ONTHNFSYK4PA6JZo/BYnZk0HldCr8 8SLJLeOcgCWPaUMyZ7hlpkOlFlBlA== 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=fm3; bh=Y7NtfBcyrbtIDlEZ0RL83Qnu11cqd J9hUGnxhgmqiLA=; b=Lpl9zGo9tG/y10QSKWaD6NCP+u9ZdsXUflh/zzmjwZv7P MpHSTZPnDAUHjUWPYpCZz8z5PpM8zkUqolpmMqZLtdivFVTenfwz8QUm3MatA9iN m0Z3bjuKY6/CJtJpFX0yjUXNX19JOE+2IEUlYjvr+yiz59ArHwUqPp27FzAhazab QjncEpKqoJmlrYCqpYVPvbhHVVATVA06+Q6bep0hVeuZVUER/7b8ct6LZt9XUzwZ 2H5NRR+gGXTlRAnboGEpqGdzKXSxNqHwZ7IpJLttMD2gWGanK7El7ykdXVrWWa4d TSdv6Utc/iCs0k1wxj07BKkanNZEGx+3Ylv+cHh6w== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C4245621DC; Sat, 30 Jun 2018 00:13:03 -0400 (EDT) Message-Id: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153033198323597270" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Sat, 30 Jun 2018 14:13:03 +1000 Archived-At: Subject: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 04:13:08 -0000 This is a multi-part message in MIME format. --_----------=_153033198323597270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ. It adds said field on both mailboxes and emails. CREATEDMODSEQ will reference OBJECTID, and has the following properties: 1) When a mailbox is created, it gets the same CREATEDMODSEQ as the HIGHESTMODSEQ at time of creation (either == 1, or if the mailstore uses a single modseq counter for everything on a user, the next modseq for that user) 2) When a mailbox gets renamed, it retains the same CREATEDMODSEQ (so long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD) 3) When an email is created, it gets the same CREATEDMODSEQ as the MODSEQ (== next modseq on that mailbox) 4) When an email is copied/moved, it depends on store behaviour - if mailboxes have different HIGHESTMODSEQ counters then it gets a new CREATEDMODSEQ for the new mailbox - but if they're part of the same modseq namespace, then it keeps the original CREATEDMODSEQ. 5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT be updated. CREATEDMODSEQ becomes a STATUS response at the mailbox level. CREATEDMODSEQ becomes a FETCH response at the email level. I'd be very happy to see suggestions for different names so that they're not confusable... Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153033198323597270 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails.  CREATEDMODSEQ will reference OBJECTID, and has the following properties:

1) When a mailbox is created, it gets the same CREATEDMODSEQ as the HIGHESTMODSEQ at time of creation (either == 1, or if the mailstore uses a single modseq counter for everything on a user, the next modseq for that user)

2) When a mailbox gets renamed, it retains the same CREATEDMODSEQ (so long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD)

3) When an email is created, it gets the same CREATEDMODSEQ as the MODSEQ (== next modseq on that mailbox)

4) When an email is copied/moved, it depends on store behaviour - if mailboxes have different HIGHESTMODSEQ counters then it gets a new CREATEDMODSEQ for the new mailbox - but if they're part of the same modseq namespace, then it keeps the original CREATEDMODSEQ.

5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT be updated.

CREATEDMODSEQ becomes a STATUS response at the mailbox level.

CREATEDMODSEQ becomes a FETCH response at the email level.

I'd be very happy to see suggestions for different names so that they're not confusable...

Cheers,

Bron.

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


--_----------=_153033198323597270-- From nobody Fri Jun 29 21:30: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 F1FEE130E54 for ; Fri, 29 Jun 2018 21:30:38 -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=hHVL/ggB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BekMcsb8 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 PNL7mHS6Rv0P for ; Fri, 29 Jun 2018 21:30:37 -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 3C8F1130E53 for ; Fri, 29 Jun 2018 21:30:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A3930222BD for ; Sat, 30 Jun 2018 00:30:36 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 30 Jun 2018 00:30:36 -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=fm3; bh=HBMzL70a8jN/Y9h98 pHbz3boMLuFUaq7iH0pzVRPMUs=; b=hHVL/ggBloHgYX2D0pTVjqXbbC0eVohqz H5bDrcBbCcePtVKuSGUOwtCbo9e9Yzd/v0hjll2c2g4DelbMkvNsgUG8pazRJUFT za5fZTwdPXvfxMJZ2rE9HgwfyWaYuOVA5o9lOznCL7jmGyjNh2FExxdrOnHElH9Y 6bElmzZsGuYHvxCy8LtjFmU294ZVPkqT8DVqufMPf/UYGsaZGyLg2A5+aNKE/seY c5UJTRx1Rs+CCb77/CQENKH982VVcXZ5kcMHd19yGpue6iojGplE7c9TZ8VAWYkZ VLMqDX17jRV2u7lG3Iirfg0SrsFsWktvoELFoFeUl1wTaw2ApSvpQ== 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=fm3; bh=HBMzL7 0a8jN/Y9h98pHbz3boMLuFUaq7iH0pzVRPMUs=; b=BekMcsb8Hyd6093oViJEFQ GNg0ynuIoBGOQLvTkPnOEGK+9MDzBZxou0krajADm4k+PCmSEaLkxB5ElnhFGoL/ bIlHNluSLFETPszMrLz/xg0woKc0FJ1uOMijr9f9hpbeUKsSNJyGEOs7I5mFuUJA XtgBvesos+sNJX1CSS6JYWwMOKEqt5jRWIgSHsmNkOENviSqxDfAddV6YRCXw3Pp 49esucMe7JnSsoS5Y1j0bmbz4tCZEby4nAXHCdTFOgLB/maKFpasLB0+d1d9PLoK Z11Vv3x9sEYdTuvLZJke/0odOfN/mO0G6qcM+ehEm8Ymbc6SXStFDlKZ9C/j6zFA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 36D1B621DC; Sat, 30 Jun 2018 00:30:36 -0400 (EDT) Message-Id: <1530333036.2364363.1425406744.412FE83F@webmail.messagingengine.com> From: Bron Gondwana To: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153033303623643630" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> Date: Sat, 30 Jun 2018 14:30:36 +1000 In-Reply-To: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 04:30:39 -0000 This is a multi-part message in MIME format. --_----------=_153033303623643630 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" One more thing - I'm planning to reference the REPLACE extension with a general statement along the lines of: The server MAY set the CREATEDMODSEQ to a value lower than the MODSEQ on an email in the case where it knows that it's an update to an existing message rather than a new message, for example servers implementing the REPLACE extension SHOULD retain the CREATEDMODSEQ of the replaced message on the newly created message. This means that a replacement of an existing draft with a new draft won't look like a brand new message. NOTE: I haven't thought about this maybe as much as I need to... so let me know if I'm being silly here... Cheers, Bron. On Sat, Jun 30, 2018, at 14:13, Bron Gondwana wrote: > Hi All, > > I'm working on a doc (and implementation) for an extension to RFC7162 > - CREATEDMODSEQ. It adds said field on both mailboxes and emails. > CREATEDMODSEQ will reference OBJECTID, and has the following > properties:> > 1) When a mailbox is created, it gets the same CREATEDMODSEQ as the > HIGHESTMODSEQ at time of creation (either == 1, or if the mailstore > uses a single modseq counter for everything on a user, the next > modseq for that user)> > 2) When a mailbox gets renamed, it retains the same CREATEDMODSEQ (so > long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD)> > 3) When an email is created, it gets the same CREATEDMODSEQ as the > MODSEQ (== next modseq on that mailbox)> > 4) When an email is copied/moved, it depends on store behaviour - if > mailboxes have different HIGHESTMODSEQ counters then it gets a new > CREATEDMODSEQ for the new mailbox - but if they're part of the same > modseq namespace, then it keeps the original CREATEDMODSEQ.> > 5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT be > updated.> > CREATEDMODSEQ becomes a STATUS response at the mailbox level. > > CREATEDMODSEQ becomes a FETCH response at the email level. > > I'd be very happy to see suggestions for different names so that > they're not confusable...> > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _________________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153033303623643630 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
One more thing - I'm planning to reference the REPLACE extension with a general statement along the lines of:

The server MAY set the CREATEDMODSEQ to a value lower than the MODSEQ on an email in the case where it knows that it's an update to an existing message rather than a new message, for example servers implementing the REPLACE extension SHOULD retain the CREATEDMODSEQ of the replaced message on the newly created message.

This means that a replacement of an existing draft with a new draft won't look like a brand new message.

NOTE: I haven't thought about this maybe as much as I need to... so let me know if I'm being silly here...

Cheers,

Bron.


On Sat, Jun 30, 2018, at 14:13, Bron Gondwana wrote:
Hi All,

I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails.  CREATEDMODSEQ will reference OBJECTID, and has the following properties:

1) When a mailbox is created, it gets the same CREATEDMODSEQ as the HIGHESTMODSEQ at time of creation (either == 1, or if the mailstore uses a single modseq counter for everything on a user, the next modseq for that user)

2) When a mailbox gets renamed, it retains the same CREATEDMODSEQ (so long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD)

3) When an email is created, it gets the same CREATEDMODSEQ as the MODSEQ (== next modseq on that mailbox)

4) When an email is copied/moved, it depends on store behaviour - if mailboxes have different HIGHESTMODSEQ counters then it gets a new CREATEDMODSEQ for the new mailbox - but if they're part of the same modseq namespace, then it keeps the original CREATEDMODSEQ.

5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT be updated.

CREATEDMODSEQ becomes a STATUS response at the mailbox level.

CREATEDMODSEQ becomes a FETCH response at the email level.

I'd be very happy to see suggestions for different names so that they're not confusable...

Cheers,

Bron.

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


_______________________________________________
Extra mailing list

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


--_----------=_153033303623643630-- From nobody Sat Jun 30 05:02: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 032E11310AD for ; Sat, 30 Jun 2018 05:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 KuMqVFphEICR for ; Sat, 30 Jun 2018 05:02:06 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id CDBC4130DFA for ; Sat, 30 Jun 2018 05:02:05 -0700 (PDT) Received: from [192.168.10.102] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id 794462B3CCA; Sat, 30 Jun 2018 12:02:04 +0000 (UTC) From: Timo Sirainen Message-Id: <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E4852EF-5DB8-404F-B92E-141A954086C1" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 30 Jun 2018 15:02:03 +0300 In-Reply-To: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> Cc: extra@ietf.org To: Bron Gondwana References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 12:02:09 -0000 --Apple-Mail=_5E4852EF-5DB8-404F-B92E-141A954086C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Jun 2018, at 7.13, Bron Gondwana wrote: >=20 > I'm working on a doc (and implementation) for an extension to RFC7162 = - CREATEDMODSEQ. It adds said field on both mailboxes and emails.=20 What's your planned use case(s) for this? I can't really think of any. --Apple-Mail=_5E4852EF-5DB8-404F-B92E-141A954086C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 30 Jun 2018, at 7.13, Bron Gondwana <brong@fastmailteam.com> wrote:

I'm working on a doc (and implementation) for an = extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both = mailboxes and emails. 

What's your planned use case(s) for this? I can't = really think of any.

= --Apple-Mail=_5E4852EF-5DB8-404F-B92E-141A954086C1-- From nobody Sat Jun 30 06:26:47 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 A495B130E89 for ; Sat, 30 Jun 2018 06:26:45 -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=jZWkSP8X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PmdpNEFR 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 AKSqe08W-wY7 for ; Sat, 30 Jun 2018 06:26:43 -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 AAB23130E6E for ; Sat, 30 Jun 2018 06:26:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0C4F721945; Sat, 30 Jun 2018 09:26:43 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sat, 30 Jun 2018 09:26:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Pm5zI7 mBTqhxh+S4XkOl0Eh+NdQ0Tx30xgNZyjVCG38=; b=jZWkSP8XDjpd/2kp1SYwm7 /Ovn0cmvpUEwwbGxZsPqJkZZmAubLcrgtXkmU+wH/Cp0KDzREwz1eV2/HA6qUedE uFGg4lG1fP4uKWnP5XjJuTs/TGVhi3Id37PzoirY6T90cTesWtCE56AUoy09cOJz syBU0a1EQu6KzTPDd1twkdXXIGcTX5qywpPBiBciES1WxByOlrFdA5lGnBbtWCVq jnYP5hdk1O9DcRMH3gH+pD5UK1QXCBhIdD07d3OhbLxl+hqhQv2AYz58J5Ijq5Lk eBxeybrd/oh/sJqR8uy7NyWqrjIWoRCByBoRCP5s4MC0VoTNFr5KFfY1OzDjq0VA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Pm5zI7 mBTqhxh+S4XkOl0Eh+NdQ0Tx30xgNZyjVCG38=; b=PmdpNEFRrdRvnn5dRD+40q zxGi1IQFaNYULUPJV+/pU3NGRiYopOVNq2zSiQUhjZv0JE9AcEa7smQTcreRfcqh wmkqIAglAmNAchuafiPGqUiXYygwNsXQq7UJgc0RQ2rF0y5D/dyD1VY0Hs8m/+RE eYp0D4GoNTgIMq2dS07pkxd4UeEI4Ed1/vueAQ9FlMCRHPebduvmZeCWPXZNn2Qk 2i+nlFjuathLkH/vEgDXSrtxv9mZGvG0aXvpLXO+HIFR2eip/ttcqxg1cPv/oH3j pc7HxIZmjNeqdhFz+1TSfvAl9KSYLL5l9NSnppoHPqrDnAu0Imq4LpKZ5fGJ2H2A == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AE78F621DC; Sat, 30 Jun 2018 09:26:42 -0400 (EDT) Message-Id: <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> From: Bron Gondwana To: Timo Sirainen Cc: extra@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153036520233850730" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> Date: Sat, 30 Jun 2018 23:26:42 +1000 In-Reply-To: <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 13:26:46 -0000 This is a multi-part message in MIME format. --_----------=_153036520233850730 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote: > On 30 Jun 2018, at 7.13, Bron Gondwana wrote:>> >> I'm working on a doc (and implementation) for an extension to RFC7162 >> - CREATEDMODSEQ. It adds said field on both mailboxes and emails.> > What's your planned use case(s) for this? I can't really think of any. So the main use-case I'm working with at the moment is "phone client wants to create a notification to user of new mail, but NOT throw up a new mail notification if the user just moved an email from Inbox to a notified folder in another client". So the phone client needs to be able to distinguish "this message has newly arrived in the mailstore" vs "this message has just been updated in some way". This piece of data is also being used in JMAP to underly the calculation for whether a message (or thread) should be in the added or changed result. And likewise for mailboxes, the createdmodseq on mailboxes is used to distingish between "got renamed" and "newly created". Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153036520233850730 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote:
On 30 Jun 2018, at 7.13, Bron Gondwana <brong@fastmailteam.com> wrote:

I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails. 

What's your planned use case(s) for this? I can't really think of any.

So the main use-case I'm working with at the moment is "phone client wants to create a notification to user of new mail, but NOT throw up a new mail notification if the user just moved an email from Inbox to a notified folder in another client".  So the phone client needs to be able to distinguish "this message has newly arrived in the mailstore" vs "this message has just been updated in some way".  This piece of data is also being used in JMAP to underly the calculation for whether a message (or thread) should be in the added or changed result.

And likewise for mailboxes, the createdmodseq on mailboxes is used to distingish between "got renamed" and "newly created".

Bron.

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


--_----------=_153036520233850730-- From nobody Sat Jun 30 12:38:19 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 83B9C130DF2 for ; Sat, 30 Jun 2018 12:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" 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 7EBvRUlTfieA for ; Sat, 30 Jun 2018 12:38:14 -0700 (PDT) Received: from sonic301-4.consmr.mail.bf2.yahoo.com (sonic301-4.consmr.mail.bf2.yahoo.com [74.6.129.43]) (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 5A4AB124D68 for ; Sat, 30 Jun 2018 12:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1530387493; bh=qL+QFnqJRH9sJTXC13AoWV/AfO3jgxVtQaJTkgn013w=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=rKNPG/a79H9uTapvk18SIvMUxJv0pQNtpBpufCJmJvGckg0bL6p2Xiy5Yo82G/da7CXHANd9qAf5K2mU6zYVgM44NW3ijEa6rhHaDDKtj3xNOti7gd3UzMCfGgCnnoLpZoVO+O4LUyhtJ8emxaROvl+2fRK6gQGvK+ePjXXFw2KXFP6wJVGGcASG1uKazzorkvnBSjuLDGmXuenJkD3xK4tAub6WorZX27r9utGRIzXNCivZ221p+alTvymHcVygcQJv40P5dLnfnPOWOaAyjE819ZnZFLSYrI4R6ZbarEThLj/MsynHcUCMOTsZMK/y04ip0CUNcSPX3npTG+Tjjw== X-YMail-OSG: hg72ue0VM1ljjEz06AwMKp4n42WOrjMXlxpRocwNm7t6CLZ32kONporJhU4W.jB EiafiKPhVGcqamIwN9MhrBo4URX3JPdq2eK3L2PQmWmLIMuLVn4.H6Zy5yKG223DUN64aW8X2i0R OdChFdiMzW9kU1bhTCVS1Jxani8YRT4YBMwOEdbpZg724FISoDLEevWUGjYspPcOOqfgwCgdBctj jOo523J8x3H_nOlBRKvwiHg5g7YWN6S4AlFBXAwLVtUDscDJaRw4p95BZz1TU3h1Gjz.erxbghin O_GuPdqkIj1aqNFf15PL0S9kBJdSIcye_bGumsNJNSMhyZmXB1Ind7LYoesVDDOppA8CX6g4qScH OYtTzwUIaPWcZqw9qymbBJhpwdixmcMU8ZHT2vxmTnE.spyVOHQ878dMqCUP5to0zNRwfsKoIxTl BwwBFwNi6Otl6JN8ikhFgyo7IS2jiYWyXpZkttxz142C0ZV_8m2Y9q6vGVW0ghKfWZ4lNPL.bN2s pd48k8hzDRyq7ylTUw8InzIJylkxoklCiKYXgnQ6rPH.OTrQoVcOyNnkl4zobvlKIQNOEkGb1Xc7 1_hQzPoBXgMl9sXvNvqq9SlRJ11wdveM2AnAoy9xHFv0Pdw4FS4p6wjk.UGDPu1aX4eoAPDj5Wug wQr1._CUtFcaQbxZRq_MxESDPpKTocidAB4yfJZ5d9_3LFRM1f8Dregduttz2ShSh6jdQxvZ3DDW Jc4.FyyIfHx9BOFVR03K2RvNnOdVwFdngyc0PkGPzli41Vg_YyQA784kwfb7._GPAe8QOyAXhFfw PhlVnkPG6DoDcsgMq8ITQQicXBuL6H7zOE4sj7pLrXeCOKZsSN9VRt2214n3DITMv3KH7p2r7CEc _ypmQoErw2LyT5CLX4B_KE1lHywuBr5xmb2cyJKNl2UHNf77.lmgyjhJ8UqgL8SviGxNoMx8DPMg CLX7qiTYdFgi.3_K9p51inV1I_9SpsF02Zp18Kg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Sat, 30 Jun 2018 19:38:13 +0000 Received: from pool-70-106-192-253.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.192.253]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e95224fe8bc2d4ba381c556a1a7d195d; Sat, 30 Jun 2018 19:38:12 +0000 (UTC) Message-ID: <5B37DBE7.5070809@aol.com> Date: Sat, 30 Jun 2018 15:37:11 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bron Gondwana CC: extra@ietf.org References: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> In-Reply-To: <1527812408.1624623.1392443640.48DE67C7@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Bringing REPLACE back X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 19:38:18 -0000 An updated draft-brandt-imap-replace-03.txt is now available ---- Network Working Group S. Brandt Internet-Draft Verizon Intended status: Standards Track June 30, 2018 Expires: January 1, 2019 IMAP REPLACE Extension draft-brandt-imap-replace-03 Abstract This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Brandt Expires January 1, 2019 [Page 1] Internet-Draft IMAP REPLACE Extension June 2018 Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3 3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 4 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 5 4. Interaction with other extensions . . . . . . . . . . . . . . 6 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. 2. Overview This document defines an IMAP [RFC3501] extension to facilitate replacing an existing message with a new one. This is accomplished by defining a new REPLACE command and extending the UID command to allow UID REPLACE. Since there is no replace function in the base IMAP specification, clients have instead had to use a combination of three separate commands issued in serial fashion; APPEND, STORE, EXPUNGE. Pipelining of these three commands is not recommended since failure Brandt Expires January 1, 2019 [Page 2] Internet-Draft IMAP REPLACE Extension June 2018 of any individual command should prevent subsequent commands from being executed lest the original message version be lost. Because of the non-atomic nature of the existing sequence, interruptions can leave messages in intermediate states which can be seen and acted upon by other clients. Such interruptions can also strand older revisions of messages, thereby forcing the user to manually clean up multiple revisions of the same message in order to avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence. In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the 3 command sequence. In handling a REPLACE command, a server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. Finally, the replaced and replacing messages SHOULD NOT be present in the mailbox at the same time. 3. REPLACE and UID REPLACE 3.1. Advertising Support for REPLACE Servers that implement the REPLACE extension will return "REPLACE" as one of the supported capabilities in the CAPABILITY command response. 3.2. REPLACE Command Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal Responses: no specific responses for this command Result: OK - replace completed NO - replace error; can't remove specified message or can't add new message content BAD - command unknown or arguments invalid Brandt Expires January 1, 2019 [Page 3] Internet-Draft IMAP REPLACE Extension June 2018 Example: C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: S: * 5 EXISTS S: * 4 EXPUNGE S: A003 OK [APPENDUID 1 2000] Replace completed 3.3. UID REPLACE Command This extends the first form of the UID command (see [RFC3501] Section 6.4.8) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than sequence number as its first parameter. Example: C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: Hopefully next year you can join us. C: S: * 5 EXISTS S: * 4 EXPUNGE S: A004 OK [APPENDUID 1 2001] Replace completed 3.4. Semantics of REPLACE and UID REPLACE The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the Brandt Expires January 1, 2019 [Page 4] Internet-Draft IMAP REPLACE Extension June 2018 message specified by the message identifier will be removed from the selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence: 1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE In the cited sequence, the quota implications of the APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as \Deleted. Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the intermediate states produced do not occur, and the response codes are different. In particular, the response codes for APPEND and EXPUNGE will be returned while those for the STORE operation MUST NOT be generated. When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed. While it may be common for the named mailbox argument to match the selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to replace a message in the \Drafts special-use mailbox with a message in the \Sent special-use mailbox following message submission. Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such as TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions. 3.5. IMAP State Diagram Impacts Unlike the APPEND command which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Brandt Expires January 1, 2019 [Page 5] Internet-Draft IMAP REPLACE Extension June 2018 4. Interaction with other extensions This section describes how REPLACE interacts with some other IMAP extensions. 4.1. RFC 4314, ACL The ACL rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current mailbox, and APPEND in the target mailbox. 4.2. RFC 4469, CATENATE Servers supporting both REPLACE and CATENATE [RFC4469] MUST support the addtional append-data and resp-text-code elements defined the Formal Syntax section of RFC4469 in conjunction with the REPLACE command. When combined with CATENATE, REPLACE can become a quite efficient way for message manipulation. Brandt Expires January 1, 2019 [Page 6] Internet-Draft IMAP REPLACE Extension June 2018 Example: User composes message and attaches photo ---------------------------------------- C: A010 APPEND Drafts (\Seen \Draft) {1201534} S: + Ready for literal data C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) C: From: Fritz Schmidt C: Message-ID: C: MIME-Version: 1.0 C: Content-Type: multipart/mixed; C: boundary="------------030305060306060609050804" C: C: --------------030305060306060609050804 C: Content-Type: text/plain; charset=utf-8; format=flowed C: Content-Transfer-Encoding: 7bit C: C: Here is picture from the fireworks C: C: Yours... C: Fritz C: C: --------------030305060306060609050804 C: Content-Type: image/jpeg; C: name="Fireworks.jpg" C: Content-Transfer-Encoding: base64 C: Content-Disposition: attachment; C: filename="Fireworks.jpg" C: C: C: --------------030305060306060609050804-- S: A010 OK [APPENDUID 1 3002] APPEND complete User completes message with To: and Subject: fields --------------------------------------------------- C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} S: + Ready for literal data C: To: Mitzy C: Subject: My view of the fireworks C: URL "/Drafts/;UID=3002") S: * 5 EXISTS S: * 4 EXPUNGE S: A011 OK [APPENDUID 1 3003] REPLACE completed Brandt Expires January 1, 2019 [Page 7] Internet-Draft IMAP REPLACE Extension June 2018 4.3. RFC 4315, UIDPLUS Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information see section 3 of RFC4315. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS specification means that the client first receives an EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.) 4.4. RFC 6785, IMAP Events in Sieve REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by REPLACE, no action will be taken that results in a imap.cause of FLAG. 4.5. RFC 7162, CONDSTORE/QRESYNC Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 are particularly relevant for this condition. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability","command-select", "mailbox", and "seq- number". [RFC4466] defines the non-terminal "append-message". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "REPLACE" command-select =/ replace replace = "REPLACE" SP seq-number SP mailbox append-message uid = "UID" SP (copy / fetch/ search / store / move / replace) Brandt Expires January 1, 2019 [Page 8] Internet-Draft IMAP REPLACE Extension June 2018 6. Security Considerations This document is believed to add no security problems beyond those that may already exist with the base IMAP specificaiton. 7. IANA Considerations The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" registry, http://www.iana.org/assignments/imap4-capabilities. 8. Acknowledgements The author would like to thank the participants of IMAPEXT with particular thanks to Arnt Gulbrandsen, Alexey Melkinov, Chris Newman, and Bron Gondwana for their specific contributions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, . [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, . [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, . [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, . Brandt Expires January 1, 2019 [Page 9] Internet-Draft IMAP REPLACE Extension June 2018 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, . [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, . 9.2. Informative References [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, . Author's Address Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 USA Email: stujenerin@aol.com Brandt Expires January 1, 2019 [Page 10] On 5/31/2018 8:20 PM, Bron Gondwana wrote: > 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 > > From nobody Sat Jun 30 16:11: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 363EE130EBD for ; Sat, 30 Jun 2018 16:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 3JHoerUqGsQC for ; Sat, 30 Jun 2018 16:11:32 -0700 (PDT) Received: from tss.iki.fi (tss.iki.fi [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4B130E35 for ; Sat, 30 Jun 2018 16:11:30 -0700 (PDT) Received: from [192.168.10.102] (unknown [88.114.32.157]) by tss.iki.fi (Postfix) with ESMTPSA id 5B82E2B3CCA; Sat, 30 Jun 2018 23:11:29 +0000 (UTC) From: Timo Sirainen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_771EBCE8-BCB1-428C-8F9D-C5296355B3FB" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 1 Jul 2018 02:11:28 +0300 In-Reply-To: <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> Cc: extra@ietf.org To: Bron Gondwana References: <1530331983.2359727.1425398664.31921FE1@webmail.messagingengine.com> <5D7E526D-62F0-474D-BE41-5F6092A71F1C@iki.fi> <1530365202.3385073.1425646120.01C42B5A@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 23:11:35 -0000 --Apple-Mail=_771EBCE8-BCB1-428C-8F9D-C5296355B3FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Jun 2018, at 16.26, Bron Gondwana wrote: >=20 > On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote: >> On 30 Jun 2018, at 7.13, Bron Gondwana > wrote: >>>=20 >>> I'm working on a doc (and implementation) for an extension to = RFC7162 - CREATEDMODSEQ. It adds said field on both mailboxes and = emails.=20 >>=20 >> What's your planned use case(s) for this? I can't really think of = any. >=20 > So the main use-case I'm working with at the moment is "phone client = wants to create a notification to user of new mail, but NOT throw up a = new mail notification if the user just moved an email from Inbox to a = notified folder in another client". So the phone client needs to be = able to distinguish "this message has newly arrived in the mailstore" vs = "this message has just been updated in some way". This requires the global modseq space for it to work. Also, an = alternative to this feature might be to just auto-add some $Copied / = $Moved keyword.. > This piece of data is also being used in JMAP to underly the = calculation for whether a message (or thread) should be in the added or = changed result. I tried quickly looking at the jmap spec to see what exactly these = meant, but didn't find it. So I guess copying/moving would be better as = "changed" then? Again for the same reason of not showing notifications = of copied/moved mails? > And likewise for mailboxes, the createdmodseq on mailboxes is used to = distingish between "got renamed" and "newly created". Nice, but again I don't really see how clients would use this. --Apple-Mail=_771EBCE8-BCB1-428C-8F9D-C5296355B3FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 30 Jun 2018, at 16.26, Bron Gondwana <brong@fastmailteam.com> wrote:

On Sat, Jun 30, = 2018, at 22:02, Timo Sirainen wrote:
On 30 Jun 2018, at 7.13, Bron = Gondwana <brong@fastmailteam.com> wrote:

I'm working on a doc (and implementation) for an extension to = RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and = emails. 

What's your planned use case(s) for = this? I can't really think of any.

So the main = use-case I'm working with at the moment is "phone client wants to create = a notification to user of new mail, but NOT throw up a new mail = notification if the user just moved an email from Inbox to a notified = folder in another client".  So the phone client needs to be able to = distinguish "this message has newly arrived in the mailstore" vs "this = message has just been updated in some = way".

This = requires the global modseq space for it to work. Also, an alternative to = this feature might be to just auto-add some $Copied / $Moved = keyword..

This piece of data is also being used in JMAP to = underly the calculation for whether a message (or thread) should be in = the added or changed result.

I = tried quickly looking at the jmap spec to see what exactly these meant, = but didn't find it. So I guess copying/moving would be better as = "changed" then?  Again for the same reason of not showing = notifications of copied/moved mails?

And likewise for mailboxes, the = createdmodseq on mailboxes is used to distingish between "got renamed" = and "newly created".

Nice, but again I don't really see how clients = would use this.

= --Apple-Mail=_771EBCE8-BCB1-428C-8F9D-C5296355B3FB--