From nobody Tue Apr 2 19:10:07 2019 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 7F674120402 for ; Tue, 2 Apr 2019 19:10:06 -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=Uq8hWDy0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U7JyKDAR 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 1I5pNar3gElj for ; Tue, 2 Apr 2019 19:10:04 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5EF12042A for ; Tue, 2 Apr 2019 19:10:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3542262D9 for ; Tue, 2 Apr 2019 22:10:01 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 02 Apr 2019 22:10:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=yUD9vuT /PayhFyRYW9NkMQ7WnhhgskMYtOj2gsYXFSM=; b=Uq8hWDy0XuiX6qcJmidDthR qKd5P9Dbkk5DwDy4mgLmfUOywJgrXBOOVCxUplXL6kZXEfWhoEtcuh9n6jg3SGYe hupNGuWrYj7Y38reH+9aSSwr07VxaTTYvCgXICG6hPao1hHt7BEDhVV75cR9CIrH CSIPMF8uShP8U/1by6jFpEHqXggNNKlDz3XVOiLmgU6J02qv/iSxHea4FkxB/KJG ZlztOPILRLOHS+H8RZMtpLyYKV1BdN1Zonm+5mPbs3qLmTBq7gho9S+gIJirB1uW KdpZMzdR/le4RyMNQ8frVO9jaeuR86Q8RoIy04f9B6o33SspvR8y7vpWkLw6l8A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yUD9vu T/PayhFyRYW9NkMQ7WnhhgskMYtOj2gsYXFSM=; b=U7JyKDARYkftYRjeXhuGPs AaNMuihwj3C9Vjcqqgj2s5sHLWCIFBXeL5eqDq5VGVLSsUEqbmH+F590qKTusKoc RB8o3K/suQvhvnKloO2ptVF0E2kNIcnGZljXL67ZPp2h39eNgohTeAOeeVXAyiJZ cIsFrDGsIG3p5VLyz9RMVVOKccXcTKL6+12fyMvMm9VefI3Zydy8jfZ0qzLSDFQJ fIa6myfXlTm8VZFD3g+BYaJrESgzJE/JDp9Wh3rB27ZzXTbUHeSjftVnyvU5NJY1 V/yUEEbnsLHSOPP/iuZuY2wpSOVvqSdj+vMkCMXCRPbXrUsBHo7geWB0+Rls3ryQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtddugdehfeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigr nhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmh epmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 31F152057A; Tue, 2 Apr 2019 22:10:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <688538e5-bd3d-478a-bfca-d890c6213df9@beta.fastmail.com> In-Reply-To: References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <17b8d4e0-0ce5-4768-891c-5a7c77f19289@gulbrandsen.priv.no> Date: Tue, 02 Apr 2019 22:09:59 -0400 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=82a61168cf8e4b3a94792da3fa4147fb Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 02:10:06 -0000 --82a61168cf8e4b3a94792da3fa4147fb Content-Type: text/plain On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrote: > On Friday 29 March 2019 19:44:53 CET, Bron Gondwana wrote: > > In this particular case, there's a pretty good piece of prior > > art for the name in RFC5232, plus multiple mentions online. > > Oh, that was easy to misunderstand, wasn't it. Sorry. I didn't mean to say > that this particular flag was a bad candidate for standardisation. Rather > that we already have two many piecemeal standardisations. If there's > another RFC, it should make some attempt to cover most of the flags that > ought to be standardised at this point in time. Yeah, I was more tempted to just do an IANA registration for it. > > That sounds reasonable. I'd be happy to help with a document > > like that, or find someone else at FastMail who might want their > > name on an RFC in exchange for doing the work :) > > I can edit, iff two big providers will produce flag lists. Alone or with a > co-editor. > > I like the way Neil has used github. I can do one for FastMail. Anyone from one of the other providers here able to get such a list? There's a handful of flags which FastMail use internally which may or may not have any interest ourside, so I'll account those separately. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --82a61168cf8e4b3a94792da3fa4147fb Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrot= e:
On Friday 29 March 2019 19:44:53 CET, Bron Gondwana= wrote:
> In this particul= ar case, there's a pretty good piece of prior 
> art for the name in RFC5232, plus multiple men= tions online.

Oh, that was easy to misunderstand, wasn't = it. Sorry. I didn't mean to say 
that this particular flag was a bad candidate for standardisati= on. Rather 
that we alre= ady have two many piecemeal standardisations. If there's 
=
another RFC, it should make some attem= pt to cover most of the flags that 
ought to be standardised at this point in time.

Yeah, I was more tempted to just do an IANA registration= for it.

> That sounds reasonable.  I'd be happy to help with a document=  
> like that, or fin= d someone else at FastMail who might want their 
> name on an RFC in exchange for doing the w= ork :)

I can edit, iff two big providers will produce flag= lists. Alone or with a 
co-editor.

I like the way Neil has used github.

I can do one for FastMail.  Anyone from one of = the other providers here able to get such a list?

There's= a handful of flags which FastMail use internally which may or may not h= ave any interest ourside, so I'll account those separately.

Bron.


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


<= /html> --82a61168cf8e4b3a94792da3fa4147fb-- From nobody Wed Apr 3 05:02:14 2019 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 B9493120089; Wed, 3 Apr 2019 05:02:05 -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_via_Datatracker?= To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155429292567.22949.15986765586199405904.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2019 05:02:05 -0700 Archived-At: Subject: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 12:02:06 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few small comments on the IANA section: It would be good to also provide a name for each of the new registries (but I'm sure IANA will ask about this in their review). However, I'm also wondering why you don't specify straight away the use of the IETF Review policy as specified in RFC5226? Is there something different in there that does not work for you? From nobody Wed Apr 3 08:47:18 2019 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 3C48812011D; Wed, 3 Apr 2019 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmcrsr7pKnGs; Wed, 3 Apr 2019 08:47:08 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 9D71812011E; Wed, 3 Apr 2019 08:47:04 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id v10so14461302iom.8; Wed, 03 Apr 2019 08:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LwzU+RUg3TNeC3s1qZUDfLrN70/qCDQeiz1mLSPTvpk=; b=H+50ZOsyebCbQi2owsSGk5O7vC8ktDgyuyoXBr2CWJeVx7jrSJjalOsc5YdZ3NjCeC desweKg8EbKOWLrkIZvcejUBK2t4eIb2SIf3zGKPrjfrCfA1uGyowo5OiciRreqabvRO Iu4aQn0hxVtk0EavMrtdTiIjcu8OeFI2sRZKms1kI5TY1DELW5crsj/3SYE7WaT48017 K/eysFslGaA0APrKsiaIW1XTo5whNYklSAh1ybLExpALbURmMQskI9corBOKKHyvP2af FYkjdtE6yPv/vBPXPGkdUfkNJjGcv10YsLfvmr+sJIMO52EsG8HkgETUX48UDjXbnKT6 BQIA== X-Gm-Message-State: APjAAAUBqD8J5MTfP3+jNvqQ9H810x2It1Q4WcOitAzM86tbBqlhFcNO BDw75XS4HlX2xJK1sx5tXn7AjMpmDyjOAD+mgXJ4nwzj X-Google-Smtp-Source: APXvYqxPo6SoX/r3dmoqnAvibGkI1mpsAmm/bM5W4QsHJQdcwbHwPxqzjCRyNOg5DHnnjNl/eXVS2bEBznmp9LdYhyE= X-Received: by 2002:a5d:97da:: with SMTP id k26mr611776ios.46.1554306423627; Wed, 03 Apr 2019 08:47:03 -0700 (PDT) MIME-Version: 1.0 References: <155429292567.22949.15986765586199405904.idtracker@ietfa.amsl.com> In-Reply-To: <155429292567.22949.15986765586199405904.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 3 Apr 2019 11:46:52 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , extra@ietf.org, Bron Gondwana , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 15:47:10 -0000 > A few small comments on the IANA section: It would be good to also provide a > name for each of the new registries (but I'm sure IANA will ask about this in > their review). The two new registries *are* named there: "PREVIEW algorithms" and "PREVIEW priority modifiers". > However, I'm also wondering why you don't specify straight away > the use of the IETF Review policy as specified in RFC5226? Is there something > different in there that does not work for you? The difference is that IETF Review allows for Informational as well. Realistically, though, I think it's just that this text was copied from RFC 3501. (And it's not 5226 any more: 8126 now.) Barry From nobody Wed Apr 3 09:21:00 2019 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 33F571201CD; Wed, 3 Apr 2019 09:20:58 -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, 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 4ylc0pU6caKD; Wed, 3 Apr 2019 09:20:55 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 C505112019C; Wed, 3 Apr 2019 09:20:55 -0700 (PDT) Received: from 200116b82cbe0b001424db5579cea23b.dip.versatel-1u1.de ([2001:16b8:2cbe:b00:1424:db55:79ce:a23b]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hBid9-0007IZ-S4; Wed, 03 Apr 2019 18:20:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 3 Apr 2019 18:20:51 +0200 Cc: The IESG , extra@ietf.org, Bron Gondwana , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155429292567.22949.15986765586199405904.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1554308455;8961b61e; X-HE-SMSGID: 1hBid9-0007IZ-S4 Archived-At: Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 16:20:58 -0000 Hi Barry, > On 3. Apr 2019, at 17:46, Barry Leiba wrote: >=20 >> A few small comments on the IANA section: It would be good to also = provide a >> name for each of the new registries (but I'm sure IANA will ask about = this in >> their review). >=20 > The two new registries *are* named there: "PREVIEW algorithms" and > "PREVIEW priority modifiers=E2=80=9D. Ah, that wasn=E2=80=99t really clear to me from the text. I would have = expected to also see IMAP in the name. Also I guess you could give IANA = better instructions where to locate the registry (on the same page as = the IMAP capabilities or a separate page). But I=E2=80=99m sure IANA = will come back to you with these questions. >=20 >> However, I'm also wondering why you don't specify straight away >> the use of the IETF Review policy as specified in RFC5226? Is there = something >> different in there that does not work for you? >=20 > The difference is that IETF Review allows for Informational as well. > Realistically, though, I think it's just that this text was copied > from RFC 3501. I would think that having IETF consensus is the important part here (and = less the internet status) and that's covered by the IETF Review policy. >=20 > (And it's not 5226 any more: 8126 now.) Yes, that=E2=80=99s of course right. Sorry. Mirja >=20 > Barry >=20 From nobody Wed Apr 3 13:23:26 2019 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 F3E5112011C; Wed, 3 Apr 2019 13:23:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2019 13:23:17 -0700 Archived-At: Subject: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 20:23:18 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Retention practices of cached previews Section 1 says “Using server generated previews allows global generation once per message, and then cached indefinitely”. Why cache indefinitely, especially if the source messages has been expunged? For privacy reasons, couldn’t this caching be consistent with the retention of the email. In Section 9, Security Considerations, there needs to be discussion of this retention too. Perhaps text like: “Implementations that pre-generate and store previews MUST ensure that the stored preview is also deleted when the corresponding mail message is expunged.” (2) Protection of previews at rest In Section 9, Security Considerations, there needs to be discussion about the potential sensitivity of these previews and the need to protect them. Perhaps text like: “Just as the messages they summarize, previews may contain sensitive information. When stored, these previews MUST be protected with equivalent authorization and confidentiality controls as the source message.” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Use of RFC 2119 words Please consider if these proposed changes are appropriate uses of RFC 2119 key words: Section 2 s/As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations must pay attention to the numbered rules at the beginning of [RFC3501] Section 9./ As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations MUST pay attention to the numbered rules at the beginning of [RFC3501] Section 9./ Section 3.1 s/Alternately, the client may explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm./ Alternately, the client MAY explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm./ (2) Section 3.1, the paragraph “If no algorithm identifier is provided, the server decides …” discusses algorithm identifiers but their use hasn’t been introduced yet. I recommend swapping the order of this paragraph with the current third paragraph (“Alternative …”) as this is where algorithms are introduced. (3) Section 4.1. Duplicate word. s/to the the language/to the language/ (4) Section 4.1. Nit on word order. s/no human-readable text to generate preview information from/no human-readable text from which to generate preview information/ (5) Section 7. In the ABNF comments, consider using “[RFC6648]” instead of “RFC 6648”. From nobody Wed Apr 3 13:38:10 2019 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 A982A1201F1; Wed, 3 Apr 2019 13:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGhg-3okBvJ6; Wed, 3 Apr 2019 13:38:01 -0700 (PDT) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (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 36AEC1201AC; Wed, 3 Apr 2019 13:38:01 -0700 (PDT) Received: by mail-it1-f171.google.com with SMTP id z126so94676itd.5; Wed, 03 Apr 2019 13:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RjcYaBV1sPxxSYy9tVpuRxRvJcsKF7hvfqIKcgmJOHM=; b=Kq0+ixYQsHGorJ4Dr+WQXl9uih9rMlgr5H36hGiUFq4OURe/Hpl4sn4maMM5XJ5YFl 6CKv9kNseLMi69C3Pc4IuN9Z5Ek+prq/7+GoM8bvkjD9pkJrRGh7VAZebTaZBTQZo3dt xAgarQ01FML5uR2mhkxQJiJGLQXCdEu6/VfHsCMX/+NUXob+Rby9qqNYqAkMltGB/n/1 qeruDQBmFCIn6yw/MPzTf0Z5650eEXpfcYdSH5AWOe1GZFEOY2vxAdvIOgrY/ORJUdUj wbGIWa1UtZGOgQBOKgdo1/kf0X6obcf2CedJbhnIFK6YNFBcVYU7uGl6oXFzcnulxwJk 2UNA== X-Gm-Message-State: APjAAAV2ZuNlgkc/dvQjCMu/KF6D1hy/TtRKNG6QgIAIBVcgSKt9DVmm w5uRjAK7+aZ1D/qY8LyublschoYegP+lgkt+c50= X-Google-Smtp-Source: APXvYqy7zcFMFE9mYzW71MfL58XCyatFMMomH1F6MP8aqNJicWPfwoxIvCIRjlsr5nK2Tk998CYR3lw8njcVf2gDwIA= X-Received: by 2002:a24:4d12:: with SMTP id l18mr1745539itb.66.1554323880182; Wed, 03 Apr 2019 13:38:00 -0700 (PDT) MIME-Version: 1.0 References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> In-Reply-To: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 3 Apr 2019 16:37:49 -0400 Message-ID: To: Roman Danyliw Cc: The IESG , extra@ietf.org, Bron Gondwana , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 20:38:03 -0000 Hi, Roman. > (1) Retention practices of cached previews > Section 1 says =E2=80=9CUsing server generated previews allows global gen= eration once > per message, and then cached indefinitely=E2=80=9D. Why cache indefinite= ly, especially > if the source messages has been expunged? For privacy reasons, couldn=E2= =80=99t this > caching be consistent with the retention of the email. "Indefinitely" doesn't mean forever... it means that the time period is not definite. That said, your suggested change makes sense, and I think we should make it= . > (2) Protection of previews at rest > In Section 9, Security Considerations, there needs to be discussion about= the > potential sensitivity of these previews and the need to protect them. Pe= rhaps > text like: =E2=80=9CJust as the messages they summarize, previews may con= tain sensitive > information. When stored, these previews MUST be protected with equivale= nt > authorization and confidentiality controls as the source message.=E2=80= =9D This also makes sense and should be made. > (1) Use of RFC 2119 words > Please consider if these proposed changes are appropriate uses of RFC 211= 9 key > words: > > Section 2 > s/As with all IMAP extension documents, the case used in writing IMAP pro= tocol > elements herein is chosen for editorial clarity, and implementations must= pay > attention to the numbered rules at the beginning of [RFC3501] Section 9./= As > with all IMAP extension documents, the case used in writing IMAP protocol > elements herein is chosen for editorial clarity, and implementations MUST= pay > attention to the numbered rules at the beginning of [RFC3501] Section 9./ > > Section 3.1 > s/Alternately, the client may explicitly indicate which algorithm(s) sho= uld be > used in a parenthesized list after the PREVIEW attribute containing the n= ame of > the algorithm./ Alternately, the client MAY explicitly indicate which > algorithm(s) should be used in a parenthesized list after the PREVIEW att= ribute > containing the name of the algorithm./ These are both applications of RFC 8174 and should stand as they are writte= n. Barry From nobody Wed Apr 3 13:46:33 2019 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 BB1AF120242; Wed, 3 Apr 2019 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 51N7YAYB8OD3; Wed, 3 Apr 2019 13:46:23 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.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 4D31912023F; Wed, 3 Apr 2019 13:46:23 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33KkI7m048913; Wed, 3 Apr 2019 16:46:18 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x33KkI7m048913 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1554324379; bh=iihckUTB04XUpnrym0nn/sgJR3BLIjPRvxspyOn38oI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=VfNq3jLuNejxV2qg7AK5OlVwU4jQP6cWDbC/CK3EeqvS7qEbsXIBX/GJkAcyH27q5 r0vCcBuwXa1gfsJ353Em92ckYtKaHXr6CZlPwAuayImLCTm4SbFNsjL/oGJAro/ucS myxV7/XH5uYTQyv7umIFsibxhBoladzmuOCsL9MM= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33KkEsu019561; Wed, 3 Apr 2019 16:46:14 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Wed, 3 Apr 2019 16:46:13 -0400 From: Roman Danyliw To: Barry Leiba CC: The IESG , "extra@ietf.org" , Bron Gondwana , "extra-chairs@ietf.org" , "draft-ietf-extra-imap-fetch-preview@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) Thread-Index: AQHU6lsdU9pkh6o9mkWEzi03EGhTD6YrKIuA//++u7A= Date: Wed, 3 Apr 2019 20:46:12 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B331BA30@marchand> References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 20:46:26 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmFycnkgTGVpYmEgW21h aWx0bzpiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAw MywgMjAxOSA0OjM4IFBNDQo+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQo+IENj OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGV4dHJhQGlldGYub3JnOyBCcm9uIEdvbmR3YW5h DQo+IDxicm9uZ0BmYXN0bWFpbHRlYW0uY29tPjsgZXh0cmEtY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLWV4dHJhLWltYXAtDQo+IGZldGNoLXByZXZpZXdAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZXh0cmEtaW1hcC1mZXRj aC0NCj4gcHJldmlldy0wMzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpLCBS b21hbi4NCj4gDQo+ID4gKDEpIFJldGVudGlvbiBwcmFjdGljZXMgb2YgY2FjaGVkIHByZXZpZXdz IFNlY3Rpb24gMSBzYXlzIOKAnFVzaW5nDQo+ID4gc2VydmVyIGdlbmVyYXRlZCBwcmV2aWV3cyBh bGxvd3MgZ2xvYmFsIGdlbmVyYXRpb24gb25jZSBwZXIgbWVzc2FnZSwNCj4gPiBhbmQgdGhlbiBj YWNoZWQgaW5kZWZpbml0ZWx54oCdLiAgV2h5IGNhY2hlIGluZGVmaW5pdGVseSwgZXNwZWNpYWxs eSBpZg0KPiA+IHRoZSBzb3VyY2UgbWVzc2FnZXMgaGFzIGJlZW4gZXhwdW5nZWQ/ICBGb3IgcHJp dmFjeSByZWFzb25zLCBjb3VsZG7igJl0DQo+ID4gdGhpcyBjYWNoaW5nIGJlIGNvbnNpc3RlbnQg d2l0aCB0aGUgcmV0ZW50aW9uIG9mIHRoZSBlbWFpbC4NCj4gDQo+ICJJbmRlZmluaXRlbHkiIGRv ZXNuJ3QgbWVhbiBmb3JldmVyLi4uIGl0IG1lYW5zIHRoYXQgdGhlIHRpbWUgcGVyaW9kIGlzIG5v dA0KPiBkZWZpbml0ZS4NCj4gVGhhdCBzYWlkLCB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2UgbWFrZXMg c2Vuc2UsIGFuZCBJIHRoaW5rIHdlIHNob3VsZCBtYWtlDQo+IGl0Lg0KPiANCj4gPiAoMikgUHJv dGVjdGlvbiBvZiBwcmV2aWV3cyBhdCByZXN0DQo+ID4gSW4gU2VjdGlvbiA5LCBTZWN1cml0eSBD b25zaWRlcmF0aW9ucywgdGhlcmUgbmVlZHMgdG8gYmUgZGlzY3Vzc2lvbg0KPiA+IGFib3V0IHRo ZSBwb3RlbnRpYWwgc2Vuc2l0aXZpdHkgb2YgdGhlc2UgcHJldmlld3MgYW5kIHRoZSBuZWVkIHRv DQo+ID4gcHJvdGVjdCB0aGVtLiAgUGVyaGFwcyB0ZXh0IGxpa2U6IOKAnEp1c3QgYXMgdGhlIG1l c3NhZ2VzIHRoZXkNCj4gPiBzdW1tYXJpemUsIHByZXZpZXdzIG1heSBjb250YWluIHNlbnNpdGl2 ZSBpbmZvcm1hdGlvbi4gIFdoZW4gc3RvcmVkLA0KPiA+IHRoZXNlIHByZXZpZXdzIE1VU1QgYmUg cHJvdGVjdGVkIHdpdGggZXF1aXZhbGVudCBhdXRob3JpemF0aW9uIGFuZA0KPiBjb25maWRlbnRp YWxpdHkgY29udHJvbHMgYXMgdGhlIHNvdXJjZSBtZXNzYWdlLuKAnQ0KPiANCj4gVGhpcyBhbHNv IG1ha2VzIHNlbnNlIGFuZCBzaG91bGQgYmUgbWFkZS4NCj4gDQo+ID4gKDEpIFVzZSBvZiBSRkMg MjExOSB3b3Jkcw0KPiA+IFBsZWFzZSBjb25zaWRlciBpZiB0aGVzZSBwcm9wb3NlZCBjaGFuZ2Vz IGFyZSBhcHByb3ByaWF0ZSB1c2VzIG9mIFJGQw0KPiA+IDIxMTkga2V5DQo+ID4gd29yZHM6DQo+ ID4NCj4gPiBTZWN0aW9uIDINCj4gPiBzL0FzIHdpdGggYWxsIElNQVAgZXh0ZW5zaW9uIGRvY3Vt ZW50cywgdGhlIGNhc2UgdXNlZCBpbiB3cml0aW5nIElNQVANCj4gPiBwcm90b2NvbCBlbGVtZW50 cyBoZXJlaW4gaXMgY2hvc2VuIGZvciBlZGl0b3JpYWwgY2xhcml0eSwgYW5kDQo+ID4gaW1wbGVt ZW50YXRpb25zIG11c3QgIHBheSBhdHRlbnRpb24gdG8gdGhlIG51bWJlcmVkIHJ1bGVzIGF0IHRo ZQ0KPiA+IGJlZ2lubmluZyBvZiBbUkZDMzUwMV0gU2VjdGlvbiA5Li8gQXMgd2l0aCBhbGwgSU1B UCBleHRlbnNpb24NCj4gPiBkb2N1bWVudHMsIHRoZSBjYXNlIHVzZWQgaW4gd3JpdGluZyBJTUFQ IHByb3RvY29sIGVsZW1lbnRzIGhlcmVpbiBpcw0KPiA+IGNob3NlbiBmb3IgZWRpdG9yaWFsIGNs YXJpdHksIGFuZCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBwYXkgYXR0ZW50aW9uDQo+ID4gdG8gdGhl IG51bWJlcmVkIHJ1bGVzIGF0IHRoZSBiZWdpbm5pbmcgb2YgW1JGQzM1MDFdIFNlY3Rpb24gOS4v DQo+ID4NCj4gPiBTZWN0aW9uIDMuMQ0KPiA+IHMvQWx0ZXJuYXRlbHksIHRoZSBjbGllbnQgbWF5 ICBleHBsaWNpdGx5IGluZGljYXRlIHdoaWNoIGFsZ29yaXRobShzKQ0KPiA+IHNob3VsZCBiZSB1 c2VkIGluIGEgcGFyZW50aGVzaXplZCBsaXN0IGFmdGVyIHRoZSBQUkVWSUVXIGF0dHJpYnV0ZQ0K PiA+IGNvbnRhaW5pbmcgdGhlIG5hbWUgb2YgdGhlIGFsZ29yaXRobS4vIEFsdGVybmF0ZWx5LCB0 aGUgY2xpZW50IE1BWQ0KPiA+IGV4cGxpY2l0bHkgaW5kaWNhdGUgd2hpY2gNCj4gPiBhbGdvcml0 aG0ocykgc2hvdWxkIGJlIHVzZWQgaW4gYSBwYXJlbnRoZXNpemVkIGxpc3QgYWZ0ZXIgdGhlIFBS RVZJRVcNCj4gPiBhdHRyaWJ1dGUgY29udGFpbmluZyB0aGUgbmFtZSBvZiB0aGUgYWxnb3JpdGht Li8NCj4gDQo+IFRoZXNlIGFyZSBib3RoIGFwcGxpY2F0aW9ucyBvZiBSRkMgODE3NCBhbmQgc2hv dWxkIHN0YW5kIGFzIHRoZXkgYXJlIHdyaXR0ZW4uDQoNClJpZ2h0LiAgSSBmb3Jnb3QgUkZDODE3 NC4gIFRoZXNlIHJlcGxhY2VtZW50cyBkb24ndCBtYWtlIHNlbnNlLg0KDQpSb21hbg0KDQo+IEJh cnJ5DQo= From nobody Wed Apr 3 14:12:03 2019 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 CCB7F120286 for ; Wed, 3 Apr 2019 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkdaF2CUAihk for ; Wed, 3 Apr 2019 14:11:59 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 5EBAA12027F for ; Wed, 3 Apr 2019 14:11:59 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 6FCAE6A23E for ; Wed, 3 Apr 2019 23:11:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554325916; bh=0dLq8K6I/gqAwU24j2BlqD6HAlZ0WmQehtSGsIdtKZ4=; h=Date:From:To:In-Reply-To:References:Subject:From; b=KZHFS//As9g5rzxDyctI+PiFXm/EjtTjyrnr04bc/g0Dz71izsccJ5JAI2QLFgXhW TsZ1ohmhD1CXuWIjAxSy2mQRaavaMAu4uk3jsl02PqiPQsGjxFutLU+0+YgBFuTAZe drsl4ZIYGN7glsccV4LntkgQuMrBW2EcYNY21gqQ4gYRESBhejDr8v3FiW4FZHR9xL l+PDBeIQwFYY+hY3dU7bZnHM75S/JwXZU/DI3XgIEBUN03oB9wFlioevGpnrSyoZlz yNASKEr2xfbF85lbOxwUXdUTjOWpe6JtRFG1ZdO4Jsx+hk4GTMoWOHd6nfIPVZxp8g B5ZGYh/PUv6FA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 636433C0399 for ; Wed, 3 Apr 2019 23:11:56 +0200 (CEST) Date: Wed, 3 Apr 2019 15:11:56 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <1967676937.3881.1554325916346@appsuite.open-xchange.com> In-Reply-To: <688538e5-bd3d-478a-bfca-d890c6213df9@beta.fastmail.com> References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <17b8d4e0-0ce5-4768-891c-5a7c77f19289@gulbrandsen.priv.no> <688538e5-bd3d-478a-bfca-d890c6213df9@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3880_610130157.1554325916340" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 21:12:02 -0000 ------=_Part_3880_610130157.1554325916340 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > On April 2, 2019 at 8:09 PM Bron Gondwana wrote: > > On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrote: > > > > > That sounds reasonable. I'd be happy to help with a document > > > like that, or find someone else at FastMail who might want their > > > name on an RFC in exchange for doing the work :) > > > > I can edit, iff two big providers will produce flag lists. Alone or with a > > co-editor. > > > > I like the way Neil has used github. > > > > > > I can do one for FastMail. Anyone from one of the other providers here able to get such a list? > In Dovecot, we recently introduced an option to do server-side attachment detection which sets either "$HasAttachment" or "$HasNoAttachment" for each message processed. Jeff already did most of the legwork on standardization text here: https://mailarchive.ietf.org/arch/msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278 michael ------=_Part_3880_610130157.1554325916340 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On April 2, 2019 at 8:09 PM Bron Gondwana <brong@fastmailteam.com> wrote:

On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrote:
> That sounds reasonable.  I'd be happy to help with a document 
> like that, or find someone else at FastMail who might want their 
> name on an RFC in exchange for doing the work :)

