From nobody Mon Oct 1 05:44:02 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474E130E60 for ; Mon, 1 Oct 2018 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpI7gqxYL8pr for ; Mon, 1 Oct 2018 05:43:59 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CB616130E61 for ; Mon, 1 Oct 2018 05:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538397838; d=isode.com; s=june2016; i=@isode.com; bh=clcyYU66ezYz3x8QxSMW8/8g26YRhhel2FIbp8TObT4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uZB420fSswn1l0r7LD0NI57nzNNJD+b1ww/sLZdS05sDUFQTO0YQsgvGChc2WjUQFpy5Tr pdRZEXCkTeZizi+Ssi27rVURAvScnTO4ra04pIj87Ypaq0OXqM3P/uZBu604SSMd6BkduS q9vU9lOSjaBqWPyjU8F4+u+0y4vwo3E=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 1 Oct 2018 13:43:57 +0100 To: extra@ietf.org From: Alexey Melnikov Message-ID: <7c4a8162-e29e-bddb-1b9a-8d4ec6b623dc@isode.com> Date: Mon, 1 Oct 2018 13:43:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Extra] AD review of draft-ietf-extra-imap-replace-00.txt 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, 01 Oct 2018 12:44:01 -0000 Hi, The document is generally in a good state and covers lots of tricky=20 interactions with other extensions. But I have a small list of minor=20 issues/nits that I would like to discuss: 3.4.=C2=A0 Semantics of REPLACE and UID REPLACE =C2=A0=C2=A0 While it may be common for the named mailbox argument to match= the =C2=A0=C2=A0 selected mailbox for the common use case of replacing a draft,= the =C2=A0=C2=A0 REPLACE extension intentionally does not require the two to be= the =C2=A0=C2=A0 same.=C2=A0 As an example, it's possible to use the REPLACE co= mmand to =C2=A0=C2=A0 replace a message in the \Drafts special-use mailbox with a me= ssage =C2=A0=C2=A0 in the \Sent special-use mailbox following message submission. I think this needs an informative reference to the Special Use RFC to=20 help readers not familiar with the term. 4.3.=C2=A0 RFC 4315, UIDPLUS =C2=A0=C2=A0 Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD s= end =C2=A0=C2=A0 APPENDUID in response to a UID REPLACE command.=C2=A0 For addi= tional =C2=A0=C2=A0 information see section 3 of RFC4315.=C2=A0 Servers implementi= ng REPLACE =C2=A0=C2=A0 and UIDPLUS are also advised to send the APPENDUID response co= de in =C2=A0=C2=A0 an untagged OK before sending the EXPUNGE or replaced response= s. All examples are using: =C2=A0* APPENDUID ... instead of =C2=A0* OK [APPENDUID ...] some text What is in the draft is syntactically invalid, as it is not a response code. =C2=A0=C2=A0 (Sending the APPENDUID in the tagged OK, as described in the U= IDPLUS =C2=A0=C2=A0 specification means that the client first receives an EXPUNGE = for a =C2=A0=C2=A0 message and afterwards APPENDUID for the new message.=C2=A0 It= can be =C2=A0=C2=A0 unnecessarily difficult to process that sequence usefully.) 5.=C2=A0 Formal Syntax =C2=A0=C2=A0 capability=C2=A0=C2=A0=C2=A0=C2=A0 =3D/ "REPLACE" =C2=A0=C2=A0 command-select =3D/ replace =C2=A0=C2=A0 replace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "REPLACE= " SP seq-number SP mailbox append-message RFC 4466 allows for multiple "append-message", if MULTIAPPEND extension=20 is present. I think your document should say explicitly that REPLACE is=20 not affected by MULTIAPPEND. =C2=A0=C2=A0 uid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D "UID" SP (copy / fetch/ search / store / move / =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 replace) From nobody Mon Oct 1 06:45:07 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46332130DFA; Mon, 1 Oct 2018 06:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlkjccxCB2WZ; Mon, 1 Oct 2018 06:45:01 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4AB130DDC; Mon, 1 Oct 2018 06:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538401500; d=isode.com; s=june2016; i=@isode.com; bh=gL3NrhXPIU7MQhVi58ZUbiH8YNWN3KkzR3ixdMKuWls=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=V/kBWZYEmcz8V9turQPCG+5UcTOUEexHkfEE0Da9Bo8Vjbi4uXmDY6GyX5RkSWtJZjoEl3 xnqrk+nWz6umoE1qP2L3kvRxKE98M1J8GxV9Sfk+JJnGVARhZ9gH7bIyc5FE+hIYTMS8Ao dO3qwbmVVHWHykBgL8YKtc7n9BX4Rig=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 1 Oct 2018 14:45:00 +0100 To: draft-ietf-extra-sieve-fcc Cc: yaojk , extra References: <153662523769.16137.7151778749740462039@ietfa.amsl.com> <2018092911370230091886@cnnic.cn> From: Alexey Melnikov Message-ID: Date: Mon, 1 Oct 2018 14:44:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <2018092911370230091886@cnnic.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FEA816075808824E231484E3" Content-Language: en-GB Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-05.txt 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, 01 Oct 2018 13:45:06 -0000 --------------FEA816075808824E231484E3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable On 29/09/2018 04:38, Jiankang Yao wrote: > Dear authors, > =C2=A0 I am preparing for the shepherd write-up. > =C2=A0=C2=A0Could you kindly=C2=A0address the following issues and update = a new=20 > version? Thanks. > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-e= xtra-sieve-fcc-05.txt=20 > > ** There is 1 instance of too long lines in the document, the longest o= ne > being 2 characters in excess of 72. > > -- The draft header indicates that this document updates RFC5435, but t= he > abstract doesn't seem to mention this, which it should. > > -- The draft header indicates that this document updates RFC5230, but t= he > abstract doesn't seem to mention this, which it should. Right, the Abstract should have a sentence or 2 about RFCs updated,=20 ideally listing what was updated. This should enable readers to decide=20 whether they need to read the rest of the document. > Checking references for intended status: Proposed Standard > -----------------------------------------------------------------------= ----- > > (See RFCs 3967 and 4897 for information about using normative refere= nces > to lower-maturity documents in RFCs) > > -- Looks like a reference, but probably isn't: '1' on line 524 > > =3D=3D Missing Reference: 'FCC' is mentioned on line 196, but not defin= ed > > -- Looks like a reference, but probably isn't: '2' on line 526 > > -- Looks like a reference, but probably isn't: '3' on line 528 > > -- Looks like a reference, but probably isn't: '4' on line 530 I don't think anything needs to be done about the above, these are just=20 false warnings from the ID-nits. > =3D=3D Unused Reference: 'RFC5321' is defined on line 495, but no expli= cit > reference was found in the text I think this can be removed. > =3D=3D Unused Reference: 'RFC5429' is defined on line 499, but no expli= cit > reference was found in the text This is related to ereject. If it stays, the document needs to explain=20 interactions (or lack thereof) with ereject. > ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) This should be updated. --------------FEA816075808824E231484E3 Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable

On 29/09/2018 04:38, Jiankang Yao wrote:

Dear authors,
=C2=A0
=C2=A0 I am preparing for the shepherd write-up.
=C2=A0
=C2=A0=C2=A0Could you kindly=C2=A0address the following issues an= d update a new version? Thanks.=C2=A0
=C2=A0
=C2=A0
=C2=A0
  ** There is 1 instance of too long lines in the document, the longest =
one
     being 2 characters in excess of 72.

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

  -- The draft header indicates that this document updates RFC5230, but the
     abstract doesn't seem to mention this, which it should.
Right, the Abstract should have a sentence or 2 about RFCs updated, ideally listing what was updated. This should enable readers to decide whether they need to read the rest of the document.=C2=A0 

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

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

  -- Looks like a reference, but probably isn't: '1' on line 524

  =3D=3D Missing Reference: 'FCC' is mentioned on line 196, but not defined

  -- Looks like a reference, but probably isn't: '2' on line 526

  -- Looks like a reference, but probably isn't: '3' on line 528

  -- Looks like a reference, but probably isn't: '4' on line 530

I don't think anything needs to be done about the above, these are just false warnings from the ID-nits.


  =3D=3D Unused Reference: 'RFC5321' is defined on line 495, but no ex=
plicit
     reference was found in the text
I think this can be removed. 
  =3D=3D Unused Reference: 'RFC5429' is defined on line 499, but no ex=
plicit
     reference was found in the text
This is related to ereject. If it stays, the document needs to explain interactions (or lack thereof) with ereject. 
  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)
This should be updated.

--------------FEA816075808824E231484E3-- From nobody Mon Oct 1 06:54:50 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F0130DFA for ; Mon, 1 Oct 2018 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=eVNOLlay; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A46gfycp 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 wfWYD1ysZeCu for ; Mon, 1 Oct 2018 06:54:46 -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 6B01F130DDC for ; Mon, 1 Oct 2018 06:54:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 275FC21F73 for ; Mon, 1 Oct 2018 09:54:45 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 01 Oct 2018 09:54:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2xCQPgmIL6wy8QBE7ifk2zSYbjWkoGl/8GAlwNkgY GM=; b=eVNOLlay5EFHdgfALdAkKnRv7Bj1VCJr6nB8q40zB8wx8MugItZAAxtpZ qHxDJyqtB393Jqem5Poy+cVvjF8u8qQwl1DuGE/NTbi9wb5R08qs6L0e5ecpPF66 0TI5lCH41JS+wgiyJEHUSIcMU3+LKTi0/0qgK+hPgOAYVUkCCerN4cO9FYn1MBNu 3bHet6cfJpCBVOmjh6IeXdKQxqBGR+6SBU9aDVBlv0tYdPkDsNBQMBB9MWZPOJ7A 3hCudCcaZD0Wx4F3M+dspEF/rhLw13UFhEiRMRTg5wIJJ4tmooEto6nLXGq+jCro bRhFAcFQ8o+bXOthl8nDfsTAiDezw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2xCQPgmIL6wy8QBE7ifk2zSYbjWkoGl/8GAlwNkgY GM=; b=A46gfycpKpbC7Qa39uINIXDXx0x5YPGDdsZaTUx3SMiq5qLmO9doFc6Tb pxrVvndha0NZwgwFNd0EUfECDgBidfH/Wr1Uc7gj65Ps7WA4HbuQR+vjSGX9MmvJ dExq0naLOXGanWHxqdrBQz2CmCxkaDN75bCeqQ9jUxZQdEuDDtDfDYNKGvJCNi3i AY69kYs5G2e3nuCJl6O/cEVyeLvcEM7LLOIoUluO/j5rFkyfXsp8JY8w5c3Wey8o FWQpa1W0kM1Ij1RQVaKWbzfr6/WZsnBwHY8rJsNyBmwa9p0iG43r/HCyb0iVzeNq a0HMXsk/W35KoHW+DUyNdsf1KvZhA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C531DE688; Mon, 1 Oct 2018 09:54:44 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-543-gf673e33-fmstable-20181001v1 X-Me-Personality: 56629417 In-Reply-To: References: <153662523769.16137.7151778749740462039@ietfa.amsl.com> <2018092911370230091886@cnnic.cn> Date: Mon, 01 Oct 2018 09:54:43 -0400 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=ded5f0901f8441e090070b7bc5ede4a1 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-05.txt 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, 01 Oct 2018 13:54:49 -0000 --ded5f0901f8441e090070b7bc5ede4a1 Content-Type: text/plain Ken is on holiday for a couple of days, so I expect we'll go through this when he's back. On Mon, Oct 1, 2018, at 23:45, Alexey Melnikov wrote: > On 29/09/2018 04:38, Jiankang Yao wrote: >> Dear authors, >> >> I am preparing for the shepherd write-up. >> >> Could you kindly address the following issues and update a new version? Thanks. >> >> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-extra-sieve-fcc-05.txt >> >> >> ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document updates RFC5435, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5230, but the abstract doesn't seem to mention this, which it should. > Right, the Abstract should have a sentence or 2 about RFCs updated, ideally listing what was updated. This should enable readers to decide whether they need to read the rest of the document. > > >> Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 524 == Missing Reference: 'FCC' is mentioned on line 196, but not defined -- Looks like a reference, but probably isn't: '2' on line 526 -- Looks like a reference, but probably isn't: '3' on line 528 -- Looks like a reference, but probably isn't: '4' on line 530 > I don't think anything needs to be done about the above, these are just false warnings from the ID-nits. > > >> == Unused Reference: 'RFC5321' is defined on line 495, but no explicit reference was found in the text > I think this can be removed. > >> == Unused Reference: 'RFC5429' is defined on line 499, but no explicit reference was found in the text > This is related to ereject. If it stays, the document needs to explain interactions (or lack thereof) with ereject. > >> ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) > This should be updated. > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --ded5f0901f8441e090070b7bc5ede4a1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Ken is on holiday for a couple of days, so I expect w= e'll go through this when he's back.

On Mon, Oct 1, 2018,= at 23:45, Alexey Melnikov wrote:

On 29/09/2018 04:38, Jiankang Yao wrote:

Dear authors,
 
  I am preparing = for the shepherd write-up.
 
 &nbs= p;Could you kindly address the following issues and update a new version? Thanks. 
 
 
 
  ** There is 1 instance of too long lines in the=
 document, the longest one
     being 2 characters in excess of 72.

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

  -- The draft header indicates that this document updates RFC5230, but =
the
     abstract doesn't seem to mention this, which it should.
Right, the Abstract should = have a sentence or 2 about RFCs updated, ideally listing what was updated. This should enable readers to decide whether they need to read the rest of the document. 
= 


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

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

  -- Looks like a reference, but probably isn't: '1' on line 524

  =3D=3D Missing Reference: 'FCC' is mentioned on line 196, but not defi=
ned

  -- Looks like a reference, but probably isn't: '2' on line 526

  -- Looks like a reference, but probably isn't: '3' on line 528

  -- Looks like a reference, but probably isn't: '4' on line 530

I don't think anything needs to be done about th= e above, these are just false warnings from the ID-nits.



  =3D=3D Unused Reference: 'RFC5321' is defined on line=
 495, but no explicit
     reference was found in the text
I think this can be removed.

  =3D=3D Unused Reference: 'RFC5429' is defined on line=
 499, but no explicit
     reference was found in the text
This is related to ereject. If it stays, the = document needs to explain interactions (or lack thereof) with ereject.

  ** Obsolete normative reference: RFC 4234 (Obsoleted=
 by RFC 5234)
This should be updated.
=

____________= ___________________________________
Extra mailing list
=
Extra@ietf.org
https://www.ietf.org/mailman/lis= tinfo/extra


--=
  Bron Gondwana, CEO, FastMail P= ty Ltd
  brong@fastmailteam.com