I can edit, iff two big providers will produce flag lists. Alone or with a 
co-editor.

I like the way Neil has used github.

I can do one for FastMail.  Anyone from one of the other providers here able to get such a list?
In Dovecot, we recently introduced an option to do server-side attachment detection which sets either "$HasAttachment" or "$HasNoAttachment" for each message processed.

Jeff already did most of the legwork on standardization text here:

https://mailarchive.ietf.org/arch/msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278

michael
------=_Part_3880_610130157.1554325916340-- From nobody Wed Apr 3 14:16:54 2019 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 B8D1E120189 for ; Wed, 3 Apr 2019 14:16:52 -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=j4QDauKc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fx9F1f1B 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 hje4-HQ2GsjP for ; Wed, 3 Apr 2019 14:16:50 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7A6120287 for ; Wed, 3 Apr 2019 14:16:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 872655DDE for ; Wed, 3 Apr 2019 17:16:49 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 03 Apr 2019 17:16:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=gU8gWfJ rmvc/RauEVLVkcoj5yPtbfPK0+luc9jTyadc=; b=j4QDauKcBYyyBhQW0pezHoE Ib7AzxcCaxfk92c+YoOhOtlA64nO+2J8lvJLZypT7InSLGDuVKhR8rzTw3YDK154 L7exUFVHFFN4VaXaqG14QNZ5xSSaGZ0KESR0X4ks6nl3OcFe57bOtRH5Q099BL0k 8uq1hcAGkxUOMTjQBLSSasxcJ2FVxde+zKcbrjjmHqjgTQsLT+ICuGnSUC4YkAcl 3MFxrdpp9qAgD7z/Y9Z3V/1sGNU2ycBdVbBd1zA9tJmJPskIn17bJQp/EdkjYkEu FOSo10Tr4S3Edi+9ouN7z7ktF943To/k6bW+AEGIyhFjyOJeOOs9l4iO7kqhQ+g= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gU8gWf Jrmvc/RauEVLVkcoj5yPtbfPK0+luc9jTyadc=; b=fx9F1f1BA5Vf6hGlub/N7I xvCx6ezRrS+uzykN8TtmRE0UQjJJQvHo8uE+yq4uxezg+4B/7DYTkUM6Hr2D+WG2 gEKRYm9k4BdS4OEYZ/eaUn3cv1EYITkCwDLmWrx7ahpjBGCKtYgthgbwUqUrUemn jWZoFdBc0Fd4AuIugM9rVREbiMm4FbeAipwrRFLFRI2b0C9t2ID7afd1aM/Tr7bS Ov/mUh2kawJCmWFdoHggsa995Zy4EpTN7VUH3I6sMwhYQlJwiIydcQRTny7ThDi7 zzNThyVu7mCypG1xXbqwZyUZjkI7ljet0RxC6JD9JeDbHEhPHH+z85se/T6Oyp4A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgddufedvucdltddurdeguddtrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefofg ggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugif rghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrg hinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BCC132057A; Wed, 3 Apr 2019 17:16:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <1967676937.3881.1554325916346@appsuite.open-xchange.com> References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <17b8d4e0-0ce5-4768-891c-5a7c77f19289@gulbrandsen.priv.no> <688538e5-bd3d-478a-bfca-d890c6213df9@beta.fastmail.com> <1967676937.3881.1554325916346@appsuite.open-xchange.com> Date: Wed, 03 Apr 2019 17:16:48 -0400 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=d4b3c1ba0d094f9799c9c4862cd8dbc9 Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 21:16:53 -0000 --d4b3c1ba0d094f9799c9c4862cd8dbc9 Content-Type: text/plain On Thu, Apr 4, 2019, at 08:12, Michael Slusarz wrote: >> On April 2, 2019 at 8:09 PM Bron Gondwana wrote: >> >> >> On Sun, Mar 31, 2019, at 18:58, Arnt Gulbrandsen wrote: >>> > That sounds reasonable. I'd be happy to help with a document >>> > like that, or find someone else at FastMail who might want their >>> > name on an RFC in exchange for doing the work :) >>> >>> I can edit, iff two big providers will produce flag lists. Alone or with a >>> co-editor. >>> >>> I like the way Neil has used github. >> >> I can do one for FastMail. Anyone from one of the other providers here able to get such a list? > In Dovecot, we recently introduced an option to do server-side attachment detection which sets either "$HasAttachment" or "$HasNoAttachment" for each message processed. > > Jeff already did most of the legwork on standardization text here: > > https://mailarchive.ietf.org/arch/msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278 We do the same in FastMail and ship an implementation with open-source Cyrus as part of the annotator. It's also used by the JMAP code to populate the JMAP data. We don't use $HasNoAttachment any more though, we just set a flag to say "the server did the processing". It would be easy to switch to a more standard processing for new messages, or even go back and re-process existing messages. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --d4b3c1ba0d094f9799c9c4862cd8dbc9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Apr 4, 2019, at 08:12, Michael Slusarz wrote:
<= /div>
On April 2, 2019 at 8:09 PM Bro= n Gondwana <brong@fastmailteam.com> wrote:


<= /div>
On Sun, Mar 31, 2019, at 18:58, A= rnt Gulbrandsen wrote:
> That sounds reasonable.  I'd be happy to h= elp with a document 
&g= t; like that, or find someone else at FastMail who might want their = ;
> name on an RFC in exc= hange for doing the work :)
=
I can edit, iff two big prov= iders will produce flag lists. Alone or with a 
co-editor.

I like the way Neil = has used github.

I can do one for FastMail.=   Anyone from one of the other providers here able to get such a li= st?
= In Dovecot, we recently introduced an option to do server-side attachmen= t detection which sets either "$HasAttachment" or "$HasNoAttachment" for= each message processed.

Jeff alre= ady did most of the legwork on standardization text here:

https://mailarchive.ietf.org/arch/= msg/imapext/MVE5eNHOaNIVGUvN1RKtBL8b278

= We do the same in FastMail and ship an implementation with open-source C= yrus as part of the annotator.  It's also used by the JMAP code to = populate the JMAP data.

<= /div>
We don't use $HasNoAttachment any= more though, we just set a flag to say "the server did the processing".=   It would be easy to switch to a more standard processing for new = messages, or even go back and re-process existing messages.

Bron.

-= -
  Bron Gondwana, CEO, FastMail = Pty Ltd
  brong@fastmailteam.com<= br>


--d4b3c1ba0d094f9799c9c4862cd8dbc9-- From nobody Wed Apr 3 14:49:17 2019 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 B1CFD120203 for ; Wed, 3 Apr 2019 14:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT7qA9pECa6k for ; Wed, 3 Apr 2019 14:49:13 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 93EA612003E for ; Wed, 3 Apr 2019 14:49:13 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 0263B6A23E for ; Wed, 3 Apr 2019 23:49:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554328150; bh=OzouqEKORnEcjDsWhK/WPAyieWpgLMEkUHlaTVxkclQ=; h=Date:From:To:In-Reply-To:References:Subject:From; b=gYgX/zDGre57DAEPl4rLmHpMHo0nYC9c1OU3g/QMPKrwJbGl6P2AX4lMTlzSQNknJ Mw5VaNY60qFW1wgkgkuwPXCRo3jM8WDlNiu4jhez7yohfrDniB0y1nm3hT3Z0sLV2a aC2Tm4OPLxAFiCXLNSejMyPv3huOJBqSR4YPJY4oSfJsVAO7DnqlfdNnl8B5NyQvSB TjQtfccZDWAnzYSik9qxXOPaMUg4K6lZ5cyIOvlH+rLsdRgP1FYnr8ppdSq7SGzTrz Jil7l8XAKRVe8qrU5puzRtUxp01UbnXNf5tWxBI2QzRwl4b1yr8i7ClILYJlnQjobk rdRs1ybdl1YAA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id EA53D3C0399 for ; Wed, 3 Apr 2019 23:49:09 +0200 (CEST) Date: Wed, 3 Apr 2019 15:49:09 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <1003410466.3899.1554328149896@appsuite.open-xchange.com> In-Reply-To: <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3898_952948028.1554328149890" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 21:49:17 -0000 ------=_Part_3898_952948028.1554328149890 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > On March 28, 2019 at 10:11 AM Bron Gondwana wrote: > > Regarding the IMAP flags, it sounds like you are asking for the $JunkRecorded flag to be standardised, as a keyword which is only set on user action? > Similar keywords were part of the IMAP keyword registry draft (eventually RFC 5788), before it was taken out: https://tools.ietf.org/rfcdiff?url2=draft-melnikov-imap-keywords-04.txt Maybe Alexey can comment on the reasoning. (I'll note that $AutoJunk, along with $NoJunk, made it into some RFC 4551/5162/7162 examples...) For our customers, the much more interesting question is a method to inform mail clients *how* to report messages as Junk (or Not Junk). RFC 6154 is as close as there is to a standard, with its "\Junk" label, but it doesn't explicitly provide details on whether messages moved to the \Junk mailbox, (or moved out of it) are definitively reported to an AV/AS provider. A SPECIAL-USE label of something like "\JunkReporting", with an explicit definition that messages moved into this mailbox by user action are reported as Junk and messages moved out of this mailbox by user action are reported as Not Junk, would be tremendously useful. michael ------=_Part_3898_952948028.1554328149890 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On March 28, 2019 at 10:11 AM Bron Gondwana <brong@fastmailteam.com> wrote:

Regarding the IMAP flags, it sounds like you are asking for the $JunkRecorded flag to be standardised, as a keyword which is only set on user action?
Similar keywords were part of the IMAP keyword registry draft (eventually RFC 5788), before it was taken out:

https://tools.ietf.org/rfcdiff?url2=draft-melnikov-imap-keywords-04.txt

Maybe Alexey can comment on the reasoning.