--ded5f0901f8441e090070b7bc5ede4a1-- From nobody Mon Oct 1 08:35:12 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACEB130DD0; Mon, 1 Oct 2018 08:35:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153840810411.21662.2030881937158907879@ietfa.amsl.com> Date: Mon, 01 Oct 2018 08:35:04 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-sieve-fcc-06.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, 01 Oct 2018 15:35:05 -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 : Sieve Extension: File Carbon Copy (Fcc) Authors : Kenneth Murchison Bron Gondwana Filename : draft-ietf-extra-sieve-fcc-06.txt Pages : 13 Date : 2018-10-01 Abstract: The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-sieve-fcc-06 https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-fcc-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-sieve-fcc-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 1 17:06:16 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2E51274D0; Mon, 1 Oct 2018 17:06:08 -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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153843876860.22428.5141613249071544159@ietfa.amsl.com> Date: Mon, 01 Oct 2018 17:06:08 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-replace-01.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: Tue, 02 Oct 2018 00:06:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP REPLACE Extension Author : Stuart Brandt Filename : draft-ietf-extra-imap-replace-01.txt Pages : 11 Date : 2018-10-01 Abstract: This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-replace-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-replace-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-replace-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 1 17:09:23 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743D71274D0 for ; Mon, 1 Oct 2018 17:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrkTV7LCySas for ; Mon, 1 Oct 2018 17:09:18 -0700 (PDT) Received: from sonic306-4.consmr.mail.bf2.yahoo.com (sonic306-4.consmr.mail.bf2.yahoo.com [74.6.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA1D124C04 for ; Mon, 1 Oct 2018 17:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1538438957; bh=jW1VmsqchP0kjsjFgLBhN24snEOGP5Tef1OMP2+WL5Q=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=dP5NSI5dw16xAI7AkfIF1THvDrSvFX8Zw+bkYnXZftTaKilUEBjhKguBjbnhxPBtnlaceZSjZHX/oLkfZbsycGshRc6XJoOuxdjDGVqjnR1itNjNQ/GfH31zRbh/gh2kYNnYGVCrNdtb57LhBdiO3MX3Y0WBUyxgdtweNfmORldsh/deg9Sh0ToRGGXdGKMskn/uvCIF3TBLFg2jUltGjjDsg1ZIyvJUoAphUBy/M6O59KmBIK41vDCyGewblgqdBQGbGYA0z12mTvLpINBk1/CXd+VVHOCQXSyuz/VkswxdidxO/pF009XdOGmysLl8x1uQ3Yod6gw1N/DvV9iX4Q== X-YMail-OSG: 32pzxx0VM1lTsPfuAhYCfTCkT_KSPth1Lz5Lp6P5_KEDMEsSjxWu3uXjGVOtSWR uxxFBGi8gO5eUZX0biVgmm97XB3cw_KZkbfKJfiP54ljGgqO67Kf6eJW1IDQHJqpHdkVafuOXb7Y J2ubM5IE1uACkyRu1gFmWrkNX2oJSwknyNal23qxUkdu3cVLDjifobYILBIMvx9TzL_tWrS8qa9d l.HdhRgu0Ta26iRKsxTrJtS.joC50iwbv3YXEej9boaFEbElnLm0YbS4U9GIgtFEbHS2QcZzra.j NgfvnRbnP0UEmHjmkws8mOe.8gjn4CHZh6oLdlc1YliKywmqlbOhx9Ue8Y4b7WbCzZwYZw.3Y4ML cCIT_Ji_cQI5v.ebnsFUPGN5LlxMtDQnLnfd9OCkp9.18N3t94nGD8q1.Q7IRO94YWMHdkuoPP8z QB4c1Xuvcaz_X7cYVm6kiPelPSmhrLJdULVA2gTcFFo.nOnhOJxjmejWYP_0Jv_dh5_ryxY1HAt2 6xYOA0J_TLJZbQ5riweoQn1MypmTjuN9Mds_3YeubeNXBifMeK9FIsf1_tuQzAWIN66q4oWyjG99 wX0LUGjnxJLm8L08BwYCXeIhdqQrOAg.vgadeAHlRevgtVTo2J9lvmoq0VRggbx48D4A.ShR3_EU MrvQymOzqtQHB4.8p5kGIrrUdFnr8WEl2SoD_eK50V542D5MhDtgu7AABWy2Q7pfHN2xJbKnY82E 1txg2W991jzYdGbRH8BYZlFmHqBv_8l1d8DobwH_WBiAD6ojBeNl.qWO0LSmCQVgZM9KyXa7nTuL LrCqkIoslC7oJGhNzh6Xm1u8R5EJ9gy47eT1Zv.c9zc4zurUXriYPRWt6hSUwnf01wMvr6cMwMmd mhck9h3oYlvUtUILIpqqKRi7T1wFU3XhBENDL6rCNw.rhHbDhstGSKBlgth3hOakQvgasTnwwecS 5xAkc.NU8c1wKyPkrj4YE6DTFhWJU7j5F7.HGBZ_XPQPYtEHSvt6rh7AbMMo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 2 Oct 2018 00:09:17 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e433aa0bc7340166d0c57d82122c5d21 for ; Tue, 02 Oct 2018 00:09:14 +0000 (UTC) Message-ID: <5BB2B718.4080001@aol.com> Date: Mon, 01 Oct 2018 20:08:56 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: extra@ietf.org References: <7c4a8162-e29e-bddb-1b9a-8d4ec6b623dc@isode.com> In-Reply-To: <7c4a8162-e29e-bddb-1b9a-8d4ec6b623dc@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] AD review of draft-ietf-extra-imap-replace-00.txt 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, 02 Oct 2018 00:09:21 -0000 Alexey - Thanks for the valuable feedback. I agree with all. I've made the necessary changes along with an update to reflect OBJECTID's status change to RFC8474. - Stuart On 10/1/2018 8:43 AM, Alexey Melnikov wrote: > Hi, > > The document is generally in a good state and covers lots of tricky > interactions with other extensions. But I have a small list of minor > issues/nits that I would like to discuss: > > > 3.4. Semantics of REPLACE and UID REPLACE > > While it may be common for the named mailbox argument to match the > selected mailbox for the common use case of replacing a draft, the > REPLACE extension intentionally does not require the two to be the > same. As an example, it's possible to use the REPLACE command to > replace a message in the \Drafts special-use mailbox with a message > in the \Sent special-use mailbox following message submission. > > I think this needs an informative reference to the Special Use RFC to > help readers not familiar with the term. > > 4.3. RFC 4315, UIDPLUS > > Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send > APPENDUID in response to a UID REPLACE command. For additional > information see section 3 of RFC4315. Servers implementing REPLACE > and UIDPLUS are also advised to send the APPENDUID response code in > an untagged OK before sending the EXPUNGE or replaced responses. > > All examples are using: > > * APPENDUID ... > > > instead of > > * OK [APPENDUID ...] some text > > What is in the draft is syntactically invalid, as it is not a response > code. > > (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS > specification means that the client first receives an EXPUNGE for a > message and afterwards APPENDUID for the new message. It can be > unnecessarily difficult to process that sequence usefully.) > > 5. Formal Syntax > > capability =/ "REPLACE" > > command-select =/ replace > replace = "REPLACE" SP seq-number SP mailbox append-message > > RFC 4466 allows for multiple "append-message", if MULTIAPPEND extension > is present. I think your document should say explicitly that REPLACE is > not affected by MULTIAPPEND. > > uid = "UID" SP (copy / fetch/ search / store / move / > replace) > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Tue Oct 2 06:14:33 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E5126DBF; Tue, 2 Oct 2018 06:14:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153848607177.5191.3859009122711894076.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2018 06:14:31 -0700 Archived-At: Subject: [Extra] Last Call: (IMAP REPLACE Extension) to Proposed Standard 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, 02 Oct 2018 13:14:32 -0000 The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'IMAP REPLACE Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-10-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 3 09:27:16 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A3E131323; Wed, 3 Oct 2018 09:27:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jiankang Yao To: X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Cc: extra@ietf.org, yaojk@cnnic.cn, iesg-secretary@ietf.org, Jiankang Yao , extra-chairs@ietf.org Message-ID: <153858403521.9010.15857740233495004111.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2018 09:27:15 -0700 Archived-At: Subject: [Extra] Publication has been requested for draft-ietf-extra-sieve-fcc-06 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 Oct 2018 16:27:15 -0000 Jiankang Yao has requested publication of draft-ietf-extra-sieve-fcc-06 as Proposed Standard on behalf of the EXTRA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ From nobody Fri Oct 5 06:45:34 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93EF130DC6; Fri, 5 Oct 2018 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogCLmGMtnuNX; Fri, 5 Oct 2018 06:45:25 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73612F1A2; Fri, 5 Oct 2018 06:45:22 -0700 (PDT) Received: from [192.168.1.103] (lab.inertia-technology.com [217.119.239.130]) by mail.dovecot.fi (Postfix) with ESMTPSA id 4BB4428D104; Fri, 5 Oct 2018 16:45:11 +0300 (EEST) To: Benjamin Kaduk , The IESG Cc: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-savedate@ietf.org, extra-chairs@ietf.org, Alexey Melnikov References: <153788471329.4728.13625249224205071592.idtracker@ietfa.amsl.com> From: Stephan Bosch Message-ID: <2fb4771e-1165-944b-29d4-de9868429b64@dovecot.fi> Date: Fri, 5 Oct 2018 15:45:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153788471329.4728.13625249224205071592.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-savedate-01: (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: Fri, 05 Oct 2018 13:45:27 -0000 Hello Mr. Kaduk, Op 25-9-2018 om 16:11 schreef Benjamin Kaduk: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-imap-savedate-01: 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-savedate/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > to permanently remove (expunge) all messages in that Trash mailbox > deleted before a certain time (e.g. a configurable expiration > > nit: comma after "e.g.". OK. > > Section 4.2 > > Should there be an example for the 'NIL response' case? I don't think that is highly important, but I guess we can add a small example for that. The modified text will then be something like: Example for selected mailbox with SAVEDATE support: C: A101 FETCH 998 (SAVEDATE) S: * 998 FETCH (SAVEDATE "01-Jan-2015 18:50:53 +0100") S: A101 OK Fetch completed. Example for selected mailbox without SAVEDATE support: C: A101 FETCH 123 (SAVEDATE) S: * 123 FETCH (SAVEDATE NIL) S: A101 OK Fetch completed. Kind regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kenttä Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Fri Oct 5 10:49:57 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432BA130E6F; Fri, 5 Oct 2018 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR1D2F6_ak4M; Fri, 5 Oct 2018 10:49:46 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 E46D4130DCF; Fri, 5 Oct 2018 10:49:45 -0700 (PDT) X-AuditID: 1209190f-9bbff70000006794-22-5bb7a4341110 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E2.78.26516.434A7BB5; Fri, 5 Oct 2018 13:49:41 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w95HnZBE026990; Fri, 5 Oct 2018 13:49:36 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w95HnSYx016856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2018 13:49:33 -0400 Date: Fri, 5 Oct 2018 12:49:28 -0500 From: Benjamin Kaduk To: Stephan Bosch Cc: The IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-savedate@ietf.org, extra-chairs@ietf.org, Alexey Melnikov Message-ID: <20181005174928.GV56675@kduck.kaduk.org> References: <153788471329.4728.13625249224205071592.idtracker@ietfa.amsl.com> <2fb4771e-1165-944b-29d4-de9868429b64@dovecot.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fb4771e-1165-944b-29d4-de9868429b64@dovecot.fi> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixG6nrmu6ZHu0wcJ1QhYzVhdZ/Dkzn9Xi 5s1HTBazVrYxWfy/2sNsMePPRGaLtSd5HNg9Vv1+z+xx+Xsrk8eSJT+ZPE41GwawRHHZpKTm ZJalFunbJXBlzN+wmLVgp0DFpslTmBsYz/N0MXJySAiYSFyc+Yu1i5GLQ0hgMZPEm9PXoJwN jBL3+26yQThXmCRaWv6zgbSwCKhITLs+hwXEZgOyG7ovM4PYIgI6EmuPTWQBaWAWOMwoMeXV b7AiYYFMiT8LF7OD2LxA+z6e+c8CMbWRUeLHutvMEAlBiZMzn4A1MAtoSdz495Kpi5EDyJaW WP6PAyTMKWAncWnnebAjRAWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3W LU5OzMtLLdI10cvNLNFLTSndxAgKdU5J/h2Mcxq8DzEKcDAq8fA6zN0eLcSaWFZcmXuIUZKD SUmU99GbrdFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHg/VgOV86YkVlalFuXDpKQ5WJTEeSe0 LI4WEkhPLEnNTk0tSC2CycpwcChJ8DotBmoULEpNT61Iy8wpQUgzcXCCDOcBGp4HUsNbXJCY W5yZDpE/xWjM0fb0+gxmjg4QKcSSl5+XKiXOqwJSKgBSmlGaBzcNlK4ksvfXvGIUB3pOmHfV IqAqHmCqg5v3CmgVE9Aq+ZwtIKtKEhFSUg2M3oqXXTeKl/omXg/gZ8hrr14YW1R5cImmzv/X 0/oFvh569HfTBa/mJQk71FPswu3L129urfB8EDildt0nldkzc3bOWnbinfWtSf7zdkkwCMf6 328yVgjr48jjfr/JqOpt0LqcJWVXZ3FblGVM0/iiKvnW9W/h6vKQwu2cO0OZ4u5fU69aeO2j EktxRqKhFnNRcSIAzAZD3zIDAAA= Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-savedate-01: (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: Fri, 05 Oct 2018 17:49:49 -0000 Hi, On Fri, Oct 05, 2018 at 03:45:06PM +0200, Stephan Bosch wrote: > Hello Mr. Kaduk, > > Op 25-9-2018 om 16:11 schreef Benjamin Kaduk: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-extra-imap-savedate-01: 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-savedate/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > to permanently remove (expunge) all messages in that Trash mailbox > > deleted before a certain time (e.g. a configurable expiration > > > > nit: comma after "e.g.". > OK. > > > > > Section 4.2 > > > > Should there be an example for the 'NIL response' case? > > I don't think that is highly important, but I guess we can add a small > example for that. The modified text will then be something like: > > Example for selected mailbox with SAVEDATE support: > > C: A101 FETCH 998 (SAVEDATE) > S: * 998 FETCH (SAVEDATE "01-Jan-2015 18:50:53 +0100") > S: A101 OK Fetch completed. > > Example for selected mailbox without SAVEDATE support: > > C: A101 FETCH 123 (SAVEDATE) > S: * 123 FETCH (SAVEDATE NIL) > S: A101 OK Fetch completed. This was just a question I had while reading, and I'm not sure what the best path is. I promise to not be offended if you leave this example out -- do what you think is best. I do appreciate seeing what the example looks like, even here in mail, though -- thank you! -Benjamin From nobody Fri Oct 12 13:06:14 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE60F130DFC; Fri, 12 Oct 2018 13:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: extra@ietf.org, draft-ietf-extra-imap-replace.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153937476673.29113.3479129914002220994@ietfa.amsl.com> Date: Fri, 12 Oct 2018 13:06:06 -0700 Archived-At: Subject: [Extra] Genart last call review of draft-ietf-extra-imap-replace-01 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, 12 Oct 2018 20:06:07 -0000 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-extra-imap-replace-01 Reviewer: Robert Sparks Review Date: 2018-10-12 IETF LC End Date: 2018-10-16 IESG Telechat date: 2018-10-25 Summary: Ready for publication as a proposed standard, but with nits to consider before publication Consider using: uid =/ replace instead of redefining uid. From nobody Fri Oct 12 15:22:25 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7366E130ECC; Fri, 12 Oct 2018 15:22:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153938292441.29185.9212164925642887501@ietfa.amsl.com> Date: Fri, 12 Oct 2018 15:22:04 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-replace-02.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: Fri, 12 Oct 2018 22:22:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP REPLACE Extension Author : Stuart Brandt Filename : draft-ietf-extra-imap-replace-02.txt Pages : 11 Date : 2018-10-12 Abstract: This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-replace-02 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-replace-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-replace-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 15 18:28:29 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3FD127333 for ; Mon, 15 Oct 2018 18:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTMCQ3Ed_QHF for ; Mon, 15 Oct 2018 18:28:25 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 364251277BB for ; Mon, 15 Oct 2018 18:28:22 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJNjWyPsVbMtAAAA--.1204S2; Tue, 16 Oct 2018 09:28:18 +0800 (CST) Date: Tue, 16 Oct 2018 09:28:17 +0800 From: "Jiankang Yao" To: extra Reply-To: yaojk References: <153616200699.19753.13957702160049989504@ietfa.amsl.com>, <2018092709114637832442@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20181016092756197991174@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart248210664022_=----" X-CM-TRANSID: AQAAf0AJNjWyPsVbMtAAAA--.1204S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KrykKry8Kw4kGrWUGFyrXrb_yoW5JrW8pF W3X34fGrykJ3Z7Kw4kGry2qw1UA34Y9ayrC3ZxKr18Aay5Ga4vyFyxt3yYv3sxJr4rWFs7 Zr10934jvrn5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xv F2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUceHqDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-03.txt 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, 16 Oct 2018 01:28:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart248210664022_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgIFRoZSBXR0xDIGZvciB0aGlzIGRyYWZ0IHdpbGwgZXhwaXJlIHNvb24s IHBscyBraW5kbHkgaGVscCB0byB0YWtlIGEgbG9vayBhdCBpdCBpZiB5b3UgaGF2ZSBub3QgZG9u ZSBpdC4NCg0KDQogIFRoYW5rcy4NCg0KDQoNCg0KSmlhbmthbmcgWWFvDQoNCreivP7Iy6O6IEpp YW5rYW5nIFlhbw0Kt6LLzcqxvOSjuiAyMDE4LTA5LTI3IDA5OjEyDQrK1bz+yMujuiBleHRyYQ0K 1vfM4qO6IFJlOiBbRXh0cmFdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZXh0cmEtc2lldmUtc3Bl Y2lhbC11c2UtMDMudHh0DQoNCkRlYXIgYWxsLA0KDQpHZW50bGUgcmVtaW5kZXIuDQpUaGlzIGRy YWZ0IHdpbGwgYmUgaW4gV0cgbGFzdCBjYWxsIGZvciAzIHdlZWtzLCB3aGljaCBlbmRzIGluIDE4 IE9jdC4uDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQpUaGFua3MgYSBsb3QuDQoNCg0KDQoN CkppYW5rYW5nIFlhbw0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIwMTgtMDktMDUg MjM6NDANClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNDOiBleHRyYQ0KU3ViamVjdDogW0V4 dHJhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWV4dHJhLXNpZXZlLXNwZWNpYWwtdXNlLTAzLnR4 dA0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBFbWFpbCBtYWlsc3RvcmUgYW5kIGVYdGVuc2lvbnMgVG8gUmV2aXNlIG9yIEFtZW5kIFdH IG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFNpZXZlIEVtYWlsIEZp bHRlcmluZzogRGVsaXZlcmluZyB0byBTcGVjaWFsLVVzZSBNYWlsYm94ZXMNCiAgICAgICAgQXV0 aG9yICAgICAgICAgIDogU3RlcGhhbiBCb3NjaA0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1leHRyYS1zaWV2ZS1zcGVjaWFsLXVzZS0wMy50eHQNClBhZ2VzICAgICAgICAgICA6IDkNCkRh dGUgICAgICAgICAgICA6IDIwMTgtMDktMDUNCg0KQWJzdHJhY3Q6DQogICBUaGUgU1BFQ0lBTC1V U0UgY2FwYWJpbGl0eSBvZiB0aGUgSU1BUCBwcm90b2NvbCAoUkZDIDYxNTQpIGFsbG93cw0KICAg Y2xpZW50cyB0byBpZGVudGlmeSBzcGVjaWFsLXVzZSBtYWlsYm94ZXM7IGUuZy4sIHdoZXJlIGRy YWZ0IG9yIHNlbnQNCiAgIG1lc3NhZ2VzIHNob3VsZCBiZSBwdXQuICBUaGlzIHNpbXBsaWZpZXMg Y2xpZW50IGNvbmZpZ3VyYXRpb24uICBJbg0KICAgY29udHJhc3QsIHRoZSBTaWV2ZSBtYWlsIGZp bHRlcmluZyBsYW5ndWFnZSAoUkZDIDUyMjgpIGN1cnJlbnRseSBoYXMNCiAgIG5vIHN1Y2ggY2Fw YWJpbGl0eS4gIFRoaXMgbWVtbyBkZWZpbmVzIGEgU2lldmUgZXh0ZW5zaW9uIHRoYXQgZmlsbHMN CiAgIHRoaXMgZ2FwOiBpdCBhZGRzIGEgdGVzdCBmb3IgY2hlY2tpbmcgd2hldGhlciBhIHNwZWNp YWwtdXNlIGF0dHJpYnV0ZQ0KICAgaXMgYXNzaWduZWQgZm9yIGEgcGFydGljdWxhciBtYWlsYm94 IG9yIGFueSBtYWlsYm94LCBhbmQgaXQgYWRkcyB0aGUNCiAgIGFiaWxpdHkgdG8gZmlsZSBtZXNz YWdlcyBpbnRvIGFuIGFub255bW91cyBtYWlsYm94IHRoYXQgaGFzIGENCiAgIHBhcnRpY3VsYXIg c3BlY2lhbC11c2UgYXR0cmlidXRlIGFzc2lnbmVkLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1zcGVjaWFsLXVzZS8NCg0KVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZXh0cmEtc2lldmUtc3BlY2lhbC11c2UtMDMNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1leHRyYS1zaWV2ZS1zcGVj aWFsLXVzZS0wMw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1leHRy YS1zaWV2ZS1zcGVjaWFsLXVzZS0wMw0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHRyYSBtYWlsaW5nIGxpc3QN CkV4dHJhQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2V4 dHJh ------=_001_NextPart248210664022_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear all,
 
   The WGLC for this draft will expire soon, pls kindly hel= p to=20 take a look at it if you have not done it.
 
 
  Thanks.
 
Jiankang Yao
 
=B7=A2=BC=FE=C8=CB=A3=BA Jiankang Yao
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2018-09-27 09:12
=CA=D5=BC=FE=C8=CB=A3=BA extra
=D6=F7=CC=E2=A3=BA Re: [Extra] I-D Action:=20 draft-ietf-extra-sieve-special-use-03.txt
 
Dear all,
 
Gentle reminder.
This draft will be in WG last call=  for 3 weeks, which ends in 18 Oct= ..
Any comments are welcome.
Thanks a lot.
 
Jiankang Yao
 
From: internet-drafts
Date: 2018-09-05 23:40
To: i-d-announce@ietf.org
CC: extra
Subject: [Extra] I-D Action:=20 draft-ietf-extra-sieve-special-use-03.txt
 
A New Internet-Draft is available from = the on-line Internet-Drafts directories.
This draft is a work item of the&n= bsp;Email mailstore and eXtensions To Revise = ;or Amend WG of the IETF.
 
        Title  &nbs= p;        : Sieve Email&= nbsp;Filtering: Delivering to Special-Use Mailboxes
        Author  &nb= sp;       : Stephan Bosch
Filename        : draft-= ietf-extra-sieve-special-use-03.txt
Pages          &nbs= p;: 9
Date           = ; : 2018-09-05
 
Abstract:
   The SPECIAL-USE capability of t= he IMAP protocol (RFC 6154) allows
   clients to identify special-use = ;mailboxes; e.g., where draft or sent
   messages should be put.  T= his simplifies client configuration.  In
   contrast, the Sieve mail filter= ing language (RFC 5228) currently has
   no such capability.  This = memo defines a Sieve extension that fills
   this gap: it adds a test&n= bsp;for checking whether a special-use attribute<= /DIV>
   is assigned for a particular&nb= sp;mailbox or any mailbox, and it adds = the
   ability to file messages into&n= bsp;an anonymous mailbox that has a
   particular special-use attribute ass= igned.
 
 
The IETF datatracker status page for th= is draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/<= /DIV>
 
There are also htmlized versions available&n= bsp;at:
https://tools.ietf.org/html/draft-ietf-extra-sieve-special-use-03
https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-special-= use-03
 
A diff from the previous version is&nbs= p;available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-extra-sieve-special-us= e-03
 
 
Please note that it may take a cou= ple of minutes from the time of submiss= ion
until the htmlized version and diff are=  available at tools.ietf.org.
 
Internet-Drafts are also available by anonym= ous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra
------=_001_NextPart248210664022_=------ From nobody Tue Oct 16 09:36:05 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80743130DEE for ; Tue, 16 Oct 2018 09:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cyMOE6HJ_PH for ; Tue, 16 Oct 2018 09:36:01 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3782F130DFD for ; Tue, 16 Oct 2018 09:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1539707760; d=isode.com; s=june2016; i=@isode.com; bh=a9E1YJdHiYkhFT9uZVc/B6PzPIAMnUMH7Xb5OMao2UI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TpRIf2G3X68t/+f2tGEKHlND/YBT9nA7zShLiwGSYQc2jH8eM78/8yqO8GnmJismHbQXM7 XHf3RR9m7MkFchtGLILhAFhCOcMYJnDxDU35BCd9MEw3EUSjLUsXCZkQCgZjw80DFZwA5V lqnzx43lm8n4N87QsK+laZEVn86HRFI=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 16 Oct 2018 17:36:00 +0100 To: extra From: Alexey Melnikov Message-ID: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com> Date: Tue, 16 Oct 2018 17:35:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt 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, 16 Oct 2018 16:36:04 -0000 Hi, The document is generally fine and contains enough details to implement,=20 but I found a few minor issues: 3.=C2=A0 Tagged Argument ":fcc" =C2=A0=C2=A0 For convenience, the "FCC" syntax element is defined here usin= g ABNF =C2=A0=C2=A0 [RFC5234] so that it can be augmented by other extensions. Actually, you are not using ABNF, you are using Sieve syntax. =C2=A0=C2=A0 FCC =3D ":fcc" Later in the same section: =C2=A0=C2=A0 If the specified mailbox doesn't exist, the =C2=A0=C2=A0 implementation MAY treat it as an error, create the mailbox, o= r file =C2=A0=C2=A0 the message into an implementation-defined mailbox. Allowing for either an error or filing into different mailboxes is going to make scripts non portable, considering that there is no way to test in a Sieve script which exact behaviour is supported. Also, why is it Ok to have all these different choices, which will=20 potentially confuse users? I would like to either have a way to test for different=20 behaviour or have some explanation in the document why all of the choices are=20 acceptable. In 3.1: =C2=A0=C2=A0 o=C2=A0 Subject: The Subject header field is OPTIONAL and MAY = be generated =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as follows: The subject is set to the charac= ters "Fcc: " followed =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the subject of the message being processe= d by the Sieve =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interpreter. Please make it clear that subject encodings used by RFC 2231 are Ok to=20 be used, so if an implementation does prefix matching, this is done after decoding. In 3.2: =C2=A0=C2=A0 Vacation auto-reply messages are MIME-compliant and MAY This is not an implementation choice and is not a compliance statement, so use of RFC 2119 MAY is not appropriate here. So please use either "may" or "can" here. There is similar text in Section 3.3. =C2=A0=C2=A0 be filed into =C2=A0=C2=A0 the target mailbox without modification. In 3.3.1: =C2=A0=C2=A0 Example: =C2=A0=C2=A0 require ["enotify", "fcc"]; =C2=A0=C2=A0 if notify_method_capability "xmpp:" "Fcc" "yes" { Is "fcc" case insensitive? (I didn't check). =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 notify :fcc "INBOX.Sent" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 :message "You got mail" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "xmpp:ken@example.com?message;subject=3DSIEVE"; =C2=A0=C2=A0 } else { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 notify :fcc "INBOX.Sent" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 :message "You got mail!" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "mailto:ken@example.com"; =C2=A0=C2=A0 } In 3.5: 3.5.=C2=A0 Interaction with Fileinto Extensions =C2=A0=C2=A0 The "fcc" extension can be used with some tagged arguments def= ined in =C2=A0=C2=A0 extensions to the "fileinto" action. This got me initially very confused and I was confused till section 3.5.4, until I saw the example. I thought you were defining use of :fcc with=20 "fileinto", but you are actually allowing use of some "fileinto" tagged arguments=20 together with ":fcc" in other actions. So maybe rephrase this like this: =C2=A0=C2=A0 This document defines how some tagged arguments defined in =C2=A0=C2=A0 extensions to the "fileinto" action can be used together with = ":fcc" =C2=A0=C2=A0 used in other actions. Or something like that. =C2=A0=C2=A0 The sections below describe its =C2=A0=C2=A0 interaction with currently defined extensions.=C2=A0 Tagged ar= guments in =C2=A0=C2=A0 future extensions to the "fileinto" command should describe th= eir =C2=A0=C2=A0 interaction with ":fcc", if any. In 3.5.1: =C2=A0=C2=A0 FCC =3D/ [":flags" ] I think use of "=3D/" is wrong here. You are not defining another=20 alternative to ":fcc", you are allowing some tags to be used together with it. I suggest you either define a separate production from FCC or you just use Sieve syntax: =C2=A0=C2=A0 ":flags" =C2=A0and describe the rest in text. (Similar issue in 3.5.2 and 3.5.3) Best Regards, Alexey From nobody Thu Oct 18 10:52:41 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90A0130DC6; Thu, 18 Oct 2018 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxZx_wTzVXtw; Thu, 18 Oct 2018 10:52:37 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C3C2E130DC0; Thu, 18 Oct 2018 10:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1539885156; d=isode.com; s=june2016; i=@isode.com; bh=s0+o8nT1yO4qmNzBPM0QLq+0g5x3wCuV5l4/7ayO15s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=m4tFV1UnhSZd/Vge35L+UcJ+jlH9T8pfsNBJRh7JA5DpD/D6H3O5+gwTKX4SfSS3hRHQQj LUs7OUc86fzRuJ6B/LaRwC9DlmaKxhVbtDP2RGeqdVj/0sBRa/mT3keVxMlYPuWwpik3uI vinMIvg3d+z5rMunrBJD35P2Q5asSOo=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Oct 2018 18:52:35 +0100 References: <5BC59599.3000501@ninebynine.org> To: extra@ietf.org, ietf-smtp From: Alexey Melnikov Openpgp: preference=signencrypt X-Forwarded-Message-Id: <5BC59599.3000501@ninebynine.org> Message-ID: Date: Thu, 18 Oct 2018 18:52:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: <5BC59599.3000501@ninebynine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Extra] Fwd: [Ietf-message-headers] Registration update: Content-MD5 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, 18 Oct 2018 17:52:40 -0000 Hi, (Sorry for cross posting) Is there any interest in deprecating use of Content-MD5 for email? Thank you, Alexey -------- Forwarded Message -------- Subject: Re: [Ietf-message-headers] Registration update: Content-MD5 Date: Tue, 16 Oct 2018 08:39:05 +0100 From: Graham Klyne To: Mark Nottingham , ietf-message-headers@ietf.org Just to be clear, this is just use with HTTP that's being obsoleted? It's also registered as a MIME header. The reason for obsoleting per RFC7231 appears to be inconsistent HTTP implementations, so I guess that doesn't apply to MIME/email? #g -- On 15/10/2018 05:30, Mark Nottingham wrote: > As discussed on the HTTP Working Group mailing list [1], we'd like to update the registry entry for Content-MD5 in HTTP. > > Proposed template: > > Header name: Content-MD5 > Protocol: http > Status: obsoleted > Reference: RFC2616 (obsoleted by RFC7231, Appendix B) > > Cheers, > > 1. https://www.w3.org/mid/C94E5914-F5F0-46D0-BABB-D42EE45DF10D@mnot.net > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Ietf-message-headers mailing list > Ietf-message-headers@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-message-headers > _______________________________________________ Ietf-message-headers mailing list Ietf-message-headers@ietf.org https://www.ietf.org/mailman/listinfo/ietf-message-headers From nobody Fri Oct 19 02:30:11 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682EB130E54 for ; Fri, 19 Oct 2018 02:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HTokln7q; dkim=pass (1536-bit key) header.d=taugh.com header.b=Xkxwqeed 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 6ntwDAGpiCbU for ; Fri, 19 Oct 2018 02:30:08 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E6CE5130E4B for ; Fri, 19 Oct 2018 02:30:07 -0700 (PDT) Received: (qmail 52176 invoked from network); 19 Oct 2018 09:30:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cbcb.5bc9a41c.k1810; bh=NxAaLTa4QCoRGOFQQ95IkQm4NTSHY1juUf37Dv0Rv3c=; b=HTokln7qhGYSZIDi+tPF2f8JkSByMCo67D6Oy46Uzqzparo+bBgi0f4TrX8OY3FzX9WBeB2uDAuiKwUbe4QOmADbCpwG4oYKpTGg8drJMtG2z5Ivi/hMcPyXXg+atp8gdP14Pg5yJJsLCqHLKbltmru2UHA0ydW+d/8YJXfhmOHvVCqtn4tuD4nxQQ8Hr5RYA2SIrmSIZtP3TZsEBnxh2tIEGQqtS5G+MNJG6YECS2ms9Rg5TGapjYXPO/HlFVxz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cbcb.5bc9a41c.k1810; bh=NxAaLTa4QCoRGOFQQ95IkQm4NTSHY1juUf37Dv0Rv3c=; b=XkxwqeedKQwjY2l591MCFxuhToqK5B/Fqr1I0q6bx5CsGjZ9fWXCUYPTElY9juGojA3Tz0fSqCX0wgLPnaI2aKseKwjZL/scOf8aiOE5DgC7xpMkG5zmBuChyCVLiwgj2sJMTcY9QHb3/NfQavzSMogoQDba+dIXT+WePSLyoeJQFQmod1+6CQXrJN6hgcvd5L8eOoRZGDSypwe8v2+2bHTFSLfPwn+JBwPpjESpWGREnYaN+ZNJodkaAXhuiKgE Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 Oct 2018 09:30:04 -0000 Received: by ary.local (Postfix, from userid 501) id 8768E20070B80F; Fri, 19 Oct 2018 11:30:02 +0200 (CEST) Date: 19 Oct 2018 11:30:02 +0200 Message-Id: <20181019093003.8768E20070B80F@ary.local> From: "John Levine" To: extra@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Extra] Fwd: [Ietf-message-headers] Registration update: Content-MD5 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: Fri, 19 Oct 2018 09:30:09 -0000 In article you write: >Hi, >(Sorry for cross posting) > >Is there any interest in deprecating use of Content-MD5 for email? I know it's defined in RFC 1864 but I've never seen in in a mail message. That RFC suggests it's useful for message/external-body MIME parts, but I haven't seen any of those in mail lately either. I gather they may be used in SIP. From nobody Fri Oct 19 07:39:42 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E25130EF3; Fri, 19 Oct 2018 07:39:41 -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.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <153995998190.6461.11044184895707534290@ietfa.amsl.com> Date: Fri, 19 Oct 2018 07:39:41 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-02.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: Fri, 19 Oct 2018 14:39:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-02.txt Pages : 127 Date : 2018-10-19 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-02 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 19 07:47:41 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D1C130EEA for ; Fri, 19 Oct 2018 07:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg3ZmHHwnz1J for ; Fri, 19 Oct 2018 07:47:38 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id DF24012958B for ; Fri, 19 Oct 2018 07:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1539960457; d=isode.com; s=june2016; i=@isode.com; bh=bBVTY1GS1L1NAOT0ysu6bXz9MUUQx3a89pB7fJBxuiQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lorNWtAA6/Lv0ieFDbhV2ocNeo87wSONBkW9fIXN3eADLZSTbDdWgPCHDLbhvdIP7D69yx N15r2djCvOdwwA+PzFmeuLW54NVSHDQnDQIShebTItPAVEmwStKsi/y6C9MXrCS9Un6u9R tTq2ZWXU9p6F1ti+FxKEi77gy5MwYlk=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 19 Oct 2018 15:47:36 +0100 To: extra@ietf.org References: <153995998190.6461.11044184895707534290@ietfa.amsl.com> From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: <244661d9-28a0-94ae-38bd-a4c8b3ae8234@isode.com> Date: Fri, 19 Oct 2018 15:47:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: <153995998190.6461.11044184895707534290@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-02.txt 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: Fri, 19 Oct 2018 14:47:40 -0000 On 19/10/2018 15:39, internet-drafts@ietf.org wrote: > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-02 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-02 This version includes support for LITERAL- and UTF-8 messages/mailbox names (contribution by Chris Newman). From nobody Fri Oct 19 11:59:42 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAFE1310DB; Fri, 19 Oct 2018 11:56:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: extra@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539088.6592.1432867173737315841.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:30 -0700 Archived-At: Subject: [Extra] extra - Requested session has been scheduled for IETF 103 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, 19 Oct 2018 18:56:38 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. extra Session 1 (1:30 requested) Thursday, 8 November 2018, Afternoon Session I 1350-1550 Room Name: Boromphimarn 3 size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/extra.ics Request Information: --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dispatch dcrup doh uta dmarc Second Priority: oauth tls calext People who must be present: Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One chair is not available on Monday. Please schedule later in the week. It would be good to hold this meeting directly before/after JMAP, since many people attend both. --------------------------------------------------------- From nobody Sat Oct 20 14:19:14 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403DF12D4E6; Sat, 20 Oct 2018 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNtbVOPNSoF2; Sat, 20 Oct 2018 14:19:05 -0700 (PDT) Received: from mauve.mrochek.com (unknown [66.159.242.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 B7557130DD8; Sat, 20 Oct 2018 14:19:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QYO1VLC8SW00EYN6@mauve.mrochek.com>; Sat, 20 Oct 2018 14:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1540070041; bh=958WMkV7nDFX6Glll6BaxVnlujmgA+UrommJ2rnC9KY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Z8r4Q138ewBTi0psN1ZiV0EG7vkcGyYixbA+0K6CqYN8dRmat6vVDW62qaxG0vUp8 IB4OThx8zbG7NHzaOp61pnRPhEIHTcKE+kpLhbo6jfM1kZaGneRPrk9qpDtetxuDK+ u7IQTy0yq22Z7mX0VkHspUof7byz40WFLvTH1eDA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QYM8BK7VLS00BGSX@mauve.mrochek.com>; Sat, 20 Oct 2018 14:13:59 -0700 (PDT) Cc: extra@ietf.org, ietf-smtp Message-id: <01QYO1VJX96600BGSX@mauve.mrochek.com> Date: Sat, 20 Oct 2018 14:08:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 18 Oct 2018 18:52:36 +0100" References: <5BC59599.3000501@ninebynine.org> To: Alexey Melnikov Archived-At: Subject: Re: [Extra] Fwd: [Ietf-message-headers] Registration update: Content-MD5 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: Sat, 20 Oct 2018 21:19:07 -0000 > (Sorry for cross posting) > Is there any interest in deprecating use of Content-MD5 for email? Seems like a lot of effort for no real again. The few implementations I've seen do interoperate, so AFAIK that's not a reason for deprecating it. Of course MD5 isn't cryptographically strong, but it's fine for a checksum, which is what RFC 1864 says it is for. (At the time the RFC was written I argued for extending its use to crypographic applications and in the process moving the algorithm from the name to the value to provide for algorithm flexibility, but there wasn't sufficient interest.) Ned > Thank you, > Alexey > -------- Forwarded Message -------- > Subject: Re: [Ietf-message-headers] Registration update: Content-MD5 > Date: Tue, 16 Oct 2018 08:39:05 +0100 > From: Graham Klyne > To: Mark Nottingham , ietf-message-headers@ietf.org > Just to be clear, this is just use with HTTP that's being obsoleted? > It's also registered as a MIME header. The reason for obsoleting per > RFC7231 appears to be inconsistent HTTP implementations, so I guess that > doesn't apply to MIME/email? > #g > -- > On 15/10/2018 05:30, Mark Nottingham wrote: > > As discussed on the HTTP Working Group mailing list [1], we'd like to update the registry entry for Content-MD5 in HTTP. > > > > Proposed template: > > > > Header name: Content-MD5 > > Protocol: http > > Status: obsoleted > > Reference: RFC2616 (obsoleted by RFC7231, Appendix B) > > > > Cheers, > > > > 1. https://www.w3.org/mid/C94E5914-F5F0-46D0-BABB-D42EE45DF10D@mnot.net > > > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ > > Ietf-message-headers mailing list > > Ietf-message-headers@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-message-headers > > > _______________________________________________ > Ietf-message-headers mailing list > Ietf-message-headers@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-message-headers > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Sat Oct 20 14:28:33 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B3130E0C; Sat, 20 Oct 2018 14:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ufkm7YBjM06l; Sat, 20 Oct 2018 14:28:29 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA698130EC0; Sat, 20 Oct 2018 14:28:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gDynK-000H26-CV; Sat, 20 Oct 2018 17:28:26 -0400 Date: Sat, 20 Oct 2018 17:28:19 -0400 From: John C Klensin To: Ned Freed , Alexey Melnikov cc: extra@ietf.org, ietf-smtp Message-ID: <2D6E95CB12593FD1605A8DBE@PSB> In-Reply-To: <01QYO1VJX96600BGSX@mauve.mrochek.com> References: <5BC59599.3000501@ninebynine.org> <01QYO1VJX96600BGSX@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Extra] [ietf-smtp] Fwd: [Ietf-message-headers] Registration update: Content-MD5 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: Sat, 20 Oct 2018 21:28:32 -0000 FWIW, +1 john --On Saturday, October 20, 2018 14:08 -0700 Ned Freed wrote: >> (Sorry for cross posting) > >> Is there any interest in deprecating use of Content-MD5 for >> email? > > Seems like a lot of effort for no real again. > > The few implementations I've seen do interoperate, so AFAIK > that's not a reason for deprecating it. > > Of course MD5 isn't cryptographically strong, but it's fine > for a checksum, which is what RFC 1864 says it is for. (At > the time the RFC was written I argued for extending its use to > crypographic applications and in the process moving the > algorithm from the name to the value to provide for algorithm > flexibility, but there wasn't sufficient interest.) > > Ned > > >> Thank you, >> Alexey > >> -------- Forwarded Message -------- >> Subject: Re: [Ietf-message-headers] Registration update: >> Content-MD5 Date: Tue, 16 Oct 2018 08:39:05 +0100 >> From: Graham Klyne >> To: Mark Nottingham , >> ietf-message-headers@ietf.org > >> Just to be clear, this is just use with HTTP that's being >> obsoleted? > >> It's also registered as a MIME header. The reason for >> obsoleting per RFC7231 appears to be inconsistent HTTP >> implementations, so I guess that doesn't apply to MIME/email? > >> # g >> -- > >> On 15/10/2018 05:30, Mark Nottingham wrote: >> > As discussed on the HTTP Working Group mailing list [1], >> > we'd like to update the registry entry for Content-MD5 in >> > HTTP. >> > >> > Proposed template: >> > >> > Header name: Content-MD5 >> > Protocol: http >> > Status: obsoleted >> > Reference: RFC2616 (obsoleted by RFC7231, Appendix B) >> > >> > Cheers, >> > >> > 1. >> > https://www.w3.org/mid/C94E5914-F5F0-46D0-BABB-D42EE45DF10D >> > @mnot.net >> > >> > >> > -- >> > Mark Nottingham https://www.mnot.net/ >> > >> > _______________________________________________ >> > Ietf-message-headers mailing list >> > Ietf-message-headers@ietf.org >> > https://www.ietf.org/mailman/listinfo/ietf-message-headers >> > > >> _______________________________________________ >> Ietf-message-headers mailing list >> Ietf-message-headers@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-message-headers > >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp From nobody Sat Oct 20 17:12:54 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1636130E17; Sat, 20 Oct 2018 17:12:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Bradner To: Cc: extra@ietf.org, draft-ietf-extra-imap-replace.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154008077269.13778.3909814853433103491@ietfa.amsl.com> Date: Sat, 20 Oct 2018 17:12:52 -0700 Archived-At: Subject: [Extra] Opsdir last call review of draft-ietf-extra-imap-replace-02 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: Sun, 21 Oct 2018 00:12:53 -0000 Reviewer: Scott Bradner Review result: Has Nits This is an OPS-DIR review of IMAP REPLACE Extension (draft-ietf-extra-imap-replace-02) imo - this proposal causes negative ops issues - i.e. it fixes potentially bad ops situations where the state of a message repository is not determinable due to the failure of one of a chain of commands. so it reduces potential ops issues that said, it seems to me that section 3.4 could more clearly state that no changes are to be made to the repository unless all changes are made - i.e., 'all or nothing' - the information is there but it is a bit convoluted and the use of a clear simple statement would help From nobody Tue Oct 23 14:17:03 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F6130DE8; Tue, 23 Oct 2018 14:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2018 14:16:54 -0700 Archived-At: Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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, 23 Oct 2018 21:16:55 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-replace-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be used instead of the RFC 2119 boilerplate.) Section 3.5 Unlike the APPEND command which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. The stated justification applies only to REPLACE. What is the justification for disallowing UID REPLACE from the authenticated state? Section 4.3 (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS specification means that the client first receives an EXPUNGE for a message and afterwards APPENDUID for the new message. [...] nit: This comma is either spurious or missing a partner (if "as described in the UIDPLUS specification" is supposed to be a parenthetical). From nobody Tue Oct 23 17:17:38 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7F0130E2F; Tue, 23 Oct 2018 17:17:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: extra@ietf.org, brong@fastmailteam.com, Bron Gondwana , draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154034025076.31224.16883500099553313425.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2018 17:17:30 -0700 Archived-At: Subject: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-replace-02: (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, 24 Oct 2018 00:17:31 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-extra-imap-replace-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D12061 COMMENTS S 2. > handling a REPLACE command, a server MUST NOT generate a response > code for the STORE +flags \DELETED portion of the sequence. > Additionally, servers supporting the REPLACE command MUST NOT infer > any inheritance of content, flags, or annotations from the message > being replaced. Finally, the replaced and replacing messages SHOULD > NOT be present in the mailbox at the same time. I don't think I understand this text. What would it look like for them to be present at the same time. From nobody Tue Oct 23 19:19:34 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A689130E8B for ; Tue, 23 Oct 2018 19:19: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1eLlUckrTtU for ; Tue, 23 Oct 2018 19:19:22 -0700 (PDT) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 24E12130F2F for ; Tue, 23 Oct 2018 19:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540347560; bh=z6513lr0/2pJe8Ub5DQ3OyodgC6UNOaPxUwVIxWP/zc=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=m5ZpKFf6Gf83CO/21Ej12Lpc4ScDAaxhONxKEpyYjfk8uUextduPB6f23bAegMOjy/joA3aFqF6qV4eNq+MMc7aI29LjgUmNUJsfBbcuWDfugIwScnDKU3ll2fXPuUmLwXGcX11lpYwvR4uW2JAjbfjIR3dihpi3B+kOYwn+QETpT6MKxeWRqiYB+uG617OipKMjtYMSK/0TFfJ11Ny+1Z0qhsIbrLEvKEs69YTq1iQFZZg9g//yBAliSgJ2NZ07Rlf/XAU8HK21o0DdZQKTr02dVaLW+yVuqx/6eqqxQvElSLq/DYdUJqeZHSXoKCepT+gSBLUGtd6wb0oJTxPGnw== X-YMail-OSG: OqoqSqUVM1mhK61Q3p_I5yLPnkmUgRcQUfU_WuM.pexYMzfT_dRfSAR4HtPA0U4 LG0fJv1f7o_03SxGJFMSOjt5UNR9qV.JZRvnEplXHagF5.T8vQXsH6HpEpedCxiPJIgGJBSueyhF DoiuRcp_xxDcOKnNAqe7E2BAE8dB20pNgTTXPjDcm8N.BI6hqMRC3K1hJzf0F1vOSHbyVOeuQEqB YOfAov_HpLOjA0RhTtlWoysVAPc5oVmHcO.teEvcD9PEqS2ZwDGv67BBd2W3Tw3tTAIeqBC6Flv2 EqWyNECyqtGZdVhawN1.TDGi2C3l9mZZAXudYCPC8ArkcKaV5AYSU0wfzHAzqhIdsWz1ePx6V9UN SaGS.cX9zYDSqHV8mrMMnB6Mq1Y1jRvH9g38ycUaFvn4muQvyb_RH7r_8x3bibk3ElZQ0QAbQskA JrrY_xBQdgn9tCf5SmOOgOKLsjJbFfVDWpM3xvuEUObJ.Pwo0DJCuVbY.R6vYJoSYXYjw8zz360G S39x1Vvp136Twvhf762cyO4FyW0KvqeIs_9I1kQ1V9MX_wg5mgiNyIYSS5n3nSb31Mmj8Gag3Iqa sYvYgWqaXpMjL2sD69KPEYln3q4V5Q7umxVhA_eC20jO2KCYpn4Dh_TSDY72VivabOUIl_ykBebo hKZrapRlY0cEl2hG1QFpOygHc4ipLu17psL0ciAadJvxXCYe5vZQQt7BHnHJQInl24dtbpCbXitR wkn_Ov57A9Y.UUYDIyGhyLXdp4.0OCbP3O9zfv92pScLDhHSlT_JIuw.0rXri7nWFd9dnetDoRmH 8j5u.YvJRZyP6RDRB2w.56sABS2WMm.OjYHvEA2I1oTo.MhBOX7EGXQoVmrPvF2BNWR4iWLeyR_a kovzRccW4WRqp80k_9JFusaHBOk.3asBgbffjyrZ3HoET5ruGeQcMLO7ufIr3pml8x9ZiL4min0O xB.R124qOZiQNvG42PZ5XoRDe2Gs79iM9_SgYbA2yUwWB8BnMbR0OoktRdbP06Ofwjo340Pvu50. 3aNsiT81TJk5M1xn04qSbwDvYyQoq Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 02:19:20 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fe367cb2a89ff9f909d84b2c5b598024; Wed, 24 Oct 2018 02:19:17 +0000 (UTC) Message-ID: <5BCFD689.3040004@aol.com> Date: Tue, 23 Oct 2018 22:18:49 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Benjamin Kaduk CC: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> In-Reply-To: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 02:19:32 -0000 Thanks for the feedback. Comments inline. On 10/23/2018 5:16 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-extra-imap-replace-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be > used instead of the RFC 2119 boilerplate.) > > Section 3.5 > > Unlike the APPEND command which is valid in the authenticated state, > the REPLACE and UID REPLACE commands MUST only be valid in the > selected state. This difference from APPEND is necessary since > REPLACE operates on message sequence numbers. > > The stated justification applies only to REPLACE. What is the > justification for disallowing UID REPLACE from the authenticated state? The syntax of REPLACE identifies the source message's Mailbox by means of the currently selected Mailbox, thus requiring Selected state. An optional source-mailbox parameter could be added to the syntax just for the UID REPLACE case, but other UID command variants such as those discussed in RFC3501 section 6.4.8 chose not to introduce UID specific syntax for specifying source-mailbox in order to support actions from Authenticated state alone. I'd prefer not to forge new ground in that area with this particular specification. > > Section 4.3 > > (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS > specification means that the client first receives an EXPUNGE for a > message and afterwards APPENDUID for the new message. [...] > > nit: This comma is either spurious or missing a partner (if "as described > in the UIDPLUS specification" is supposed to be a parenthetical). > > From nobody Tue Oct 23 19:24:18 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD30130E41; Tue, 23 Oct 2018 19:24:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AWG5VyqmIxBu; Tue, 23 Oct 2018 19:24:14 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 01AE3130DD2; Tue, 23 Oct 2018 19:24:10 -0700 (PDT) X-AuditID: 1209190c-579ff70000000dcf-53-5bcfd7c86c03 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.5E.03535.9C7DFCB5; Tue, 23 Oct 2018 22:24:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id w9O2O3Vj010421; Tue, 23 Oct 2018 22:24:05 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9O2NxPt012367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 22:24:01 -0400 Date: Tue, 23 Oct 2018 21:23:58 -0500 From: Benjamin Kaduk To: Stuart Brandt Cc: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org Message-ID: <20181024022358.GQ45914@kduck.kaduk.org> References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> <5BCFD689.3040004@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BCFD689.3040004@aol.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT0T15/Xy0weL1GhZ/zsxntXi0ZyWb xayVbUwW/6/2MFvM+DOR2aLrZbgDm8f93SvZPS5/b2XyWLLkJ1MAcxSXTUpqTmZZapG+XQJX xvXjK9gLfgpVXP6yjrmBcTZ/FyMnh4SAicSC+TNYuhi5OIQE1jBJvO+YzQrhbGSU+NY+mQ3C ucsksbxvFztIC4uAqsSkk2sZQWw2ARWJhu7LzCC2iICaxNdbc9lBGpgFljJKbJjSCNYgLJAg 0d90DMzmBdq37OFEMFtIIEvi3bZ3zBBxQYmTM5+wgNjMAloSN/69ZOpi5ACypSWW/+MACXMK qEucOfafCcQWFVCW2Nt3iH0Co8AsJN2zkHTPQuhewMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1 SNdQLzezRC81pXQTIyiwOSV5djCeeeN1iFGAg1GJh/dA7floIdbEsuLK3EOMkhxMSqK8Vw8D hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwKmsA5XhTEiurUovyYVLSHCxK4rwTWhZHCwmkJ5ak ZqemFqQWwWRlODiUJHjnXQNqFCxKTU+tSMvMKUFIM3FwggznARq+CqSGt7ggMbc4Mx0if4pR UUqc99BVoIQASCKjNA+uF5R4JLL317xiFAd6RZh3N0g7DzBpwXW/AhrMBDT4uvoZkMEliQgp qQZGbaXnyxco5zn/Wl59eAW70MnYP2/YrlZK8fjXZUv4125k/MRbMPMIU7pJ44H05xVzn7jc qn5tIh73goHzRt7Mu1/rJBY5aq3jj8zIfZFT7h/6Kv7BgtVvWK0WvDdrcMpZnjtruiDfLoUv 2f2GM1sWOx/eVWyYlW9Q3e51f06hbWELtxZnVJESS3FGoqEWc1FxIgBT0qF3FwMAAA== Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 02:24:16 -0000 On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote: > Thanks for the feedback. Comments inline. > > On 10/23/2018 5:16 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-extra-imap-replace-02: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be > > used instead of the RFC 2119 boilerplate.) > > > > Section 3.5 > > > > Unlike the APPEND command which is valid in the authenticated state, > > the REPLACE and UID REPLACE commands MUST only be valid in the > > selected state. This difference from APPEND is necessary since > > REPLACE operates on message sequence numbers. > > > > The stated justification applies only to REPLACE. What is the > > justification for disallowing UID REPLACE from the authenticated state? > > The syntax of REPLACE identifies the source message's Mailbox by means > of the currently selected Mailbox, thus requiring Selected state. > > An optional source-mailbox parameter could be added to the syntax just > for the UID REPLACE case, but other UID command variants such as those > discussed in RFC3501 section 6.4.8 chose not to introduce UID specific > syntax for specifying source-mailbox in order to support actions from > Authenticated state alone. I'd prefer not to forge new ground in that > area with this particular specification. I probably should have made it clear: I also prefer to not forge such new ground in this specification. But does it make sense to make a nod to this reality in the document and note that this restriction is also applied to UID REPLACE for consistency? Thanks, Benjamin From nobody Tue Oct 23 20:14:17 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5C130EA9 for ; Tue, 23 Oct 2018 20:14:14 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU-fzLNz7yVl for ; Tue, 23 Oct 2018 20:14:12 -0700 (PDT) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (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 3367F130E4C for ; Tue, 23 Oct 2018 20:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540350844; bh=/mETTQC4xBnB6Z2Pe5c58EpZsxfa5qvJue7oKBLnK94=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=o97zXrFfjyyvDuLiuPEJz3cdT+2GiaM4gRdTkDV15oAJo0KOpu057OpW03zS1XSSxlBmyRepH19FioPbavR5dPfUJgfi/bw9kAf57F+rgNGByuRMSYr0Y/FjPjLVeW9T1V4osOrwKq0y2mN6Fk6J658yQXOrqe+Ydkb031tQiDYoSbItGVkjyXfYM9YQRTAyluKr9lFQ97rPKu0ufbuEl31rpZdkgDHXwTNl9ZlNvT4esl2oM3vtoJsNebfKbeY7F22OrxTS9tjjTdHIF4FZ9oxut/iEifg05zYZM20PgmyXWsDVUYeNpYtlEmRaH0kL8hl4kS3qv7OI1I35pS/izw== X-YMail-OSG: _y7yBaUVM1ldvHOWq.68NpqanlVv4XE2wZ034zlCm0T_ajIbbbqW1e.MYJMYhFU laRNnGz0wPLgwleyoGJmdIB7f5XJq2FXRfNt31jlyyFvmPxI9zn9JbyaFMb9hIeBvsk.YKoK9iUS Ck62VQzlRGFpa0SdkpzUg7mz7h3l2f9_kp0.765Tx1x0nJSw4R0KTLFgMfmbqATe._8dfRad3zXb _OIXgGmeeCuQvakENkvxZoDk6Yr6ofEajP8lTGFvB9NqtD8bi_Tgy0eY1gfI2aIpNZ6ukCGlmM8X pc6v3MRq1llU0wf7wbOnUf5IcCW7buA6Aa7ySw_lKYpmBajtG5bZY7IQEVHJuSDhejlgZ.cjsb2v MSxlX949MLrrSZO0gdT6icsBE1jjMkS1gryDOO3TGFyZRU19u.9.kGcQAmVCDCxap0tXSK68D5JI 8qTmhWtkhj9y.ygeN1j9aIBLdaGutHjHA5.gceVwHKb8ZuyJOf9n4eft6EzJWIK1Tnbt.V79q_LS xmTgckJBXoFdXR2JMYaPH8syywCI8eZz.w6vNdRUCzS.NkxVt06TvBNBlq.afxjppQSNunlGsy5w us3SkwmhQZUnrlY6v4VBe5IBcReGoFBT7r.B.HmA3H49yzUqP87rIy4Q2VEz7IzVB8hkZ.J90TKH euJKVd86DqclI4xKeP5k_GGxjkeNGzi8MQ_mSryXGcgJQXCEiKbjg6V1jez525S85zWeS1hCaG21 tEut4ekt4EUocjLdI7sgjl67Omm0ljqDHls1IwhaoVJuOa3KKz0XQCOlO1Fax1DWg7vjXyquGiLK OTNzRWNbki4YdcysqRogZpbEDX30Xk62HFf86xscUZMHtwK7f6InAQAW_XGb7nbYKTH2ImkBZ1I4 lOjxPD1cHa0XW81Mem0KsVJYBKCp.VQmmCNz0YrQ.vJ6gd3vPsIyicS4Ock_MdB6ZWSgm5TmpoOw wx_j2roCGzMInoNrpd_YuLmfGiMhAZFVhCT67edkCI1GXryFlh42Wd_yfttsiqFx.sy4JfJ73rGQ kU9fjHJjoJqcCIWi_wjuhpZR5Mb9RS3d7Rik- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 03:14:04 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd79a59f3c67d5141154f53f212e9aa6; Wed, 24 Oct 2018 03:14:01 +0000 (UTC) Message-ID: <5BCFE35D.5020703@aol.com> Date: Tue, 23 Oct 2018 23:13:33 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Benjamin Kaduk CC: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> <5BCFD689.3040004@aol.com> <20181024022358.GQ45914@kduck.kaduk.org> In-Reply-To: <20181024022358.GQ45914@kduck.kaduk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 03:14:16 -0000 On 10/23/2018 10:23 PM, Benjamin Kaduk wrote: > On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote: >> Thanks for the feedback. Comments inline. >> >> On 10/23/2018 5:16 PM, Benjamin Kaduk wrote: >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-extra-imap-replace-02: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Section 1 >>> >>> (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be >>> used instead of the RFC 2119 boilerplate.) >>> >>> Section 3.5 >>> >>> Unlike the APPEND command which is valid in the authenticated state, >>> the REPLACE and UID REPLACE commands MUST only be valid in the >>> selected state. This difference from APPEND is necessary since >>> REPLACE operates on message sequence numbers. >>> >>> The stated justification applies only to REPLACE. What is the >>> justification for disallowing UID REPLACE from the authenticated state? >> >> The syntax of REPLACE identifies the source message's Mailbox by means >> of the currently selected Mailbox, thus requiring Selected state. >> >> An optional source-mailbox parameter could be added to the syntax just >> for the UID REPLACE case, but other UID command variants such as those >> discussed in RFC3501 section 6.4.8 chose not to introduce UID specific >> syntax for specifying source-mailbox in order to support actions from >> Authenticated state alone. I'd prefer not to forge new ground in that >> area with this particular specification. > > I probably should have made it clear: I also prefer to not forge such new > ground in this specification. But does it make sense to make a nod to this > reality in the document and note that this restriction is also applied to > UID REPLACE for consistency? Makes sense. Would the nod be more helpful when discussing state impacts (section 3.5) or when discussing UID REPLACE syntax (section 3.3)? > > Thanks, > > Benjamin > From nobody Tue Oct 23 20:14:27 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A145B130DFD for ; Tue, 23 Oct 2018 20:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 BkS2GlrukigC for ; Tue, 23 Oct 2018 20:14:21 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 0F04F130EDF for ; Tue, 23 Oct 2018 20:14:19 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id n26-v6so2780775lfl.1 for ; Tue, 23 Oct 2018 20:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q9Xv3zv2a5vCAJF2W5fdiwJcuawO5+ue8702xWvT+B8=; b=0UQ9TztQALh8IO9tDiC9rxDKZ1RG0chhQ+yRUGOOesQl95I2YImltcVIz98OiNc1hI X40hg9/XqcO62EKBerIrTagM3mpB9RrUyIStGwu4y/69bAcehAawRhC3a+677MeI+TxI E5ciNyj+Q4cthzFaMbxXFFZLEw+TNMteIBLDsN2t9K3CkFSaT/pkTEtpAfFKXyRFcdqu xdtksHxZEDy7FR7z9+ScaxW563G1EqPZJrLiKd9fBZO2RRqjpeqsqo3f1q4znW23zIks 6LFjL/LVHU/0pwOACCQvGYvMu/wOB5AkQSNw4KOhgjb1nfJo3c1C5uiz2AHF8amvjJZ0 3Adw== 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=Q9Xv3zv2a5vCAJF2W5fdiwJcuawO5+ue8702xWvT+B8=; b=hLT+HnRQbYqWnpQCunhEWoL0b4kE2FIWm6xRx5y0+3awTCQohTWs6D5jSFnUBYU1en zLIwI6VMYi7rWDjyGil1wR1lpObm2uaAWSk+fhcDGzmeez2INt9xwNv6ybwWIdImH10v jekizjkUr0HIxvLsOMNDJgIzB614+8Fps1nBpIGdQFtikw6UkUspjXifoHkzudSaMjCQ uOOcE6mjJsv8MwLaTZGkot/7J0M2GIoUv81FBpAjBC0bgM7kzyaoTbIh+qvMAvRH7EUs 5mut9H3tLibMOvGYrKHRllAhMCDbCk21CdP/lO8Emvrz+PYyg6WWsI7Ca0hs5ZZJ8ghg VcIQ== X-Gm-Message-State: ABuFfohJmQ7ewK2Chmmmc5A/6GiS8AngRkN6vrMBzC8s2CyCiE2fCq6A iNR73LnDQzHZksgWMLXMZ6STvYIwK7cK+KQO6jdHlA== X-Google-Smtp-Source: ACcGV61CG7UFZ+3z/MKT6NYyZ+bcnWrUTrOd8L4yeCW5XDJxmnzxUmx6I8gwJI84dDtY5tATPJQ05qRJoiI14TjZkNo= X-Received: by 2002:a19:5a05:: with SMTP id o5mr14386101lfb.140.1540350857216; Tue, 23 Oct 2018 20:14:17 -0700 (PDT) MIME-Version: 1.0 References: <154034025076.31224.16883500099553313425.idtracker@ietfa.amsl.com> <5BCFE181.5040007@aol.com> In-Reply-To: <5BCFE181.5040007@aol.com> From: Eric Rescorla Date: Tue, 23 Oct 2018 20:13:40 -0700 Message-ID: To: stujenerin@aol.com Cc: IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ac97860578f0e1df" Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 03:14:24 -0000 --000000000000ac97860578f0e1df Content-Type: text/plain; charset="UTF-8" OK, do you think you could make that clearer along the lines as you have done here. -Ekr On Tue, Oct 23, 2018 at 8:10 PM Stuart Brandt wrote: > Thanks, Eric. Comments inline. > > On 10/23/2018 8:17 PM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-extra-imap-replace-02: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D12061 > > > > > > > > COMMENTS > > S 2. > >> handling a REPLACE command, a server MUST NOT generate a response > >> code for the STORE +flags \DELETED portion of the sequence. > >> Additionally, servers supporting the REPLACE command MUST NOT > infer > >> any inheritance of content, flags, or annotations from the message > >> being replaced. Finally, the replaced and replacing messages > SHOULD > >> NOT be present in the mailbox at the same time. > > > > I don't think I understand this text. What would it look like for them > > to be present at the same time. > > > > This wording was a compromise from the original > draft-brandt-imap-replace-00 that had much stronger language around the > atomicity of REPLACE. In discussions just prior to IETF93, the strict > atomic guarantee was considered a hindrance to adoption by server > implementors. The "SHOULD NOT" here is intended to *discourage* server > implementors from allowing clients to discover and therefore act on both > original and new messages, but acknowledges that in some cases it may be > unavoidable. > > To answer your question more directly, it would look like it looks today > without the REPLACE extension -- 2 independent messages existing > concurrently for a moment in time along with the potential issues > highlighted in the Overview section. > --000000000000ac97860578f0e1df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, do you think you could make that clearer along th= e lines as you have done here.