(I'll note that $AutoJunk, along with $NoJunk, made it into some RFC 4551/5162/7162 examples...)

For our customers, the much more interesting question is a method to inform mail clients *how* to report messages as Junk (or Not Junk).  RFC 6154 is as close as there is to a standard, with its "\Junk" label, but it doesn't explicitly provide details on whether messages moved to the \Junk mailbox, (or moved out of it) are definitively reported to an AV/AS provider.

A SPECIAL-USE label of something like "\JunkReporting", with an explicit definition that messages moved into this mailbox by user action are reported as Junk and messages moved out of this mailbox by user action are reported as Not Junk, would be tremendously useful.

michael

------=_Part_3898_952948028.1554328149890-- From nobody Wed Apr 3 15:12:11 2019 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 26AAD120298 for ; Wed, 3 Apr 2019 15:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqRyOPk0Ia5H for ; Wed, 3 Apr 2019 15:12:08 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 55DDF12016F for ; Wed, 3 Apr 2019 15:12:08 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 4CDE46A23E for ; Thu, 4 Apr 2019 00:12:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554329524; bh=A9PPHSzMRkLv2ctbPFANYrG/qg494UPhGEIX2tumM/Y=; h=Date:From:To:Subject:From; b=2H+nzGiv61HUWIIpxLSUj1WZQzVnB0BUde4BNv7OpIdNnrHI05GcLC9Hd7VYAiLsj JKDDCAqSw39rBO9JW0G4h0GjtdOpG48FETmwosvo6Huc7eOBGNKE5yDhodg4VxJunQ Cva50vTyZZt/ZNiXXea2hMPY0b15ptKZNKAvgGRNtqnRudCiqa1Rh7KiR/8YMo6mj3 8+fXwmtMpBtx7wXAkJ7B8HWShcKOGpz1q2cLtK2GNTXZdo7CTFwcssP97Ovpd1IL54 Pkkka41Lj6umCPCRVX3xBOd5AC/IX63edOvgQYGIxE93NOlUqotGKoZUsw0q1sNiG5 Zs8hGfHubQk4w== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 434463C0399 for ; Thu, 4 Apr 2019 00:12:04 +0200 (CEST) Date: Wed, 3 Apr 2019 16:12:04 -0600 (MDT) From: Michael Slusarz To: extra@ietf.org Message-ID: <1625398863.3912.1554329524199@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: [Extra] draft-ietf-extra-imap4rev2-04: ALERT X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 22:12:10 -0000 Is "ALERT" useful anymore? It's limited to ASCII output, which restricts which languages can even be represented in the output text. It becomes more useful if LANGUAGE extension is implemented and used. But how many clients use this extension? The context where ALERT seems most useful is during authentication. Things like "your password has expired", "your account has been compromised", "Your email plan has expired, please renew your contract", etc. Gmail has WEBALERT to facilitate this kind of user interaction by directing to a webpage, which is the standard way to facilitate this kind of more complex feedback. Or maybe something like "[URLALERT ]", where URL can be any registered URL type and a client only needs to handle URL types it understands, would be more generic and future-proof. Not sure if this is something to address in rev2, or something that would be better served in a future extension. michael From nobody Wed Apr 3 16:02:19 2019 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 8EE671202C9; Wed, 3 Apr 2019 16:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0A_3lbhmSJX; Wed, 3 Apr 2019 16:02:15 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 363CA1202C3; Wed, 3 Apr 2019 16:02:11 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 5A4CE6A23E; Thu, 4 Apr 2019 01:02:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554332529; bh=g6+yXZ7MDPLLd5tx4QFAlN/fO641wK1AKjG2k78K3M4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=7JBBhIcBddzRbIEOHVZYV684VJ4hGUuloY8X6Q4j8x6c3lMRBMJEun9932bngHhEV bjGXMbbUwqNim7mUxvB+Lm/Lfj1hx6+B2vFohHEG/cAuCcIinz7xeU36+tmaHB83jI xv9N2SIXVGk+2YtyS+M4ixZOaVpe9SjvXS/2NrOiC2EAQ2PCtMOpmMB56dDkymVvfY DyrdfnbQnsq4ZcHwNLmENHYmxqKTsE6VepeL/r4VTBrtCpVJyHsbQ97LICE1ql80ch tgGZqiaHXwKQ7lhjyYcOxLa6Tw1LTZcoLRi9lCN5zS6RtdbyaIx9VkPEYey2uhsNwb NuXtzDMdRmXcg== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 4CF3C3C0399; Thu, 4 Apr 2019 01:02:09 +0200 (CEST) Date: Wed, 3 Apr 2019 17:02:09 -0600 (MDT) From: Michael Slusarz To: Stefan Santesson , Stefan Santesson via Datatracker , secdir@ietf.org Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-fetch-preview.all@ietf.org Message-ID: <400432883.3939.1554332529253@appsuite.open-xchange.com> In-Reply-To: <155325148211.23112.1549884159837912898@ietfa.amsl.com> References: <155325148211.23112.1549884159837912898@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-imap-fetch-preview-03 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 23:02:18 -0000 Hello Stefan, Thanks for your review. Comments below. > On March 22, 2019 at 4:44 AM Stefan Santesson via Datatracker wrote: > > However the security consideration section seems to lack relevant information. > The current security considerations section raise the threat of DOS attacks. > It is, however, not clear to me how the risk of DOS is affected or mitigated by > the fact that request for preview data is restricted to authenticated clients. > A discussion of this seems at least to be relevant for the context. Background: the security consideration section is adapted from similar text in the CONVERT (RFC 5259) security considerations section. Denial of server attacks here are exclusively due to authenticated users issuing PREVIEW generation commands. DOS would occur by exhausting local server resources. This kind of DOS attack is similar to DOS attacks that can be done with core IMAP commands available for authenticated users (e.g. excessive FETCHs, APPEND floods). To that extent, we could add additional language from 5259 to this document along the lines of: "In order to mitigate such attacks, servers SHOULD log the client authentication identity on FETCH operations in order to facilitate tracking of abusive clients." ...although, this is not exclusive to PREVIEW extension so maybe this is something that can/should be added more generally to imap4rev2 (in draft) Security Considerations. The only algorithm defined in this document is a text-parsing algorithm, so theoretically there are security considerations involved in this text parsing. However, IMAP servers are required to do all sorts of text parsing in order to return FETCH data so this extension is not adding a different security risk that already doesn't exist with base RFC 3501 functionality. I would be fine with adding a line stating that all security risks associated with base IMAP spec are applicable to this document also. michael From nobody Wed Apr 3 16:40:50 2019 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 7AD041200FB for ; Wed, 3 Apr 2019 16:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RbLghwvd1bOF for ; Wed, 3 Apr 2019 16:40:42 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78A431202E1 for ; Wed, 3 Apr 2019 16:40:42 -0700 (PDT) Received: (qmail 5305 invoked from network); 3 Apr 2019 23:40:41 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (e444d1aa-5669-11e9-a01f-9bc39f70b3b8); Wed, 03 Apr 2019 16:40:41 -0700 To: extra@ietf.org References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <1003410466.3899.1554328149896@appsuite.open-xchange.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Wed, 3 Apr 2019 16:40:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1003410466.3899.1554328149896@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: e444d1aa-5669-11e9-a01f-9bc39f70b3b8 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 23:40:49 -0000 On 2019-04-03 2:49 p.m., Michael Slusarz wrote: >> On March 28, 2019 at 10:11 AM Bron Gondwana >> wrote: >> >> Regarding the IMAP flags, it sounds like you are asking for the >> $JunkRecorded flag to be standardised, as a keyword which is only set >> on user action? > Similar keywords were part of the IMAP keyword registry draft > (eventually RFC 5788), before it was taken out: > > https://tools.ietf.org/rfcdiff?url2=draft-melnikov-imap-keywords-04.txt > > Maybe Alexey can comment on the reasoning. > > (I'll note that $AutoJunk, along with $NoJunk, made it into some RFC > 4551/5162/7162 examples...) > > For our customers, the much more interesting question is a method to > inform mail clients *how* to report messages as Junk (or Not Junk).  RFC > 6154 is as close as there is to a standard, with its "\Junk" label, but > it doesn't explicitly provide details on whether messages moved to the > \Junk mailbox, (or moved out of it) are definitively reported to an > AV/AS provider. > > A SPECIAL-USE label of something like "\JunkReporting", with an explicit > definition that messages moved into this mailbox by user action are > reported as Junk and messages moved out of this mailbox by user action > are reported as Not Junk, would be tremendously useful. > > michael We would support this idea, but want to of course mention, that we have to work with email client providers who still want their own use of a flag, eg for training etc.. that the client would be responsible for setting both flags, instead of just mucking with the \JunkReporting flag.. or using it for purposes other than what it is intended. Of course, it would be nice to define from an IMAP side, a 'hook' mechanism, so that on detection of the change in that flag, a server defined action could be called. And should marking a message with that flag, mean that IMAP should move it to the special use junk folder? Or if it is in the junk folder, should IMAP move the message to inbox? We would of course like to see a 'hook' mechanism, that can be used so we can also use that information for adding to the users blacklist/whitelist natively via IMAP, instead of only through our webmail implementations, no matter what email client the end user is using. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Wed Apr 3 16:52:23 2019 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 5AD7E1202F6 for ; Wed, 3 Apr 2019 16:52:21 -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=NKLMESCr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Tg1+oljR 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 MdZfMQC3v7_K for ; Wed, 3 Apr 2019 16:52:19 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500811202F1 for ; Wed, 3 Apr 2019 16:52:19 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6882721EAD for ; Wed, 3 Apr 2019 19:52:17 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 03 Apr 2019 19:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=+PrZ3jI mxC/xs5PJOTWKnJn+M//4ZYYKyEGpswRng/U=; b=NKLMESCr0IWXUKxqtmOapH3 uglf//UhwueFKfJWv70n0OZPvc97NIrAnkvTZQn3lU35OzOYYyH7MznWvC9oaKvS Ulamk4rv2cwmmwCyVSi3bOwWtNz/X0iAaBNbMtogEr3BQFk/SrJDdYgBUrfPCdTE K0nNvljXL9WRPRc+G7n50B2KIZMwp+tklJ/SWWRAEmf+m9dN+c4Rr74VMz8Qp9LO snTmTNZbaS9898i8sGKWr6fn3ShCNOtgKdL/42gIQpuepAhsummGjgGKp11OTUhQ qwDXNWaKjYKo/kNH086GGmLSzz88KGlsfUbEyIYx2hByaINej0/PU004GlEhNOQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+PrZ3j ImxC/xs5PJOTWKnJn+M//4ZYYKyEGpswRng/U=; b=Tg1+oljRZnWGb2pHYslf2m YabMWJm5afo4Bm0ZPBERoPhRKrxnm5aOyddsuvP0sho3PfqS5hXRpgOBK9vQlvqU vG9fdLmjzOhSImtfbxeE4iVw+hq8SPAEXDYQ7ghz49F444M40jRPdm6xvk+x1sW9 Bbrg6/BfSJe9q7saJPmdtp1j30wY6qOok/pDK3r4QvboKoxJ8X2+QmU6ndQl5q/b a+QyZUDvvs/HXH4f9sm+xDbij46uxWst3zknCtf/gGaQgs/fCsRMqNMUl3r1aSk/ I1izqd0ZlOhu9WvN7wuf6o42ANE7GvlsxTJybv4WPvD25acpCgwUHMU0x6K6xdgg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdeggddvieculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhn shdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpe hmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E12D72057A; Wed, 3 Apr 2019 19:52:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 64588216 Message-Id: <34412433-fa56-490c-860e-4d923ac5e3df@beta.fastmail.com> In-Reply-To: References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <1003410466.3899.1554328149896@appsuite.open-xchange.com> Date: Wed, 03 Apr 2019 19:52:16 -0400 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=75a6dd108b7a4e1bb9a3d0df398f4b1e Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 03 Apr 2019 23:52:21 -0000 --75a6dd108b7a4e1bb9a3d0df398f4b1e Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable At FastMail, we plan to simply add hooks on the IMAP server side so if a= n email is moved to the Spam folder it is learned as spam, and if moved = out of the spam folder (except to trash) it is learned as non-spam. Also= if an email is moved to the Archive folder it would be learned as non-s= pam. Client-side filtering seems to be universally garbage from what we've se= en with customer support tickets. I don't know we need a flag to indicat= e to clients that the server will learn based on folder movement, as hop= efully most clients already move messages in/out of the spam folder when= you report spam/not-spam from a client and so this will Just Work=E2=84= =A2=EF=B8=8F. Neil. --75a6dd108b7a4e1bb9a3d0df398f4b1e Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
At FastMail, we= plan to simply add hooks on the IMAP server side so if an email is move= d to the Spam folder it is learned as spam, and if moved out of the spam= folder (except to trash) it is learned as non-spam. Also if an email is= moved to the Archive folder it would be learned as non-spam.
<= div>
Client-side filtering seems to be universally garbage= from what we've seen with customer support tickets. I don't know we nee= d a flag to indicate to clients that the server will learn based on fold= er movement, as hopefully most clients already move messages in/out of t= he spam folder when you report spam/not-spam from a client and so this w= ill Just Work=E2=84=A2=EF=B8=8F.

Neil. --75a6dd108b7a4e1bb9a3d0df398f4b1e-- From nobody Wed Apr 3 18:13:00 2019 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 5E2F6120357 for ; Wed, 3 Apr 2019 18:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 P-tQKcyr9nw3 for ; Wed, 3 Apr 2019 18:12:56 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 989F11201B1 for ; Wed, 3 Apr 2019 18:12:56 -0700 (PDT) Received: (qmail 18891 invoked from network); 4 Apr 2019 01:12:55 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (c6d31c96-5676-11e9-91f4-ab704c62840a); Wed, 03 Apr 2019 18:12:55 -0700 To: extra@ietf.org References: <49b87029-7cc2-4324-9d97-f7fa2b8762ce@www.fastmail.com> <25ed8a44-6fce-4778-d9cd-d732b7cb91f6@linuxmagic.com> <533a9f07-80c6-4cbc-b7af-fe10ce62580c@www.fastmail.com> <1003410466.3899.1554328149896@appsuite.open-xchange.com> <34412433-fa56-490c-860e-4d923ac5e3df@beta.fastmail.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <942d0f1b-f164-a015-9c6f-de94358e9b23@linuxmagic.com> Date: Wed, 3 Apr 2019 18:12:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <34412433-fa56-490c-860e-4d923ac5e3df@beta.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: c6d31c96-5676-11e9-91f4-ab704c62840a X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] Fwd: Personnel change for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 04 Apr 2019 01:12:59 -0000 For us, that is one option, so right now we are looking at all the arguments, however it does seem people like the big button 'This is Junk' more, they won't bother 'training', and don't really understand the concept. Training is something techies understand, but not the average user. They would rather click 'delete' than remember to move it to junk, IMHO.. So, it is about standardizing how/what should happen when a person clicks the big button.. We 'could' use that to trigger a move to Junk, which would trigger other things.. or we can use flags. Our concern, is that things other than user interaction could trigger a MOVE, eg an email clients own internal spam detection methods.. which is not what we want to know, we want to know when the 'human' makes that decision. Make sense? On 2019-04-03 4:52 p.m., Neil Jenkins wrote: > At FastMail, we plan to simply add hooks on the IMAP server side so if > an email is moved to the Spam folder it is learned as spam, and if moved > out of the spam folder (except to trash) it is learned as non-spam. Also > if an email is moved to the Archive folder it would be learned as non-spam. > > Client-side filtering seems to be universally garbage from what we've > seen with customer support tickets. I don't know we need a flag to > indicate to clients that the server will learn based on folder movement, > as hopefully most clients already move messages in/out of the spam > folder when you report spam/not-spam from a client and so this will Just > Work™️. > > Neil. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Fri Apr 5 14:05:20 2019 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 20B20120620; Fri, 5 Apr 2019 14:05:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2019 14:05:13 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 21:05:14 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I wavered a lot about whether this was DISCUSS-worthy, but it seems like we should at least talk about how big a risk for future confusion there is: I'm a little confused by the ABNF for 'capability' in Section 7 -- it seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and Section 3.1 talk only about *algorithms* in PREVIEW capability responses (and not modifiers). Is the intent to have capability tags for (non-mandatory) priority modifiers? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.1 Alternately, the client may explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm. These algorithms MUST be one nit: there's potential for misparsing here (e.g., that the PREVIEW attribute contains the name of the algorithm and the parenthesized list is after that), so maybe put "after the PREVIEW attribte" in parentheses or offset by commas. of the algorithms identified as supported in the PREVIEW capability responses. [...] nit: singular/plural mismatch between "these algorithms" and "one of". Section 7 How much discussion was there about "SHOULD be registered" (as opposed to "MUST be registered")? Section 8 side note: This is one of the shortest IANA considerations sections I've seen thta creates registries (in that it doesn't lay out a registration template), but IANA seems to be saying they have what information they need, so who am I to complain... Section 9 I agree with Roman that there should be discussion of the caching/data retention strategy for message previews. This existing text about denial-of-service attacks is probably fine, though I might consider rephrasing it along the lines of "this mechanism introduces a new way for clients to make requests that consume server resources. As is the case for all such mechanisms, it could be used as part of a denial-of-service attack on server resources, e.g., via excessive memory or CPU usage, or increased storage if preview results are cached on the server after generation. The additional attack surface presented by this specific mechanism is not believed to higher risk that other similar mechanisms in use already, since the individual resource consumption per message processed is likely to be modest. Nonetheless, servers MAY limit the resources consumed by preview generation." As I write the above, though, I wonder how this interacts with the previous text in Section 3.1 about how the "server MUST honor a client's algorithm priority decision". Does that mean that if some future (expensive) algorithm is specified, once a server implements that algorithm, any client can force its use and thus the expensive resource consumption on the server? It's not entirely clear to me how this MAY interacts with that MUST, in such a hypothetical scenario. From nobody Sun Apr 7 20:25:39 2019 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 D1A5A1202C3; Sun, 7 Apr 2019 20:25:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2019 20:25:30 -0700 Archived-At: Subject: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 03:25:31 -0000 Barry Leiba has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- — Section 3.1 — I don’t understand “the client’s priority decision”: what decision is that? And what’s the point of giving the server a list of algorithms here, given that they all have to be ones that are supported by the server? Won’t the server always have to use the first one in the list? If not, please add some text explaining what the server does. — Section 3.2 — If the preview is not available, the server MUST return NIL as the PREVIEW response. A NIL response indicates to the client that preview information MAY become available in a future PREVIEW FETCH request. Note that this is semantically different than returning a zero-length string, which indicates an empty preview. I think the MUST here is hard to follow, because the text doesn’t make a clear enough distinction between “preview is not available” and “an empty preview”. Can you expand the text a bit to explain the distinction more clearly, as this is a protocol requirement? Also, as I noted in response to Meral’s Gen-ART review it would be good to be clear how encrypted messages should be handled in this regard. — Section 4.1 — The preview text MUST be treated as text/plain MIME data by the client. I think this requires a normative reference to RFC 2046. — Section 5.1 — The way you have LAZY working isn’t really consistent with the IMAP protocol model. In that model, the client would not have to ask for the preview twice, one with LAZY and one without. Instead, with LAZY, the server would return FETCH PREVIEW responses when it could — perhaps some in the first set of FETCH responses, and some, where the PREVIEW part was missing before, in unsolicited FETCH responses when the preview became available. That way, the server has the responsibility of setting off a separate task to generate the previews, and to send them to the client when it has them (at which point it either saves the for future FETCHes or doesn’t). As it’s written here, the client has to open a separate IMAP session with the server and ask a second time for the previews it’s missing — a separate session to avoid blocking other action on the main session. And if the server has spun off a task to preemptively generate them because the client asked once (a good practice, given the description here) it has to retain them for some indefinite period waiting for the client to ask again. Why was this not done with the first mechanism? — Section 7 — As was mentioned in Ben’s review, either the ABNF for “capability” is in error (it should not include “preview-mod-ext”) or the description needs to be significantly beefed up. I’m guessing that the intent is that PREVIEW= capabilities include both algorithms and modifiers, that PREVIEW=FUZZY is required, that the presence of any preview algorithm implies PREVIEW=LAZY such that the latter not only need not be specified, but is not permitted to be. So we might have “PREVIEW=FUZZY PREVIEW=FURRY PREVIEW=SLEEPY”, which would mean we support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY. Is that correct? That seems somewhat obtuse to me, overloading the PREVIEW= capability and inviting confusion. — Section 8 — It seems like a bad idea to have to keep the IMAP Capabilities registry in sync with the two new registries: as it stands, when you add a new algorithm you have to add it to the Preview Algorithms registry, and also add a corresponding entry in the Capabilities registry... and similarly for a modifier, if I have that right above. Why not follow the model of AUTH= and RIGHTS=, and just reserve the PREVIEW= capability in the registry, allowing it to apply to entries from the two new registries? That avoids inconsistencies in registrations if we later add algorithms or modifiers. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 3.1 — Nit: Please change “alternately” to “alternatively”. These algorithms MUST be one of the algorithms identified as supported in the PREVIEW capability responses. There’s a number-agreement problem here. NEW All algorithms in the list MUST have been included in the list of algorithms identified as supported in the PREVIEW capability responses. END — Section 3.2 — This relaxed requirement permits a server to offer previews as an option without requiring potentially burdensome storage and/or processing requirements to guarantee immutability for a use case that does not require this strictness. That’s sensible, but can you include some text giving an example of a situation where the preview might change? Given that the messages themselves are immutable, why would applying the same algorithm to the same text give different results? — Section 4.1 — The server SHOULD limit the length of the preview text to 200 preview characters. This length should provide sufficient data to generally support both various languages (and their different average word lengths) and different client display size requirements. The server MUST NOT output preview text longer than 256 preview characters. The text here should make it clear, because many implementers do not understand the difference, that these refer to *characters*, not *bytes*, and that 200 or 256 characters can possibly be much longer than 256 bytes. I worry that an implementer might allocate a buffer of 256 bytes, thinking that’s enough, and have it overflowed. The server SHOULD remove any formatting markup that exists in the original text. This is OK as it is, but perhaps a bit more specific than necessary. I think the sense is that the server is meant to do its best to render the preview as plain text, because that’s what the client will treat it as. As such, I would fold this into the earlier paragraph that talks about no transfer encoding, and maybe say it something like this: The generated string will be treated by the client as plain text, so the server should do its best to provide a meaningful plain text string. The generated string MUST NOT be content transfer encoded and MUST be encoded in UTF-8 [RFC3629]. For purposes of this section, a "preview character" is defined as a single UCS character encoded in UTF-8. The server SHOULD also remove any formatting markup, and do what other processing might be useful in rendering the preview as plain text. From nobody Mon Apr 8 12:38:46 2019 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 75FEA12032F; Mon, 8 Apr 2019 12:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jzFYptgdv4s7; Mon, 8 Apr 2019 12:38:34 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 35167120088; Mon, 8 Apr 2019 12:38:34 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38JYh2m189503; Mon, 8 Apr 2019 19:38:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=76D6xKlJ4rf1ADa47P12SOBTUBBMW1qMPlyiQjt11qE=; b=naiYeAK+5qQ0T8/hr09QfIVYQsIDrp7NWSewml0d2SaEQwuCH1vokEz86xlOFgGqmntF vXItlw48fHQfIq3O1EcIz32N5lK3CIFK4EnSQkt35WhP4DlMHFCNFjjWxoUJ7F4uTSDM MeaNKimjq8Z1DkD0KiaKMVK4IL8QkuzCbUTPUn6OkGkN9v19ClCObdCX5VsfNwFMGHzK akn7YM4LY36hmXD31AX4DM2G8UtwA5W9h4BNmMCULPRCanHVtGdQAuX6YQolEgnRbquB I9409lLO9gjjq8hUlsioLjZUEX5HLnsDFmVzEz/BM4UysZWOKQkCFW64+RXcj5YaGitt Fg== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2rpkhsrqnn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:38:29 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38JcPmn015979; Mon, 8 Apr 2019 19:38:29 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2rph7s6j4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:38:29 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x38JcR9r025715; Mon, 8 Apr 2019 19:38:27 GMT Received: from [10.145.183.62] (/10.145.183.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Apr 2019 12:38:26 -0700 From: "Chris Newman" To: "Barry Leiba" Cc: "The IESG" , extra@ietf.org, "Bron Gondwana" , draft-ietf-extra-imap-fetch-preview@ietf.org Date: Mon, 08 Apr 2019 12:38:02 -0700 X-Mailer: MailMate (1.12.4r5594) Message-ID: <899C7434-8C5F-42B1-A99B-3DC46483472B@oracle.com> In-Reply-To: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 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-1810050000 definitions=main-1904080150 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080149 Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 19:38:37 -0000 On 7 Apr 2019, at 20:25, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-extra-imap-fetch-preview-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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ies= g_statement_discuss-2Dcriteria.html&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZ= h8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D= MX001Ss_AeNyXvo6ikSivMny92vtZHwv1o5u46suxv0&s=3DE7J5zigfcri3VIAMhsM-C7rxl= MvQsinhAupR0vFaE4Q&e=3D > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= =2Eorg_doc_draft-2Dietf-2Dextra-2Dimap-2Dfetch-2Dpreview_&d=3DDwIGaQ&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiE= U3xl9LcD2OOJG3TXfI&m=3DMX001Ss_AeNyXvo6ikSivMny92vtZHwv1o5u46suxv0&s=3DJG= Z_W2tQh-5CzY9IdDs4v_W8HvA2t830SFv9RiL8Snw&e=3D > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > =E2=80=94 Section 3.1 =E2=80=94 > > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority decis= ion=E2=80=9D: what = > decision is that? > And what=E2=80=99s the point of giving the server a list of algorithms = here, = > given that > they all have to be ones that are supported by the server? Won=E2=80=99= t = > the server > always have to use the first one in the list? If not, please add some = > text > explaining what the server does. > > =E2=80=94 Section 3.2 =E2=80=94 > > If the preview is not available, the server MUST return NIL as the > PREVIEW response. A NIL response indicates to the client that > preview information MAY become available in a future PREVIEW FETCH > request. Note that this is semantically different than returning a > zero-length string, which indicates an empty preview. > > I think the MUST here is hard to follow, because the text doesn=E2=80=99= t = > make a clear > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D a= nd =E2=80=9Can = > empty preview=E2=80=9D. > Can you expand the text a bit to explain the distinction more clearly, = > as this > is a protocol requirement? Also, as I noted in response to Meral=E2=80= =99s = > Gen-ART > review it would be good to be clear how encrypted messages should be = > handled in > this regard. > > =E2=80=94 Section 4.1 =E2=80=94 > > The preview text MUST be treated as text/plain MIME data by the > client. > > I think this requires a normative reference to RFC 2046. > > =E2=80=94 Section 5.1 =E2=80=94 > > The way you have LAZY working isn=E2=80=99t really consistent with the = IMAP = > protocol > model. In that model, the client would not have to ask for the = > preview twice, > one with LAZY and one without. Instead, with LAZY, the server would = > return > FETCH PREVIEW responses when it could =E2=80=94 perhaps some in the fir= st = > set of FETCH > responses, and some, where the PREVIEW part was missing before, in = > unsolicited > FETCH responses when the preview became available. That way, the = > server has > the responsibility of setting off a separate task to generate the = > previews, and > to send them to the client when it has them (at which point it either = > saves the > for future FETCHes or doesn=E2=80=99t). That alternative design would take control away from the client, make = the client code more complex, and make the server code more complex. For = clients using deployed request/response-style IMAP APIs, your proposal = would violate the API model and thus be incredibly hard to implement = without replacing a lot of the API. On the server side, even if I was = willing to implement what you propose (and I'm not), I'd have to refuse = to issue the untagged response until all PREVIEWs were generated to make = sure request/response style client APIs could handle that server = behavior -- at which point it's far less efficient than the proposed = design where the client has control. I happen to consider the tagged/asynchronous part of the IMAP model to = be an elegant design that is a failure in practice when it encounters = the real world of implementations. The fact is the majority of clients = and client APIs just get the model wrong -- they're so used to = request/response that they try to shove a cache/update model into a = request/response model with predictably bad results. In our 8.0 server = release, we tried to push the envelope just a little bit by generating = untagged EXISTS responses between commands (a behavior that's explicitly = encouraged by the IMAP base spec) and that broke interoperability with = more than one IMAP client in practice so we had to add an option to = suppress that behavior to maintain interoperability with those = (admittedly buggy) clients. > As it=E2=80=99s written here, the client has to open a separate IMAP se= ssion = > with the > server and ask a second time for the previews it=E2=80=99s missing =E2=80= =94 a = > separate session > to avoid blocking other action on the main session. And if the server = > has spun > off a task to preemptively generate them because the client asked once = > (a good > practice, given the description here) it has to retain them for some = > indefinite > period waiting for the client to ask again. As it turns out, that's exactly the implementation model followed by = clients that generate previews manually without this extension. So with = the new preview extension those clients just tweak the first command to = add LAZY PREVIEW fetch so they possibly get early previews (improving = the UI for a very small change). Then the client implementer can add an = alternate code path to use the non-LAZY preview fetch variant instead of = computing manually or the client implementer could ignore the non-LAZY = preview feature and have fewer codepaths to test -- their choice (and = the better choice might depend on whether the client is mobile or = desktop -- something the server doesn't know). Since our server implemented PREVIEW before LAZY was added, I find the = proposed LAZY an inconvenient but defensible addition to the protocol = because it allows the client this additional implementation flexibility. = But if the LAZY extension didn't give the client flexibility, then I'd = consider the feature objectionable -- it would be significant = unnecessary complexity without a defensible implementation benefit. > Why was this not done with the first mechanism? I can't speak to why the author wrote it that way, but as a server = implementor, I find the way LAZY is presently specified to be perfectly = acceptable and it has a straightforward implementation in my server. = However, the proposed alternate design would be a royal PITA to = implement on my server. - Chris > =E2=80=94 Section 7 =E2=80=94 > > As was mentioned in Ben=E2=80=99s review, either the ABNF for = > =E2=80=9Ccapability=E2=80=9D is in error > (it should not include =E2=80=9Cpreview-mod-ext=E2=80=9D) or the descri= ption needs = > to be > significantly beefed up. I=E2=80=99m guessing that the intent is that = > PREVIEW=3D > capabilities include both algorithms and modifiers, that PREVIEW=3DFUZZ= Y = > is > required, that the presence of any preview algorithm implies = > PREVIEW=3DLAZY such > that the latter not only need not be specified, but is not permitted = > to be. So > we might have =E2=80=9CPREVIEW=3DFUZZY PREVIEW=3DFURRY PREVIEW=3DSLEEPY= =E2=80=9D, which = > would mean we > support the algorithms FUZZY and FURRY, and the modifiers LAZY and = > SLEEPY. Is > that correct? > > That seems somewhat obtuse to me, overloading the PREVIEW=3D capability= = > and > inviting confusion. > > =E2=80=94 Section 8 =E2=80=94 > > It seems like a bad idea to have to keep the IMAP Capabilities = > registry in sync > with the two new registries: as it stands, when you add a new = > algorithm you > have to add it to the Preview Algorithms registry, and also add a = > corresponding > entry in the Capabilities registry... and similarly for a modifier, if = > I have > that right above. > > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve the= = > PREVIEW=3D > capability in the registry, allowing it to apply to entries from the = > two new > registries? That avoids inconsistencies in registrations if we later = > add > algorithms or modifiers. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =E2=80=94 Section 3.1 =E2=80=94 > > Nit: Please change =E2=80=9Calternately=E2=80=9D to =E2=80=9Calternativ= ely=E2=80=9D. > > These algorithms MUST be one > of the algorithms identified as supported in the PREVIEW capability > responses. > > There=E2=80=99s a number-agreement problem here. > > NEW > All algorithms in the list MUST have been included in the > list of algorithms identified as supported in the PREVIEW = > capability > responses. > END > > =E2=80=94 Section 3.2 =E2=80=94 > > This relaxed requirement permits a > server to offer previews as an option without requiring potentially > burdensome storage and/or processing requirements to guarantee > immutability for a use case that does not require this strictness. > > That=E2=80=99s sensible, but can you include some text giving an exampl= e of = > a situation > where the preview might change? Given that the messages themselves = > are > immutable, why would applying the same algorithm to the same text give > different results? > > =E2=80=94 Section 4.1 =E2=80=94 > > The server SHOULD limit the length of the preview text to 200 = > preview > characters. This length should provide sufficient data to = > generally > support both various languages (and their different average word > lengths) and different client display size requirements. > > The server MUST NOT output preview text longer than 256 preview > characters. > > The text here should make it clear, because many implementers do not = > understand > the difference, that these refer to *characters*, not *bytes*, and = > that 200 or > 256 characters can possibly be much longer than 256 bytes. I worry = > that an > implementer might allocate a buffer of 256 bytes, thinking that=E2=80=99= s = > enough, and > have it overflowed. > > The server SHOULD remove any formatting markup that exists in the > original text. > > This is OK as it is, but perhaps a bit more specific than necessary. = > I think > the sense is that the server is meant to do its best to render the = > preview as > plain text, because that=E2=80=99s what the client will treat it as. A= s = > such, I would > fold this into the earlier paragraph that talks about no transfer = > encoding, and > maybe say it something like this: > > The generated string will be treated by the client as plain text, = > so > the server should do its best to provide a meaningful plain text = > string. > The generated string MUST NOT be content transfer encoded and MUST = > be > encoded in UTF-8 [RFC3629]. For purposes of this section, a = > "preview > character" is defined as a single UCS character encoded in UTF-8. = > The > server SHOULD also remove any formatting markup, and do what other > processing might be useful in rendering the preview as plain text. > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DMX001Ss_AeNyXvo= 6ikSivMny92vtZHwv1o5u46suxv0&s=3DN-3gUpkcA9xNcWGc9Rom-LAlShVKARcwVlk-0CUM= jHc&e=3D From nobody Mon Apr 8 12:50:36 2019 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 A7F6C120446; Mon, 8 Apr 2019 12:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YWKJm4_57B11; Mon, 8 Apr 2019 12:50:33 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 CFE2C120442; Mon, 8 Apr 2019 12:50:25 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38JgSMU000793; Mon, 8 Apr 2019 19:50:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=WlVhbeBLd0BveVrpIyuVg8ezsBYit/xlKqGvTnDOIb0=; b=iVmLw7/2uT1bl3DICl3mVGK+g9sJaTwEozGaTa3VTMNfsfDFkVnOi0rFsDw30sbttAE5 i6crYPwMxp92bUj7BksxRRK9Ifz+1L9wYR6Jx2QmgZPDkRv0PWuyljvR490/UYZwFb9V W10CsLSmBWyadZq105IPbPqy2Rv3xARtIaQhGge5GG16CIeicMz898e+do04yWHW3GO/ p12ojUcZlXsw+8V2i3Vij3rc7xYRlF9h3P3moQqwbA6YKoMJoVa/h3sHYWF4s5BUBlG0 GiGSv3wjDfCJa+armMekX0L9+5wj/h/YZf2f59umFtYwd6IhQiBlXeVnF1/9WYboQQNU Xg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rpkhsrsfp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:50:19 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38JnZcl084441; Mon, 8 Apr 2019 19:50:18 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2rpytb7rag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:50:18 +0000 Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x38JoHEg028478; Mon, 8 Apr 2019 19:50:17 GMT Received: from [10.145.183.62] (/10.145.183.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Apr 2019 12:50:16 -0700 From: "Chris Newman" To: "Barry Leiba" Cc: extra@ietf.org, "Bron Gondwana" , "The IESG" , draft-ietf-extra-imap-fetch-preview@ietf.org Date: Mon, 08 Apr 2019 12:50:12 -0700 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: <899C7434-8C5F-42B1-A99B-3DC46483472B@oracle.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <899C7434-8C5F-42B1-A99B-3DC46483472B@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 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-1810050000 definitions=main-1904080150 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080150 Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 19:50:36 -0000 On 8 Apr 2019, at 12:38, Chris Newman wrote: > On 7 Apr 2019, at 20:25, Barry Leiba via Datatracker wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> =E2=80=94 Section 3.1 =E2=80=94 >> >> I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority deci= sion=E2=80=9D: what = >> decision is that? >> And what=E2=80=99s the point of giving the server a list of algorithms= = >> here, given that >> they all have to be ones that are supported by the server? Won=E2=80=99= t = >> the server >> always have to use the first one in the list? If not, please add = >> some text >> explaining what the server does. >> >> =E2=80=94 Section 3.2 =E2=80=94 >> >> If the preview is not available, the server MUST return NIL as the >> PREVIEW response. A NIL response indicates to the client that >> preview information MAY become available in a future PREVIEW FETCH >> request. Note that this is semantically different than returning = >> a >> zero-length string, which indicates an empty preview. >> >> I think the MUST here is hard to follow, because the text doesn=E2=80=99= t = >> make a clear >> enough distinction between =E2=80=9Cpreview is not available=E2=80=9D = and =E2=80=9Can = >> empty preview=E2=80=9D. >> Can you expand the text a bit to explain the distinction more = >> clearly, as this >> is a protocol requirement? Also, as I noted in response to Meral=E2=80= =99s = >> Gen-ART >> review it would be good to be clear how encrypted messages should be = >> handled in >> this regard. >> >> =E2=80=94 Section 4.1 =E2=80=94 >> >> The preview text MUST be treated as text/plain MIME data by the >> client. >> >> I think this requires a normative reference to RFC 2046. >> >> =E2=80=94 Section 5.1 =E2=80=94 >> >> The way you have LAZY working isn=E2=80=99t really consistent with the= IMAP = >> protocol >> model. In that model, the client would not have to ask for the = >> preview twice, >> one with LAZY and one without. Instead, with LAZY, the server would = >> return >> FETCH PREVIEW responses when it could =E2=80=94 perhaps some in the fi= rst = >> set of FETCH >> responses, and some, where the PREVIEW part was missing before, in = >> unsolicited >> FETCH responses when the preview became available. That way, the = >> server has >> the responsibility of setting off a separate task to generate the = >> previews, and >> to send them to the client when it has them (at which point it either = >> saves the >> for future FETCHes or doesn=E2=80=99t). > > That alternative design would take control away from the client, make = > the client code more complex, and make the server code more complex. = > For clients using deployed request/response-style IMAP APIs, your = > proposal would violate the API model and thus be incredibly hard to = > implement without replacing a lot of the API. On the server side, even = > if I was willing to implement what you propose (and I'm not), I'd have = > to refuse to issue the untagged response until all PREVIEWs were = > generated to make sure request/response style client APIs could handle = > that server behavior -- at which point it's far less efficient than = > the proposed design where the client has control. Sorry for the typo: s/refuse to issue the untagged response/refuse to = issue the tagged response/ - Chris > I happen to consider the tagged/asynchronous part of the IMAP model to = > be an elegant design that is a failure in practice when it encounters = > the real world of implementations. The fact is the majority of clients = > and client APIs just get the model wrong -- they're so used to = > request/response that they try to shove a cache/update model into a = > request/response model with predictably bad results. In our 8.0 server = > release, we tried to push the envelope just a little bit by generating = > untagged EXISTS responses between commands (a behavior that's = > explicitly encouraged by the IMAP base spec) and that broke = > interoperability with more than one IMAP client in practice so we had = > to add an option to suppress that behavior to maintain = > interoperability with those (admittedly buggy) clients. > >> As it=E2=80=99s written here, the client has to open a separate IMAP = >> session with the >> server and ask a second time for the previews it=E2=80=99s missing =E2= =80=94 a = >> separate session >> to avoid blocking other action on the main session. And if the = >> server has spun >> off a task to preemptively generate them because the client asked = >> once (a good >> practice, given the description here) it has to retain them for some = >> indefinite >> period waiting for the client to ask again. > > As it turns out, that's exactly the implementation model followed by = > clients that generate previews manually without this extension. So = > with the new preview extension those clients just tweak the first = > command to add LAZY PREVIEW fetch so they possibly get early previews = > (improving the UI for a very small change). Then the client = > implementer can add an alternate code path to use the non-LAZY preview = > fetch variant instead of computing manually or the client implementer = > could ignore the non-LAZY preview feature and have fewer codepaths to = > test -- their choice (and the better choice might depend on whether = > the client is mobile or desktop -- something the server doesn't know). > > Since our server implemented PREVIEW before LAZY was added, I find the = > proposed LAZY an inconvenient but defensible addition to the protocol = > because it allows the client this additional implementation = > flexibility. But if the LAZY extension didn't give the client = > flexibility, then I'd consider the feature objectionable -- it would = > be significant unnecessary complexity without a defensible = > implementation benefit. > >> Why was this not done with the first mechanism? > > I can't speak to why the author wrote it that way, but as a server = > implementor, I find the way LAZY is presently specified to be = > perfectly acceptable and it has a straightforward implementation in my = > server. However, the proposed alternate design would be a royal PITA = > to implement on my server. > > - Chris > >> =E2=80=94 Section 7 =E2=80=94 >> >> As was mentioned in Ben=E2=80=99s review, either the ABNF for = >> =E2=80=9Ccapability=E2=80=9D is in error >> (it should not include =E2=80=9Cpreview-mod-ext=E2=80=9D) or the descr= iption = >> needs to be >> significantly beefed up. I=E2=80=99m guessing that the intent is that= = >> PREVIEW=3D >> capabilities include both algorithms and modifiers, that = >> PREVIEW=3DFUZZY is >> required, that the presence of any preview algorithm implies = >> PREVIEW=3DLAZY such >> that the latter not only need not be specified, but is not permitted = >> to be. So >> we might have =E2=80=9CPREVIEW=3DFUZZY PREVIEW=3DFURRY PREVIEW=3DSLEEP= Y=E2=80=9D, which = >> would mean we >> support the algorithms FUZZY and FURRY, and the modifiers LAZY and = >> SLEEPY. Is >> that correct? >> >> That seems somewhat obtuse to me, overloading the PREVIEW=3D capabilit= y = >> and >> inviting confusion. >> >> =E2=80=94 Section 8 =E2=80=94 >> >> It seems like a bad idea to have to keep the IMAP Capabilities = >> registry in sync >> with the two new registries: as it stands, when you add a new = >> algorithm you >> have to add it to the Preview Algorithms registry, and also add a = >> corresponding >> entry in the Capabilities registry... and similarly for a modifier, = >> if I have >> that right above. >> >> Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve th= e = >> PREVIEW=3D >> capability in the registry, allowing it to apply to entries from the = >> two new >> registries? That avoids inconsistencies in registrations if we later = >> add >> algorithms or modifiers. >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> =E2=80=94 Section 3.1 =E2=80=94 >> >> Nit: Please change =E2=80=9Calternately=E2=80=9D to =E2=80=9Calternati= vely=E2=80=9D. >> >> These algorithms MUST be one >> of the algorithms identified as supported in the PREVIEW = >> capability >> responses. >> >> There=E2=80=99s a number-agreement problem here. >> >> NEW >> All algorithms in the list MUST have been included in the >> list of algorithms identified as supported in the PREVIEW = >> capability >> responses. >> END >> >> =E2=80=94 Section 3.2 =E2=80=94 >> >> This relaxed requirement permits a >> server to offer previews as an option without requiring = >> potentially >> burdensome storage and/or processing requirements to guarantee >> immutability for a use case that does not require this strictness. >> >> That=E2=80=99s sensible, but can you include some text giving an examp= le of = >> a situation >> where the preview might change? Given that the messages themselves = >> are >> immutable, why would applying the same algorithm to the same text = >> give >> different results? >> >> =E2=80=94 Section 4.1 =E2=80=94 >> >> The server SHOULD limit the length of the preview text to 200 = >> preview >> characters. This length should provide sufficient data to = >> generally >> support both various languages (and their different average word >> lengths) and different client display size requirements. >> >> The server MUST NOT output preview text longer than 256 preview >> characters. >> >> The text here should make it clear, because many implementers do not = >> understand >> the difference, that these refer to *characters*, not *bytes*, and = >> that 200 or >> 256 characters can possibly be much longer than 256 bytes. I worry = >> that an >> implementer might allocate a buffer of 256 bytes, thinking that=E2=80=99= s = >> enough, and >> have it overflowed. >> >> The server SHOULD remove any formatting markup that exists in the >> original text. >> >> This is OK as it is, but perhaps a bit more specific than necessary. = >> I think >> the sense is that the server is meant to do its best to render the = >> preview as >> plain text, because that=E2=80=99s what the client will treat it as. = As = >> such, I would >> fold this into the earlier paragraph that talks about no transfer = >> encoding, and >> maybe say it something like this: >> >> The generated string will be treated by the client as plain text, = >> so >> the server should do its best to provide a meaningful plain text = >> string. >> The generated string MUST NOT be content transfer encoded and MUST = >> be >> encoded in UTF-8 [RFC3629]. For purposes of this section, a = >> "preview >> character" is defined as a single UCS character encoded in UTF-8. = >> The >> server SHOULD also remove any formatting markup, and do what other >> processing might be useful in rendering the preview as plain text. >> >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DMX001Ss_AeNyXv= o6ikSivMny92vtZHwv1o5u46suxv0&s=3DN-3gUpkcA9xNcWGc9Rom-LAlShVKARcwVlk-0CU= MjHc&e=3D > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3Dq6dTBfAoGFIPzPP= L0c5W5HJEhd3f5a3XZxbznsvpXIs&s=3DfZWNDIoHV89pwoQ6inIBrCdhzPnNlCI2MCUWe-KO= N0o&e=3D From nobody Mon Apr 8 13:38:17 2019 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 E390D12063C; Mon, 8 Apr 2019 13:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 13:38:09 -0700 Archived-At: Subject: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 20:38:10 -0000 Adam Roach has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who has worked on this document. I have a handful of comments that should be considered prior to publication. --------------------------------------------------------------------------- §3.1: > These algorithms MUST be one > of the algorithms identified as supported in the PREVIEW capability > responses. This is confusing, as "algorithms" and "one of" don't make sense with each other. Is it meant to say something like "...MUST be a subset of the algorithms..."? --------------------------------------------------------------------------- §3.1: > If a client requests an algorithm that is unsupported, > the server MUST return a tagged BAD response. This appear to be underspecified, or at least nonintuitive. As written, it seems to say that an algorithm list of (known-1, known-2, unknown, known-3) would be considered invalid, even though there are plenty of supported, requested algorithms that could be used. Is this actually intended to be an error? If so, please make it explicit, as it's pretty counterintuitive. (As an aside: it's also unnecessarily fragile from an interop perspective, so I would suggest that this is not the desired behavior: I believe you want to return an error only when *none* of the requested algorithms are supported). --------------------------------------------------------------------------- §6, example 5: > C: E1 CAPABILITY > S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES > S: E1 OK Capability command completed. > [...a mailbox is SELECTed...] > C: E2 SEARCH RETURN (SAVE) FROM "FOO" > C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY)) This example shows the use of a modifier ("LAZY") with an algorithm; however, this modifier doesn't appear to be advertised by the server in its CAPABILITY line. If I understand how this is supposed to work (looking at the definitions in section 7), I would have expected: S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY PREVIEW=LAZY SEARCHRES I'll note that this syntax effectively places algorithms and modifiers in the same namespace, although IANA doesn't seem to be given any explicit instructions about this. I think this needs to be cleaned up prior to publication. I would make this last point a DISCUSS, except that it appears to be covered by Benjamin's DISCUSS already. --------------------------------------------------------------------------- §1: > Using server generated previews allows global generation once per0 nit: "server-generated" From nobody Mon Apr 8 19:00:29 2019 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 3606512006A; Mon, 8 Apr 2019 19:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 QCrnS1YklS2c; Mon, 8 Apr 2019 19:00:24 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 9CD52120094; Mon, 8 Apr 2019 19:00:24 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id n11so12913677ioh.1; Mon, 08 Apr 2019 19:00:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0rCnkBxk3QVtPzzTG9IKbU0ATcKGCixsoNIViRwT5uA=; b=FIBof+CtYVJY3Sfn86Ke2TkRLAs+Hc0Br19UHK4YQxeha49t2g2MQihv0b4Pcz+Qh6 lPvGBZlhwmrP6W8nKHGjAZ9/QBU9nLDlyuclP2KZfsJKPBv+CfsxHpbv7+MXkUGwlOZ7 LNiqweoZvrflNslQAnfafG2lmolaBaXkVgoWLiWR6+WAvWqrs1cFcgarghP8IjufnE/Q 2Ro5wr2D0nvHCxkH1x50oaaVIUgLlFRO3bzW+MC7aOOXY9ejDhYw210abdPm+VO6nk32 g9lHV+qgJmyY25wxvfZxuuGvaDXNnfQNjW++x+sdBCORLVNl5bv3E7AGUF5qkaFZfNaB oEPA== X-Gm-Message-State: APjAAAWFUbmMcl/lVFVwqvLpCW4miaXYWroz0kFc6S1oRvnj1LRDWX8O cX2gNSiuHHNbTtU71OUwpwCNfiogQzFzbA4GA0U= X-Google-Smtp-Source: APXvYqxG3MrDN8r4CWweN/TQplQW4gv4H++CoHxy8zdpm3QH6sm2cuVC9qyqQ/eWGrwfBSuWvzXIxyMyxGpbAs7ADFU= X-Received: by 2002:a5d:97da:: with SMTP id k26mr21478705ios.46.1554775223420; Mon, 08 Apr 2019 19:00:23 -0700 (PDT) MIME-Version: 1.0 References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <899C7434-8C5F-42B1-A99B-3DC46483472B@oracle.com> In-Reply-To: <899C7434-8C5F-42B1-A99B-3DC46483472B@oracle.com> From: Barry Leiba Date: Mon, 8 Apr 2019 22:00:12 -0400 Message-ID: To: Chris Newman Cc: The IESG , extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 02:00:27 -0000 Excellent, Chris; thanks for the detailed response, and I'm happy with that part of the DISCUSS. The part I'm going to save for future reference is this one: > I happen to consider the tagged/asynchronous part of the IMAP model to > be an elegant design that is a failure in practice when it encounters > the real world of implementations. The fact is the majority of clients > and client APIs just get the model wrong -- they're so used to > request/response that they try to shove a cache/update model into a > request/response model with predictably bad results. Thanks for that. Barry On Mon, Apr 8, 2019 at 3:38 PM Chris Newman wrote= : > > On 7 Apr 2019, at 20:25, Barry Leiba via Datatracker wrote: > > Barry Leiba has entered the following ballot position for > > draft-ietf-extra-imap-fetch-preview-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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ies= g_statement_discuss-2Dcriteria.html&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DMX0= 01Ss_AeNyXvo6ikSivMny92vtZHwv1o5u46suxv0&s=3DE7J5zigfcri3VIAMhsM-C7rxlMvQsi= nhAupR0vFaE4Q&e=3D > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_doc_draft-2Dietf-2Dextra-2Dimap-2Dfetch-2Dpreview_&d=3DDwIGaQ&c=3DRoP1= YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9L= cD2OOJG3TXfI&m=3DMX001Ss_AeNyXvo6ikSivMny92vtZHwv1o5u46suxv0&s=3DJGZ_W2tQh-= 5CzY9IdDs4v_W8HvA2t830SFv9RiL8Snw&e=3D > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > =E2=80=94 Section 3.1 =E2=80=94 > > > > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority decis= ion=E2=80=9D: what > > decision is that? > > And what=E2=80=99s the point of giving the server a list of algorithms = here, > > given that > > they all have to be ones that are supported by the server? Won=E2=80= =99t > > the server > > always have to use the first one in the list? If not, please add some > > text > > explaining what the server does. > > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > If the preview is not available, the server MUST return NIL as the > > PREVIEW response. A NIL response indicates to the client that > > preview information MAY become available in a future PREVIEW FETCH > > request. Note that this is semantically different than returning a > > zero-length string, which indicates an empty preview. > > > > I think the MUST here is hard to follow, because the text doesn=E2=80= =99t > > make a clear > > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D a= nd =E2=80=9Can > > empty preview=E2=80=9D. > > Can you expand the text a bit to explain the distinction more clearly, > > as this > > is a protocol requirement? Also, as I noted in response to Meral=E2=80= =99s > > Gen-ART > > review it would be good to be clear how encrypted messages should be > > handled in > > this regard. > > > > =E2=80=94 Section 4.1 =E2=80=94 > > > > The preview text MUST be treated as text/plain MIME data by the > > client. > > > > I think this requires a normative reference to RFC 2046. > > > > =E2=80=94 Section 5.1 =E2=80=94 > > > > The way you have LAZY working isn=E2=80=99t really consistent with the = IMAP > > protocol > > model. In that model, the client would not have to ask for the > > preview twice, > > one with LAZY and one without. Instead, with LAZY, the server would > > return > > FETCH PREVIEW responses when it could =E2=80=94 perhaps some in the fir= st > > set of FETCH > > responses, and some, where the PREVIEW part was missing before, in > > unsolicited > > FETCH responses when the preview became available. That way, the > > server has > > the responsibility of setting off a separate task to generate the > > previews, and > > to send them to the client when it has them (at which point it either > > saves the > > for future FETCHes or doesn=E2=80=99t). > > That alternative design would take control away from the client, make > the client code more complex, and make the server code more complex. For > clients using deployed request/response-style IMAP APIs, your proposal > would violate the API model and thus be incredibly hard to implement > without replacing a lot of the API. On the server side, even if I was > willing to implement what you propose (and I'm not), I'd have to refuse > to issue the untagged response until all PREVIEWs were generated to make > sure request/response style client APIs could handle that server > behavior -- at which point it's far less efficient than the proposed > design where the client has control. > > I happen to consider the tagged/asynchronous part of the IMAP model to > be an elegant design that is a failure in practice when it encounters > the real world of implementations. The fact is the majority of clients > and client APIs just get the model wrong -- they're so used to > request/response that they try to shove a cache/update model into a > request/response model with predictably bad results. In our 8.0 server > release, we tried to push the envelope just a little bit by generating > untagged EXISTS responses between commands (a behavior that's explicitly > encouraged by the IMAP base spec) and that broke interoperability with > more than one IMAP client in practice so we had to add an option to > suppress that behavior to maintain interoperability with those > (admittedly buggy) clients. > > > As it=E2=80=99s written here, the client has to open a separate IMAP se= ssion > > with the > > server and ask a second time for the previews it=E2=80=99s missing =E2= =80=94 a > > separate session > > to avoid blocking other action on the main session. And if the server > > has spun > > off a task to preemptively generate them because the client asked once > > (a good > > practice, given the description here) it has to retain them for some > > indefinite > > period waiting for the client to ask again. > > As it turns out, that's exactly the implementation model followed by > clients that generate previews manually without this extension. So with > the new preview extension those clients just tweak the first command to > add LAZY PREVIEW fetch so they possibly get early previews (improving > the UI for a very small change). Then the client implementer can add an > alternate code path to use the non-LAZY preview fetch variant instead of > computing manually or the client implementer could ignore the non-LAZY > preview feature and have fewer codepaths to test -- their choice (and > the better choice might depend on whether the client is mobile or > desktop -- something the server doesn't know). > > Since our server implemented PREVIEW before LAZY was added, I find the > proposed LAZY an inconvenient but defensible addition to the protocol > because it allows the client this additional implementation flexibility. > But if the LAZY extension didn't give the client flexibility, then I'd > consider the feature objectionable -- it would be significant > unnecessary complexity without a defensible implementation benefit. > > > Why was this not done with the first mechanism? > > I can't speak to why the author wrote it that way, but as a server > implementor, I find the way LAZY is presently specified to be perfectly > acceptable and it has a straightforward implementation in my server. > However, the proposed alternate design would be a royal PITA to > implement on my server. > > - Chris > > > =E2=80=94 Section 7 =E2=80=94 > > > > As was mentioned in Ben=E2=80=99s review, either the ABNF for > > =E2=80=9Ccapability=E2=80=9D is in error > > (it should not include =E2=80=9Cpreview-mod-ext=E2=80=9D) or the descri= ption needs > > to be > > significantly beefed up. I=E2=80=99m guessing that the intent is that > > PREVIEW=3D > > capabilities include both algorithms and modifiers, that PREVIEW=3DFUZZ= Y > > is > > required, that the presence of any preview algorithm implies > > PREVIEW=3DLAZY such > > that the latter not only need not be specified, but is not permitted > > to be. So > > we might have =E2=80=9CPREVIEW=3DFUZZY PREVIEW=3DFURRY PREVIEW=3DSLEEPY= =E2=80=9D, which > > would mean we > > support the algorithms FUZZY and FURRY, and the modifiers LAZY and > > SLEEPY. Is > > that correct? > > > > That seems somewhat obtuse to me, overloading the PREVIEW=3D capability > > and > > inviting confusion. > > > > =E2=80=94 Section 8 =E2=80=94 > > > > It seems like a bad idea to have to keep the IMAP Capabilities > > registry in sync > > with the two new registries: as it stands, when you add a new > > algorithm you > > have to add it to the Preview Algorithms registry, and also add a > > corresponding > > entry in the Capabilities registry... and similarly for a modifier, if > > I have > > that right above. > > > > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve the > > PREVIEW=3D > > capability in the registry, allowing it to apply to entries from the > > two new > > registries? That avoids inconsistencies in registrations if we later > > add > > algorithms or modifiers. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > =E2=80=94 Section 3.1 =E2=80=94 > > > > Nit: Please change =E2=80=9Calternately=E2=80=9D to =E2=80=9Calternativ= ely=E2=80=9D. > > > > These algorithms MUST be one > > of the algorithms identified as supported in the PREVIEW capability > > responses. > > > > There=E2=80=99s a number-agreement problem here. > > > > NEW > > All algorithms in the list MUST have been included in the > > list of algorithms identified as supported in the PREVIEW > > capability > > responses. > > END > > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > This relaxed requirement permits a > > server to offer previews as an option without requiring potentially > > burdensome storage and/or processing requirements to guarantee > > immutability for a use case that does not require this strictness. > > > > That=E2=80=99s sensible, but can you include some text giving an exampl= e of > > a situation > > where the preview might change? Given that the messages themselves > > are > > immutable, why would applying the same algorithm to the same text give > > different results? > > > > =E2=80=94 Section 4.1 =E2=80=94 > > > > The server SHOULD limit the length of the preview text to 200 > > preview > > characters. This length should provide sufficient data to > > generally > > support both various languages (and their different average word > > lengths) and different client display size requirements. > > > > The server MUST NOT output preview text longer than 256 preview > > characters. > > > > The text here should make it clear, because many implementers do not > > understand > > the difference, that these refer to *characters*, not *bytes*, and > > that 200 or > > 256 characters can possibly be much longer than 256 bytes. I worry > > that an > > implementer might allocate a buffer of 256 bytes, thinking that=E2=80= =99s > > enough, and > > have it overflowed. > > > > The server SHOULD remove any formatting markup that exists in the > > original text. > > > > This is OK as it is, but perhaps a bit more specific than necessary. > > I think > > the sense is that the server is meant to do its best to render the > > preview as > > plain text, because that=E2=80=99s what the client will treat it as. A= s > > such, I would > > fold this into the earlier paragraph that talks about no transfer > > encoding, and > > maybe say it something like this: > > > > The generated string will be treated by the client as plain text, > > so > > the server should do its best to provide a meaningful plain text > > string. > > The generated string MUST NOT be content transfer encoded and MUST > > be > > encoded in UTF-8 [RFC3629]. For purposes of this section, a > > "preview > > character" is defined as a single UCS character encoded in UTF-8. > > The > > server SHOULD also remove any formatting markup, and do what other > > processing might be useful in rendering the preview as plain text. > > > > > > _______________________________________________ > > Extra mailing list > > Extra@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_= JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DMX001Ss_AeNyXvo6ikS= ivMny92vtZHwv1o5u46suxv0&s=3DN-3gUpkcA9xNcWGc9Rom-LAlShVKARcwVlk-0CUMjHc&e= =3D From nobody Tue Apr 9 01:52:44 2019 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 19057120116; Tue, 9 Apr 2019 01:52:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155479996302.14150.9763168163917095444.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2019 01:52:43 -0700 Archived-At: Subject: [Extra] Magnus Westerlund's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 09 Apr 2019 08:52:43 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In relation to Benjamin's Discuss. I also think there are necessary to clarify if the Capability usage of PREVIEW is a single algorithm or allows listing all the algorithms server supports. From nobody Wed Apr 10 05:33:38 2019 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 3E6FE120112; Wed, 10 Apr 2019 05:33:30 -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=W7NkQQDL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RwsDBh0M 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 HsvnHPXq9Yc2; Wed, 10 Apr 2019 05:33:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29F0120058; Wed, 10 Apr 2019 05:33:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F36EB21E82; Wed, 10 Apr 2019 08:33:27 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 08:33:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=f6ENm JdUhwdyU0HZSMf0trH0tfy9ykakMH4FwYGIJsA=; b=W7NkQQDL+qBqC8GSYRCIs KtsboV0HgN9+woE/lavGnQq1bErKRjWJah27sNpa2pMZTgsf6E+CvQFe32y9OAHx 7BA8gKb+aA5N+HyHEKSxaZrmLzMaPgvw3lS0CdhXACkxsvY1k6ZN3aEPSih5ovas TcHCLcVAmB9RKWdXuXrvLFgbsnyTlQizw9Vhu6CJabZG983gfvwzuIm9mXsbDf1e fFcxOjc5bRBI7868RJUtLp9YFmoOtFptJqIVo2cIJyOUiyxUFw69cauwN52pe2ay t+93na2zuKgv5e6/uNvAAx33QpJGmoVI4l4JjuqXni66cQQ3GIMhqAum6TqBaGET A== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=f6ENmJdUhwdyU0HZSMf0trH0tfy9ykakMH4FwYGIJ sA=; b=RwsDBh0MybrNDwL0U3GTq01Je0uS5fp3b/65wY56GhzOlfTioG1EoqkxU lMBw6Qg+INgRjBgLCzj0bcL3IcLqj9XQJdvy7cihnmksJ+LH2cCyjNQhO01lS8UK XFtkuVMXBqr8rtZCrPU4/jmQYwgWJwndnDAoycB+L5m0JDQlRW1g8HOznrNlg8hz DXvQlnUDK0x4Xq7jzJ6SyXNEHb4SATgGxGGnKLxwvqEarmyM9nF7lgso4rq0KkeY /P703ezgoKkwZAkbERrYtbvcyCOTAaP4q4woAYTwOAZcDpRaNjb6QWhLWP2swFwQ p1f2fXAH5s0CVx3S36Z1Lk06dJmTg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6C98BD48AF; Wed, 10 Apr 2019 08:33:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: In-Reply-To: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 08:33:12 -0400 From: "Alexey Melnikov" To: "Barry Leiba" , "The IESG" Cc: extra@ietf.org, "Bron Gondwana" , draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] =?utf-8?q?Barry_Leiba=27s_Discuss_on_draft-ietf-extra-im?= =?utf-8?q?ap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 12:33:30 -0000 Hi Barry, Replying to your DISCUSS comments only: On Mon, Apr 8, 2019, at 4:25 AM, Barry Leiba via Datatracker wrote: > ----------------------------------------------------------------------= > DISCUSS: > ----------------------------------------------------------------------= >=20 > =E2=80=94 Section 3.1 =E2=80=94 >=20 > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority deci= sion=E2=80=9D: what decision is that?=20 > And what=E2=80=99s the point of giving the server a list of algorithms= here, given that > they all have to be ones that are supported by the server? Won=E2=80=99= t the server > always have to use the first one in the list? If not, please add some= text > explaining what the server does. For some reason I missed that multiple are allowed here. I think this is= overcomplicated and the WG should probably re-review whether multiple s= hould be allowed here. (Adam raised a few comments on the same section. It needs more work.) > =E2=80=94 Section 3.2 =E2=80=94 >=20 > If the preview is not available, the server MUST return NIL as the > PREVIEW response. A NIL response indicates to the client that > preview information MAY become available in a future PREVIEW FETCH > request. Note that this is semantically different than returning a= > zero-length string, which indicates an empty preview. >=20 > I think the MUST here is hard to follow, because the text doesn=E2=80=99= t make a clear > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D = and =E2=80=9Can empty preview=E2=80=9D.=20 > Can you expand the text a bit to explain the distinction more clearly,= as this > is a protocol requirement? Also, as I noted in response to Meral=E2=80= =99s Gen-ART > review it would be good to be clear how encrypted messages should be h= andled in > this regard. Right. > =E2=80=94 Section 4.1 =E2=80=94 >=20 > The preview text MUST be treated as text/plain MIME data by the > client. >=20 > I think this requires a normative reference to RFC 2046. Agreed. > =E2=80=94 Section 5.1 =E2=80=94 >=20 > The way you have LAZY working isn=E2=80=99t really consistent with the= IMAP protocol > model. In that model, the client would not have to ask for the previe= w twice, > one with LAZY and one without. Instead, with LAZY, the server would r= eturn > FETCH PREVIEW responses when it could =E2=80=94 perhaps some in the fi= rst set of FETCH > responses, and some, where the PREVIEW part was missing before, in uns= olicited > FETCH responses when the preview became available. That way, the serv= er has > the responsibility of setting off a separate task to generate the prev= iews, and > to send them to the client when it has them (at which point it either = saves the > for future FETCHes or doesn=E2=80=99t). >=20 > As it=E2=80=99s written here, the client has to open a separate IMAP s= ession with the > server and ask a second time for the previews it=E2=80=99s missing =E2= =80=94 a separate session > to avoid blocking other action on the main session. And if the server= has spun > off a task to preemptively generate them because the client asked once= (a good > practice, given the description here) it has to retain them for some i= ndefinite > period waiting for the client to ask again. >=20 > Why was this not done with the first mechanism? I think you had a good exchange with Chris Newman on this. > =E2=80=94 Section 7 =E2=80=94 >=20 > As was mentioned in Ben=E2=80=99s review, either the ABNF for =E2=80=9C= capability=E2=80=9D is in error > (it should not include =E2=80=9Cpreview-mod-ext=E2=80=9D) or the descr= iption needs to be > significantly beefed up. I=E2=80=99m guessing that the intent is that= PREVIEW=3D > capabilities include both algorithms and modifiers, that PREVIEW=3DFUZ= ZY is > required, that the presence of any preview algorithm implies PREVIEW=3D= LAZY such > that the latter not only need not be specified, but is not permitted t= o be. So > we might have =E2=80=9CPREVIEW=3DFUZZY PREVIEW=3DFURRY PREVIEW=3DSLEEP= Y=E2=80=9D, which would mean we > support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLE= EPY. Is > that correct? I think this is the intent. I agree that the document needs to be update= d to clarify this. > That seems somewhat obtuse to me, overloading the PREVIEW=3D capabilit= y and > inviting confusion. >=20 > =E2=80=94 Section 8 =E2=80=94 >=20 > It seems like a bad idea to have to keep the IMAP Capabilities registr= y in sync > with the two new registries: as it stands, when you add a new algorith= m you > have to add it to the Preview Algorithms registry, and also add a corr= esponding > entry in the Capabilities registry... and similarly for a modifier, if= I have > that right above. >=20 > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve th= e PREVIEW=3D > capability in the registry, allowing it to apply to entries from the t= wo new > registries? That avoids inconsistencies in registrations if we later = add > algorithms or modifiers. I think this is a good idea. Best Regards, Alexey From nobody Wed Apr 10 05:43:19 2019 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 8AF091202E4; Wed, 10 Apr 2019 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=fastmail.fm header.b=DaXO6KRq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uKp9C3Tm 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 pAn_7EZAwxWu; Wed, 10 Apr 2019 05:43:15 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9D3120072; Wed, 10 Apr 2019 05:43:14 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2EC2221FF5; Wed, 10 Apr 2019 08:43:14 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 08:43:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=hJY+c8Ncl6HtLFS+6EVIb56E1kAHE3Z CyYhVx80ySZg=; b=DaXO6KRqh9pls3ekEUA73uzPmXh/1QHv/ke2dPcRoU8KmS/ iBIdGIRDyytAovCNPCF7xJDq4RW1KnIUnfUJoItpM19gM/avbWcFmGoRbKexIzsM VzLrKgFcQqe6OP1KTdKCcj2FL4t5N5S4DVgcv8pRX6VcN4RrMYxiKFWDlJxOjQkD T+PVbqQ7kxN3SCcxtGeMpf9Fylntzov8kF3CBXMokKxdURMJwUfY2qPeBt1d6Rma Ct4HttYJXRFsIFQMTw3ubXA+hnSjLIhnviJt3s5oqGjLv6eMmahdXok5uERLUpI8 KxcGiK44TjnHB/f98eabRk7aFZOS7ZLosMzH+0w== 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-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hJY+c8 Ncl6HtLFS+6EVIb56E1kAHE3ZCyYhVx80ySZg=; b=uKp9C3TmpINOBKTXnJxNI/ OXc0suk8xLOLZC7uVKEiETI5Hu2UtCc7Y1gB4Nw29yIovcjlav+crAylQuXf/d6y lBVvCc70A5BMDjPLo1rsqcTc9kh85GZWf26LcMisMpDJRellebwMAfoNLURTBChM vqGRjRq9/ugHcWBBzvzZ1PGnVyXcmfOuFnHTv1RnU8FBcZszhsCc9Ewp0Yr3kN+X /htrYcbCuxOTumUsfUKlmFUP37wdlqax4px+NHuM/lQ/mlDtdMk8MNXJovJj65jn qW6E0xCBsUPmPDsS8vrvyVDFsgsK9iD5Kgqv6gwlaki0qawJ50Rz4N05W5SeQSWA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhm rghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AC8AD48AB; Wed, 10 Apr 2019 08:43:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: In-Reply-To: References: <155429292567.22949.15986765586199405904.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 08:42:58 -0400 From: "Alexey Melnikov" To: "Mirja Kuehlewind" , "Barry Leiba" Cc: extra@ietf.org, "Bron Gondwana" , "The IESG" , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Extra] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-extra-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 12:43:17 -0000 Hi Mirja/Barry, On Wed, Apr 3, 2019, at 5:21 PM, Mirja Kuehlewind wrote: > Hi Barry, > > > On 3. Apr 2019, at 17:46, Barry Leiba wrote: > > > > > >> However, I'm also wondering why you don't specify straight away > >> the use of the IETF Review policy as specified in RFC5226? Is there something > >> different in there that does not work for you? > > > > The difference is that IETF Review allows for Informational as well. > > Realistically, though, I think it's just that this text was copied > > from RFC 3501. > > I would think that having IETF consensus is the important part here > (and less the internet status) and that's covered by the IETF Review > policy. "standards track or IESG-approved experimental RFC" is used for other IMAP related registries, but I agree that "IETF Review" should be sufficient here. I doubt we will get any extensions here, but I think we want IETF review for them. Best Regards, Alexey From nobody Wed Apr 10 05:46:35 2019 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 EA80D12032D; Wed, 10 Apr 2019 05:46:32 -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=mMJGp53L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vExEqjrz 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 gtaaBB3kSQUi; Wed, 10 Apr 2019 05:46:31 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A709120072; Wed, 10 Apr 2019 05:46:31 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1C51A21EEB; Wed, 10 Apr 2019 08:46:30 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 08:46:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=5NQ35 +Xjopa1FpkjdcofpvwM+HzK3A5KxvYEJjbilA8=; b=mMJGp53LpJN2DyUx3mq6E ZsnNwuMFtYH5CQbHBhQsH2V3Fose4xws80ygb5zIanZ1oj1dMpKF42aE/3EDZB1/ Pge3dm8efBSjRcZA6LsCpnFX2Q6JTU0AwuYeZutO3EdZ23tquYbzwGMtM0rfT2qc Z5KC5hQC/XEAsPDMYPiWePZy/LGpO3iHiVRleDw2JEeaNR0QuDu6iXDDJoqrpFgh Djx/r/PM+dbFhU56UWprd+leSiokw/Ul+We8Z0QD30v6hwN3+ci9icJGpl2FJSfx uExwy1ThJUSEO10oYyDy7MyeoHjVsVsaw80xU3xfhaEKp9YLj7TtKjuJloFP0JlJ w== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=5NQ35+Xjopa1FpkjdcofpvwM+HzK3A5KxvYEJjbil A8=; b=vExEqjrzjnPRvPOFINrvZ5Vshm5FcPu201QL8oJIu1Lr1DLo+Q9wO/x96 eUK/DodhbWW3yv9zYLdWb37rlTPoO3vkoC+jFxJHaIt3XObNgGcQ1wE/79XYhYPs ZasydQW2sAQRrFajDos5RcPZVQ0sOjfnmLLgkozTtQKaKUyB2afBddYI5MdNYEf+ 8A8bOpXSonbsdicnZFHDqh4ISL6SpVeirrqjwKnPv+wP3urwUKLEtqIKmRih+6sf npj8uAfjVaCMubHyTiiLlxRFXXcVDPi4aEH50pVSsw6VFMzQZ4kb5Kc/ES/zr5NR sDpR6vg0uKqoyp1fMH7o3szIcIkgQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C2F20D48AF; Wed, 10 Apr 2019 08:46:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: In-Reply-To: References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 08:46:15 -0400 From: "Alexey Melnikov" To: "Barry Leiba" , "Roman D. Danyliw" Cc: extra@ietf.org, "Bron Gondwana" , "The IESG" , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] =?utf-8?q?Roman_Danyliw=27s_Discuss_on_draft-ietf-extra-?= =?utf-8?q?imap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 12:46:33 -0000 Hi, On Wed, Apr 3, 2019, at 9:38 PM, Barry Leiba wrote: > Hi, Roman. >=20 > > (1) Retention practices of cached previews > > Section 1 says =E2=80=9CUsing server generated previews allows globa= l generation once > > per message, and then cached indefinitely=E2=80=9D. Why cache indef= initely, especially > > if the source messages has been expunged? For privacy reasons, coul= dn=E2=80=99t this > > caching be consistent with the retention of the email. >=20 > "Indefinitely" doesn't mean forever... it means that the time period > is not definite. > That said, your suggested change makes sense, and I think we should ma= ke it.. This might be obvious for IMAP server implementors, because this is a st= ate associated with a message and once the message is gone there is no w= ay to retrieve it. But agree that the text can be improved here. > > (2) Protection of previews at rest > > In Section 9, Security Considerations, there needs to be discussion = about the > > potential sensitivity of these previews and the need to protect them= . Perhaps > > text like: =E2=80=9CJust as the messages they summarize, previews ma= y contain sensitive > > information. When stored, these previews MUST be protected with equ= ivalent > > authorization and confidentiality controls as the source message.=E2= =80=9D >=20 > This also makes sense and should be made. Sure. Best Regards, Alexey From nobody Wed Apr 10 05:52:52 2019 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 AB55F120372; Wed, 10 Apr 2019 05:52:50 -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=JaCwCc95; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qwH48+2p 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 WCE9NM6SsSJu; Wed, 10 Apr 2019 05:52:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAA2120072; Wed, 10 Apr 2019 05:52:48 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 447C121F83; Wed, 10 Apr 2019 08:52:47 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 08:52:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=2Ow/n N4aXQJINTeKWsBb6S8DxoVCjPI92aKcEniN/iM=; b=JaCwCc95e+GGvWHp8JlM2 xtasopOAJGmNWiOthDVo5tRtbNoqsJZkHWe9PjPMBB1s0+Qs7cEj3P/rG4o/LFrk 608asoClvGx0aIH+dZSSzFjZCY4BGkeoIvSZyvte/2n4cA5N2m6uLDcaw6+OZoce KorAp/oT/73XGDHP+lv6drNCVf6aub6t8MT2V6lAiVrZsaf5Q8QZP8XRrAoNLTuI 4KDjn1sAPOUg/dhLl3zMkJc+hIPzfPicO1aWUqRQefE7fGUL71on6tAFlE90RchR mPa6RnwQ7Egw+2/X2/3I2HDHMnUxy/MDhqW/jbn5kfYFO/5Nq3fq3cebFLD9cgru Q== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=2Ow/nN4aXQJINTeKWsBb6S8DxoVCjPI92aKcEniN/ iM=; b=qwH48+2pf4wkwgHOthBMfrKDV15y0MYTlFe0y5wwTwzz6r3fKsOrTp3K+ aO5wLVE3gPUawwg+p9xA97wlIj3dG/CssQVWpVRjGiHu3bT1EfsJdHICkBtz/C19 ff/pGSRs/vDq4TSmPCr9G0MMvqLAqhJlC7CHWKlmcvIiNzLcJa1casUlkrTjmOrz 6A208GE8/KOC+En5qjVSwSoDkhuLvbRid2vC/QlX38FM7OrB331M0JM6+OM2aAa7 X9qgkU2hRE4nVUBVMgW16GfsEkWZ5sGhkXrTnIWqs+BIKJu4C1Z1pMy0mcYugEdi Y/OdfNL8k8H2m2j+Voti8INZE5/lg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 84D9DD48AB; Wed, 10 Apr 2019 08:52:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: In-Reply-To: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> References: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 08:52:31 -0400 From: "Alexey Melnikov" To: "Adam Roach" , "The IESG" Cc: extra@ietf.org, "Bron Gondwana" , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] =?utf-8?q?Adam_Roach=27s_No_Objection_on_draft-ietf-extr?= =?utf-8?q?a-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 12:52:51 -0000 Hi Adam, Thank you for your comments: On Mon, Apr 8, 2019, at 9:38 PM, Adam Roach via Datatracker wrote: > ----------------------------------------------------------------------= > COMMENT: > ----------------------------------------------------------------------= >=20 > Thanks to everyone who has worked on this document. I have a handful o= f comments > that should be considered prior to publication. >=20 > ----------------------------------------------------------------------= ----- >=20 > =C2=A73.1: >=20 > > These algorithms MUST be one > > of the algorithms identified as supported in the PREVIEW capability= > > responses. >=20 > This is confusing, as "algorithms" and "one of" don't make sense with = each > other. Is it meant to say something like "...MUST be a subset of the > algorithms..."? >=20 > ----------------------------------------------------------------------= ----- >=20 > =C2=A73.1: >=20 > > If a client requests an algorithm that is unsupported, > > the server MUST return a tagged BAD response. >=20 > This appear to be underspecified, or at least nonintuitive. As written= , > it seems to say that an algorithm list of (known-1, known-2, unknown, = known-3) > would be considered invalid, even though there are plenty of supported= , > requested algorithms that could be used. Is this actually intended to = be an > error? If so, please make it explicit, as it's pretty counterintuitive= . >=20 > (As an aside: it's also unnecessarily fragile from an interop perspect= ive, so I > would suggest that this is not the desired behavior: I believe you wan= t to > return an error only when *none* of the requested algorithms are suppo= rted). I think this section is a mess. If we want to allow for multiple algorit= hms here, then, as you point out, handling of error cases need to be des= cribed. This will be fixed. > ----------------------------------------------------------------------= ----- >=20 > =C2=A76, example 5: >=20 > > C: E1 CAPABILITY > > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY SEARCHRES > > S: E1 OK Capability command completed. > > [...a mailbox is SELECTed...] > > C: E2 SEARCH RETURN (SAVE) FROM "FOO" > > C: E3 FETCH $ (UID PREVIEW (LAZY=3DFUZZY)) >=20 > This example shows the use of a modifier ("LAZY") with an algorithm; h= owever, > this modifier doesn't appear to be advertised by the server in its CAP= ABILITY > line. If I understand how this is supposed to work (looking at the def= initions > in section 7), I would have expected: >=20 > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY PREVIEW=3DLAZY SEARCHRE= S >=20 > I'll note that this syntax effectively places algorithms and modifiers= in the > same namespace, although IANA doesn't seem to be given any explicit > instructions about this.=20 Right, Barry has DISCUSS on this point. > I think this needs to be cleaned up prior to > publication. I would make this last point a DISCUSS, except that it a= ppears > to be covered by Benjamin's DISCUSS already. From nobody Wed Apr 10 06:34:35 2019 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 18DB71200D7; Wed, 10 Apr 2019 06:34:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155490326809.23033.8472544257348086538.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 06:34:28 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 13:34:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Re-issuing ballot position to direct discussion of the ABNF for 'capability' to Barry's ballot thread; the rest of the COMMENT is unchanged] Section 3.1 Alternately, the client may explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm. These algorithms MUST be one nit: there's potential for misparsing here (e.g., that the PREVIEW attribute contains the name of the algorithm and the parenthesized list is after that), so maybe put "after the PREVIEW attribte" in parentheses or offset by commas. of the algorithms identified as supported in the PREVIEW capability responses. [...] nit: singular/plural mismatch between "these algorithms" and "one of". Section 7 How much discussion was there about "SHOULD be registered" (as opposed to "MUST be registered")? Section 8 side note: This is one of the shortest IANA considerations sections I've seen thta creates registries (in that it doesn't lay out a registration template), but IANA seems to be saying they have what information they need, so who am I to complain... Section 9 I agree with Roman that there should be discussion of the caching/data retention strategy for message previews. This existing text about denial-of-service attacks is probably fine, though I might consider rephrasing it along the lines of "this mechanism introduces a new way for clients to make requests that consume server resources. As is the case for all such mechanisms, it could be used as part of a denial-of-service attack on server resources, e.g., via excessive memory or CPU usage, or increased storage if preview results are cached on the server after generation. The additional attack surface presented by this specific mechanism is not believed to higher risk that other similar mechanisms in use already, since the individual resource consumption per message processed is likely to be modest. Nonetheless, servers MAY limit the resources consumed by preview generation." As I write the above, though, I wonder how this interacts with the previous text in Section 3.1 about how the "server MUST honor a client's algorithm priority decision". Does that mean that if some future (expensive) algorithm is specified, once a server implements that algorithm, any client can force its use and thus the expensive resource consumption on the server? It's not entirely clear to me how this MAY interacts with that MUST, in such a hypothetical scenario. From nobody Wed Apr 10 09:33:27 2019 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 4DA0A1204AA; Wed, 10 Apr 2019 09:33:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155491399722.9512.11002649582098559943.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 09:33:17 -0700 Archived-At: Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 16:33:19 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-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-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Barry's DISCUSS point on Section 3.2. In Section 4.1, I suggest s/The FUZZY algorithm/The FUZZY algorithm identifier/ (since it doesn't refer to an actual algorithm) From nobody Wed Apr 10 18:58:43 2019 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 A28D4120151; Wed, 10 Apr 2019 18:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENTwLd8WQ9-o; Wed, 10 Apr 2019 18:58:31 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 56926120163; Wed, 10 Apr 2019 18:58:31 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8BD826A25F; Thu, 11 Apr 2019 03:58:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554947909; bh=dtsf+U9SJtjLf6DHA5dAbdvpfWQXX0+xAoeCQZs3qZ0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=7iRhkA9RqJ0hBDtLR9OdRfSXyuDpeM7/JJYeTy7ekpZQ/Ng4kyZ3HqPrv6sln8EC1 udSMDI7rXLuoUNMTjaICa+pqW1tf2P3KdIGS5Cx1oxALE68Btm+kl7t4LAi/X5kkrb ROuqW6JuO3qa3Aj0swUHI1EUfDffGT37UqcIPHVhmdeiOFArDn84RslvMWkPy+bxkW T4JzgsF7KNi9nAFbvr1SfBKjDTbPB4KTj8nZXtFVE6ht9pvgiVmjSKqi/MVyLL4GXn 59U9scwwBOXK2Tg1RaaOACyuxdMcp71Bdhv/1PSlDyZCFnee5FI2fBft9mwt1TdR9S wdEcwv8SH05ZA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7238E3C00AB; Thu, 11 Apr 2019 03:58:29 +0200 (CEST) Date: Wed, 10 Apr 2019 19:58:29 -0600 (MDT) From: Michael Slusarz To: Roman Danyliw , Roman Danyliw via Datatracker , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <270245125.18005.1554947909394@appsuite.open-xchange.com> In-Reply-To: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 01:58:34 -0000 Roman, Thanks for your comments. See below: > On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (1) Retention practices of cached previews > Section 1 says =E2=80=9CUsing server generated previews allows global gen= eration once > per message, and then cached indefinitely=E2=80=9D. Why cache indefinite= ly, especially > if the source messages has been expunged? For privacy reasons, couldn=E2= =80=99t this > caching be consistent with the retention of the email. >=20 > In Section 9, Security Considerations, there needs to be discussion of th= is > retention too. Perhaps text like: =E2=80=9CImplementations that pre-gene= rate and store > previews MUST ensure that the stored preview is also deleted when the > corresponding mail message is expunged.=E2=80=9D Agree with your comments (and Barry and Alexey) that this language can be i= mproved. I implemented better language last week in the draft ... but unfo= rtunately I can't access those changes at the moment as our RCS system is i= nvolved in a public cloud outage. Once back online, I'll share the revised= text. > (2) Protection of previews at rest > In Section 9, Security Considerations, there needs to be discussion about= the > potential sensitivity of these previews and the need to protect them. Pe= rhaps > text like: =E2=80=9CJust as the messages they summarize, previews may con= tain sensitive > information. When stored, these previews MUST be protected with equivale= nt > authorization and confidentiality controls as the source message.=E2=80= =9D My recollection is that I added this text, or a slight derivation of it, to= the Security section. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (2) Section 3.1, the paragraph =E2=80=9CIf no algorithm identifier is pro= vided, the > server decides =E2=80=A6=E2=80=9D discusses algorithm identifiers but the= ir use hasn=E2=80=99t been > introduced yet. I recommend swapping the order of this paragraph with th= e > current third paragraph (=E2=80=9CAlternative =E2=80=A6=E2=80=9D) as this= is where algorithms are > introduced. >=20 > (3) Section 4.1. Duplicate word. s/to the the language/to the language/ >=20 > (4) Section 4.1. Nit on word order. s/no human-readable text to generate > preview information from/no human-readable text from which to generate pr= eview > information/ >=20 > (5) Section 7. In the ABNF comments, consider using =E2=80=9C[RFC6648]= =E2=80=9D instead of > =E2=80=9CRFC 6648=E2=80=9D. Fixes to these various nits were added to the draft. Per Barry's reply, I = did not implement the proposed RFC 8174 changes. michael From nobody Wed Apr 10 19:32:18 2019 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 A4837120119; Wed, 10 Apr 2019 19:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoPZHWdGpSBM; Wed, 10 Apr 2019 19:32:14 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 040E51200B2; Wed, 10 Apr 2019 19:32:13 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 819A96A25F; Thu, 11 Apr 2019 04:32:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554949931; bh=oxTSErv1TeEdBIDOrNCgCuwg+13uYBjkN4fX3bcJkC8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=SPqC1yGCCTjv/u2UxZfone+2FGLJjMWBqwrFQ1I6wqXw4bcAyskaqepbhHbj3ffWp kOAmRiFRmWgkfiEafdB51lAMxrYrCQlKgrE++oDI1J/N5ZnO1gKk5d7WTpyjYFDbVW CwlIKOpBcmgzRa9iXXn1WUjCwsxWL/g4L3vddxV0HaZybJViZ8fCupm5NJaw9ro30m bSFAnV9AUIdPV+ZITTGxkzoHV5OB4vpxvk38zqe0UuRs5yia5wRSI0ORCREdSrkzRP zb8x6dR5x4HP0wpAMkKHSsFT4Dt1lJ/gszyjISQ3QBglvQbozAqle5qlDMEcj4MXpQ UvXeEQ4tgwkJg== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 6CD4B3C0066; Thu, 11 Apr 2019 04:32:11 +0200 (CEST) Date: Wed, 10 Apr 2019 20:32:11 -0600 (MDT) From: Michael Slusarz To: Benjamin Kaduk , Benjamin Kaduk via Datatracker , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <200085968.18013.1554949931366@appsuite.open-xchange.com> In-Reply-To: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 02:32:17 -0000 Benjamin, Thank you for the comments. Disccusion below: > On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I wavered a lot about whether this was DISCUSS-worthy, but it seems like > we should at least talk about how big a risk for future confusion there > is: > > I'm a little confused by the ABNF for 'capability' in Section 7 -- it > seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and > Section 3.1 talk only about *algorithms* in PREVIEW capability responses > (and not modifiers). Is the intent to have capability tags for > (non-mandatory) priority modifiers? [Edit: looks like this was discussion item moved to Barry's ballot, but I'll leave the discussion here for clarity in the thread history] I struggled with the decision to include priority modifier extensions in the draft. Algorithm extensions make sense, as there can be competing or expanded way of generating preview text in the future. But priority modifiers are tied to the behavior of the command, not the output of the command. In the case there would be a need for a priority modifier in the future, that's a fundamental change to the semantics of the command itself and would probably require extensive discussion. Under further thought and review, I would be perfectly fine with removing the extension/registry for priority modifiers and simply making it an explicit part of the base command. This would simplify the draft a bit. Thoughts? (To answer your original DISCUSS: a separate CAPABILITY string wasn't defined, because it is implicit in PREVIEW=FUZZY, which is required to implement PREVIEW, that LAZY must also be handled. Not requiring PREVIEW=LAZY, and not defining what a potential capability would look like in the future, were explicit choices.) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 7 > > How much discussion was there about "SHOULD be registered" (as opposed > to "MUST be registered")? Alexey and I discussed in a previous thread, located here: I think a valid summation is that Alexy was pushing hard for MUST register, but my reading of 6648 is that it allows flexibility in allowing extensions, as long as you follow naming conventions. My personal example is that there is at least one additional PREVIEW extension we may develop, and which may be implemented quickly, but there is no intention to register that extension (at least at the beginning) because it is a very specific use-case that may not be generally useful to the wider Internet. So demanding a MUST register to me seems unduly harsh and inflexible. > Section 9 > > I agree with Roman that there should be discussion of the caching/data > retention strategy for message previews. As mentioned in response to Roman, I worked on this language last week and I will share with the group once I have access to that revision. > This existing text about denial-of-service attacks is probably fine, > though I might consider rephrasing it along the lines of "this mechanism > introduces a new way for clients to make requests that consume server > resources. As is the case for all such mechanisms, it could be used as > part of a denial-of-service attack on server resources, e.g., via > excessive memory or CPU usage, or increased storage if preview results > are cached on the server after generation. The additional attack > surface presented by this specific mechanism is not believed to higher > risk that other similar mechanisms in use already, since the individual > resource consumption per message processed is likely to be modest. > Nonetheless, servers MAY limit the resources consumed by preview > generation." > > As I write the above, though, I wonder how this interacts with the > previous text in Section 3.1 about how the "server MUST honor a client's > algorithm priority decision". Does that mean that if some future > (expensive) algorithm is specified, once a server implements that > algorithm, any client can force its use and thus the expensive resource > consumption on the server? It's not entirely clear to me how this MAY > interacts with that MUST, in such a hypothetical scenario. I don't see this as any different of a problem than with other IMAP commands. Example: a user issues a SORT/THREAD command in a large mailbox, and that command would require 10,000s of message accesses to return. An IMAP server should be allowed to abort the response somehow (we will return an unsorted list, for example), subject to some kind of resource limitations, even though the requirements of the command is that it must return a sorted list. More broadly, any IMAP command should be subject to this kind of truncation if there is concern that completion risks resource starvation as a consequence. (On that note, I thought there was some sort of "resource limitation" response code defined for this kind of situation, e.g. in RFC 5530, but it looks like there isn't. Maybe we need something like this). michael From nobody Wed Apr 10 20:31:52 2019 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 6FDE7120091; Wed, 10 Apr 2019 20:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENiEPuUgjVOA; Wed, 10 Apr 2019 20:31:47 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 848EE12006A; Wed, 10 Apr 2019 20:31:47 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 066D86A25F; Thu, 11 Apr 2019 05:31:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554953504; bh=barQZuLZ++3KhN+e3DS1ojy65Nlm2FMc1vbBRY4rUEA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=JfFtkMXnfWF/0C1P6Ttim429rbJp7t/xUm5Qd2/IcVX3NY4ExVluZKmCtxWKfU/KA CiPrODRxKB5MiP/yltzyEeUANLG024X3XaxTN8Hh7k4MvyTzlKPYAJ2aL27BFcM6AN eZh0Hd8igmA+9jdhPPYuhRzri4yfViTiud0ub3xszmIs06lja+0paKalALxTAC8eh7 lCXy74hVgoiLO9+yeAJvBl4ogpdDwdQ5HD+WlUgFcPXchcNHRBwzqxBWXqe00zKzrE 5RySiLvxEOP6rV+13o9YxBKd2i4RjA/Qco21gy2dq0LpO1GXADgaGBkhaHavfj4sHm G0QHhfpE5R/Bw== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id EC27D3C0066; Thu, 11 Apr 2019 05:31:43 +0200 (CEST) Date: Wed, 10 Apr 2019 21:31:43 -0600 (MDT) From: Michael Slusarz To: Barry Leiba , Barry Leiba via Datatracker , The IESG Cc: extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <1478535427.18024.1554953503900@appsuite.open-xchange.com> In-Reply-To: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 03:31:51 -0000 Barry, Thanks for your detailed comments. Discussion below, which hopefully incor= porates the important parts of comments from Alexey, Chris, Adam, and Benja= min. > On April 7, 2019 at 9:25 PM Barry Leiba via Datatracker wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =E2=80=94 Section 3.1 =E2=80=94 >=20 > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority decisio= n=E2=80=9D: what decision is that?=20 > And what=E2=80=99s the point of giving the server a list of algorithms he= re, given that > they all have to be ones that are supported by the server? Won=E2=80=99t= the server > always have to use the first one in the list? If not, please add some te= xt > explaining what the server does. Consensus seems to be this section is confusing, or unclear, or unneeded, o= r some combination of this three. I'll start with providing a (future) real-world example, and why this behav= ior exists in its present form. Given a hypothetical future algorithm "IMA= GE" (generate image/jpeg preview if image data exists in message), I issue = this preview command: a FETCH 1 (PREVIEW (LAZY=3DIMAGE FUZZY)) This is asking the server: provide me an image preview of the message, but = ONLY if 1) the message actually contains image information and 2) that imag= e information is already generated or can be generated very quickly. Other= wise, fall back to FUZZY generation. I find that use-case plausible, albeit not something useful given the curre= nt landscape of a single algorithm. The alternative would be to have to se= nd PREVIEW algorithms one at a time, non-pipelined, which is precisely the = kind of inefficient client/server interaction this extension is trying to m= inimize. I do agree that there is language that can surely be cleaned up here, espec= ially regarding error handling. But I will hold off on rewriting the secti= on until we can have some discussion/consensus as to whether the proposed u= sage discussed above is something that others believe we should be supporti= ng. > =E2=80=94 Section 3.2 =E2=80=94 >=20 > If the preview is not available, the server MUST return NIL as the > PREVIEW response. A NIL response indicates to the client that > preview information MAY become available in a future PREVIEW FETCH > request. Note that this is semantically different than returning a > zero-length string, which indicates an empty preview. >=20 > I think the MUST here is hard to follow, because the text doesn=E2=80=99t= make a clear > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D and= =E2=80=9Can empty preview=E2=80=9D.=20 > Can you expand the text a bit to explain the distinction more clearly, as= this > is a protocol requirement? "Preview not available" examples =3D * Preview generation isn't available at the moment (previews are generate= d in a separate thread, and that pool is saturated) * Body text is not available at the moment, so preview can't be generated= . * The preview text has not been generated within the alotted time (e.g. L= AZY modifier) > Also, as I noted in response to Meral=E2=80=99s Gen-ART > review it would be good to be clear how encrypted messages should be hand= led in > this regard. Do we want to be specific to the encrypted message use case? What about a = single MIME part containing application/octet-stream data which the preview= parser knows nothing about? I think the encrypted message use case can be handled by a better descripti= on of how to handle any data that the preview generator does not know how t= o meaningfully parse. Something like "If the message contains no body info= rmation that the FUZZY parser can meaningfully display to the user, an empt= y preview should be returned." or "An empty preview means that the FUZZY a= lgorithm has made a definitive decision that no meaningful preview text can= be generated for the message." > =E2=80=94 Section 4.1 =E2=80=94 >=20 > The preview text MUST be treated as text/plain MIME data by the > client. >=20 > I think this requires a normative reference to RFC 2046. Ack. > =E2=80=94 Section 5.1 =E2=80=94 >=20 > The way you have LAZY working isn=E2=80=99t really consistent with the IM= AP protocol > model. In that model, the client would not have to ask for the preview t= wice, > one with LAZY and one without. Instead, with LAZY, the server would retu= rn > FETCH PREVIEW responses when it could =E2=80=94 perhaps some in the first= set of FETCH > responses, and some, where the PREVIEW part was missing before, in unsoli= cited > FETCH responses when the preview became available. That way, the server = has > the responsibility of setting off a separate task to generate the preview= s, and > to send them to the client when it has them (at which point it either sav= es the > for future FETCHes or doesn=E2=80=99t). >=20 > As it=E2=80=99s written here, the client has to open a separate IMAP sess= ion with the > server and ask a second time for the previews it=E2=80=99s missing =E2=80= =94 a separate session > to avoid blocking other action on the main session. And if the server ha= s spun > off a task to preemptively generate them because the client asked once (a= good > practice, given the description here) it has to retain them for some inde= finite > period waiting for the client to ask again. >=20 > Why was this not done with the first mechanism? I believe Chris' discussion handled Barry's concerns here. I'll add from real-world experience that LAZY is the thing my client develo= pers absolutely would yell and scream at me if I took out from this proposa= l. We have been using this paradigm for several years now, and it has been= very successful for us at high usage rates and it works in a variety of cl= ient types. =20 > =E2=80=94 Section 7 =E2=80=94 >=20 > As was mentioned in Ben=E2=80=99s review, either the ABNF for =E2=80=9Cca= pability=E2=80=9D is in error > (it should not include =E2=80=9Cpreview-mod-ext=E2=80=9D) or the descript= ion needs to be > significantly beefed up. I=E2=80=99m guessing that the intent is that PR= EVIEW=3D > capabilities include both algorithms and modifiers, that PREVIEW=3DFUZZY = is > required, that the presence of any preview algorithm implies PREVIEW=3DLA= ZY such > that the latter not only need not be specified, but is not permitted to b= e. So > we might have =E2=80=9CPREVIEW=3DFUZZY PREVIEW=3DFURRY PREVIEW=3DSLEEPY= =E2=80=9D, which would mean we > support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY= . Is > that correct? >=20 > That seems somewhat obtuse to me, overloading the PREVIEW=3D capability a= nd > inviting confusion. See discussion on Benjamin's DISCUSS (although he withdrew in favor of this= DISCUSS point). In short, I propose that we remove "priority modifiers" as a category that = can be extended, so that "PREVIEW=3D" is solely intended to list algorithm = types. > =E2=80=94 Section 8 =E2=80=94 >=20 > It seems like a bad idea to have to keep the IMAP Capabilities registry i= n sync > with the two new registries: as it stands, when you add a new algorithm y= ou > have to add it to the Preview Algorithms registry, and also add a corresp= onding > entry in the Capabilities registry... and similarly for a modifier, if I = have > that right above. >=20 > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve the P= REVIEW=3D > capability in the registry, allowing it to apply to entries from the two = new > registries? That avoids inconsistencies in registrations if we later add > algorithms or modifiers. See above. With my proposal to remove priority modifiers, I believe this d= iscussion point becomes moot. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =E2=80=94 Section 3.2 =E2=80=94 >=20 > This relaxed requirement permits a > server to offer previews as an option without requiring potentially > burdensome storage and/or processing requirements to guarantee > immutability for a use case that does not require this strictness. >=20 > That=E2=80=99s sensible, but can you include some text giving an example = of a situation > where the preview might change? Given that the messages themselves are > immutable, why would applying the same algorithm to the same text give > different results? We discussed this on the list in the past, but one example would be loss of= cached preview data on the server and re-generation uses a newer algorithm= version which produces slightly different text. The consensus was that we should not be making extraordinary efforts/costs = to ensure this text never changes, where this text is not being held out as= being the canonical view of the message contents in the first place. =20 > =E2=80=94 Section 4.1 =E2=80=94 >=20 > The server SHOULD limit the length of the preview text to 200 preview > characters. This length should provide sufficient data to generally > support both various languages (and their different average word > lengths) and different client display size requirements. >=20 > The server MUST NOT output preview text longer than 256 preview > characters. >=20 > The text here should make it clear, because many implementers do not unde= rstand > the difference, that these refer to *characters*, not *bytes*, and that 2= 00 or > 256 characters can possibly be much longer than 256 bytes. I worry that = an > implementer might allocate a buffer of 256 bytes, thinking that=E2=80=99s= enough, and > have it overflowed. I feel that this can be accomplished with a sentence after the definition o= f "preview character" of something like "Note: a single preview character m= ay compromise multiple octets, so any buffers implemented to conform to the= string limitations identified in this document should be sized to prevent = possible overflow errors." > The server SHOULD remove any formatting markup that exists in the > original text. >=20 > This is OK as it is, but perhaps a bit more specific than necessary. I t= hink > the sense is that the server is meant to do its best to render the previe= w as > plain text, because that=E2=80=99s what the client will treat it as. As = such, I would > fold this into the earlier paragraph that talks about no transfer encodin= g, and > maybe say it something like this: >=20 > The generated string will be treated by the client as plain text, so > the server should do its best to provide a meaningful plain text strin= g. > The generated string MUST NOT be content transfer encoded and MUST be > encoded in UTF-8 [RFC3629]. For purposes of this section, a "preview > character" is defined as a single UCS character encoded in UTF-8. The > server SHOULD also remove any formatting markup, and do what other > processing might be useful in rendering the preview as plain text. I'm fine with this. michael From nobody Wed Apr 10 20:45:57 2019 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 8965D1201EE; Wed, 10 Apr 2019 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93owC844B981; Wed, 10 Apr 2019 20:45:53 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 B83EC1201A0; Wed, 10 Apr 2019 20:45:53 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 1851F6A25F; Thu, 11 Apr 2019 05:45:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554954352; bh=jGIpOL9VjCLta7vDulBdsgY+VyJksTmM2UIkKq8n8ic=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=xA3umboOczk8UPebOb0BVaQbZVWteO6u0n6PBLw6jZdTOiEaXS6yhCA3p/CpjkzFp Iz+oBmpLmmszqY/c22MzIVTGq36C42ognbaAcvAH5CoI+v250wAGBFowICqrhTI3vE uNsklu65DBIdDeWTCItL3Wa0VdZaKNnshkbhw3wkvW0VmyYAoD4nquGtWtRaHp28Q6 dqMXhwxHMExOO7GC+HmE1fA5xs32r1gABDd5fyLcbotkANVzDsoQz9fELBodGWuFUD accaAK2YRim88lkHO6OCKW67yIAVQZHHUuywY/vQRb+WNDbKI7uIkNGni6bS+l5laN F4g/mzX3EgXZw== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 053E13C0066; Thu, 11 Apr 2019 05:45:52 +0200 (CEST) Date: Wed, 10 Apr 2019 21:45:48 -0600 (MDT) From: Michael Slusarz To: Adam Roach , Adam Roach via Datatracker , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <589634421.18028.1554954351946@appsuite.open-xchange.com> In-Reply-To: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> References: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 03:45:56 -0000 Adam, Thanks for your comments. Discussion below. > On April 8, 2019 at 2:38 PM Adam Roach via Datatracker = wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =C2=A73.1: >=20 > > These algorithms MUST be one > > of the algorithms identified as supported in the PREVIEW capability > > responses. >=20 > This is confusing, as "algorithms" and "one of" don't make sense with eac= h > other. Is it meant to say something like "...MUST be a subset of the > algorithms..."? Noted that the topic of multiple algorithm selection is being discussed in = Barry's DISCUSS. That being said, if multiple algorithm support is decided to be kept, what = about changing this to: "All algorithms specified in the list MUST be identified as being supported= by the server by appearing in a PREVIEW capability response." (or "PREVIEW= =3D capability response" maybe?) > =C2=A73.1: >=20 > > If a client requests an algorithm that is unsupported, > > the server MUST return a tagged BAD response. >=20 > This appear to be underspecified, or at least nonintuitive. As written, > it seems to say that an algorithm list of (known-1, known-2, unknown, kno= wn-3) > would be considered invalid, even though there are plenty of supported, > requested algorithms that could be used. Is this actually intended to be = an > error? If so, please make it explicit, as it's pretty counterintuitive. >=20 > (As an aside: it's also unnecessarily fragile from an interop perspective= , so I > would suggest that this is not the desired behavior: I believe you want t= o > return an error only when *none* of the requested algorithms are supporte= d). See Barry's DISCUSS response. Agreed that error handling is not specified = adequately in current text. To mirror duplicate algorithm language, how about: "Unsupported algorithms = in the list MUST be ignored. If the list contains no supported algorithms, = the server MUST return a tagged BAD response to the FETCH command." >=20 > -------------------------------------------------------------------------= -- >=20 > =C2=A76, example 5: >=20 > > C: E1 CAPABILITY > > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY SEARCHRES > > S: E1 OK Capability command completed. > > [...a mailbox is SELECTed...] > > C: E2 SEARCH RETURN (SAVE) FROM "FOO" > > C: E3 FETCH $ (UID PREVIEW (LAZY=3DFUZZY)) >=20 > This example shows the use of a modifier ("LAZY") with an algorithm; howe= ver, > this modifier doesn't appear to be advertised by the server in its CAPABI= LITY > line. If I understand how this is supposed to work (looking at the defini= tions > in section 7), I would have expected: >=20 > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY PREVIEW=3DLAZY SEARCHRES >=20 > I'll note that this syntax effectively places algorithms and modifiers in= the > same namespace, although IANA doesn't seem to be given any explicit > instructions about this. I think this needs to be cleaned up prior to > publication. I would make this last point a DISCUSS, except that it appe= ars > to be covered by Benjamin's DISCUSS already. This has been discussed in several other places already. I am proposing re= moving priority modifier extensions, which would address this concern. michael From nobody Wed Apr 10 20:59:34 2019 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 B83E3120258; Wed, 10 Apr 2019 20:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPVpb2mq0Mek; Wed, 10 Apr 2019 20:59:31 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 EF04212020A; Wed, 10 Apr 2019 20:59:30 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 3B9DF6A25F; Thu, 11 Apr 2019 05:59:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554955169; bh=KkI4B8Y/5LZz1H+Decg8RD43Fh4Cel5eRH37sOEZCsw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=8U2GXC17ZrwI19C0H1rJ3Cb8qUsJNvwYAPqA8jMdt2lrfFBkr/JZBmvz7RgdwObLk S1VTbwZNw1M4YEc4WgB1QXYrQX0UX3tICWjULcqp89ycfsjZcak92yqpBJ2lmncbH6 YMUwjAvcGSmbFLXYu7a19h+N7Xn9vI0U/otGuwTzZ/QzMkuAyJwZ55jA3riC33xOla T4iwa3B4SjkBkzBdR0EkpA80aVwVFAdG+LkhIsfQCE+25PGxmIWH+Jq5buOOVQkLfO IP7Gep7RkxixKLjDgavAg61HZUCcZOJkT8c3bPSfdFa7fd7HL/grNjbq7Jxa8zj9O5 2dUjFgtouHCdA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 229C83C0066; Thu, 11 Apr 2019 05:59:29 +0200 (CEST) Date: Wed, 10 Apr 2019 21:59:28 -0600 (MDT) From: Michael Slusarz To: Alissa Cooper , Alissa Cooper via Datatracker , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <168198734.18032.1554955169064@appsuite.open-xchange.com> In-Reply-To: <155491399722.9512.11002649582098559943.idtracker@ietfa.amsl.com> References: <155491399722.9512.11002649582098559943.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 03:59:33 -0000 Alissa, Thanks for your comment. See below. > On April 10, 2019 at 10:33 AM Alissa Cooper via Datatracker wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 4.1, I suggest s/The FUZZY algorithm/The FUZZY algorithm identifier/ > (since it doesn't refer to an actual algorithm) I think the better revision might be to take out the word "identifier" (or replace it with "list") in Section 3.1. I don't think there's confusion as to what "algorithm" is referring to in the context of the document, although we should be consistent in its usage throughout. michael From nobody Thu Apr 11 03:23:54 2019 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 E7599120116; Thu, 11 Apr 2019 03:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=fastmail.fm header.b=SquDq5mo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IRAtbSym 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 WjSatv3q06ni; Thu, 11 Apr 2019 03:23: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 5960912004D; Thu, 11 Apr 2019 03:23:46 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5D6B521DB7; Thu, 11 Apr 2019 06:23:45 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 11 Apr 2019 06:23:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=PVoVb nPahd+TBjoT0P/LwBAqgin/x3lYwTEXmT/zIak=; b=SquDq5moftkR19xPcUul5 PZq4Q39N0zSsay8+PjlbJRIJ+JD0zz/Uy89i7PFOFHWDeNVgoaXeo8hWqQf13hUW nX4UJLCRFRMqCNXL++DVDJUa19t3MipahK0J0KiF7MqBbOAItk4p7CAbQByj0JQj WhsRp7sGJ6mAm+TUSIPuLz18qtleSI5/Na7CtuXjha/IA9t7nFYA/Vj0B3K67a7j yt/a01ocScz7Ea0nc97aR+LZuJquWXbfFtA3mV+NDzBmoJ6ptCrGihu+ObooqPJ+ hd3BGtY2QaUa9tuyfwLWcKaIe7HKuGN1ZzzwW6JjkuUkPUFKR60+xZW0IyqRmfSL g== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=PVoVbnPahd+TBjoT0P/LwBAqgin/x3lYwTEXmT/zI ak=; b=IRAtbSymgjHp3H5hjf7wY/D7nKDZ0FyPcv48LZcJzlAahSLGfd4KMHE5R kbm7OtPu77nhKsGsZ4wjHoVrGX2d/dV7SKZ96ZGnJiOj/YHD0xRJUMsdyZAJ/Z+z fzlX5UVwIRAupHx6hwr6GIMDkZjtcc0aN6MESO4N9BfIUazJ599H6jgQPCzeWATr 9cd0YZxqGKfn2bPzcXeaxWeEzus/S4ZKnQJBd9S6npu4wxQlj3jPHjB5qD5aRAiS o7+UZzzCH4J54QoyY3rnHp++a1tzEFMgw009cV0opHma9w0k6MK+Zhl+H/B3anhs Xj33CoBiQIJt2+oYlSiN3vdKnERrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudelgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 72D69D4133; Thu, 11 Apr 2019 06:23:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: <87ee0088-2e0f-4000-a90a-12da28fc2531@www.fastmail.com> In-Reply-To: <589634421.18028.1554954351946@appsuite.open-xchange.com> References: <155475588989.30030.14071614051532431093.idtracker@ietfa.amsl.com> <589634421.18028.1554954351946@appsuite.open-xchange.com> Date: Thu, 11 Apr 2019 06:23:23 -0400 From: "Alexey Melnikov" To: "Michael Slusarz" , "Adam Roach" , "Adam Roach via Datatracker" , "The IESG" Cc: extra@ietf.org, "Bron Gondwana" , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] =?utf-8?q?Adam_Roach=27s_No_Objection_on_draft-ietf-extr?= =?utf-8?q?a-imap-fetch-preview-03=3A_=28with_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 10:23:48 -0000 Hi Michael, On Thu, Apr 11, 2019, at 4:46 AM, Michael Slusarz wrote: > Adam, >=20 > Thanks for your comments. Discussion below. >=20 > > On April 8, 2019 at 2:38 PM Adam Roach via Datatracker wrote: > > --------------------------------------------------------------------= -- > > COMMENT: > > --------------------------------------------------------------------= -- > > > > =C2=A73.1: > >=20 > > > These algorithms MUST be one > > > of the algorithms identified as supported in the PREVIEW capabili= ty > > > responses. > >=20 > > This is confusing, as "algorithms" and "one of" don't make sense wit= h each > > other. Is it meant to say something like "...MUST be a subset of the= > > algorithms..."? >=20 > Noted that the topic of multiple algorithm selection is being discusse= d=20 > in Barry's DISCUSS. >=20 > That being said, if multiple algorithm support is decided to be kept,=20= > what about changing this to: >=20 > "All algorithms specified in the list MUST be identified as being=20 > supported by the server by appearing in a PREVIEW capability response.= "=20 > (or "PREVIEW=3D capability response" maybe?) You already need to deal with unrecognized algorithms (the text you sugg= ested below), so having a MUST here doesn't make sense. > > =C2=A73.1: > >=20 > > > If a client requests an algorithm that is unsupported, > > > the server MUST return a tagged BAD response. > >=20 > > This appear to be underspecified, or at least nonintuitive. As writt= en, > > it seems to say that an algorithm list of (known-1, known-2, unknown= , known-3) > > would be considered invalid, even though there are plenty of support= ed, > > requested algorithms that could be used. Is this actually intended t= o be an > > error? If so, please make it explicit, as it's pretty counterintuiti= ve. > >=20 > > (As an aside: it's also unnecessarily fragile from an interop perspe= ctive, so I > > would suggest that this is not the desired behavior: I believe you w= ant to > > return an error only when *none* of the requested algorithms are sup= ported). >=20 > See Barry's DISCUSS response. Agreed that error handling is not=20 > specified adequately in current text. >=20 > To mirror duplicate algorithm language, how about: "Unsupported=20 > algorithms in the list MUST be ignored. If the list contains no=20 > supported algorithms, the server MUST return a tagged BAD response to=20= > the FETCH command." This looks reasonable to me. > > --------------------------------------------------------------------= ------- > >=20 > > =C2=A76, example 5: > >=20 > > > C: E1 CAPABILITY > > > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY SEARCHRES > > > S: E1 OK Capability command completed. > > > [...a mailbox is SELECTed...] > > > C: E2 SEARCH RETURN (SAVE) FROM "FOO" > > > C: E3 FETCH $ (UID PREVIEW (LAZY=3DFUZZY)) > >=20 > > This example shows the use of a modifier ("LAZY") with an algorithm;= however, > > this modifier doesn't appear to be advertised by the server in its C= APABILITY > > line. If I understand how this is supposed to work (looking at the d= efinitions > > in section 7), I would have expected: > >=20 > > S: * CAPABILITY IMAP4rev1 PREVIEW=3DFUZZY PREVIEW=3DLAZY SEARCH= RES > >=20 > > I'll note that this syntax effectively places algorithms and modifie= rs in the > > same namespace, although IANA doesn't seem to be given any explicit > > instructions about this. I think this needs to be cleaned up prior t= o > > publication. I would make this last point a DISCUSS, except that it= appears > > to be covered by Benjamin's DISCUSS already. >=20 > This has been discussed in several other places already. I am=20 > proposing removing priority modifier extensions, which would address=20= > this concern. I think this is a reasonable course of action. Best Regards, Alexey From nobody Thu Apr 11 03:30:23 2019 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 18D9912011D; Thu, 11 Apr 2019 03:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=fastmail.fm header.b=jRXaRRzl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T4CYDvZJ 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 XTrsQtdDdQrg; Thu, 11 Apr 2019 03:30:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AA512004D; Thu, 11 Apr 2019 03:30:14 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 65AEC21FB5; Thu, 11 Apr 2019 06:30:13 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 11 Apr 2019 06:30:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=O89AVmQtoeoNcXyLvN0VwGAFv6oPQqN 8J7T8KxKy8lM=; b=jRXaRRzlJ7Lb3wl5Gj27vpL9yQePzMoscqnNDm4/tGRB3Zv IRd2WqByLQb7VuQnGkY+AJr2/Kkv8K0yrQGlUAv140OaP2nhGya78S6nRkSD7510 gmpEGnx0R1n66bDekHCni+KYlmDDBReWoR8MUQwPTGy7otIGacyfYwhMn40Q4nWF n+5nKaxAXhQkhAIXE9UKkQd/eau7j28Z1svEHPWKGyaLHQHNw7ZvgkkSKy0PVAsD ADL852LkgUtEWHzXwIyxoEjnk3EOkn6EzZTSQPQ+kT3UFR+rdowOllDdHKgrnSFy /hyIJbP5EVPUKeno1DtQLJIo30eVv61kyidnNBA== 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-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=O89AVm QtoeoNcXyLvN0VwGAFv6oPQqN8J7T8KxKy8lM=; b=T4CYDvZJqSNUG9gMui8AUH TxN/z0Byq6H3H/ESoJCn6dLOngRlRvmYrm6IdbTVrf3aaF/hdM8fhRdLRa4SyZ/H DSYQgwbiQ1l4n/MPCD94SyiyVOIHPrMJsQgb2vZMh/REuQuxkm7JwiM8wIeHrCWy LX7HwCWgAWgHUrMMNVO3q/vATeePCk+85QRlynIevjxgkP/tdomqkSMp1vCVR7XS Cy9999Lw1B9InYegN2G+90/lIiD1sbaL88GtIue7byyCQTzsoK8oFNkhlSFkrS51 DgTviuaaIW3cx68+xeMBlAgbuK6t8E02ySsdSvNyDHtEWjS48qmg5BaxcpHDhZqw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudelgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgrnhgrrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A5194D4132; Thu, 11 Apr 2019 06:30:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 21611513 Message-Id: <62c55cb4-68db-4a16-82ef-4f9df7f1ad56@www.fastmail.com> In-Reply-To: <200085968.18013.1554949931366@appsuite.open-xchange.com> References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> <200085968.18013.1554949931366@appsuite.open-xchange.com> Date: Thu, 11 Apr 2019 06:29:51 -0400 From: "Alexey Melnikov" To: "Michael Slusarz" , "Benjamin Kaduk" , "Adam Roach via Datatracker" , "The IESG" Cc: extra@ietf.org, "Bron Gondwana" , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Extra] =?utf-8?q?Benjamin_Kaduk=27s_Discuss_on_draft-ietf-extra?= =?utf-8?q?-imap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 10:30:17 -0000 Hi Michael, On Thu, Apr 11, 2019, at 3:32 AM, Michael Slusarz wrote: > More broadly, any IMAP command should be subject to this kind of > truncation if there is concern that completion risks resource > starvation as a consequence. (On that note, I thought there was some > sort of "resource limitation" response code defined for this kind of > situation, e.g. in RFC 5530, but it looks like there isn't. Maybe we > need something like this). I think we have TEMPFAIL for this: Best Regards, Alexey From nobody Thu Apr 11 12:11:21 2019 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 170611203F9; Thu, 11 Apr 2019 12:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 mUijQn1y0p_D; Thu, 11 Apr 2019 12:11:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 460F6120311; Thu, 11 Apr 2019 12:11:10 -0700 (PDT) Received: from kduck.mit.edu (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.14.7/8.12.4) with ESMTP id x3BJB3iI024588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 15:11:05 -0400 Date: Thu, 11 Apr 2019 14:11:03 -0500 From: Benjamin Kaduk To: Michael Slusarz Cc: Benjamin Kaduk via Datatracker , The IESG , extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <20190411191103.GQ18549@kduck.mit.edu> References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> <200085968.18013.1554949931366@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200085968.18013.1554949931366@appsuite.open-xchange.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 19:11:14 -0000 On Wed, Apr 10, 2019 at 08:32:11PM -0600, Michael Slusarz wrote: > Benjamin, > > Thank you for the comments. Disccusion below: > > > On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I wavered a lot about whether this was DISCUSS-worthy, but it seems like > > we should at least talk about how big a risk for future confusion there > > is: > > > > I'm a little confused by the ABNF for 'capability' in Section 7 -- it > > seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and > > Section 3.1 talk only about *algorithms* in PREVIEW capability responses > > (and not modifiers). Is the intent to have capability tags for > > (non-mandatory) priority modifiers? > > [Edit: looks like this was discussion item moved to Barry's ballot, but I'll leave the discussion here for clarity in the thread history] [Ok] > I struggled with the decision to include priority modifier extensions in the draft. > > Algorithm extensions make sense, as there can be competing or expanded way of generating preview text in the future. But priority modifiers are tied to the behavior of the command, not the output of the command. In the case there would be a need for a priority modifier in the future, that's a fundamental change to the semantics of the command itself and would probably require extensive discussion. > > Under further thought and review, I would be perfectly fine with removing the extension/registry for priority modifiers and simply making it an explicit part of the base command. This would simplify the draft a bit. Thoughts? That would definitely simplify things (and IIUC remove the concerns here). I don't want to pressure you or the WG into making that decision, though -- pick what seems best for the technology, and figuring out how to describe it properly will come pretty easily after that. > (To answer your original DISCUSS: a separate CAPABILITY string wasn't defined, because it is implicit in PREVIEW=FUZZY, which is required to implement PREVIEW, that LAZY must also be handled. Not requiring PREVIEW=LAZY, and not defining what a potential capability would look like in the future, were explicit choices.) > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 7 > > > > How much discussion was there about "SHOULD be registered" (as opposed > > to "MUST be registered")? > > Alexey and I discussed in a previous thread, located here: (I missed the link, but I don't want to relitigate the question if it was already covered.) > I think a valid summation is that Alexy was pushing hard for MUST register, but my reading of 6648 is that it allows flexibility in allowing extensions, as long as you follow naming conventions. > > My personal example is that there is at least one additional PREVIEW extension we may develop, and which may be implemented quickly, but there is no intention to register that extension (at least at the beginning) because it is a very specific use-case that may not be generally useful to the wider Internet. So demanding a MUST register to me seems unduly harsh and inflexible. With a "standards-track or IESG-approved experimental RFC" registration policy, that's probably true. It might be different with a lighter-weight registration policy like "expert review", though. > > Section 9 > > > > I agree with Roman that there should be discussion of the caching/data > > retention strategy for message previews. > > As mentioned in response to Roman, I worked on this language last week and I will share with the group once I have access to that revision. > > > This existing text about denial-of-service attacks is probably fine, > > though I might consider rephrasing it along the lines of "this mechanism > > introduces a new way for clients to make requests that consume server > > resources. As is the case for all such mechanisms, it could be used as > > part of a denial-of-service attack on server resources, e.g., via > > excessive memory or CPU usage, or increased storage if preview results > > are cached on the server after generation. The additional attack > > surface presented by this specific mechanism is not believed to higher > > risk that other similar mechanisms in use already, since the individual > > resource consumption per message processed is likely to be modest. > > Nonetheless, servers MAY limit the resources consumed by preview > > generation." > > > > As I write the above, though, I wonder how this interacts with the > > previous text in Section 3.1 about how the "server MUST honor a client's > > algorithm priority decision". Does that mean that if some future > > (expensive) algorithm is specified, once a server implements that > > algorithm, any client can force its use and thus the expensive resource > > consumption on the server? It's not entirely clear to me how this MAY > > interacts with that MUST, in such a hypothetical scenario. > > I don't see this as any different of a problem than with other IMAP commands. Example: a user issues a SORT/THREAD command in a large mailbox, and that command would require 10,000s of message accesses to return. An IMAP server should be allowed to abort the response somehow (we will return an unsorted list, for example), subject to some kind of resource limitations, even though the requirements of the command is that it must return a sorted list. > > More broadly, any IMAP command should be subject to this kind of truncation if there is concern that completion risks resource starvation as a consequence. (On that note, I thought there was some sort of "resource limitation" response code defined for this kind of situation, e.g. in RFC 5530, but it looks like there isn't. Maybe we need something like this). I'm happy with that answer (and would be happy to see a document with such a new response code appear). Thanks, Ben From nobody Thu Apr 11 16:34:40 2019 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 5272012034E; Thu, 11 Apr 2019 16:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8sx7tbPJy9FR; Thu, 11 Apr 2019 16:34:37 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 0F97D1200FF; Thu, 11 Apr 2019 16:34:37 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3BNUREa121630; Thu, 11 Apr 2019 23:34:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=QXTi4ibgoohry+6xz8ZEaHb1c7uDWtBPiHdMvcBOowQ=; b=c7tzuwx5zlm5fU35atzXmWm72Ce5jsF0w4I3jMXeSZSjRES7o5Rycz5BvLd63vKOpYed RtpeHHgmPbyFm2Nrnb1KOMVCJb4Ys5rGC/5fGiU0k/MV540uD8tj9YGsPmqZy/IZztUw 3FcgaiwwjJyNcQWyDwhjPnq1mE6I5mrge/Fx2ioNXcqjDINgOY4ypYhpJavRpmD134em OjuPy9X6NGWllTA0udDJZ7oL0Q1a1zuqMKn8mkiZEHve8AsM7fANZWSVpFSFNu55g0jG LbH7BVtLOPqThI8dQms/OhLL6avfqbuOmLWbKyMA+HoQVdQ8PM5qapBmEX+OkBMx21+N QA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rpkhtbs2t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Apr 2019 23:34:31 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3BNXhju104509; Thu, 11 Apr 2019 23:34:30 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2rpytd26st-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Apr 2019 23:34:30 +0000 Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x3BNYThq003704; Thu, 11 Apr 2019 23:34:29 GMT Received: from [192.168.56.1] (/166.154.192.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Apr 2019 16:34:29 -0700 From: "Chris Newman" To: "Michael Slusarz" Cc: "Benjamin Kaduk" , "Benjamin Kaduk via Datatracker" , "The IESG" , extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Date: Thu, 11 Apr 2019 16:34:23 -0700 X-Mailer: MailMate (1.12.4r5594) Message-ID: <2CEEDFCA-72F6-46B1-BB4F-5585E003F57B@oracle.com> In-Reply-To: <200085968.18013.1554949931366@appsuite.open-xchange.com> References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> <200085968.18013.1554949931366@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9224 signatures=668685 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-1810050000 definitions=main-1904110151 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9224 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110151 Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 23:34:38 -0000 On 10 Apr 2019, at 19:32, Michael Slusarz wrote: > Benjamin, > > Thank you for the comments. Disccusion below: > >> On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker = >> wrote: >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> I wavered a lot about whether this was DISCUSS-worthy, but it seems = >> like >> we should at least talk about how big a risk for future confusion = >> there >> is: >> >> I'm a little confused by the ABNF for 'capability' in Section 7 -- it >> seems to allow for (e.g.) PREVIEW=3DLAZYV2, but the introduction and >> Section 3.1 talk only about *algorithms* in PREVIEW capability = >> responses >> (and not modifiers). Is the intent to have capability tags for >> (non-mandatory) priority modifiers? > > [Edit: looks like this was discussion item moved to Barry's ballot, = > but I'll leave the discussion here for clarity in the thread history] > > I struggled with the decision to include priority modifier extensions = > in the draft. > > Algorithm extensions make sense, as there can be competing or expanded = > way of generating preview text in the future. But priority modifiers = > are tied to the behavior of the command, not the output of the = > command. In the case there would be a need for a priority modifier in = > the future, that's a fundamental change to the semantics of the = > command itself and would probably require extensive discussion. > > Under further thought and review, I would be perfectly fine with = > removing the extension/registry for priority modifiers and simply = > making it an explicit part of the base command. This would simplify = > the draft a bit. Thoughts? As a server implementor, I think that's a good proposal to resolve this = issue. - Chris > (To answer your original DISCUSS: a separate CAPABILITY string wasn't = > defined, because it is implicit in PREVIEW=3DFUZZY, which is required t= o = > implement PREVIEW, that LAZY must also be handled. Not requiring = > PREVIEW=3DLAZY, and not defining what a potential capability would look= = > like in the future, were explicit choices.) > > >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> Section 7 >> >> How much discussion was there about "SHOULD be registered" (as = >> opposed >> to "MUST be registered")? > > Alexey and I discussed in a previous thread, located here: > > I think a valid summation is that Alexy was pushing hard for MUST = > register, but my reading of 6648 is that it allows flexibility in = > allowing extensions, as long as you follow naming conventions. > > My personal example is that there is at least one additional PREVIEW = > extension we may develop, and which may be implemented quickly, but = > there is no intention to register that extension (at least at the = > beginning) because it is a very specific use-case that may not be = > generally useful to the wider Internet. So demanding a MUST register = > to me seems unduly harsh and inflexible. > >> Section 9 >> >> I agree with Roman that there should be discussion of the = >> caching/data >> retention strategy for message previews. > > As mentioned in response to Roman, I worked on this language last week = > and I will share with the group once I have access to that revision. > >> This existing text about denial-of-service attacks is probably fine, >> though I might consider rephrasing it along the lines of "this = >> mechanism >> introduces a new way for clients to make requests that consume server >> resources. As is the case for all such mechanisms, it could be used = >> as >> part of a denial-of-service attack on server resources, e.g., via >> excessive memory or CPU usage, or increased storage if preview = >> results >> are cached on the server after generation. The additional attack >> surface presented by this specific mechanism is not believed to = >> higher >> risk that other similar mechanisms in use already, since the = >> individual >> resource consumption per message processed is likely to be modest. >> Nonetheless, servers MAY limit the resources consumed by preview >> generation." >> >> As I write the above, though, I wonder how this interacts with the >> previous text in Section 3.1 about how the "server MUST honor a = >> client's >> algorithm priority decision". Does that mean that if some future >> (expensive) algorithm is specified, once a server implements that >> algorithm, any client can force its use and thus the expensive = >> resource >> consumption on the server? It's not entirely clear to me how this = >> MAY >> interacts with that MUST, in such a hypothetical scenario. > > I don't see this as any different of a problem than with other IMAP = > commands. Example: a user issues a SORT/THREAD command in a large = > mailbox, and that command would require 10,000s of message accesses to = > return. An IMAP server should be allowed to abort the response = > somehow (we will return an unsorted list, for example), subject to = > some kind of resource limitations, even though the requirements of the = > command is that it must return a sorted list. > > More broadly, any IMAP command should be subject to this kind of = > truncation if there is concern that completion risks resource = > starvation as a consequence. (On that note, I thought there was some = > sort of "resource limitation" response code defined for this kind of = > situation, e.g. in RFC 5530, but it looks like there isn't. Maybe we = > need something like this). > > michael > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_extra&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3D_6NkoEgIENsYMaN= oSASPfK2B1zYYYPt9O1NJVWklBGw&s=3DYRIPXtCQVIlTe3Fk5OkDQMENKX5db8JeL5XXhi7D= fAU&e=3D From nobody Wed Apr 24 20:52:26 2019 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 5B2571202CD; Wed, 24 Apr 2019 20:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXhCfIYBnKtS; Wed, 24 Apr 2019 20:52:22 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 A88131202CE; Wed, 24 Apr 2019 20:52:22 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 307E86A350; Thu, 25 Apr 2019 05:52:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1556164340; bh=PBmUa2obSB5xHoZ/lVw2/mFjNFI+Kkvn7pKiUpudW3o=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=T0mDJG1x6IIA3WVIAZOysVgk+gks37BBOWKUgFcQ8kzhZawi8udqBjLUxxMKND5HR iDnjHXlreHDDNnTJaH0WiZ/HU7kr5elaNnSezR74K7OkoK6EdtecK0N7lIWZOOI2ns n/ARg7FM2BMy9pby88EMIw2x4t1nwY9vBkbMeJ+e/zRZIA/L77b+JLmx7S7PjFAHhQ +skK465RylTzzeOhU56tDVuEHK3pL4ARtBkas0IYzjs9vgWN3AvNOe2KZdHfByNBlt Fv1EEnnSvq9Hdg5ZKRTjW8biAGnZiGlgndPzEzN5jBB98uEQcNZ8o+rB9wdWwP+L2Y tlt9aVyr8SAxw== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 13BE53C01B8; Thu, 25 Apr 2019 05:52:20 +0200 (CEST) Date: Wed, 24 Apr 2019 21:52:19 -0600 (MDT) From: Michael Slusarz To: Alexey Melnikov , Michael Slusarz , Benjamin Kaduk , Adam Roach via Datatracker , The IESG Cc: extra@ietf.org, Bron Gondwana , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <2055354549.44771.1556164340005@appsuite.open-xchange.com> In-Reply-To: <62c55cb4-68db-4a16-82ef-4f9df7f1ad56@www.fastmail.com> References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> <200085968.18013.1554949931366@appsuite.open-xchange.com> <62c55cb4-68db-4a16-82ef-4f9df7f1ad56@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 25 Apr 2019 03:52:26 -0000 > On April 11, 2019 at 4:29 AM Alexey Melnikov wrote: > > Hi Michael, > > On Thu, Apr 11, 2019, at 3:32 AM, Michael Slusarz wrote: > > > More broadly, any IMAP command should be subject to this kind of > > truncation if there is concern that completion risks resource > > starvation as a consequence. (On that note, I thought there was some > > sort of "resource limitation" response code defined for this kind of > > situation, e.g. in RFC 5530, but it looks like there isn't. Maybe we > > need something like this). > > I think we have TEMPFAIL for this: As a bare response code, this seems like the correct answer. But in RFC 5259, TEMPFAIL is defined as a "transcoding request [that] failed temporarily". My opinion: I don't think that maps to failing a[ny] IMAP request due to resource constraints. michael From nobody Wed Apr 24 21:59:35 2019 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 02C1F1202DC; Wed, 24 Apr 2019 21:59:26 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <155616836591.32005.8433082720353158422@ietfa.amsl.com> Date: Wed, 24 Apr 2019 21:59:26 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-04.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 25 Apr 2019 04:59:26 -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: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-04.txt Pages : 13 Date : 2019-04-24 Abstract: This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated representation of message data useful as a contextual preview of the entire message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-04 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-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 Apr 25 11:44:50 2019 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 3F9E912023F; Thu, 25 Apr 2019 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 7aM_HLTSnV7G; Thu, 25 Apr 2019 11:44:40 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.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 3145B120227; Thu, 25 Apr 2019 11:44:40 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3PIiY2L040086; Thu, 25 Apr 2019 14:44:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x3PIiY2L040086 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556217874; bh=8kojQT7WZJ7c3aclBM5fzC01oyApy/f5OoLWmORzyMo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nf5eRkwUst+t/qX779mmQKal6JcqQ73XuxsfddsqXaROrpMJN4yqzzdZ5IK5Zbs2G EjqBdMlPcwtptIXGCQ0iWpoVMdtKNvswBRqHxeZFI24fk4P9r1WC8z9c1seqSwEfuz 6JAGSMe9e1/7Y2if3Ko4I/dOVKwh5lQhrntvzJXQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3PIiXNC026921; Thu, 25 Apr 2019 14:44:33 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 25 Apr 2019 14:44:32 -0400 From: Roman Danyliw To: Michael Slusarz , "The IESG" CC: "extra@ietf.org" , "brong@fastmailteam.com" , "extra-chairs@ietf.org" , "draft-ietf-extra-imap-fetch-preview@ietf.org" Thread-Topic: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) Thread-Index: AQHU6lsdU9pkh6o9mkWEzi03EGhTD6Y2gnWAgBbS0cA= Date: Thu, 25 Apr 2019 18:44:29 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon> References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> <270245125.18005.1554947909394@appsuite.open-xchange.com> In-Reply-To: <270245125.18005.1554947909394@appsuite.open-xchange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 25 Apr 2019 18:44:42 -0000 SGkgTWljaGFlbCENCg0KVGhhbmtzIGZvciB0aGUgLTA0IHVwZGF0ZS4gIENvbW1lbnRzIGJlbG93 IC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgW21haWx0 bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFNsdXNhcnoNCj4g U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSA5OjU4IFBNDQo+IFRvOiBSb21hbiBEYW55 bGl3IDxyZGRAY2VydC5vcmc+OyBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlcg0KPiA8bm9y ZXBseUBpZXRmLm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZXh0cmFAaWV0 Zi5vcmc7IGJyb25nQGZhc3RtYWlsdGVhbS5jb207IGV4dHJhLWNoYWlyc0BpZXRmLm9yZzsgZHJh ZnQtDQo+IGlldGYtZXh0cmEtaW1hcC1mZXRjaC1wcmV2aWV3QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbRXh0cmFdIFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZXh0cmEt aW1hcC1mZXRjaC0NCj4gcHJldmlldy0wMzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g DQo+IFJvbWFuLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiAgU2VlIGJlbG93Og0K PiANCj4gPiBPbiBBcHJpbCAzLCAyMDE5IGF0IDI6MjMgUE0gUm9tYW4gRGFueWxpdyB2aWEgRGF0 YXRyYWNrZXINCj4gPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+IERJU0NVU1M6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gKDEpIFJldGVu dGlvbiBwcmFjdGljZXMgb2YgY2FjaGVkIHByZXZpZXdzIFNlY3Rpb24gMSBzYXlzIOKAnFVzaW5n DQo+ID4gc2VydmVyIGdlbmVyYXRlZCBwcmV2aWV3cyBhbGxvd3MgZ2xvYmFsIGdlbmVyYXRpb24g b25jZSBwZXIgbWVzc2FnZSwNCj4gPiBhbmQgdGhlbiBjYWNoZWQgaW5kZWZpbml0ZWx54oCdLiAg V2h5IGNhY2hlIGluZGVmaW5pdGVseSwgZXNwZWNpYWxseSBpZg0KPiA+IHRoZSBzb3VyY2UgbWVz c2FnZXMgaGFzIGJlZW4gZXhwdW5nZWQ/ICBGb3IgcHJpdmFjeSByZWFzb25zLCBjb3VsZG7igJl0 DQo+ID4gdGhpcyBjYWNoaW5nIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgcmV0ZW50aW9uIG9mIHRo ZSBlbWFpbC4NCj4gPg0KPiA+IEluIFNlY3Rpb24gOSwgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMs IHRoZXJlIG5lZWRzIHRvIGJlIGRpc2N1c3Npb24gb2YNCj4gPiB0aGlzIHJldGVudGlvbiB0b28u ICBQZXJoYXBzIHRleHQgbGlrZTog4oCcSW1wbGVtZW50YXRpb25zIHRoYXQNCj4gPiBwcmUtZ2Vu ZXJhdGUgYW5kIHN0b3JlIHByZXZpZXdzIE1VU1QgZW5zdXJlIHRoYXQgdGhlIHN0b3JlZCBwcmV2 aWV3IGlzDQo+ID4gYWxzbyBkZWxldGVkIHdoZW4gdGhlIGNvcnJlc3BvbmRpbmcgbWFpbCBtZXNz YWdlIGlzIGV4cHVuZ2VkLuKAnQ0KPiANCj4gQWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzIChhbmQg QmFycnkgYW5kIEFsZXhleSkgdGhhdCB0aGlzIGxhbmd1YWdlIGNhbiBiZQ0KPiBpbXByb3ZlZC4g IEkgaW1wbGVtZW50ZWQgYmV0dGVyIGxhbmd1YWdlIGxhc3Qgd2VlayBpbiB0aGUgZHJhZnQgLi4u IGJ1dA0KPiB1bmZvcnR1bmF0ZWx5IEkgY2FuJ3QgYWNjZXNzIHRob3NlIGNoYW5nZXMgYXQgdGhl IG1vbWVudCBhcyBvdXIgUkNTIHN5c3RlbQ0KPiBpcyBpbnZvbHZlZCBpbiBhIHB1YmxpYyBjbG91 ZCBvdXRhZ2UuICBPbmNlIGJhY2sgb25saW5lLCBJJ2xsIHNoYXJlIHRoZSByZXZpc2VkDQo+IHRl eHQuDQoNCkl0IGRvZXNuJ3QgbG9vayBsaWtlIHRoZSByZXZpc2VkIHRleHQgdG8gYWRkcmVzcyB0 aGUgcmV0ZW50aW9uIGlzc3VlIG1hZGUgaXQgaW50byAtMDQuICBGdXJ0aGVybW9yZSwgdGhlIG5l dyBsYW5ndWFnZSBpbiBTZWN0aW9uIDksICJJZiBzdG9yZWQgcGVybWFuZW50bHksIC4uLiIgcmVp dGVyYXRlcyBteSBjb25jZXJuLiANCg0KPiA+ICgyKSBQcm90ZWN0aW9uIG9mIHByZXZpZXdzIGF0 IHJlc3QNCj4gPiBJbiBTZWN0aW9uIDksIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLCB0aGVyZSBu ZWVkcyB0byBiZSBkaXNjdXNzaW9uDQo+ID4gYWJvdXQgdGhlIHBvdGVudGlhbCBzZW5zaXRpdml0 eSBvZiB0aGVzZSBwcmV2aWV3cyBhbmQgdGhlIG5lZWQgdG8NCj4gPiBwcm90ZWN0IHRoZW0uICBQ ZXJoYXBzIHRleHQgbGlrZTog4oCcSnVzdCBhcyB0aGUgbWVzc2FnZXMgdGhleQ0KPiA+IHN1bW1h cml6ZSwgcHJldmlld3MgbWF5IGNvbnRhaW4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiAgV2hlbiBz dG9yZWQsDQo+ID4gdGhlc2UgcHJldmlld3MgTVVTVCBiZSBwcm90ZWN0ZWQgd2l0aCBlcXVpdmFs ZW50IGF1dGhvcml6YXRpb24gYW5kDQo+IGNvbmZpZGVudGlhbGl0eSBjb250cm9scyBhcyB0aGUg c291cmNlIG1lc3NhZ2Uu4oCdDQo+IA0KPiBNeSByZWNvbGxlY3Rpb24gaXMgdGhhdCBJIGFkZGVk IHRoaXMgdGV4dCwgb3IgYSBzbGlnaHQgZGVyaXZhdGlvbiBvZiBpdCwgdG8gdGhlDQo+IFNlY3Vy aXR5IHNlY3Rpb24uDQoNClRoZSBuZXcgdGV4dCBhZGRyZXNzZXMgbXkgY29uY2Vybi4gIFRoYW5r cy4NCg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDT01NRU5UOg0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPg0KPiA+ICgyKSBTZWN0aW9uIDMuMSwgdGhlIHBhcmFncmFwaCDigJxJZiBubyBhbGdvcml0 aG0gaWRlbnRpZmllciBpcw0KPiA+IHByb3ZpZGVkLCB0aGUgc2VydmVyIGRlY2lkZXMg4oCm4oCd IGRpc2N1c3NlcyBhbGdvcml0aG0gaWRlbnRpZmllcnMgYnV0DQo+ID4gdGhlaXIgdXNlIGhhc27i gJl0IGJlZW4gaW50cm9kdWNlZCB5ZXQuICBJIHJlY29tbWVuZCBzd2FwcGluZyB0aGUgb3JkZXIN Cj4gPiBvZiB0aGlzIHBhcmFncmFwaCB3aXRoIHRoZSBjdXJyZW50IHRoaXJkIHBhcmFncmFwaCAo 4oCcQWx0ZXJuYXRpdmUg4oCm4oCdKQ0KPiA+IGFzIHRoaXMgaXMgd2hlcmUgYWxnb3JpdGhtcyBh cmUgaW50cm9kdWNlZC4NCj4gPg0KPiA+ICgzKSBTZWN0aW9uIDQuMS4gIER1cGxpY2F0ZSB3b3Jk LiBzL3RvIHRoZSB0aGUgbGFuZ3VhZ2UvdG8gdGhlDQo+ID4gbGFuZ3VhZ2UvDQo+ID4NCj4gPiAo NCkgU2VjdGlvbiA0LjEuICBOaXQgb24gd29yZCBvcmRlci4gcy9ubyBodW1hbi1yZWFkYWJsZSB0 ZXh0IHRvDQo+ID4gZ2VuZXJhdGUgcHJldmlldyBpbmZvcm1hdGlvbiBmcm9tL25vIGh1bWFuLXJl YWRhYmxlIHRleHQgZnJvbSB3aGljaCB0bw0KPiA+IGdlbmVyYXRlIHByZXZpZXcgaW5mb3JtYXRp b24vDQo+ID4NCj4gPiAoNSkgU2VjdGlvbiA3LiAgSW4gdGhlIEFCTkYgY29tbWVudHMsIGNvbnNp ZGVyIHVzaW5nIOKAnFtSRkM2NjQ4XeKAnQ0KPiA+IGluc3RlYWQgb2Yg4oCcUkZDIDY2NDjigJ0u DQo+IA0KPiBGaXhlcyB0byB0aGVzZSB2YXJpb3VzIG5pdHMgd2VyZSBhZGRlZCB0byB0aGUgZHJh ZnQuICBQZXIgQmFycnkncyByZXBseSwgSSBkaWQNCj4gbm90IGltcGxlbWVudCB0aGUgcHJvcG9z ZWQgUkZDIDgxNzQgY2hhbmdlcy4NCg0KTG9va3MgZ29vZC4gIFRoYW5rIHlvdS4NCg0KUm9tYW4N Cg== From nobody Sun Apr 28 21:29:06 2019 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 938B41200B5; Sun, 28 Apr 2019 21:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo0NwjVM_Wsf; Sun, 28 Apr 2019 21:29:01 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 73292120098; Sun, 28 Apr 2019 21:29:01 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 642F56A33B; Mon, 29 Apr 2019 06:28:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1556512139; bh=ghpB5QiNAEarSvC1fVw5mbCaXVtJcnY80Q9II/T7doI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Jj0PUu6ATM4xtoqvjNJJG8xXHtDMIYDPGks0OVHK1BVWYclN0uZ/yCcumvw819EBp cHHcdQ8cczL2jODp2GNYj4EdQnLqVX/1gvXWDn7MV3WuaITJOJZDdOqPeqXsJkSKOw fxRwq5LzBpoYD8m4cESu7yUgeKa/nw2wd91Ol97Nd3qd3e0CmrrXl4K5KjpAjphHhI TouyJWYr/4QGt2Ji6PSvNR4X4XH3zAjaOX7VymRAErXkIUnPbxRDddTuS0g62A1+g/ HOGh/FX459yaiZYc7Wrr/CsTHK684WbQ3LMKgsrC2133Mg+MgBc7vZ8z/FpOmuVKWR vny3Z8V/Y22Ng== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 487F33C0042; Mon, 29 Apr 2019 06:28:59 +0200 (CEST) Date: Sun, 28 Apr 2019 22:28:58 -0600 (MDT) From: Michael Slusarz To: Roman Danyliw , Michael Slusarz , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <1314584272.50149.1556512139210@appsuite.open-xchange.com> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon> References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> <270245125.18005.1554947909394@appsuite.open-xchange.com> <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 04:29:06 -0000 > On April 25, 2019 at 12:44 PM Roman Danyliw wrote: > > > -----Original Message----- > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Michael Slusarz > > Sent: Wednesday, April 10, 2019 9:58 PM > > To: Roman Danyliw ; Roman Danyliw via Datatracker > > ; The IESG > > Cc: extra@ietf.org; brong@fastmailteam.com; extra-chairs@ietf.org; draf= t- > > ietf-extra-imap-fetch-preview@ietf.org > > Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-f= etch- > > preview-03: (with DISCUSS and COMMENT) > >=20 > > Roman, > >=20 > > Thanks for your comments. See below: > >=20 > > > On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker > > wrote: > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > (1) Retention practices of cached previews Section 1 says =E2=80=9CUs= ing > > > server generated previews allows global generation once per message, > > > and then cached indefinitely=E2=80=9D. Why cache indefinitely, espec= ially if > > > the source messages has been expunged? For privacy reasons, couldn= =E2=80=99t > > > this caching be consistent with the retention of the email. > > > > > > In Section 9, Security Considerations, there needs to be discussion o= f > > > this retention too. Perhaps text like: =E2=80=9CImplementations that > > > pre-generate and store previews MUST ensure that the stored preview i= s > > > also deleted when the corresponding mail message is expunged.=E2=80= =9D > >=20 > > Agree with your comments (and Barry and Alexey) that this language can = be > > improved. I implemented better language last week in the draft ... but > > unfortunately I can't access those changes at the moment as our RCS sys= tem > > is involved in a public cloud outage. Once back online, I'll share the= revised > > text. >=20 > It doesn't look like the revised text to address the retention issue made= it into -04. Furthermore, the new language in Section 9, "If stored perma= nently, ..." reiterates my concern.=20 Guilty. There was work being done in multiple local repositories, and some= changes were not merged to the final draft. I've addressed your concerns around permanence language in both Section 1 a= nd Section 9, and will be pushing an updated draft in a few minutes. michael From nobody Sun Apr 28 21:35:59 2019 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 5FE9E12029A; Sun, 28 Apr 2019 21:35:57 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <155651255724.21078.2020003078707601359@ietfa.amsl.com> Date: Sun, 28 Apr 2019 21:35:57 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-fetch-preview-05.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 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, 29 Apr 2019 04:35:58 -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: Message Preview Generation Author : Michael M. Slusarz Filename : draft-ietf-extra-imap-fetch-preview-05.txt Pages : 13 Date : 2019-04-28 Abstract: This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated representation of message data useful as a contextual preview of the entire message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-fetch-preview-05 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-fetch-preview-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-fetch-preview-05 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/