-Ekr

=

On Tue, Oct 23,= 2018 at 8:10 PM Stuart Brandt <st= ujenerin@aol.com> wrote:
Tha= nks, Eric. Comments inline.

On 10/23/2018 8:17 PM, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-extra-imap-replace-02: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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-replace/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D1206= 1
>
>
>
> COMMENTS
> S 2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0handling a REPLACE command, a server MUS= T NOT generate a response
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0code for the STORE +flags \DELETED porti= on of the sequence.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Additionally, servers supporting the REP= LACE command MUST NOT infer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0any inheritance of content, flags, or an= notations from the message
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0being replaced.=C2=A0 Finally, the repla= ced and replacing messages SHOULD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0NOT be present in the mailbox at the sam= e time.
>
> I don't think I understand this text. What would it look like for = them
> to be present at the same time.
>

This wording was a compromise from the original
draft-brandt-imap-replace-00 that had much stronger language around the atomicity of REPLACE.=C2=A0 In discussions just prior to IETF93, the strict=
atomic guarantee was considered a hindrance to adoption by server
implementors. The "SHOULD NOT" here is intended to *discourage* s= erver
implementors from allowing clients to discover and therefore act on both original and new messages, but acknowledges that in some cases it may be unavoidable.

To answer your question more directly, it would look like it looks today without the REPLACE extension -- 2 independent messages existing
concurrently for a moment in time along with the potential issues
highlighted in the Overview section.
--000000000000ac97860578f0e1df-- From nobody Tue Oct 23 20:20:11 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37638130DD8 for ; Tue, 23 Oct 2018 20:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMxG7ftdemFo for ; Tue, 23 Oct 2018 20:20:07 -0700 (PDT) Received: from sonic314-42.consmr.mail.bf2.yahoo.com (sonic314-42.consmr.mail.bf2.yahoo.com [74.6.132.216]) (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 AF97C128CFD for ; Tue, 23 Oct 2018 20:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540351206; bh=RFSQ3uuBNO168PftLVYMFODvsrHAuxuYXzyZm1IEu7M=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=A1uHlRTicXMiqUEbhMNuwqJ6ezRwI0kAPnpojVXp9jJo4fc941yIvkymsUrDRn+ygGuc7Z8Tgek5maZryyjP16ZoZ5R2bVoqgWJ/kkBMgWDtrg3UMwuWcMcPMwQf67T66yXzzwtEtDrJkpd1e4HbPllYRHpzgQXiM2cMJ0kL5LeEJgFmoXvct2vKumw7MoYfx/CVgtku/TrOF+7/cg2U/7QTE4EWYpbnhxGpZIC238JrPvIdB5V6j0lA5tbIQEV55VWhXPOnY+rCJxDYujv/KpkZqBwJIK51r8/PSPMsxCB3crqk6PtaE6dUa2N22CVesIbB84vgvwXf0rzjnjDA6w== X-YMail-OSG: A4TAp0EVM1nWZzbyAswkz2oRA..Dg8x_GYQwlrHZFVRMS4vR_Lr0LrNdrnaHwJR Khj2bWO8PYLAaqOED83gF8uzAe74lWcBJMGhlVR_qMsUj3OXOw54- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 03:20:06 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 54a702fb6ce1b5119162a1e63cc1ec0e; Wed, 24 Oct 2018 03:06:04 +0000 (UTC) Message-ID: <5BCFE181.5040007@aol.com> Date: Tue, 23 Oct 2018 23:05:37 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla CC: The IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org References: <154034025076.31224.16883500099553313425.idtracker@ietfa.amsl.com> In-Reply-To: <154034025076.31224.16883500099553313425.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 03:20:09 -0000 Thanks, Eric. Comments inline. On 10/23/2018 8:17 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-extra-imap-replace-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D12061 > > > > COMMENTS > S 2. >> handling a REPLACE command, a server MUST NOT generate a response >> code for the STORE +flags \DELETED portion of the sequence. >> Additionally, servers supporting the REPLACE command MUST NOT infer >> any inheritance of content, flags, or annotations from the message >> being replaced. Finally, the replaced and replacing messages SHOULD >> NOT be present in the mailbox at the same time. > > I don't think I understand this text. What would it look like for them > to be present at the same time. > This wording was a compromise from the original draft-brandt-imap-replace-00 that had much stronger language around the atomicity of REPLACE. In discussions just prior to IETF93, the strict atomic guarantee was considered a hindrance to adoption by server implementors. The "SHOULD NOT" here is intended to *discourage* server implementors from allowing clients to discover and therefore act on both original and new messages, but acknowledges that in some cases it may be unavoidable. To answer your question more directly, it would look like it looks today without the REPLACE extension -- 2 independent messages existing concurrently for a moment in time along with the potential issues highlighted in the Overview section. From nobody Tue Oct 23 20:32:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FF1130DDA for ; Tue, 23 Oct 2018 20:32:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gOLf2OsMfkU for ; Tue, 23 Oct 2018 20:32:21 -0700 (PDT) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (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 BD20B12D4E6 for ; Tue, 23 Oct 2018 20:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540351940; bh=pSodZcG/8MYNqrejjtV4zi4AxDg4Vwm8E03z377+VPY=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=CQqnxyQh6rj4QWhKCBZGCyuikS/2OQiPhkZQ/e1wapLUV8MPbDAsGEfKEVstg0XTlv4pDj+A9mpVD6euGau/kmqFnqa8CEg9H8/NZTQ7SVH5cXSVp98+GxmDlgGaZYGu8wQ7DsgpdiAzozq4TIj4ZggeWR/VaR+1P8kaCc0AjvYS3iI23KL1HHfwqXJkgHteq62UbnxLXlZKZVbIPEebdt47mKNfnMJhiassPftK+iI6SEL4uirwQEz2z3ecKHoWIvTLtRdMtejTPIHzBwASm9TjucxJ+STINGSKYuMV8tgijWTiZEl/Ws6D+uMDQvu3bvtjveqV8azZFrMdKHbRlA== X-YMail-OSG: ZGtwnakVM1n1XTk5VrJ7QscEBDaiNrX6ugYkJkceDxtymAshwBFUfdy9XVBfnPk 8ZOqh6XuDHKrHH65KOVq0e.tT0Wd6s5dQpZb6NSgWb6cV6PdINwkSvHz8mvnC5oF.4u77w5cwg5X 73hRbBwD20u1YhI5AV4xWl6nxcGOJIh_IRjYecjsWL9UTDfLUaKZRV4fsIGqjiJyhGBF.sKBg24h H_DOZ0EjqFV7asApnzAiaSJgVO9eh2NL4OzgIIC8Kq_fejmV5ofmVg.MDcn.1sD0eXBq413BvM8x l6NZJvYKEnAGImwl4Tty52luh9zcOVKpEKXt8t4lJobX9os6c9KRlcQmQ5u.vxi9rETUWCuU5_KA 0.zJ8p96ub_97gZ23chFjzYsLL2GLB0wCnbGTfWyb8s2DCMPQeH8.l0kBODNNU6nScD0Kf7bsvmT i9bqwy1Bd9gpkwwDxzK7HIfwl3dmWHhMY3CZN9N7YQbzymnCsT7ZknxKQ3wSnkZ7zLnq8v7NfkTh Jxytb.ba6Xjs.J51GyV0hxgz8QyOj069ARHWIXlHmCUuk3pkcTgmpjHjHX3yu8RXW7qAXG1pPBhC l_Bu0lBln_KwyUKOembpn9NDTZ.5MA0B7dmuqycKibOIXm.GvjIPxWQkfqI4ecW_HyiKEXVL9D43 aMtNNSvjVIy.6a54l.9sm6CTz0E0pmR4sKYfTnsDQOTNDBfMcIdw9urJE9cU85LmOY06kwga3wZ2 L2wmrwE6A00Nq_I_tK9w7OR36ACcJ7uhqb.1lRkcoxwSoh0wIa63uPUDZ6tkEr8t5P_eoJDkhzg4 AVIgNM08qG1_YPPOo3oVY7RIfxG.8Vhd0FKMSHlnRs7k2sVVmfm7XnBYQ35qvf0diFOWTZxgIzg. RL2nW3DS014LtkzSzFF69FQQ1Nd2KRZel9_4CPbKgO8JVm69DO4kzksBn.LkyN5eFlWDxtPsva2m pqnyqhBSVMI7jtKzkOrWOP5hW2T1TsGOGVnzmNfN6l.ja_wpLt3VvFj48YZ9x6D4sCkvotOw7yyv btsZuc25iQOMTZW3lSrwDX1lt3IopIXq5RbGF_BJsTCixA19kvtZiGb1Ebw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 03:32:20 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a067204cdab6a99487d8b3cac77d6546; Wed, 24 Oct 2018 03:32:18 +0000 (UTC) Message-ID: <5BCFE7A6.8070008@aol.com> Date: Tue, 23 Oct 2018 23:31:50 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Eric Rescorla CC: extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, IESG , extra-chairs@ietf.org References: <154034025076.31224.16883500099553313425.idtracker@ietfa.amsl.com> <5BCFE181.5040007@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 03:32:24 -0000 Sure. I'll see if I can improve clarity of this issue. - Stuart On 10/23/2018 11:13 PM, Eric Rescorla wrote: > OK, do you think you could make that clearer along the lines as you have > done here. > > -Ekr > > > On Tue, Oct 23, 2018 at 8:10 PM Stuart Brandt > wrote: > > Thanks, Eric. Comments inline. > > On 10/23/2018 8:17 PM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-extra-imap-replace-02: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to > cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D12061 > > > > > > > > COMMENTS > > S 2. > >> handling a REPLACE command, a server MUST NOT generate a > response > >> code for the STORE +flags \DELETED portion of the sequence. > >> Additionally, servers supporting the REPLACE command MUST > NOT infer > >> any inheritance of content, flags, or annotations from the > message > >> being replaced. Finally, the replaced and replacing > messages SHOULD > >> NOT be present in the mailbox at the same time. > > > > I don't think I understand this text. What would it look like for > them > > to be present at the same time. > > > > This wording was a compromise from the original > draft-brandt-imap-replace-00 that had much stronger language around the > atomicity of REPLACE. In discussions just prior to IETF93, the strict > atomic guarantee was considered a hindrance to adoption by server > implementors. The "SHOULD NOT" here is intended to *discourage* server > implementors from allowing clients to discover and therefore act on > both > original and new messages, but acknowledges that in some cases it > may be > unavoidable. > > To answer your question more directly, it would look like it looks > today > without the REPLACE extension -- 2 independent messages existing > concurrently for a moment in time along with the potential issues > highlighted in the Overview section. > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Tue Oct 23 20:39:06 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0EF130DE0 for ; Tue, 23 Oct 2018 20:39:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llyBuJtNsRgO for ; Tue, 23 Oct 2018 20:39:04 -0700 (PDT) Received: from sonic305-4.consmr.mail.bf2.yahoo.com (sonic305-4.consmr.mail.bf2.yahoo.com [74.6.133.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7651E12D4F2 for ; Tue, 23 Oct 2018 20:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540352343; bh=PBUM9SmMdetQa0cD2WOqh7aFHM/4d+1hCzwtp9Ih748=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=tlqVZq8vXn18HRTqZExuTt3i+Bkp7yLU36N+rshsiLimphGER9bguPihzrE28j9PpKf/62PiDd1359fH6itVyyfq8WutY/3YQTU4/3ivLhd1v5tE5tbc5CvIPaCN1fwRLH3SOWZu99hu/LeAvDipO0/La1kCdsapfy5+C+nS1agPz4W9EIX25OZfQv3gSKphXASgnpR87/Y7PpD6BqFLerIWg6DZyCV0bAqLjBMOsJrCDpsoYJq2ksCJg/0V9izIqP2Ka8h5ILdSWnuuz4x3iPnh0kH9vvKoa6jY0CnuqAm3A9TRHQrgJHwQF7M9MOWh+3t0vrNeJ4okOUoWIfGkXw== X-YMail-OSG: BdiETN0VM1lB2YRtM9ChCignkiKqGC.bKtqtMiLfdlsrpl0gO_9LROY4bPJddbx _uVDkcylvkx0FK7nEZTC5QB8jtI2FQs1Q1tw7Y7IGNzZXPvZEYvc3Hv_BO3ycxt3E6Xl.4giRF.S w4s2R.IpR_q07DX9T3W3PmHivruSaDiyQxPgqJbOoryEVMox7iKMcN1hFGXICwg796FwPQLCx0gB vehpFJMqVPxUrfGt.onB5mBV6nouWOQOmRA12JaMoyRJGJvuETzqhP55K8qV_5GYqGrwAxyUb1qr h1JRs1AcyqvVhIMdr7kfVrMJX_f.QNuyPWcw.vGcO2wqQkkD9fDQ7ChI1HZ3DT733_XsDoPfnbuF ufiinwrPz8IVfcjf9_pP51PA_wJ66bgYJtF_XWw2d0kncp19I4DbZgYe6sTCEvt3HCXEpVLufk2N 1i5PLMq68UjlZdL6LI2FLl7l0X3eKBBK5w_OV1OoFPhVIfciGb4dbbkSgBqEip3on3ZhImcM5hAb Z49GWc8Nxzio0igr6I1Bs0fHqvxrk8hqDieB5oaEuBwkMdOhQI7YYuSQHBRh4haS04QMrKDEex4F 0LxOeFkW29M9fnnLPRjCn2dysg9SkpnBGyT9AlbgpDQAcjQd0IAzdiGcnE.OTcIQkm2lJTs.klJg HPir2vmoMKr7J45Gm_FckH2LBhHDsXO.NXqmpD5MlgJa8vsDU81R1ZMMx_yQknfGvdmuaC6i.2V8 dMFkKxfY1V5KYvLTCZtV82_boWXrGQghRznDz1RinKgCuwDOvjtuWHfN6HWRwHl4RJ8CWMPSsi8x JYSyw0ZDciz4y3LXvUIQSIoGreQ68ZBrWxZ6ZvYI82PgqDJFXIQeg_PweBvXMwOarW1RFOgfMtyf gaIZ82sOl3I.lczKixM.wSqXjLoEyQlK6hLiLHpLTPXZ5M39CSttBNz6C5nYfbMpWNNvPGTHwg.o SXAQr7Qq3z1UmlbdEj2PuIos8hM8Lj90dbPH42wxtLqN4E7GySryOjGvnJhLQYZVwzS1HqYXtDSY k9.jCXgrnPePUV5HjnJ.8v39KQnOLvbIAqw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 03:39:03 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 05381467c50ccf1b0593ea224e4f2087; Wed, 24 Oct 2018 03:28:59 +0000 (UTC) Message-ID: <5BCFE6DF.1000005@aol.com> Date: Tue, 23 Oct 2018 23:28:31 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Scott Bradner CC: ops-dir@ietf.org, extra@ietf.org, draft-ietf-extra-imap-replace.all@ietf.org, ietf@ietf.org References: <154008077269.13778.3909814853433103491@ietfa.amsl.com> In-Reply-To: <154008077269.13778.3909814853433103491@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-replace-02 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, 24 Oct 2018 03:39:05 -0000 Thanks, Scott. Comments inline On 10/20/2018 8:12 PM, Scott Bradner wrote: > Reviewer: Scott Bradner > Review result: Has Nits > > This is an OPS-DIR review of IMAP REPLACE Extension > (draft-ietf-extra-imap-replace-02) > > imo - this proposal causes negative ops issues - i.e. it fixes potentially bad > ops situations where the state of a message repository is not determinable due > to the failure of one of a chain of commands. so it reduces potential ops issues > > that said, it seems to me that section 3.4 could more clearly state that no > changes are to be made to the repository unless all changes are made - i.e., > 'all or nothing' - the information is there but it is a bit convoluted and the > use of a clear simple statement would help We had discussed this back around IETF93 and some server implementors indicated issues with an atomic guarantee. While I personally think it's much more valuable with such a guarantee, the wording for when to send the untagged EXPUNGE and the suppression of intermediate state responses was intended to cover the not-always-all-or-nothing nature. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Tue Oct 23 21:00:09 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 174A8130DE0; Tue, 23 Oct 2018 20:59:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154035359808.31373.16459164548875812554.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2018 20:59:58 -0700 Archived-At: Subject: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-replace-02: (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, 24 Oct 2018 03:59:58 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-extra-imap-replace-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm curious about one point - In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the 3 command sequence. In handling a REPLACE command, a server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. Finally, the replaced and replacing messages SHOULD NOT be present in the mailbox at the same time. I can imagine that having the replaced and replacing messages present at the same time is better than having the replaced message deleted and the replacing message not stored due to quota limits when pipelining APPEND, STORE, EXPUNGE, but is SHOULD the right level of requirement language here? Is MUST just a non-starter? From nobody Tue Oct 23 21:45:24 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 460C7130DEA; Tue, 23 Oct 2018 21:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154035632227.31409.14362991214477694122.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2018 21:45:22 -0700 Archived-At: Subject: [Extra] Ben Campbell's Yes on draft-ietf-extra-imap-replace-02: (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, 24 Oct 2018 04:45:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-extra-imap-replace-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this effort. I am balloting "yes", but I have some minor (mostly editorial) comments: §1: Is there a reason not to use the new boilerplate from RFC 8174? §3.4: "the intermediate states produced do not occur," That seems an odd statement; one might say that if a state did not occur it was not produced. Would it make sense to just say "the intermediate states do not occur"? §3.5: "Unlike the APPEND command which is valid..." Missing comma before "which". From nobody Wed Oct 24 03:54:15 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2D130DC2; Wed, 24 Oct 2018 03:54:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154037844748.6895.10305259306527815276.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 03:54:07 -0700 Archived-At: Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-replace-02: (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, 24 Oct 2018 10:54:07 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-extra-imap-replace-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please take a look at the Gen-ART review. From nobody Wed Oct 24 03:55:16 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3856E130DC2; Wed, 24 Oct 2018 03:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=L+Uvpm93; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uSMfpCmA 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 Z77Nj51WKdO2; Wed, 24 Oct 2018 03:55:06 -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 598DD1286D9; Wed, 24 Oct 2018 03:55:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 795C6E1E; Wed, 24 Oct 2018 06:55:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 24 Oct 2018 06:55:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Y /n/H/EvBDy1qdom7xRDAzzlvkZK6gMMrWSdq6I1Aeg=; b=L+Uvpm93Up4m3Diaa mSq5Tl0cWWKUB6YXUd8w4ZBCGJFaMAh7vNzieGPLZqoKBBhdeIrIJ5zqG3MK0BBw me8x1QEdSaJhVufMA1wehnFE/CtEP52LzUcGGAq9XVD7QbJPmOIsjDn3kZqPUFrK /0OFbb8nvrDYqaEnea/BVQVGovuCTXT/voXFB/0RmlLtYfXOAlLBOQv3IVgCh9Yw OBc2rT77IaP2PPKenpX36Ygydf0HLoWLnuVwQyiJb1oOqRm9Ns3ScQqdt6rFUwYr urGTe6bnw6/QLMKBy0o08EYbue3oFe05hlS43ey2j8K8RTQaWXGDg7FA73BvAcyA uBYdw== 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=fm1; bh=Y/n/H/EvBDy1qdom7xRDAzzlvkZK6gMMrWSdq6I1A eg=; b=uSMfpCmAl5enPA07II0QbbUIU5ktfPjZ+X2JQOT+qtRF2aOy/Fq7zXI57 Yg+rud5CjSk+X5sMMruCyrvlw8/WjjgDYfGbunPDRpSlhG+i91J4qRiZLmNidvhV yPr+4ak+DYktMeRtCMBODzKcGj5Bl31XxM+U7z4EAR5ccfYcm0XUgI8tX5XP1YOZ 2qwwVxG51q1Hsr92KE+erFwGos3/c+CKdBmOp3EkIlSoTwsKxu/EPSBG8THjP3M1 E/klpbjlYJPpwdUWh9zmE1mALxwot13uttWIivEzkYUvX6ErB4nAlHoExfuCJI+O VhK3mBSt3wWA3Do9IHUQQNrJDYwQw== X-ME-Sender: X-ME-Proxy: Received: from rtp-vpn3-681.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id C0E1C102F0; Wed, 24 Oct 2018 06:55:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153937476673.29113.3479129914002220994@ietfa.amsl.com> Date: Wed, 24 Oct 2018 12:55:01 +0200 Cc: General Area Review Team , extra@ietf.org, draft-ietf-extra-imap-replace.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3468495D-FEDC-46E8-AF86-87E77038938F@cooperw.in> References: <153937476673.29113.3479129914002220994@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-imap-replace-01 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, 24 Oct 2018 10:55:08 -0000 Robert, thanks for your review. I flagged it in my ballot since there = has been no response. I entered a No Objection ballot. Alissa > On Oct 12, 2018, at 10:06 PM, Robert Sparks = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-extra-imap-replace-01 > Reviewer: Robert Sparks > Review Date: 2018-10-12 > IETF LC End Date: 2018-10-16 > IESG Telechat date: 2018-10-25 >=20 > Summary: Ready for publication as a proposed standard, but with nits = to consider before publication >=20 > Consider using: >=20 > uid =3D/ replace=20 >=20 > instead of redefining uid. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 24 04:48:30 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7AC130E70 for ; Wed, 24 Oct 2018 04:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKKLCyeDVNmz for ; Wed, 24 Oct 2018 04:48:24 -0700 (PDT) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (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 5682C130E6D for ; Wed, 24 Oct 2018 04:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540381703; bh=zvIE2BsSzPxGJeVXf1NfXycjFNM5c53B5dj8SQ2pNs0=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=MSjrnRXKYeXYaSt427W2xdSpKlpQYg2uF+COVCTNw6ph9NiSL8uFnq5MUdDlfj9jOUAHavQkUPVNPamP7UUUQ3pOsH9wRbmiVc/ToPIKS9TF+Os7iLIxr5M06k1L9NESNoKHBL7aXYBpnkCq3FEocPDHSKZHKIC8v+MQMjAHZQLDwjvxvEnQHj4zjSZdPIhtludtR9sJ6i0hiu1S2Jc1kRcGf3HsKL2tlEse9TXse2CmCx3g8ZPIWU8p6S8nVZJsv2GcuJ7amRd+cm3tDMQJq9QMoOr0kdcKpDjWEmt9qQXYjJ8baBbX9Ekq5Ng+bc2bIbJDNcUeo0dp1rthyriOLw== X-YMail-OSG: OA1EdX0VM1nkrWwFkz5_16ZHUg2av1NEFe0ZzZEX6I4CghW0R91JPmPlHMHRVH. TWi6O5SxKw_TsK6a50fbXLBVD1qPtmk0KaCvmDcnTQwAfD4vv8p3bMrYiZ77e8dYtjkiRpS6ezEs MerN6a9xrkcxmQT72YDWLH8RH7.9NKrUgUhIH8idXJRsuQQUxmPmfWvNKLm_pRUeZu7TGqeh6Sfp jZD2OFBxn6kQtxwx3qAFQRadvpC_nQjie36z2TWZfBCqKu0dd40i3pIwA38A8PD26ELjVRnh3KB9 ZT1ZPKi54E3EoL3TrYBlHs5g8MFIGCv54fzEB5tO0blat80cusjwMZNCosdYTSzMi.wiVx1iNMEG yDmfn13V6.VGcDgvsBVryjXm.XYvJUjj2yCLeIOhV2gaPuagn_3hlLwTZJ_SuQXCn5x5fmOs8o6F JA6PoYlFqp19vIejXdvY6JFT_iusk4ZxREFPV7QbmQe1z_Yu1T2xT1yqoWdTVYRuIaNwf0srE5LN wCB.xfFxt8JCsA8zWmp_4.LlCQ86R4hly1VQoSxn.Zra0MNY933Pzhk.CEG1LQnWg1BaltUZdMti PhWrJ6kaXbhE.tyJuzXiy3SKiSYomF4TFaCQjqd7s.SY5At42ctZa58GQFTMyOzrpbp6DKc1N5ki .Mled7AMVDSalQ7AfnAeNvhgdxnxS3SlSn9..8m6ZyTfjbnTnrO7UeinaU6Pl_DcwgrOzIni5Rsv qYPVhrBFN4LmYT4PpU8bMgrFw058P77NwsyiR3DuquqQqUejXjhYvySzBoQFCs18xOzQDWuHT_b7 j.VY2vRLOWpz7ZwwVCM.e9GAn684eqbMCP9CNejv27H2IXsLfNWwvvz.FhrBzpTMQ47jTzhrC2R7 E5u2xxSNx4xKCfzoMqcRy8Lrfv3NPq35bkOmgJEAKWQyLy6ep8e1UcXBs67kfV.rWn.2SDy30nf_ ujcILrs3Yg743fnwt8.z8Q_O0cC873D5Ph95BYn30O2zXcrnV8Rn6s2FZntDXuSymmKNEia6O_DT wwn6.MH0nHnNZfHUONd.6TYc6enYNn9bJ Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 11:48:23 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 59fcd78cf6ca1f9947f642daaa2c926d; Wed, 24 Oct 2018 11:48:17 +0000 (UTC) Message-ID: <5BD05BE3.9060202@aol.com> Date: Wed, 24 Oct 2018 07:47:47 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Spencer Dawkins CC: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <154035359808.31373.16459164548875812554.idtracker@ietfa.amsl.com> In-Reply-To: <154035359808.31373.16459164548875812554.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 11:48:27 -0000 Thanks, Spencer. This same question was raised elsewhere, so I will try to bring more clarity to it. - Stuart On 10/23/2018 11:59 PM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-extra-imap-replace-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm curious about one point - > > In its simplest form, the REPLACE command is a single-command > encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a > message, except that it avoids any of the quota implications or > intermediate states associated with the 3 command sequence. In > handling a REPLACE command, a server MUST NOT generate a response > code for the STORE +flags \DELETED portion of the sequence. > Additionally, servers supporting the REPLACE command MUST NOT infer > any inheritance of content, flags, or annotations from the message > being replaced. Finally, the replaced and replacing messages SHOULD > NOT be present in the mailbox at the same time. > > I can imagine that having the replaced and replacing messages present at the > same time is better than having the replaced message deleted and the replacing > message not stored due to quota limits when pipelining APPEND, STORE, EXPUNGE, > but is SHOULD the right level of requirement language here? Is MUST just a > non-starter? > > From nobody Wed Oct 24 04:56:16 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FC5130E4F for ; Wed, 24 Oct 2018 04:56:14 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3V1ZHaHj_0Q for ; Wed, 24 Oct 2018 04:56:12 -0700 (PDT) Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 6880F128A5C for ; Wed, 24 Oct 2018 04:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540382170; bh=8V9BZwicN+bUGumTnpCm+XzXiNLI0mN3wwLwiBR8Xa8=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=hmC9W2FDl0DKLG0JE0Guftonx3H6pBzMAZo6cSDY6Aq82VBQp6nPnGUz0pBZcht04ELl9oYKfUncuST0YUCWiC2CJgD5gHSSao0fxp+G91EHMKmoTi8W68gA+c9MRhrQ6+ro68VtINMCIJe9CsM325LpMg3aopgufR1hcLnQ5Non9Goevk07mSXk6EgXsRNUi4do1975bH5aLENCwGT5TecxRMEVolJ3PZgo/rqn8PWll5oa8Nn5jxlWR327PiWcNt139onwIbIY0bx6Ip323vmvM+6SOJ3SLMG1wcQyX7IZ7Xbt5jsG7VFBTNc2BmfBf8XPLJc/LMW4gYqVeB5MFQ== X-YMail-OSG: lktQJ2gVM1nv9Qa9ko2xNwuKZ5luV1gfexkaBCKlHBp7CCldkQxqslI1fjgK.g3 fudXuvdLWflMM5tE1kmEQtedpaEDsRKVbbOHxB96ssKGqcZ1wm..lVdCTMSsiIkvqhrssQKv8OSL 4FiiR2FwlzBmQ_BsC..vughN4GiquwLD9bTVsI49RXTj.YwCIPl.MtfiP0LS6iEvbsvkIb0uqhEe 9rhFG7eSmruz1VIqof65qHtXhhPP9_DOvX.aXiIoKtqfuXWrodY3mugFI_lhEo2H11uy1WSTEhtg BgpEhsY5MtfSBHAH3mom1yq8wvd_GslcCeJunlK3YkCYzPv94FfAR3MQQu_g51npotOCYMugZZz0 mSvub03tNEuU4fEg_g1_qrTmkxQs2qp0GOKhBMo0q3Rg1wxQVADAPZy8LZMQO.J9bB4_Mfkx8zHA g8qROk6wG03t9gomofII6E5C8HyBkcIeF0PqKeDasKw0cUEUcErBrHwp78YyP_WVdRTVKWXv_jyJ 4W_sjaAxLkw0sfOm6DeQRjIn8v6vO0CzjvUqPbXkfJ0uqw3gohRU3YbS4Id3XPGTzIkeXovtHiDL CN8049wtElmq5pgkX4xd9jS45mrk22mP4oiQkVvjvCpHwT5XYbhtXdDPQdyhVreuk5Pbd5K3fFfY SmBvVaBjgtIZHbLfP0oVkRJtuL.As3kHej_8sQM6IOLuJMyy1JeIzY9n4Ylr81_ZQStcOO9d0g3P P__FjrFlmi3T0Gx3qvGRmZjxIlw.CvdoRow1tMu2gHyXi.bz2j8qg0KlGGF7.MLvV5ZHPaMRMyUT 9ozyhsV5Hvige0dAfA1oaSvUbUlDUEZmRU3PQZRCZVJyNvsfQY9waqU2G8LZ.xNirezeQf7pBLYT R2QP6R1QgsYjQ3zeijw8aBmFbucbZizz._59FSR9liz0_Fgr3o94Xnx29k82Luar.DbOYY9CPUPv slDXih.WA1zXyDhtUUwPQGQFmIkB9ailTSGYU5x7MUSlRdo2vX9THXPdXzZGSe6Rw2R1qwNblsu0 tdyXomGL94lRV7nSwMOj0ykzgA97JhH_W Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 11:56:10 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp409.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 89890086e7d10ab2f7a6cfa1bbc751ed; Wed, 24 Oct 2018 11:46:05 +0000 (UTC) Message-ID: <5BD05B5E.9040206@aol.com> Date: Wed, 24 Oct 2018 07:45:34 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ben Campbell CC: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <154035632227.31409.14362991214477694122.idtracker@ietfa.amsl.com> In-Reply-To: <154035632227.31409.14362991214477694122.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Extra] Ben Campbell's Yes on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 11:56:15 -0000 Thanks, Ben. I agree with all 3 comments and will make the necessary corrections. On 10/24/2018 12:45 AM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-extra-imap-replace-02: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this effort. I am balloting "yes", but I have some minor (mostly > editorial) comments: > > §1: Is there a reason not to use the new boilerplate from RFC 8174? > > §3.4: "the intermediate states produced do not occur," > That seems an odd statement; one might say that if a state did not occur it was > not produced. Would it make sense to just say "the intermediate states do not > occur"? > > §3.5: "Unlike the APPEND command which is valid..." > Missing comma before "which". > > From nobody Wed Oct 24 05:28:59 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915B0130E5E for ; Wed, 24 Oct 2018 05:28:56 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDgmdLayr7HQ for ; Wed, 24 Oct 2018 05:28:54 -0700 (PDT) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 ED83613106B for ; Wed, 24 Oct 2018 05:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540384119; bh=yh09gb32BaLmLiYC78FEDavXwJJ7F1gATTCAE41EJwE=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=g6AXJsR0vQakRkRCh6wos38rcebWjeuW+FIJ8vErLrSUppZCBhGBVgzYUg2Jeb0xiK643qcgRA8oXJTnNuv0asAtHDT9w/Zwev/GJSOk5FzNXLJA7MeF6hzNZ3CiMKBGal/lSX8XonOjS9XyzSccuFj4XtVxQ4R57yiPviRIllo9ZlDEGoXryz7rYv6uuscwLWNgCQCXhCK9oRWR15BAbM3Z568Kfd8p5zxhmMS6uTSDjhuCowVUjLTCMTxohudPNdBO1N1sGrcWf4jJOc60Kv3IPRecT1jhZFNRgs0xQwWNPt+OgYMJAhO/b503U9Qs8az40Ua/dUs/rb/8ErQBPw== X-YMail-OSG: fI..PcsVM1myP1zByl0aYcAXcy.d4f1xvTACAiIeQAmbOW3jE8WnQbsqporHoVE Iauqb1Ui2wBfCHFr0Boq5lRF_cUPTwLjc4sEXk14XgN2IPNPZksPUi94j9tqgVjb8PaCI6c65z8i mS8kMI8pTGALjArKIbLFfij4LYBJtrBX0xfw9jD0Ffw92Sb13CAe912s.y9l0.TOaH.TK9WLi.Sp Owb5POqi_icp0c.2Iyh9Q.fZBTxf0R0oEG3fI4KZNKab2L73Wkp7UOXgitbFFvhbmmkyG3HoWoTq ZDa8.t6BuCiXjZWZvpSCwfbIms6iRGs283a9FTVWzsLg9zizz_tN0n_H4Nfk1txsY5XdYCs80r4i xm0OLmwbVDWY5GylZwiGeeDEGrJoKuHF5v1v1d8hgJk7FGQI.lCex719VPVIFCBMQYYm7Ky0tIei g8JQJG7RHSq_e6f11Js26ZA9P416o4NxUE_NS2nnYvHuXTr3JQZ845r0Sl8j7avbK9imujf8_KKA GUIWKuPOUm_t4nXae9.NindGp.WkgwTECx5Gj3DAza2CYX9Kthv0bTzTGe6SBeCA5zWScnWQ0cko nvm19eVmXde.2WllJkdaqt3ATlN73KaFGVrrAzsqGnn0WYME8kSq.GzmWvDKTYaf2dAjvvkCWUZ8 d57D7gVzWPqylYuQDRnQ1jRJ6s4fUnN9gLXgOVmFxrcVDU9d4aEZKxYN1UnRY2q6VH1ZC1xmiA4o GFNzWfSJ47j9sj7M7TapRMafMKzIU_VKwUgARrS7.j23U1IhQgvNOvQp3gu_V6y0.sWsahsygLck 71kb7jFQvv9OY3AYhoq8kXBSqdlYQ3hQEcIJv8sZxRng2KSsvLwugiBiHdgM9pZGI3adMv_rcKnI ZDjHrh3iFudmaAd01SsFBnK.Cu8UEKDw.sEIw8l7rUBAzsHgTv4SZx7.O7.yQbMOpZ_ooZFhh9QZ KSUoC5pihOhFUqZ3Kz3wPg0dXAW0HDQNEL5nTT3q.GkDoL8F8lzzDOjkIcwB3adNCTd6u5raAEst pCsnnZ7zI4mbuh3FO6jWEszUUXu4Oxm0DHQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 12:28:39 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp407.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 61a89d86a1b675f7cfdba762f4477cca; Wed, 24 Oct 2018 12:18:34 +0000 (UTC) Message-ID: <5BD062FB.6010002@aol.com> Date: Wed, 24 Oct 2018 08:18:03 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alissa Cooper CC: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org References: <154037844748.6895.10305259306527815276.idtracker@ietfa.amsl.com> In-Reply-To: <154037844748.6895.10305259306527815276.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap-replace-02: (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: Wed, 24 Oct 2018 12:28:57 -0000 Thanks, Alissa. I will incorporate your suggestion. On 10/24/2018 6:54 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-extra-imap-replace-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please take a look at the Gen-ART review. > > From nobody Wed Oct 24 18:31:12 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AA5130DCD for ; Wed, 24 Oct 2018 18:31:11 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjZnz3x6hCCa for ; Wed, 24 Oct 2018 18:31:09 -0700 (PDT) Received: from sonic312-22.consmr.mail.bf2.yahoo.com (sonic312-22.consmr.mail.bf2.yahoo.com [74.6.128.84]) (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 097D11292AD for ; Wed, 24 Oct 2018 18:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540431067; bh=zC8nFf8HvG6FGMW4RzP26KXG39s9BNOw8u8BXvRlx5A=; h=Date:From:To:Subject:From:Subject; b=uIKw/ZQwOzuxxAXXnbrM4E27sTpmj5VUcseFsrLVsa7ZHRCPlH5tQnPu/jD2toO5unvXMncFP6noxK3nScZEPIVttigPhWNoU+nVqmQozkZgDMc+ZlXsRxdOSEwPhSRav5o1R1V6JlToZclEkHLMQQdDIOfa3U6Ms6zbK9JhoVvSUG9lxhIV0BmzpNJol/x7yLD6eQuW/cDm0/sJNnljPLTjSLvP2WVMolDvMxGbCiwbsjLf44sErK/C4glNljPl3z2t3r9HV6JR0oAAF7h5CHcYkJ42vYHr05fs519blWVdMyFnHL5Rn5KcOc4PO6vxvCVVBN5agyFHovUcZqJs7Q== X-YMail-OSG: cgOujw0VM1npJIJU8JvrtPRH8Kbz4oHzB7Z6ul2bSKslk2rKsn.094eBp5UMOZx f_nzG8qZwaxnkPAHqLmdgFTEHjjjEHU.Q5JLdsalqJN1iClu2tgj8dcO5gtZaywlCOuvlMVJf8yC s89T_2YbVQb8LkNxagduMW6ytUwKxJiit29MKQEBMN3YV9CcLbG4WA2IStAdAi7XkuWMYjHR8HzH 5Il0ExgpNh7_QlzdznTqVrq5Cupeda61w.enneU93YGyHyxy1WdA3VDrDtmoxw2B12HKwvdaiSPA WBgt9QhdAyTS0S6GSnY1miUzkma0rHj81Va8flb.SJk2OLPBACplNCqOwXoQfQtWZmu8B_w.D6D3 D_bc5Q8HLTooh0vWjfEc_Om1vELabN_otayRZOhk34KRgCFzxDPlobDcq_tsfTj64G1gXhO4kJLc 4Px2H2bnx05709x0a6hlUWd7.ZK8Cy_5fJK_yEuESctjARp.e_KbpC.ZWjlCTikogWzfq2m4kcyB BTBCXrfAPVgls0TTIBuawvRhof5jfM2bjF6eXD1bmQRvi2P0iipAdIQTVgAQG_BgwRXG32HPeDa0 1LgZfBfZmjn9euux2K4F4WFLm_fhEJI_zzuVCmhJAicnzZgijnDrJqJN0Wwzh6s9Ys5kdGjJiV7w Gy4UATin5m5isuN9Np3MCZhnJR_iM8h99LkvO7IGRrthWxkrocQ4mK2tA6ne4BGF3WK6EUMJ9A1s 7_jmdc0N2vXygKzr2ACcSDwBA6TOBSa8RgGveP5O0BpeZWL4xNMgzx2EHTN1ANCpTwrxiZE4KqPw _GBVovzq9Ct6vGmfGCvbn_gfvu1K99U9B6cQdlADvG6B8hEoM13oQskYgcbiWZKyDywIZT0RQK75 .fdCDnjzhn0Xnw1Gr6TmuxW5qq_fkYSZLBeyFcJaBuEnWy59xtatvg_j3iaaS2IFlfdZZV3m_fKv vYGcVIgvVmVazxS3CMcl_1kNv6vxJ717f3Stqd3EHIdPbhET9jmoOzTAlUDoTZM2t1AY1tdwlsS7 O2MpogfdHGCektPnp Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Oct 2018 01:31:07 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8a4b0630d4dd80b61f586f2859098398 for ; Thu, 25 Oct 2018 01:31:04 +0000 (UTC) Message-ID: <5BD11CB4.5080909@aol.com> Date: Wed, 24 Oct 2018 21:30:28 -0400 From: Stuart Brandt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: extra@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Extra] Proposed update to draft-ietf-extra-imap-replace-02 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 Oct 2018 01:31:11 -0000 Based on yesterday's last call feedback, there seems to be 2 areas where wording of the draft lacked clarity for reviewers. The following are proposed changes that I will make once the submission tool reopens. Feedback is welcomed. A) Lack of clarity on state diagram impacts relative to UID REPLACE Current... Unlike the APPEND command which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Proposed... Unlike the APPEND command, which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Additionally, the REPLACE extension intentionally follows the convention for UID commands found in [RFC3501] section 6.4.8 in that the UID variant of the command does not support use from the authenticated state. B) Lack of clarity in final paragraph of the section 2 Current... In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the 3 command sequence. In handling a REPLACE command, a server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. Finally, the replaced and replacing messages SHOULD NOT be present in the mailbox at the same time. Proposed... In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the 3 command sequence. Server developers are encouraged to implement REPLACE as an atomic operation to simplify error handling, minimize operational concerns, and reduce potential security problems. For systems where this is not possible, communication with the requesting client must ensure no confusion of message store state. A server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced. From nobody Thu Oct 25 08:13:29 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C762130E76; Thu, 25 Oct 2018 08:13:18 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <154048039825.16407.9558029979044586316@ietfa.amsl.com> Date: Thu, 25 Oct 2018 08:13:18 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap-replace-03.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 Oct 2018 15:13:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP REPLACE Extension Author : Stuart Brandt Filename : draft-ietf-extra-imap-replace-03.txt Pages : 11 Date : 2018-10-25 Abstract: This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap-replace-03 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap-replace-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap-replace-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 25 10:45:55 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5102B130DFC; Thu, 25 Oct 2018 10:45:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 H0fDQ_oLg29n; Thu, 25 Oct 2018 10:45:45 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 509211277D2; Thu, 25 Oct 2018 10:45:44 -0700 (PDT) X-AuditID: 12074422-b8dff7000000039d-96-5bd201457ec3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7A.49.00925.54102DB5; Thu, 25 Oct 2018 13:45:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id w9PHjdil012381; Thu, 25 Oct 2018 13:45:39 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9PHjYTK031677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Oct 2018 13:45:36 -0400 Date: Thu, 25 Oct 2018 12:45:34 -0500 From: Benjamin Kaduk To: Stuart Brandt Cc: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org Message-ID: <20181025174533.GD45914@kduck.kaduk.org> References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> <5BCFD689.3040004@aol.com> <20181024022358.GQ45914@kduck.kaduk.org> <5BCFE35D.5020703@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BCFE35D.5020703@aol.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1nVjvBRtsGO7qMWfM/NZLR7tWclm MWtlG5PF/6s9zBYz/kxktuh6Ge7A5nF/90p2j8vfW5k8liz5yRTAHMVlk5Kak1mWWqRvl8CV sWT9dpaCl2IVr4++YmtgXC3UxcjJISFgIvF17i3mLkYuDiGBNUwSf65dYodwNjJKTJj2GCpz l0ni9uRrzCAtLAKqEv+Wz2IFsdkEVCQaui+DxUUE1CS+3poL1s0ssJRRYsOURnaQhLBAgkR/ 0zEwmxdo38xHC5lAbCGBTYwS/x/xQcQFJU7OfMICYjMLaEnc+PcSqIYDyJaWWP6PAyTMKaAu 0bsEolVUQFlib98h9gmMArOQdM9C0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO9 3MwSvdSU0k2MoMBmd1HawTjxn9chRgEORiUe3gnfLkYLsSaWFVfmHmKU5GBSEuVNTAEK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuHdexsox5uSWFmVWpQPk5LmYFES553YsjhaSCA9sSQ1OzW1 ILUIJivDwaEkwavFcClaSLAoNT21Ii0zpwQhzcTBCTKcB2j4vv8gw4sLEnOLM9Mh8qcYFaXE eSNBmgVAEhmleXC9oMQjkb2/5hWjONArwrxsIFU8wKQF1/0KaDAT0OAZChdABpckIqSkGhiF 554Lee5X6b56f77C0W+Pz8Tucn0YN2dLx/OXtltuHK39oSatqupoqJratUX+xbp7WmlHpdYf 3f7Yep+Q35dFB/UaFrUE3edx79zNs2LqfkGmn10Vmdddj3G/Ut8140Be3zq1nwdnBWxdzyEf dyCZq+iL5s8lTh6Sxz4G+alcC3m57NzD1bsuKbEUZyQaajEXFScCAP+UoL8XAwAA Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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, 25 Oct 2018 17:45:47 -0000 On Tue, Oct 23, 2018 at 11:13:33PM -0400, Stuart Brandt wrote: > On 10/23/2018 10:23 PM, Benjamin Kaduk wrote: > > On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote: > >> Thanks for the feedback. Comments inline. > >> > >> On 10/23/2018 5:16 PM, Benjamin Kaduk wrote: > >>> Benjamin Kaduk has entered the following ballot position for > >>> draft-ietf-extra-imap-replace-02: No Objection > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> Section 1 > >>> > >>> (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be > >>> used instead of the RFC 2119 boilerplate.) > >>> > >>> Section 3.5 > >>> > >>> Unlike the APPEND command which is valid in the authenticated state, > >>> the REPLACE and UID REPLACE commands MUST only be valid in the > >>> selected state. This difference from APPEND is necessary since > >>> REPLACE operates on message sequence numbers. > >>> > >>> The stated justification applies only to REPLACE. What is the > >>> justification for disallowing UID REPLACE from the authenticated state? > >> > >> The syntax of REPLACE identifies the source message's Mailbox by means > >> of the currently selected Mailbox, thus requiring Selected state. > >> > >> An optional source-mailbox parameter could be added to the syntax just > >> for the UID REPLACE case, but other UID command variants such as those > >> discussed in RFC3501 section 6.4.8 chose not to introduce UID specific > >> syntax for specifying source-mailbox in order to support actions from > >> Authenticated state alone. I'd prefer not to forge new ground in that > >> area with this particular specification. > > > > I probably should have made it clear: I also prefer to not forge such new > > ground in this specification. But does it make sense to make a nod to this > > reality in the document and note that this restriction is also applied to > > UID REPLACE for consistency? > > Makes sense. Would the nod be more helpful when discussing state impacts > (section 3.5) or when discussing UID REPLACE syntax (section 3.3)? It feels more natural to me in Section 3.5, but I have no claim to be an authority in this matter :) Thanks, Benjamin From nobody Thu Oct 25 15:57:17 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7A5130DBE for ; Thu, 25 Oct 2018 15:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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=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 eDNH0YbaCB00 for ; Thu, 25 Oct 2018 15:57:15 -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 5FFA8127B92 for ; Thu, 25 Oct 2018 15:57:15 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9PMsSYw010902; Thu, 25 Oct 2018 22:57:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=T+a+Add7YRbshN0uuzmFYr2U+KJENBM3o+ymR5OD/Aw=; b=eQDNaIiicwZ3zVEi0ujhN4akpUdIyqCn9ZxNcysO/LL/ht+lJxpr9DxjLY1Hkria8fOP tTvEBVOES5z/FwgIUWH9ZU8pTHTgSQUR1/gbKrIwJ1CANJ3NwqgJyRPpCccBD97DgvWz kqsM2dqpcDzYcl5vvKkfBwhAA/jwz+bNmNk77ieIyrl7C5qSNHAnCL18eIXrqCfOVxhX 1wCMRbJB53Q6E1WtAPenaDa1LuMjx1x4ogP+rUqGie9FyMHe1t9nCZJFoPJ7Ki7211dW zOcn+QdxTuhtMVRilnLdDz0+bQNRzGsPEOY1XQm808RgdyINYufTcXKGnhdSkrhl8f/j 4g== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2n7usumccx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 22:57:12 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9PMv7Od020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 22:57:07 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9PMv6Uf011507; Thu, 25 Oct 2018 22:57:06 GMT Received: from [10.159.255.166] (/10.159.255.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Oct 2018 15:57:06 -0700 From: "Chris Newman" To: "Stuart Brandt" Cc: extra@ietf.org Date: Thu, 25 Oct 2018 15:56:59 -0700 X-Mailer: MailMate (1.12r5523) Message-ID: In-Reply-To: <5BD11CB4.5080909@aol.com> References: <5BD11CB4.5080909@aol.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9057 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=470 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250189 Archived-At: Subject: Re: [Extra] Proposed update to draft-ietf-extra-imap-replace-02 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 Oct 2018 22:57:17 -0000 On 24 Oct 2018, at 18:30, Stuart Brandt wrote: > B) Lack of clarity in final paragraph of the section 2 > > Current... > In its simplest form, the REPLACE command is a single-command > encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for > a > message, except that it avoids any of the quota implications or > intermediate states associated with the 3 command sequence. In > handling a REPLACE command, a server MUST NOT generate a response > code for the STORE +flags \DELETED portion of the sequence. > Additionally, servers supporting the REPLACE command MUST NOT infer > any inheritance of content, flags, or annotations from the message > being replaced. Finally, the replaced and replacing messages > SHOULD > NOT be present in the mailbox at the same time. > > Proposed... > In its simplest form, the REPLACE command is a single-command > encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for > a > message, except that it avoids any of the quota implications or > intermediate states associated with the 3 command sequence. Server > developers are encouraged to implement REPLACE as an atomic > operation > to simplify error handling, minimize operational concerns, and > reduce > potential security problems. For systems where this is not > possible, > communication with the requesting client must ensure no confusion > of > message store state. A server MUST NOT generate a response code > for > the STORE +flags \DELETED portion of the sequence. Additionally, > servers supporting the REPLACE command MUST NOT infer any > inheritance > of content, flags, or annotations from the message being replaced. This is a good improvement. I consider it important to avoid an atomic behavior requirement to increase chances of implementation, but the new wording does a better job of stating the technical goal. - Chris From nobody Thu Oct 25 16:16:53 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDF312D7F8 for ; Thu, 25 Oct 2018 16:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPe0go_yHRcz for ; Thu, 25 Oct 2018 16:16:51 -0700 (PDT) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 538FC128D0C for ; Thu, 25 Oct 2018 16:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540509410; bh=gXTNGNpKTn1TOThDqFs2rMQBd5rpGGCUestdpKdNfIo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=YhYFwrEcS8oosYX05UGw56Mm1uKKnK3X8V0ILHXPI6gGbgaobx17eHFypdn+aZE1AzYQ/fr5I0ez/XUyvPkeIwp1HTdtImmRtiL9oxj0ve74NCeTVT7aKpsKpY0LAjUBXZpiwSphGd0yrC57xofjJ6CqUEZL7fbfAtRCawvFPxVNhwiAOWecnbL9TU0a7q9CstMmvT476259ZIdjAeSbp7JMLIctucgugCjdBvqlMO8RPBjziMss9T+XJgzojNGCS3GfzmZVT0vpwAdAEXR4w59ykghdLZq+mZFyHOfHY/iXyrsg8lBk6ykKKi0lk1DgK4pi2S583J11xFms3CUQsw== X-YMail-OSG: S3jECYIVM1mgTmKIp3W_ZRToO3Oi9LhF2QJEnrLG1QAKSobHyVufNYJFhNNMbt5 Y_jwccAoGqOR1AbNF57AtwABF6aTSwVNR78U29XeC0u7Pe0dAvwVoPlkDHSOsYR2Q4FbO_54Qq3Q UXAtftCAxEq35yIDr62KKlfVWMsSZcNzYpfTbph.oX_tkhj.RDV2L5wYM8dq8nwzz2JvIXn6BAbv 2rFuiueeQ93ywEwcmEmiR1LIHEg9IN3dMapKNWkRn6ZtBexozGDTPJ8TtDd_iQ6gRkF7SSV.5lA1 JxzNp4kdYNH7PbaJmCzm.A3jtW1Kr4AE3gy2Tc.AzkVW47Uvsaj8JTKUgKzYK3LYBSuYcIhAdO3Q KYna5hxwdJ3HW9FMigcmvZWDy0MQLun8TqwjymhwXi80ydHt6pY9IrVmnTCAUnIqCjMYXtwWeDrm kVmLVBMQk0Lnk__PzxHlxZENwt0IY1.BLN3ult.qxbLzP07GlTKFCeadIZt3qFyKeKIyu9wxEjBz O_b63Vne2wYtrmLteYW5vr1JKdnD3HmUZjJ7ovKa7qJgVrmy3xuC.tD.zqrrrDlXnI2iZyPnAOc8 SNZwMl1.NGVtyyR3FdKTopkgfetkkQTifTgOXOmJ5H9CbolkVc3b_LFzKZj85FioNRToDyIrIUZP KGl_zuRhmy.1ih1lCEZzZIq7QgULs29_KG6G0fSde2ltb21VVEXes40DGDRFUNpi4V051bWoMrGu Mh.1JI0MINc1Jac31kW216IJx.pLV70G.WrLQQs5nW__e1K.srtJ2ZIBkf9lNsgd_Bt1uhb.raxe DJHAbDSnCT0kNhT7oQMY2_WSRbl1EC4YI0uIzJcvfhlVNWWFwr2xV8h2S1dt0d5YVRU88kguk9F5 JweSCGryOykQbEYYWamk652Irr_fasYNXwfAbk5J0V4.t70OYPgJrL2FSIwT5NXNZvd1Zr2EOcD1 kDoZ7lWc4l26Q7l7Ia1sozl0oSOwqWj44BtO3H2oklmeUv2AgrH8EEfCx9d6kBWdvkLQ_GRroaO1 WVe5qRNFgSGxjAOfOZgXl5zNbBUvc Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Oct 2018 23:16:50 +0000 Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 653bb476d6f7ab7202cb4edd6479afe7; Thu, 25 Oct 2018 23:06:47 +0000 (UTC) To: Benjamin Kaduk References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com> <5BCFD689.3040004@aol.com> <20181024022358.GQ45914@kduck.kaduk.org> <5BCFE35D.5020703@aol.com> <20181025174533.GD45914@kduck.kaduk.org> Cc: The IESG , draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org From: Stuart Brandt Message-ID: <5BD24C5A.4030201@aol.com> Date: Thu, 25 Oct 2018 19:06:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20181025174533.GD45914@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (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, 25 Oct 2018 23:16:53 -0000 Thanks for the continued feedback, Benjamin. I'm glad you suggested section 3.5 because that's exactly where I added additional text in the -03 update today. Hopefully the additional text addresses your original feedback. - Stuart On 10/25/2018 1:45 PM, Benjamin Kaduk wrote: > On Tue, Oct 23, 2018 at 11:13:33PM -0400, Stuart Brandt wrote: >> On 10/23/2018 10:23 PM, Benjamin Kaduk wrote: >>> On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote: >>>> Thanks for the feedback. Comments inline. >>>> >>>> On 10/23/2018 5:16 PM, Benjamin Kaduk wrote: >>>>> Benjamin Kaduk has entered the following ballot position for >>>>> draft-ietf-extra-imap-replace-02: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Section 1 >>>>> >>>>> (RFC 8174 provides an updated version of the BCP 14 boilerplate that can be >>>>> used instead of the RFC 2119 boilerplate.) >>>>> >>>>> Section 3.5 >>>>> >>>>> Unlike the APPEND command which is valid in the authenticated state, >>>>> the REPLACE and UID REPLACE commands MUST only be valid in the >>>>> selected state. This difference from APPEND is necessary since >>>>> REPLACE operates on message sequence numbers. >>>>> >>>>> The stated justification applies only to REPLACE. What is the >>>>> justification for disallowing UID REPLACE from the authenticated state? >>>> >>>> The syntax of REPLACE identifies the source message's Mailbox by means >>>> of the currently selected Mailbox, thus requiring Selected state. >>>> >>>> An optional source-mailbox parameter could be added to the syntax just >>>> for the UID REPLACE case, but other UID command variants such as those >>>> discussed in RFC3501 section 6.4.8 chose not to introduce UID specific >>>> syntax for specifying source-mailbox in order to support actions from >>>> Authenticated state alone. I'd prefer not to forge new ground in that >>>> area with this particular specification. >>> >>> I probably should have made it clear: I also prefer to not forge such new >>> ground in this specification. But does it make sense to make a nod to this >>> reality in the document and note that this restriction is also applied to >>> UID REPLACE for consistency? >> >> Makes sense. Would the nod be more helpful when discussing state impacts >> (section 3.5) or when discussing UID REPLACE syntax (section 3.3)? > > It feels more natural to me in Section 3.5, but I have no claim to be an > authority in this matter :) > > Thanks, > > Benjamin > From nobody Fri Oct 26 03:41:25 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99454130DD0; Fri, 26 Oct 2018 03:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLIoHiIOOxXv; Fri, 26 Oct 2018 03:41:22 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 320B6130DC0; Fri, 26 Oct 2018 03:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540550481; d=isode.com; s=june2016; i=@isode.com; bh=NRGHV9bTcAHBuQMWXdO8SN6BeaOu3ikfKNAX1EAHs4c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VA4XmbJ637/PJK6rPkgUD+oNRks5h2WAfqv5kgP78unQoWLltlkG91AZ3+ZiBvXiUd81MG 9Yw9bCcIawN4BiaQ0Lybp8HaE5LR4joVW86yUn1thhpo4O3L66t6mWzZwhlmJSJx9vWazM QJxzTgmAOVeQqQt3kHq+gwar58p6p0Q=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 26 Oct 2018 11:41:21 +0100 To: Alissa Cooper , Robert Sparks Cc: extra@ietf.org, draft-ietf-extra-imap-replace.all@ietf.org, General Area Review Team References: <153937476673.29113.3479129914002220994@ietfa.amsl.com> <3468495D-FEDC-46E8-AF86-87E77038938F@cooperw.in> From: Alexey Melnikov Message-ID: <3ef88da8-0406-3e07-f2e5-dd8a826bd34c@isode.com> Date: Fri, 26 Oct 2018 11:40:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <3468495D-FEDC-46E8-AF86-87E77038938F@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] [Gen-art] Genart last call review of draft-ietf-extra-imap-replace-01 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: Fri, 26 Oct 2018 10:41:24 -0000 Hi all, On 24/10/2018 11:55, Alissa Cooper wrote: > Robert, thanks for your review. I flagged it in my ballot since there has been no response. I entered a No Objection ballot. Actually, this change has an error and should instead be: uid =/ "UID" SP replace Best Regards, Alexey >> On Oct 12, 2018, at 10:06 PM, Robert Sparks wrote: >> >> Reviewer: Robert Sparks >> Review result: Ready with Nits >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-extra-imap-replace-01 >> Reviewer: Robert Sparks >> Review Date: 2018-10-12 >> IETF LC End Date: 2018-10-16 >> IESG Telechat date: 2018-10-25 >> >> Summary: Ready for publication as a proposed standard, but with nits to consider before publication >> >> Consider using: >> >> uid =/ replace >> >> instead of redefining uid. >> >> >> >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra From nobody Sun Oct 28 08:07:13 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664DA128CE4 for ; Sun, 28 Oct 2018 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD0Iij6hIi_E for ; Sun, 28 Oct 2018 08:07:10 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D5A64127333 for ; Sun, 28 Oct 2018 08:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540739229; d=isode.com; s=june2016; i=@isode.com; bh=MOFSqLim8r8ZfygxIM6vsCj74Hd/M70mbuPEBGHFkM8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Ht9FlNB59f35gr/DpfLL9cbG9H9hb51zFqxxQjMxbZcTWH+7s31JXa/aWOP97Z2UsSl8yb 0oyR/d6nJx0kbyk5uVPL07uJCx458yxa9oWesa8ZRaUqLQ3vc9omhktWPhWPrguAQAV+8a V16RORN3gfgoLonQwbDVm2L/I5IHfm8=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 28 Oct 2018 15:07:09 +0000 To: extra@ietf.org From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: Date: Sun, 28 Oct 2018 15:07:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: [Extra] Comments on draft-ietf-extra-sieve-special-use-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: Sun, 28 Oct 2018 15:07:12 -0000 Hi all, I've just tried to implement this Sieve extension and I have a couple of comments: 3. Test "specialuse_exists" Usage: specialuse_exists [] This defines an optional argument. According to the base Sieve RFC 5228, optional arguments must be tagged: 2.6.1. Positional Arguments Positional arguments are given to a command that discerns their meaning based on their order. When a command takes positional arguments, all positional arguments must be supplied and must be in the order prescribed. and 2.6.3. Optional Arguments Optional arguments are exactly like tagged arguments except that they may be left out, in which case a default value is implied. Because optional arguments tend to result in shorter scripts, they have been used far more than tagged arguments. So I don't think you can have "mailbox" being positional without a tag! 4. ":specialuse" Argument to "fileinto" Command Usage: fileinto [:specialuse ] Can I suggest that all special-use-flag strings should not include the leading "\" character? It requires escaping in Sieve, so people might make mistakes when writing scripts. Best Regards, Alexey From nobody Mon Oct 29 05:06:47 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82765130ED0 for ; Mon, 29 Oct 2018 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo6BT_ShA7Sx for ; Mon, 29 Oct 2018 05:06:45 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id D84BB130EC0 for ; Mon, 29 Oct 2018 05:06:44 -0700 (PDT) Received: from [192.168.1.104] (lab.inertia-technology.com [217.119.239.130]) by mail.dovecot.fi (Postfix) with ESMTPSA id E4B5B2B3C8D; Mon, 29 Oct 2018 14:06:32 +0200 (EET) To: Alexey Melnikov , extra@ietf.org References: From: Stephan Bosch Message-ID: Date: Mon, 29 Oct 2018 13:06:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-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: Mon, 29 Oct 2018 12:06:46 -0000 Hi Alexey, Op 28-10-2018 om 16:07 schreef Alexey Melnikov: > Hi all, > I've just tried to implement this Sieve extension and I have a couple of > comments: > > 3. Test "specialuse_exists" > > Usage: specialuse_exists [] > > > This defines an optional argument. According to the base Sieve RFC 5228, > optional arguments must be tagged: > > 2.6.1. Positional Arguments > > Positional arguments are given to a command that discerns their > meaning based on their order. When a command takes positional > arguments, all positional arguments must be supplied and must be in > the order prescribed. > > and > > 2.6.3. Optional Arguments > > Optional arguments are exactly like tagged arguments except that they > may be left out, in which case a default value is implied. Because > optional arguments tend to result in shorter scripts, they have been > used far more than tagged arguments. > > So I don't think you can have "mailbox" being positional without a tag! Then what about the entirety of the "imap4flags" extension? Lots of tag-less optional arguments can be found there. I am not against having some ":mailbox" tag here, but the current syntax does make things more concise. > 4. ":specialuse" Argument to "fileinto" Command > > Usage: fileinto [:specialuse ] > > > Can I suggest that all special-use-flag strings should not include the > leading "\" character? It requires escaping in Sieve, so people might > make mistakes when writing scripts. I have no strong opinion about that. Disadvantage of doing that is that it can be confusing for people with IMAP experience and it becomes inconsistent with imap4flags. Anyone else want to pitch in? Regards, -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kenttä Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- From nobody Mon Oct 29 09:11:58 2018 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1A130FFA; Mon, 29 Oct 2018 09:11:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , extra@ietf.org, brong@fastmailteam.com, draft-ietf-extra-imap-replace@ietf.org, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154082951639.4741.12149866932969072823.idtracker@ietfa.amsl.com> Date: Mon, 29 Oct 2018 09:11:56 -0700 Archived-At: Subject: [Extra] Protocol Action: 'IMAP REPLACE Extension' to Proposed Standard (draft-ietf-extra-imap-replace-03.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 Oct 2018 16:11:57 -0000 The IESG has approved the following document: - 'IMAP REPLACE Extension' (draft-ietf-extra-imap-replace-03.txt) as Proposed Standard This document is the product of the Email mailstore and eXtensions To Revise or Amend Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/ Technical Summary This spec extends IMAP to provide a way for clients to replace an existing message with a new message. This is particularly useful for updating Draft messages, as it can avoid transient quota limitations. Working Group Summary This is a draft which has been around for a while without a good working group to progress it. There was some discussion of whether it could be implemented as an extension to the existing APPEND command instead, but the need to have a mailbox selected in order to EXPUNGE the original message made it clear that a new command would be more consistent. Document Quality The document spells out interactions with other extensions. Several implementors are interested in implementing this extension. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Alexey Melnikov RFC Editor Note In Section 5, change the last ABNF production to read: OLD: uid =/ replace New: uid =/ "UID" SP replace From nobody Tue Oct 30 13:15:03 2018 Return-Path: X-Original-To: extra@ietfa.amsl.com Delivered-To: extra@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C585812D4F0 for ; Tue, 30 Oct 2018 13:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT7Pq_qzB64M for ; Tue, 30 Oct 2018 13:15:00 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5709E1276D0 for ; Tue, 30 Oct 2018 13:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540930499; d=isode.com; s=june2016; i=@isode.com; bh=Fd0y315Y0H13A1pEmLsfQSpciedbdUb878//4cr8P5U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=E8GutGEUmm7lRDUmIN0ywbYCSzfgSs3kmbJV1+AOfv2mznICnsz2XJ9nuKcWaPXEGRMl5d 1NTD8V//b7C+6SkLqAnY9g1H9r12xdpBf4GJdXZ6SSpy0Kui9/zYD6bG8Zjna3qeWyEtoD vj0eCXP2F5+vQMAbJlORPRsYskvTWbk=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 30 Oct 2018 20:14:58 +0000 To: Stephan Bosch , extra@ietf.org, Ned Freed References: From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: <6b72363d-6f00-3ef7-2398-05690926b6f5@isode.com> Date: Tue, 30 Oct 2018 20:15:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-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: Tue, 30 Oct 2018 20:15:02 -0000 Hi Stephan, On 29/10/2018 12:06, Stephan Bosch wrote: > Hi Alexey, >=20 >=20 > Op 28-10-2018 om 16:07 schreef Alexey Melnikov: >> Hi all, >> I've just tried to implement this Sieve extension and I have a couple of >> comments: >> >> 3.=C2=A0 Test "specialuse_exists" >> >> =C2=A0=C2=A0=C2=A0 Usage:=C2=A0 specialuse_exists [] >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 >> >> This defines an optional argument. According to the base Sieve RFC 5228, >> optional arguments must be tagged: >> >> =C2=A0=C2=A0 2.6.1.=C2=A0 Positional Arguments >> >> =C2=A0=C2=A0=C2=A0 Positional arguments are given to a command that disce= rns their >> =C2=A0=C2=A0=C2=A0 meaning based on their order.=C2=A0 When a command tak= es positional >> =C2=A0=C2=A0=C2=A0 arguments, all positional arguments must be supplied a= nd must be in >> =C2=A0=C2=A0=C2=A0 the order prescribed. >> >> =C2=A0 and >> >> =C2=A0=C2=A0 2.6.3.=C2=A0 Optional Arguments >> >> =C2=A0=C2=A0=C2=A0 Optional arguments are exactly like tagged arguments e= xcept that they >> =C2=A0=C2=A0=C2=A0 may be left out, in which case a default value is impl= ied.=C2=A0 Because >> =C2=A0=C2=A0=C2=A0 optional arguments tend to result in shorter scripts, = they have been >> =C2=A0=C2=A0=C2=A0 used far more than tagged arguments. >> >> So I don't think you can have "mailbox" being positional without a tag! >=20 > Then what about the entirety of the "imap4flags" extension? Guilty as charged :-). I entirely forgot about that and the reason why I haven't noticed is because my implementation doesn't support "variables" extension, so variable name parameter to addflag/removeflag/setflag is never allowed. Any other opinions (Ned?). I just want to make sure that if we violating some kind of architectural principle specified in the base Sieve script, than we decide to do this deliberately. (Or maybe we just agree that there is no architectural principle to begin with.) > Lots of > tag-less optional arguments can be found there. I am not against having > some ":mailbox" tag here, but the current syntax does make things more > concise. >=20 >> 4.=C2=A0 ":specialuse" Argument to "fileinto" Command >> >> =C2=A0=C2=A0=C2=A0 Usage:=C2=A0 fileinto [:specialuse ] >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> >> Can I suggest that all special-use-flag strings should not include the >> leading "\" character? It requires escaping in Sieve, so people might >> make mistakes when writing scripts. >=20 > I have no strong opinion about that. Disadvantage of doing that is that > it can be confusing for people with IMAP experience and it becomes > inconsistent with imap4flags. Yes, that is true. At the same time in JMAP we can do remove leading "\" character from flag names as well. So yes, I am not fully decided on this issue. Anybody else wants to comment? > Anyone else want to pitch in? >=20 > Regards, >=20