Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9sr2C070865; Tue, 30 Nov 2004 01:54:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAU9srf1070864; Tue, 30 Nov 2004 01:54:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9sq4h070759 for ; Tue, 30 Nov 2004 01:54:52 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 822C0154009; Tue, 30 Nov 2004 09:54:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Philip Guenther Cc: Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> <200411292223.iATMNjTP062535@lab.smi.sendmail.com> In-Reply-To: <200411292223.iATMNjTP062535@lab.smi.sendmail.com> Message-ID: <20041130095434.13627.39231.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 30 Nov 2004 09:54:34 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 29 22:23:45 2004, Philip Guenther wrote: > > Ken Murchison writes: > ... > >Yes. The draft makes the false assumption that *all* existing > >implementations use the 'd' right to control DELETE. Cyrus made > the >decision a while back to separate mailbox ops (DELETE) from > message ops >(\Deleted and EXPUNGE). Its unfortunate that RFC 2086 > was >vague/ambiguous w.r.t. DELETE. > ... > >One easy way to do this might be to make 'c' a macro in the new > draft >just like 'd' and create a new bit for CREATE (e.g. 'k') > Then the >mapping would be: > > > >Cyrus: 'c' -> "kx", 'd' -> "te" > >Others: 'c' -> "k", 'd' -> "xte" > > This makes sense to me, but our server has this problem too, being > distantly derived from Cyrus. Does anyone actually know of a server > that controls DELETE with the 'd' right? CommunigatePro does, but *also* controls it with the "c" right on the parent. (In other words, given A/B, issuing DELETE A/B requires "c" right in A and "d" right in B) I would guess that Sun's implementation might require the parent "c" right, as well, given that their JavaMail [client] API documents that as required, but that's pure speculation on my part - I can't access their server implementation's documentation. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATMNlEE050556; Mon, 29 Nov 2004 14:23:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATMNlQd050555; Mon, 29 Nov 2004 14:23:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATMNkCa050546 for ; Mon, 29 Nov 2004 14:23:46 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iATMNkEU012024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 29 Nov 2004 14:23:46 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iATMNkEU012024 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=ROyfw0bP6jfTkpK19lgv5l/ILzsvjk31AJ7fJtD2hO0nwKtoZHI9hpO7SPUR5gV1m vRtGF1PCebdwQtsqvSv+xVfjlSaEZFC6NQVFeA49PE/fpZBwNf2q7I51RtRWx9c6wf1 cJU9rSW/pNASsh2whVpgW/GUbR7BMvb2QsvNqfE= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iATMNjTP062535; Mon, 29 Nov 2004 14:23:45 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411292223.iATMNjTP062535@lab.smi.sendmail.com> To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG From: Philip Guenther Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) In-reply-to: <41991116.9010001@oceana.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> Date: Mon, 29 Nov 2004 14:23:45 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: ... >Yes. The draft makes the false assumption that *all* existing >implementations use the 'd' right to control DELETE. Cyrus made the >decision a while back to separate mailbox ops (DELETE) from message ops >(\Deleted and EXPUNGE). Its unfortunate that RFC 2086 was >vague/ambiguous w.r.t. DELETE. ... >One easy way to do this might be to make 'c' a macro in the new draft >just like 'd' and create a new bit for CREATE (e.g. 'k') Then the >mapping would be: > >Cyrus: 'c' -> "kx", 'd' -> "te" >Others: 'c' -> "k", 'd' -> "xte" This makes sense to me, but our server has this problem too, being distantly derived from Cyrus. Does anyone actually know of a server that controls DELETE with the 'd' right? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPDEUUB081513; Thu, 25 Nov 2004 05:14:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPDEUTs081511; Thu, 25 Nov 2004 05:14:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPDEP6M080856 for ; Thu, 25 Nov 2004 05:14:29 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id AAA42154009; Thu, 25 Nov 2004 13:14:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG , Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> <41A3AE85.3030109@isode.com> In-Reply-To: <41A3AE85.3030109@isode.com> Message-ID: <20041125131410.29723.97056.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 25 Nov 2004 13:14:10 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Nov 23 21:41:25 2004, Alexey Melnikov wrote: > Suggested text: > Rights is a string listing a (possibly empty) set of alphanumeric > characters, each character listing a set of operations which is > being > controlled. Lowercase letters are reserved for ''standard'' > rights, listed > below. (Note that for compatibility with deployed clients and > servers uppercase rights are not allowed). > > And update ABNF to enforce this. > > That's fine by me. > In the ACL2 document we should say something like this: > Unlike the RFC 2086, the letter rights are case-insensitive, so > the right "R" is the same as the right "r". > > That's also fine by me. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOIv2Uv074198; Wed, 24 Nov 2004 10:57:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOIv2gc074197; Wed, 24 Nov 2004 10:57:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOIux89074100 for ; Wed, 24 Nov 2004 10:57:01 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOIuqPB010197 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 10:56:52 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOIuqPB010197 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=rU5Im1WByzv+2vQC6eLHKW16Ur5R8U4wataHxMdUlArzXschUvJ5OtdCi69NTYzNa pUHa7cS3ClsOUIlWy6FqZV3QBatFDYT9xYHK+Yu9400MoY6dSvUM/3msl317KYlGYlz gJ4lIKTFEub53YGOdwlCny9mk6u/vk5yHe4Ru2E= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOIuq5U071235; Wed, 24 Nov 2004 10:56:52 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411241856.iAOIuq5U071235@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <41A3AE85.3030109@isode.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> <41A3AE85.3030109@isode.com> Date: Wed, 24 Nov 2004 10:56:52 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Suggested text: > Rights is a string listing a (possibly empty) set of alphanumeric > characters, each character listing a set of operations which is being > controlled. Lowercase letters are reserved for ''standard'' rights, > listed below. (Note that for compatibility with deployed clients and > servers uppercase rights are not allowed). I can live with this. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBLBA7081032; Wed, 24 Nov 2004 03:21:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOBLBwT081031; Wed, 24 Nov 2004 03:21:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBL6lD080631 for ; Wed, 24 Nov 2004 03:21:09 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 24 Nov 2004 11:20:36 +0000 Message-ID: <41A3AE85.3030109@isode.com> Date: Tue, 23 Nov 2004 21:41:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > Looks like there was actually unanimity among seven voters to require > both clients and servers to send only lower-case rights in 2086upd, > but some quibbling about other details (whether to accept upper-case, > what precise wording to use). Cyrus' proposed wording was: > >> 'Rights in 2086upd are case-insenstive, however clients and servers >> MUST use lower-case rights to be compatible with clients or servers >> supporting the original 2086 specification.' > > Philip suggested a slight modification that servers that advertise > support for 2086upd should be able to accept upper-case rights as well > (but not send them, if I understand). > > Alexey and Dave suggested that the spec not even use the word > "case-insensitive" to not confuse people. > > So Alexey, how about you propose new text for 2086upd? Suggested text: Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Lowercase letters are reserved for ''standard'' rights, listed below. (Note that for compatibility with deployed clients and servers uppercase rights are not allowed). And update ABNF to enforce this. In the ACL2 document we should say something like this: Unlike the RFC 2086, the letter rights are case-insensitive, so the right "R" is the same as the right "r". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI1H80070315; Tue, 23 Nov 2004 10:01:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANI1HnN070314; Tue, 23 Nov 2004 10:01:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI1GN9070255 for ; Tue, 23 Nov 2004 10:01:16 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iANI1C97024149 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 23 Nov 2004 10:01:13 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Tue, 23 Nov 2004 10:01:01 -0800 To: IMAP Extensions WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looks like there was actually unanimity among seven voters to require both clients and servers to send only lower-case rights in 2086upd, but some quibbling about other details (whether to accept upper-case, what precise wording to use). Cyrus' proposed wording was: > 'Rights in 2086upd are case-insenstive, however clients and servers > MUST use lower-case rights to be compatible with clients or servers > supporting the original 2086 specification.' Philip suggested a slight modification that servers that advertise support for 2086upd should be able to accept upper-case rights as well (but not send them, if I understand). Alexey and Dave suggested that the spec not even use the word "case-insensitive" to not confuse people. So Alexey, how about you propose new text for 2086upd? Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANFJDQw021359; Tue, 23 Nov 2004 07:19:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANFJDci021358; Tue, 23 Nov 2004 07:19:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iANFJAgo021196 for ; Tue, 23 Nov 2004 07:19:11 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id F300B1BDE90; Tue, 23 Nov 2004 16:18:45 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id CFDBB1BDE87; Tue, 23 Nov 2004 16:18:44 +0100 (CET) Message-Id: Date: Tue, 23 Nov 2004 16:14:40 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Alexey Melnikov , Philip Guenther , Lisa Dusseault References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <200411230204.iAN248jq002789@lab.smi.sendmail.com> <41A35121.5030602@isode.com> In-Reply-To: <41A35121.5030602@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > So I am in favor of saying that upper-case rights in 2086upd are not allowed. > > And I agree that ACL2 should relax this to make rights case-insensitive. I'm happy with that. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANF3Kjq015866; Tue, 23 Nov 2004 07:03:20 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANF3KPx015865; Tue, 23 Nov 2004 07:03:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANF3JXH015796 for ; Tue, 23 Nov 2004 07:03:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 15:02:58 +0000 Message-ID: <41A35121.5030602@isode.com> Date: Tue, 23 Nov 2004 15:02:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Lisa Dusseault , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <200411230204.iAN248jq002789@lab.smi.sendmail.com> In-Reply-To: <200411230204.iAN248jq002789@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >I'm in favor of requiring servers that advertise the RIGHTS capability >to treat rights as case-insensitive. This requirement would (obviously) >not be retroactive to implementation that only support ACL and not >RIGHTS, so it does not invalidate any implementations. I find the >described behavior of existing implementations largely irrelevant to >this decision: upgrading an implementation from just ACL to ACL+RIGHTS >is clearly going to require code changes for the new rights; adding a >"tolower()" call would just be one of those changes. > >For the benefit of client implementors, a note could be added that warns >that there exist common ACL implementations that predate this >requirement and therefore that clients MUST send the standard rights as >lowercase letters when talking to a server that does not support the >RIGHTS extension. > > As there is no way for a client to announce its capabilities, the server MUST always send rights in lower-case. I just really see no point of saying that rights are case-insensitive when there are effectively case-sensitive for existing ACL implementations. >Leaving the meaning of uppercase rights implementation defined doesn't >help anyone and means we simply get to have this same discussion all >over again come ACL2. > > I agree, we need to either disallow upper-case rights or make them equal to the lower-case counterparts. I don't think anybody has presented a good argument for making upper-case and lower-case rights different. However, I share David's concern that even mentioning the word "case-insensitive" will mislead some implementors. So I am in favor of saying that upper-case rights in 2086upd are not allowed. And I agree that ACL2 should relax this to make rights case-insensitive. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAN24901038494; Mon, 22 Nov 2004 18:04:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAN249N1038493; Mon, 22 Nov 2004 18:04:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAN249Rk038442 for ; Mon, 22 Nov 2004 18:04:09 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAN248Jw024619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 22 Nov 2004 18:04:08 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAN248Jw024619 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=G40sxHcV7XeDKFnI2lE4eCU48W6Z6i34p+iykcIbiCyYdbxuw1+sIKFrEJOZtCnsq HLobpGmBVTaUweMQqFDiS9SPnow8w6ru++Ux3jqbDhGJcLE//XDgm6GqbcooH+qCyY9 8ussYjrhrwjyvBKhWfeNe9osR9f4AOOU9cHw09w= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAN248jq002789; Mon, 22 Nov 2004 18:04:08 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411230204.iAN248jq002789@lab.smi.sendmail.com> To: Lisa Dusseault Cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Date: Mon, 22 Nov 2004 18:04:08 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm in favor of requiring servers that advertise the RIGHTS capability to treat rights as case-insensitive. This requirement would (obviously) not be retroactive to implementation that only support ACL and not RIGHTS, so it does not invalidate any implementations. I find the described behavior of existing implementations largely irrelevant to this decision: upgrading an implementation from just ACL to ACL+RIGHTS is clearly going to require code changes for the new rights; adding a "tolower()" call would just be one of those changes. For the benefit of client implementors, a note could be added that warns that there exist common ACL implementations that predate this requirement and therefore that clients MUST send the standard rights as lowercase letters when talking to a server that does not support the RIGHTS extension. Leaving the meaning of uppercase rights implementation defined doesn't help anyone and means we simply get to have this same discussion all over again come ACL2. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMATRRY047909; Mon, 22 Nov 2004 02:29:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMATROk047908; Mon, 22 Nov 2004 02:29:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMATQEC047802 for ; Mon, 22 Nov 2004 02:29:27 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id A2ADB154009; Mon, 22 Nov 2004 10:29:22 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Philip Guenther Cc: Mark Crispin , Alexey Melnikov , , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <200411192350.iAJNo48o001654@lab.smi.sendmail.com> In-Reply-To: <200411192350.iAJNo48o001654@lab.smi.sendmail.com> Message-ID: <20041122102922.21034.86175.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 22 Nov 2004 10:29:22 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 23:50:04 2004, Philip Guenther wrote: > Furthermore, I would suggest that servers SHOULD return a BAD > response > if a client specifies an unknown right. Silently ignoring part of > what > a client says is a recipe for later dissension...like the current > discussion. Indeed. That doesn't solve the existing problem, though. > On one point: > > Dave Cridland writes: > ... > >And ACL2 is a total replacement, in effect. RFC2086 will die out, > >along with this specification too, and while there will be a > >compatibility option in most implementations, that's something > that >will fall out of use quite happily by itself. > > I disagree that ACL2 should be a complete replacement; with the > possible > exception of adding another right or two, ACL2 should simply refer > to > 2086upd for their definition and syntax. ACL2 implementations are > going > to need to support plain ACL for a goodly time to come; we should do > everything we can to avoid unnecessary incompatibilities between > them. > > (Even simply repeating the text from 2086upd in ACL2 would be error > prone. Would a latter erratum automatically apply to both? What > if the > text got editted slightly differently when republished?) No, agreed. So we stick to the rights letters and definitions, but ACL2 simply makes them case-insensitive for its interface. 2086upd issues a blanket-ban on uppercase rights being defined, in preparation for this. This should result in simpler language, and I believe greater interoperability. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMAPplM044037; Mon, 22 Nov 2004 02:25:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMAPpUc044036; Mon, 22 Nov 2004 02:25:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMAPgao043752 for ; Mon, 22 Nov 2004 02:25:42 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 13C94154009; Mon, 22 Nov 2004 10:25:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Lisa Dusseault Cc: Jutta Degener , IMAP Extensions WG , Mark Crispin , Arnt Gulbrandsen , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> In-Reply-To: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: <20041122102532.21034.48798.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 22 Nov 2004 10:25:32 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat Nov 20 17:25:43 2004, Lisa Dusseault wrote: > Ok, can we get summarizing arguments from the different positions > here (case-sensitive v. case-insensitive ACL tokens) and tell me > your vote? I can't see a clear consensus yet despite a fair amount > of discussion over this choice. Summary: 1) Existing RFC2086 implementations assume case-sensitivity: Refs: See source code of implementations. 2) Existing, widely deployed implementations break silently when case-insensitivity is assumed. Refs: Tested against Cyrus IMAPd. SETACL with uppercase rights discards those rights, returns OK. 3) Definition of rights as case-insensitive is more likely to lead to clients which send uppercase rights - even though against the standard, the resultant wording has considerable scope to confuse. If broken implementations sending uppercase rights to existing implementations received a BAD in return, I'd vote for this. However, they don't, and a silent discarding of rights is likely to cause newly released software to fail to interoperate with existing implementations. Therefore, as much as I would personally like case-insensitive right letters, I have to vote against changing the existing syntax, on the basis of interoperability. In ACL2, I'd be happy to see the ACL SET/STORE/DELETE syntax use case-insensitive rights - I'm not against the change, merely the timing of it. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKKxFXK004078; Sat, 20 Nov 2004 12:59:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKKxFKV004077; Sat, 20 Nov 2004 12:59:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKKxACM004054 for ; Sat, 20 Nov 2004 12:59:10 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAKKxE9N021844; Sat, 20 Nov 2004 12:59:14 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAKKxDBI013230; Sat, 20 Nov 2004 12:59:13 -0800 Date: Sat, 20 Nov 2004 12:59:13 -0800 (PST) From: Mark Crispin To: Cyrus Daboo cc: Lisa Dusseault , IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 20 Nov 2004, Cyrus Daboo wrote: > 'Rights in 2086upd are case-insenstive, however clients and servers MUST use > lower-case rights to be compatible with clients or servers supporting the > original 2086 specification.' OK. > As long as the lower-case requirement applies to servers as well as clients I > vote for case-insensitivity. I agree to this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJh4JA082107; Sat, 20 Nov 2004 11:43:04 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKJh4Ix082106; Sat, 20 Nov 2004 11:43:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJgxY4082042 for ; Sat, 20 Nov 2004 11:43:03 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.0.1.3] (pool-68-162-181-10.pitt.east.verizon.net [68.162.181.10]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAKIYc6E012269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Nov 2004 13:34:39 -0500 Date: Sat, 20 Nov 2004 14:42:54 -0500 From: Cyrus Daboo To: Mark Crispin , Lisa Dusseault cc: IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On November 20, 2004 11:09:44 -0800 Mark Crispin wrote: > On Sat, 20 Nov 2004, Lisa Dusseault wrote: >> Ok, can we get summarizing arguments from the different positions here >> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? >> I can't see a clear consensus yet despite a fair amount of discussion >> over this choice. > > Mark votes for mandatory case-insensitivity in servers which claim to be > 2086upd compliant (ACL2 goes without saying), and for a prohibition on > clients sending upper-case to 2086 and 2086upd servers. The latter > provision is subject to review in ACL2. > That's not good enough because it potentially breaks existing clients which expect case-sensitive (lower-case) values from the server. The proper way to do this is: 'Rights in 2086upd are case-insenstive, however clients and servers MUST use lower-case rights to be compatible with clients or servers supporting the original 2086 specification.' As long as the lower-case requirement applies to servers as well as clients I vote for case-insensitivity. However, if that requirement on the server is not applied, then I vote for case-sensitivity in 2086upd. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ9pbU071485; Sat, 20 Nov 2004 11:09:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKJ9pu3071484; Sat, 20 Nov 2004 11:09:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ9o50071469 for ; Sat, 20 Nov 2004 11:09:51 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAKJ9ivw011236; Sat, 20 Nov 2004 11:09:45 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAKJ9i7I011253; Sat, 20 Nov 2004 11:09:44 -0800 Date: Sat, 20 Nov 2004 11:09:44 -0800 (PST) From: Mark Crispin To: Lisa Dusseault cc: Jutta Degener , IMAP Extensions WG , Arnt Gulbrandsen , Alexey Melnikov , Dave Cridland Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 20 Nov 2004, Lisa Dusseault wrote: > Ok, can we get summarizing arguments from the different positions here > (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? I > can't see a clear consensus yet despite a fair amount of discussion over this > choice. Mark votes for mandatory case-insensitivity in servers which claim to be 2086upd compliant (ACL2 goes without saying), and for a prohibition on clients sending upper-case to 2086 and 2086upd servers. The latter provision is subject to review in ACL2. The intent is to install case-insensitivity by transition; by putting servers on notice that they must fix any case-sensitivity to be 2086upd compliant, without breaking any existing behavior. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKHQRC8036915; Sat, 20 Nov 2004 09:26:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKHQRO9036914; Sat, 20 Nov 2004 09:26:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKHQMn3036856 for ; Sat, 20 Nov 2004 09:26:22 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAKHPtZe009410 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 20 Nov 2004 09:26:00 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Sat, 20 Nov 2004 09:25:43 -0800 To: Jutta Degener , IMAP Extensions WG , Mark Crispin , Arnt Gulbrandsen , Alexey Melnikov , Dave Cridland X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ok, can we get summarizing arguments from the different positions here (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? I can't see a clear consensus yet despite a fair amount of discussion over this choice. I need to know your vote even if you've already stated your position because some opinions were given before much discussion happened, and I need to know if the discussion changed anybody's mind. Also welcoming input from those who've stayed silent so far. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKFtbBa001950; Sat, 20 Nov 2004 07:55:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKFtb09001948; Sat, 20 Nov 2004 07:55:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKFtZ5s001889 for ; Sat, 20 Nov 2004 07:55:36 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 20 Nov 2004 15:55:24 +0000 Message-ID: <419F68E6.9000808@isode.com> Date: Sat, 20 Nov 2004 15:55:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >> However, do you honestly think that client authors will change their >> code to send uppercase rights? (I mean, discounting the kinds of >> authors who deliberately do weird things because they can.) > > I don't think that; I *know* that. Mark, can you elaborate? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK0GMIh059705; Fri, 19 Nov 2004 16:16:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAK0GMfW059688; Fri, 19 Nov 2004 16:16:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK0GKSW059627 for ; Fri, 19 Nov 2004 16:16:20 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAK0GLMs016985; Fri, 19 Nov 2004 16:16:21 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAK0GK38032199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Nov 2004 16:16:20 -0800 Date: Fri, 19 Nov 2004 16:14:18 -0800 (Pacific Standard Time) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Dave Cridland wrote: > Nor will they use 2086upd servers either. As I understand things, 2086upd is > fully intended to be a stopgap until ACL2. Let's treat it like one. If the transition isn't started with 2086upd, it won't happen. > Wait... You "know" client authors will actively edit their code and put in > uppercase rights, then lowercase them for backwards compatibility with "pure" > RFC2086 servers if/when they encounter them? > Why? Yes, I know. There are a number of reasons of doing this, few of which have anything to do with technical excellence. For example, some client authors intentionally build software that works differentially with specific servers. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJNorvG050572; Fri, 19 Nov 2004 15:50:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJNorYQ050571; Fri, 19 Nov 2004 15:50:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJNolk8050521 for ; Fri, 19 Nov 2004 15:50:48 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAJNo9fQ019241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 19 Nov 2004 15:50:10 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAJNo9fQ019241 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=uYcIhXISlTJSPU3kby3umcfdxm5mIec+GuA81P8KHJ0S4uK1mRpYnXL62lRTjhgR2 TV2SAfGPFbqsJD5dPLHsFo169KNHORDI0AEqOmbDeu73DXBROcsxc8nOWp61ZXyN0ty uGjs58v5dTFe51kfViPsfgRDcBBhTlRLZ39hkd4= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAJNo48o001654; Fri, 19 Nov 2004 15:50:05 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411192350.iAJNo48o001654@lab.smi.sendmail.com> To: Dave Cridland Cc: Mark Crispin , Alexey Melnikov , ietf-imapext@imc.org, Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Date: Fri, 19 Nov 2004 15:50:04 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm in favor of Mark's proposed clarification that rights MUST be treated as case-insensitive. Furthermore, I would suggest that servers SHOULD return a BAD response if a client specifies an unknown right. Silently ignoring part of what a client says is a recipe for later dissension...like the current discussion. On one point: Dave Cridland writes: ... >And ACL2 is a total replacement, in effect. RFC2086 will die out, >along with this specification too, and while there will be a >compatibility option in most implementations, that's something that >will fall out of use quite happily by itself. I disagree that ACL2 should be a complete replacement; with the possible exception of adding another right or two, ACL2 should simply refer to 2086upd for their definition and syntax. ACL2 implementations are going to need to support plain ACL for a goodly time to come; we should do everything we can to avoid unnecessary incompatibilities between them. (Even simply repeating the text from 2086upd in ACL2 would be error prone. Would a latter erratum automatically apply to both? What if the text got editted slightly differently when republished?) Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJxnmA047805; Fri, 19 Nov 2004 11:59:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJJxnWM047804; Fri, 19 Nov 2004 11:59:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJxmrH047752 for ; Fri, 19 Nov 2004 11:59:49 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6F415154009; Fri, 19 Nov 2004 19:59:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen , Brian Candler Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> In-Reply-To: Message-ID: <20041119195947.21034.42728.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 19:59:47 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 17:48:33 2004, Mark Crispin wrote: > On Fri, 19 Nov 2004, Brian Candler wrote: >> That's if I understand correctly: the ACL2 proposal is being >> dropped. > > Is ACL2 being dropped? > > I oppose that. Likewise. ACL2 isn't being dropped, at least not unless we can't last-call it by 2005/02/05, as far as I'm aware. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJumiY045622; Fri, 19 Nov 2004 11:56:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJJumYI045621; Fri, 19 Nov 2004 11:56:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJul2D045539 for ; Fri, 19 Nov 2004 11:56:48 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 1165E154009; Fri, 19 Nov 2004 19:56:46 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 19:56:46 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 16:41:53 2004, Mark Crispin wrote: > On Fri, 19 Nov 2004, Dave Cridland wrote: >> It solves no problems, it adds complexity. >> Adding complexity has a history of adding problems. >> Therefore we cannot (or, if you prefer, should not) make this >> change. >> What's there to understand? This isn't rocket science... > > IMAP is a protocol which stipulates case-independence in its tokens > throughout. Only data, such as message data or (optionally) > mailbox names are case-dependent, but even then INBOX is > case-independent. > > ACL rights are an IMAP token. The only reason why anyone ever > thought that they would be case-dependent was that the syntax rule > used was astring in order to avoid having to decide upon a syntax > for empty rights. This was a design mistake in 2086. I have been > objecting to 2086's design mistakes repeatedly for many years. > > Therefore, ACL rights are the only IMAP token which is > case-dependent. This solves no problems (the additional 26 rights > are not needed), it adds complexity. Adding complexity has a > history of adding problems. Therefore we cannnot (or, if you > prefer, should not) make this change. What's there to understand? > This isn't rocket science... > > I agree with all of that, which may surprise you. It's an argument *against* RFC2086, however, and not an argument *for* changing it now. In fact, the text you copied from my email stipulates "[...] make this change [...]". RFC2086 has *made* a change, a bad one I agree, but it's one we should live with until ACL2. >> I've yet to see *any* technical argument for (a) here - lots of >> discussion about whether it's more in the "spirit of IMAP", etc. >> Nothing about whether it's actually a useful or sensible thing to >> do, especially in this specification. > > The best way to ruin a technical specification is to ignore the > original spirit and graft on something that is totally foreign. > > And again, I agree - RFC2086 wasn't a terribly good way of handling ACLs. It was under-specified, has a confusing array of rights, and is generally against the spirit of IMAP. I can't stand many things about it, and this includes the way that rights are named right at the top of the list. But the spirit of RFC2086 - in fact, more than that, the actual implementations - use a case-sensitive interpretation throughout. > C++ is an excellent example. > > Well, I personally like the language, but I'll raise you Perl, although arguably that didn't have a spirit to be broken when OO was grafted on. Perhaps XLISP? >>> Simply define that any 2086upd (and ACL2) compliant server MUST >>> have case-insensitive rights,... >>> *AND* >>> define that servers MUST send rights as lower case (MUST NOT send >>> rights >>> as upper case) >> The two above suggest that rights remain case-sensitive to all >> intents and purposes. >> I fail to see any practical difference that this makes. > > Not quite. They establish the framework for the future. In > particular, they instruct new implementations to read > case-insensitive, even though at present they must only send > lowercase. Some time in the future, the latter part of the > previous sentence will be moot; nobody will use pre-2086upd servers > any more. > > Nor will they use 2086upd servers either. As I understand things, 2086upd is fully intended to be a stopgap until ACL2. Let's treat it like one. >> However, do you honestly think that client authors will change >> their code to send uppercase rights? (I mean, discounting the >> kinds of authors who deliberately do weird things because they >> can.) > > I don't think that; I *know* that. > > Wait... You "know" client authors will actively edit their code and put in uppercase rights, then lowercase them for backwards compatibility with "pure" RFC2086 servers if/when they encounter them? Why? >> Now, on the contrary position, will there be new client authors >> who misunderstand, or simply fail to read, the specification, hear >> that "rights are case-insensitive", and break interoperability >> with older servers? I believe this will be the case - hence the >> reason why additional complexity tends to cause problems. > > Pre-2086upd servers will rapidly become extinct, and clients will > be written that can only handle 2086upd. > > Otherwise, there is no point to 2086upd, and this entire effort > should be abandoned as a waste of time. It's not a waste of time - it clarifies 2086 enormously, sets down useful rules (rather than inferences) for what rights control what, and transitioning from 2086upd to ACL2 should prove much simpler. And ACL2 is a total replacement, in effect. RFC2086 will die out, along with this specification too, and while there will be a compatibility option in most implementations, that's something that will fall out of use quite happily by itself. The *only* thing we need to do to ensure that we can have case-insensitive rights in the future - should we want them, and not simply replace them with a much more IMAP-like syntax[*] - is to stress that rights are all lowercase - at least for now. Banning them outright would be simpler: The sentence beginning "Rights is a string listing..." in section 3 gets replaced with "Rights is a string listing a (possibly empty) set of lower case US-ASCII letters and digits, each character listing a set of operations which is being controlled." The ANBF gets adjusted accordingly to rule out uppercase rights. That's a simple clarification of RFC2086, well within the scope of this draft, perfectly sensible, won't break anything even if misread, leaves all our options open. Dave. * - Think syntax like A002 ACL SET (INBOX Personal/*) user=Fred (\Read \Write \Insert \Seen \Deleted) - although I've not thought about a clearer syntax for the user=Fred ugliness, nor the flag names. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIXl4h094204; Fri, 19 Nov 2004 10:33:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJIXlkg094203; Fri, 19 Nov 2004 10:33:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIXgMN094149 for ; Fri, 19 Nov 2004 10:33:43 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJIXfUg006977; Fri, 19 Nov 2004 10:33:41 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJIXeuI027500; Fri, 19 Nov 2004 10:33:40 -0800 Date: Fri, 19 Nov 2004 10:33:40 -0800 (PST) From: Mark Crispin To: Lisa Dusseault cc: Jutta Degener , Arnt Gulbrandsen , ietf-imapext@imc.org, Brian Candler , Alexey Melnikov , Dave Cridland Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Lisa Dusseault wrote: > That's not the plan... the plan is to get 2086upd done quickly then get back > to ACL2. That's what I had been led to believe. Thank you Lisa for restating this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJINAkJ088596; Fri, 19 Nov 2004 10:23:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJINAji088593; Fri, 19 Nov 2004 10:23:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIN6tt088517 for ; Fri, 19 Nov 2004 10:23:06 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAJIMnZe030496 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 Nov 2004 10:22:51 -0800 In-Reply-To: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Jutta Degener , Arnt Gulbrandsen , ietf-imapext@imc.org, Brian Candler , Alexey Melnikov , Dave Cridland From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Fri, 19 Nov 2004 10:22:43 -0800 To: Mark Crispin X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That's not the plan... the plan is to get 2086upd done quickly then get back to ACL2. lisa On Nov 19, 2004, at 9:48 AM, Mark Crispin wrote: > > On Fri, 19 Nov 2004, Brian Candler wrote: >> That's if I understand correctly: the ACL2 proposal is being dropped. > > Is ACL2 being dropped? > > I oppose that. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHmgrv066417; Fri, 19 Nov 2004 09:48:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHmg6Y066416; Fri, 19 Nov 2004 09:48:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHmbLk066353 for ; Fri, 19 Nov 2004 09:48:41 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJHmYIo001108; Fri, 19 Nov 2004 09:48:34 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJHmXrh024495; Fri, 19 Nov 2004 09:48:33 -0800 Date: Fri, 19 Nov 2004 09:48:33 -0800 (PST) From: Mark Crispin To: Brian Candler cc: Dave Cridland , Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119171901.GA2629@uk.tiscali.com> Message-ID: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Brian Candler wrote: > That's if I understand correctly: the ACL2 proposal is being dropped. Is ACL2 being dropped? I oppose that. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHJHEK048271; Fri, 19 Nov 2004 09:19:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHJHWA048270; Fri, 19 Nov 2004 09:19:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHJ7sc048128 for ; Fri, 19 Nov 2004 09:19:08 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 9ADAF13C85; Fri, 19 Nov 2004 12:19:04 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id 0CD752ABF1; Fri, 19 Nov 2004 12:18:58 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CVCPV-0000h4-Hm; Fri, 19 Nov 2004 17:19:01 +0000 Date: Fri, 19 Nov 2004 17:19:01 +0000 From: Brian Candler To: Mark Crispin Cc: Dave Cridland , Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <20041119171901.GA2629@uk.tiscali.com> References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Nov 19, 2004 at 08:41:53AM -0800, Mark Crispin wrote: > Therefore, ACL rights are the only IMAP token which is case-dependent. > This solves no problems (the additional 26 rights are not needed), it > adds complexity. I can't see any complexity with the one-to-one mapping of US-ASCII characters to rights; a two-to-one mapping looks more complex to me. It adds complexity in servers parsing commands, and clients parsing responses. A server, after all, may not be able to lowercase the entire line which comes in, so it still has to do this token by token. Mailbox names, apart from [Ii][Nn][Bb][Oo][Xx], are permitted to be case-sensitive, but clients have to be aware that they could also be case-insensitive. Now *that* added a hell of a lot of complexity; with UTF-7 encoded Unicode mailbox names, determining whether two characters are the same disregarding case is a non-trivial task. > >However, do you honestly think that client authors will change their code > >to send uppercase rights? (I mean, discounting the kinds of authors who > >deliberately do weird things because they can.) > > I don't think that; I *know* that. Sure, give them the option and at least one person will. But I don't see what benefit would have accrued by giving them the ability to do so, when you could just say that they can't. > Pre-2086upd servers will rapidly become extinct, and clients will be > written that can only handle 2086upd. > > Otherwise, there is no point to 2086upd, and this entire effort should be > abandoned as a waste of time. I don't see the logic there. There clearly are things that are broken in rfc 2086 in the sense that they need clarifying - the rights needed to delete mailboxes, for instance. Some or indeed most existing applications may already behave "correctly", due to luck or telepathy in interpreting the original interpretation, and therefore not need changing. That's if I understand correctly: the ACL2 proposal is being dropped. *That* would have been a replacement, leading to three types of clients/servers: those that do ACL1, those that do ACL2, and those which do both. Making 2086upd instead should leave the majority of existing 2086 implementations compliant with 2086upd; that is, in most cases they should not need to be changed to become 2086upd compliant. Or am I misunderstanding the thrust of the 2086upd concept? Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGg3uu025475; Fri, 19 Nov 2004 08:42:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJGg3PN025474; Fri, 19 Nov 2004 08:42:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGfw1s025404 for ; Fri, 19 Nov 2004 08:41:58 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJGfs9v021002; Fri, 19 Nov 2004 08:41:54 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJGfrC1030835; Fri, 19 Nov 2004 08:41:53 -0800 Date: Fri, 19 Nov 2004 08:41:53 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Dave Cridland wrote: > It solves no problems, it adds complexity. > Adding complexity has a history of adding problems. > Therefore we cannot (or, if you prefer, should not) make this change. > What's there to understand? This isn't rocket science... IMAP is a protocol which stipulates case-independence in its tokens throughout. Only data, such as message data or (optionally) mailbox names are case-dependent, but even then INBOX is case-independent. ACL rights are an IMAP token. The only reason why anyone ever thought that they would be case-dependent was that the syntax rule used was astring in order to avoid having to decide upon a syntax for empty rights. This was a design mistake in 2086. I have been objecting to 2086's design mistakes repeatedly for many years. Therefore, ACL rights are the only IMAP token which is case-dependent. This solves no problems (the additional 26 rights are not needed), it adds complexity. Adding complexity has a history of adding problems. Therefore we cannnot (or, if you prefer, should not) make this change. What's there to understand? This isn't rocket science... > I've yet to see *any* technical argument for (a) here - lots of discussion > about whether it's more in the "spirit of IMAP", etc. Nothing about whether > it's actually a useful or sensible thing to do, especially in this > specification. The best way to ruin a technical specification is to ignore the original spirit and graft on something that is totally foreign. C++ is an excellent example. >> Simply define that any 2086upd (and ACL2) compliant server MUST have >> case-insensitive rights,... >> *AND* >> define that servers MUST send rights as lower case (MUST NOT send rights >> as upper case) > The two above suggest that rights remain case-sensitive to all intents and > purposes. > I fail to see any practical difference that this makes. Not quite. They establish the framework for the future. In particular, they instruct new implementations to read case-insensitive, even though at present they must only send lowercase. Some time in the future, the latter part of the previous sentence will be moot; nobody will use pre-2086upd servers any more. > However, do you honestly think that client authors will change their code to > send uppercase rights? (I mean, discounting the kinds of authors who > deliberately do weird things because they can.) I don't think that; I *know* that. > Now, on the contrary position, will there be new client authors who > misunderstand, or simply fail to read, the specification, hear that "rights > are case-insensitive", and break interoperability with older servers? I > believe this will be the case - hence the reason why additional complexity > tends to cause problems. Pre-2086upd servers will rapidly become extinct, and clients will be written that can only handle 2086upd. Otherwise, there is no point to 2086upd, and this entire effort should be abandoned as a waste of time. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJG5JOI008745; Fri, 19 Nov 2004 08:05:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJG5Jqq008743; Fri, 19 Nov 2004 08:05:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJG5EZ5008700 for ; Fri, 19 Nov 2004 08:05:19 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id F0143154009; Fri, 19 Nov 2004 16:05:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 16:05:10 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 16:01:47 2004, Mark Crispin wrote: > On Thu, 18 Nov 2004, Dave Cridland wrote: >> Therefore, we cannot make rights case-insensitive. Any attempt to >> do so would appear to create more problems than it could possibly >> solve. > > I don't understand why. > > It solves no problems, it adds complexity. Adding complexity has a history of adding problems. Therefore we cannot (or, if you prefer, should not) make this change. What's there to understand? This isn't rocket science... > You identified that there is a problem that would be caused by an > abrupt transition. So don't have an abrupt transition. This isn't > rocket science; we know how to do this. > > [As an aside, all abrupt transitions in protocols cause problems...] Indeed - but there are two ways of avoiding an abrupt transition. Either: a) Use some careful language in the specification, defining a set of rules by which there is, in effect, no transition apparent for innocent implementations. b) Not have a transition at all. (a) can be done - I appreciate that changes are possible, and indeed sometimes needed to further the protocol. The outlined rules you state do indeed provide this. I think (b) has more technical merit in this circumstance, however. In fact, I've yet to see *any* technical argument for (a) here - lots of discussion about whether it's more in the "spirit of IMAP", etc. Nothing about whether it's actually a useful or sensible thing to do, especially in this specification. > Simply define that any 2086upd (and ACL2) compliant server MUST > have case-insensitive rights,... > *AND* > define that servers MUST send rights as lower case (MUST NOT send > rights > as upper case) The two above suggest that rights remain case-sensitive to all intents and purposes. I fail to see any practical difference that this makes. I see an aesthetic difference - we can now say "They're case-insensitive", but I don't see any *real* difference. This *is* adding complexity, to the language used if nothing else. Case-insensitive means "upper and lower case are treated identically". This says "upper and lower case are treated identically, except that you can't use upper case". Some cases are less insensitive than others, if you like literary paraphrasing. > *AND* > define that clients MUST send rights as lower case (MUST NOT send > rights as upper case) to pre-2086upd servers. > > If there is no way for a client to detect a pre-2086upd server, > then simply remove "to pre-2086upd servers" in the last part. > > There is a way to detirmine if the server supports the extra rights, and, by inference, is RFC2086-upd or not, true. However, do you honestly think that client authors will change their code to send uppercase rights? (I mean, discounting the kinds of authors who deliberately do weird things because they can.) The only circumstance I can think of is clients which send XET rather than xet - the new rights being added as capitals. I can't really see this being an advantage to the author to do so, and I strongly suspect that all existent implementations of RFC2086 will use the lowercase characters for consistency anyway. Now, on the contrary position, will there be new client authors who misunderstand, or simply fail to read, the specification, hear that "rights are case-insensitive", and break interoperability with older servers? I believe this will be the case - hence the reason why additional complexity tends to cause problems. The interoperability break is particularly disturbing - it's a silent breakage in at least one widely deployed implementation, for example: C: A01 SETACL INBOX foo lrS S: A01 OK Completed C: A02 GETACL INBOX S: * ACL INBOX dwd lrswipcda foo lr S: A02 OK Completed > In ACL2, this can be removed entirely, at least for ACL2 only > software. > > For ACL2, which is now a long way off, we can make different decisions. It's worth reserving all uppercase rights in this specification to keep the options open. >> lswiPda is currently treated by many clients and servers as lswida. > > How many clients rely upon this behavior by sending lswiPda > assuming that the server will see it as lswida? None, because P isn't a defined right. However, if we wave some mythical case-insensitivity at client authors, somebody somewhere *will* misread (or not read) this, and get very, very confused about why their rights aren't being set by the server. (Apologies for answering your rhetorical question.) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIQN5o070198; Thu, 18 Nov 2004 10:26:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIIQNp3070197; Thu, 18 Nov 2004 10:26:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIQHl0070168 for ; Thu, 18 Nov 2004 10:26:22 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAIHIE6E012489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 12:18:14 -0500 Date: Thu, 18 Nov 2004 13:26:13 -0500 From: Cyrus Daboo To: Mark Crispin , Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On November 17, 2004 14:24:30 -0800 Mark Crispin wrote: >> (Personally, I'd prefer case-*in*sensitivity - I have trouble >> remembering which case meant what, why shouldn't other people; >> but our implementations don't behave like that now.) > > This is my preference as well, and is consistant with the rest of IMAP. > > Unless there is an intent to use upper-case rights in the future to mean > something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but that > clients MUST send rights as lowercase? My client will not recognize rights from a server if they are upper case, so the server would have to send lowercase rights as well to be backwards compatible, at which point the rights are effectively case sensitive. WRT use of upper-case, I know at some point in the ACL2 debate we had talked about a simplified model of rights for 'simple' clients: e.g. 'RWX' style rights that would be tied in some well-defined way to the underlying lower case rights. So my feeling is we should reserve uppercase rights for now. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAII0vIF062326; Thu, 18 Nov 2004 10:00:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAII0v05062325; Thu, 18 Nov 2004 10:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAII0uNu062318 for ; Thu, 18 Nov 2004 10:00:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 18:00:57 +0000 Message-ID: <419CE358.1030107@isode.com> Date: Thu, 18 Nov 2004 18:00:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: >> Having said that I have to admit that I don't have a strong opinion >> on the issue. I would slightly prefere prohibiting uppercase rights - >> many existing clients will not treat them the same way as their >> lowercase counterparts. > > Indeed, Arnt has to start begging for mercy right now, it seems - > lswiPda is currently treated by many clients and servers as lswida. > > Cyrus IMAPd, Which is arguably a bug. > as well as every client I've examined the source for (not many) ignore > unrecognised rights, which include all uppercase ones. 2086upd requires that all clients that can do SETACL preserve unrecognized rights. For clients that only use GETACL/MYRIGHTS, it is ok to ignore unrecognized rights. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHn8B0058418; Thu, 18 Nov 2004 09:49:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIHn86E058417; Thu, 18 Nov 2004 09:49:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHn79k058401 for ; Thu, 18 Nov 2004 09:49:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 17:49:04 +0000 Message-ID: <419CE08E.3090207@isode.com> Date: Thu, 18 Nov 2004 17:49:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin CC: Dave Cridland , ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Thu, 18 Nov 2004, Dave Cridland wrote: > >> Therefore, we cannot make rights case-insensitive. Any attempt to do >> so would appear to create more problems than it could possibly solve. > > I don't understand why. > > You identified that there is a problem that would be caused by an > abrupt transition. So don't have an abrupt transition. This isn't > rocket science; we know how to do this. > > Simply define that any 2086upd (and ACL2) compliant server MUST have > case-insensitive rights,... > *AND* > define that servers MUST send rights as lower case (MUST NOT send rights > as upper case) > *AND* > define that clients MUST send rights as lower case (MUST NOT send > rights as upper case) to pre-2086upd servers. The 2086upd document defines a new capability, so we can do that. And the client will be able to detect pre-2086upd servers. > If there is no way for a client to detect a pre-2086upd server, then > simply remove "to pre-2086upd servers" in the last part. > > In ACL2, this can be removed entirely, at least for ACL2 only software. Yes. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1r5j022300; Thu, 18 Nov 2004 08:01:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIG1rCV022299; Thu, 18 Nov 2004 08:01:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1qu5022283 for ; Thu, 18 Nov 2004 08:01:52 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAIG1lEF024607; Thu, 18 Nov 2004 08:01:47 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAIG1lkF008190; Thu, 18 Nov 2004 08:01:47 -0800 Date: Thu, 18 Nov 2004 08:01:47 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 18 Nov 2004, Dave Cridland wrote: > Therefore, we cannot make rights case-insensitive. Any attempt to do so would > appear to create more problems than it could possibly solve. I don't understand why. You identified that there is a problem that would be caused by an abrupt transition. So don't have an abrupt transition. This isn't rocket science; we know how to do this. Simply define that any 2086upd (and ACL2) compliant server MUST have case-insensitive rights,... *AND* define that servers MUST send rights as lower case (MUST NOT send rights as upper case) *AND* define that clients MUST send rights as lower case (MUST NOT send rights as upper case) to pre-2086upd servers. If there is no way for a client to detect a pre-2086upd server, then simply remove "to pre-2086upd servers" in the last part. In ACL2, this can be removed entirely, at least for ACL2 only software. > lswiPda is currently treated by many clients and servers as lswida. How many clients rely upon this behavior by sending lswiPda assuming that the server will see it as lswida? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFcpqe014151; Thu, 18 Nov 2004 07:38:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIFcpII014150; Thu, 18 Nov 2004 07:38:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFcjGQ014125 for ; Thu, 18 Nov 2004 07:38:46 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6BEFC154009; Thu, 18 Nov 2004 15:38:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: , Jutta Degener , Mark Crispin , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> In-Reply-To: <419CA15D.9010300@isode.com> Message-ID: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 15:38:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 13:19:25 2004, Alexey Melnikov wrote: > Arnt Gulbrandsen wrote: >> Mark Crispin writes: >>> On Wed, 17 Nov 2004, Jutta Degener wrote: >>> >>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble >>>> remembering which case meant what, why shouldn't other people; >>>> but our implementations don't behave like that now.) >>> >>> This is my preference as well, and is consistant with the rest of >>> IMAP. >>> >>> Unless there is an intent to use upper-case rights in the future >>> to mean something different, would it be possible to transit to a >>> case insensitive regime by stating that rights are >>> case-insensitive, but that clients MUST send rights as lowercase? >> >> >> I strongly agree. It's hard enough to remember lswipda, if lswiPda >> were someday to be different I'd have to beg for mercy. Mark's >> suggestion is a good way forward, IMO. > > I remember we were using "S" as as an example, i.e. "s" controls > the private \Seen and "S" might control the shared \Seen flag. > So if we are going to allow for upper case rights, they have to be > somehow related to the corresponding lowercase ones. > > That seems fair, though we'd have to try to ensure that they followed the same relationship where possible, hence "n" would become "N", and "m" would become "n". I'm not fussed on using uppercase rights at all, though. > Having said that I have to admit that I don't have a strong opinion > on the issue. I would slightly prefere prohibiting uppercase rights > - many existing clients will not treat them the same way as their > lowercase counterparts. Indeed, Arnt has to start begging for mercy right now, it seems - lswiPda is currently treated by many clients and servers as lswida. Cyrus IMAPd, as well as every client I've examined the source for (not many) ignore unrecognised rights, which include all uppercase ones. They all appear to transform the rights string into a bitfield using code very similar to: { char * p( rights ); /* assuming rights is a char * */ unsigned rights_bitfield( 0 ); while( *p ) { switch( *p ) { case 'a': rights_bitfield |= IMAP_ACL_ADMIN; break; /* etc, without a default: */ } } } Hence unknown rights are completely ignored (good for clients, not so sure this is correct for a server) and this includes uppercase rights. Therefore, we cannot make rights case-insensitive. Any attempt to do so would appear to create more problems than it could possibly solve. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDJSFP065294; Thu, 18 Nov 2004 05:19:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIDJSQV065293; Thu, 18 Nov 2004 05:19:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDJR6O065278 for ; Thu, 18 Nov 2004 05:19:27 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 13:19:26 +0000 Message-ID: <419CA15D.9010300@isode.com> Date: Thu, 18 Nov 2004 13:19:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org, Jutta Degener , Mark Crispin Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> In-Reply-To: <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Mark Crispin writes: > >> On Wed, 17 Nov 2004, Jutta Degener wrote: >> >>> (Personally, I'd prefer case-*in*sensitivity - I have trouble >>> remembering which case meant what, why shouldn't other people; but >>> our implementations don't behave like that now.) >> >> This is my preference as well, and is consistant with the rest of IMAP. >> >> Unless there is an intent to use upper-case rights in the future to >> mean something different, would it be possible to transit to a case >> insensitive regime by stating that rights are case-insensitive, but >> that clients MUST send rights as lowercase? > > > I strongly agree. It's hard enough to remember lswipda, if lswiPda > were someday to be different I'd have to beg for mercy. Mark's > suggestion is a good way forward, IMO. I remember we were using "S" as as an example, i.e. "s" controls the private \Seen and "S" might control the shared \Seen flag. So if we are going to allow for upper case rights, they have to be somehow related to the corresponding lowercase ones. Having said that I have to admit that I don't have a strong opinion on the issue. I would slightly prefere prohibiting uppercase rights - many existing clients will not treat them the same way as their lowercase counterparts. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDGqs5064659; Thu, 18 Nov 2004 05:16:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIDGqWK064658; Thu, 18 Nov 2004 05:16:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDGkOE064563 for ; Thu, 18 Nov 2004 05:16:47 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 13:16:38 +0000 Message-ID: <419CA0B5.7060302@isode.com> Date: Thu, 18 Nov 2004 13:16:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Lyndon Nerenberg writes: > >> Just to be Devil's Advocate: >> >> 1) Are we sure 36 rights will be enough? > > Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the > standard ever becomes that complex and finegrained, then IMO, even > sane and reasonable client developers may develop specifically for the > two most common servers. I agree that 36 rights is too much. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIB7m0J087283; Thu, 18 Nov 2004 03:07:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIB7mIJ087282; Thu, 18 Nov 2004 03:07:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAIB7l65087267 for ; Thu, 18 Nov 2004 03:07:48 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 02F091A70F; Thu, 18 Nov 2004 12:07:47 +0100 (CET) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 37B7F1A6D0; Thu, 18 Nov 2004 12:05:26 +0100 (CET) Message-Id: Date: Thu, 18 Nov 2004 12:05:05 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Lyndon Nerenberg , Jutta Degener , Mark Crispin References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg writes: > Just to be Devil's Advocate: > > 1) Are we sure 36 rights will be enough? Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the standard ever becomes that complex and finegrained, then IMO, even sane and reasonable client developers may develop specifically for the two most common servers. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIB0kBK081267; Thu, 18 Nov 2004 03:00:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIB0kcD081263; Thu, 18 Nov 2004 03:00:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAIB0f8R081082 for ; Thu, 18 Nov 2004 03:00:45 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id D70EF1A713; Thu, 18 Nov 2004 12:00:29 +0100 (CET) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 6CD4B1A6D0; Thu, 18 Nov 2004 12:00:06 +0100 (CET) Message-Id: <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> Date: Thu, 18 Nov 2004 11:59:45 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Jutta Degener , Mark Crispin References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Wed, 17 Nov 2004, Jutta Degener wrote: >> (Personally, I'd prefer case-*in*sensitivity - I have trouble >> remembering which case meant what, why shouldn't other people; but >> our implementations don't behave like that now.) > > This is my preference as well, and is consistant with the rest of IMAP. > > Unless there is an intent to use upper-case rights in the future to > mean something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but > that clients MUST send rights as lowercase? I strongly agree. It's hard enough to remember lswipda, if lswiPda were someday to be different I'd have to beg for mercy. Mark's suggestion is a good way forward, IMO. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIA1Hm8043547; Thu, 18 Nov 2004 02:01:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIA1HJF043546; Thu, 18 Nov 2004 02:01:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIA1Clv043373 for ; Thu, 18 Nov 2004 02:01:12 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 945E6154009; Thu, 18 Nov 2004 10:01:07 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> In-Reply-To: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> Message-ID: <20041118100107.21034.37810.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 10:01:07 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed Nov 17 20:43:07 2004, Cyrus Daboo wrote: > --On November 17, 2004 20:27:35 +0000 Alexey Melnikov > wrote: > >>> Leave it the same as 2086 (original), but perhaps call extra >>> attention >>> to the fact that it is case-sensitive. >> >> RFC 2086 was silent on the issue. I believe the intention was to >> make >> rights case-sensitive. > > OK, well I guess we will have to find out what real implementations > did and make sure it is clear in 2086upd which way it should be. I > can tell you that my implementation treats the rights as > case-sensitive. I can tell you that Mutt and Mozilla Mail/News also both appear to treat rights as case-sensitive. I could be wrong, but it looks that way. I can't tell you what the server implementations do, although I know Cyrus IMAPd just ignores any unknown rights, including upper-case ones. I strongly suspect that everything treats them as case-sensitive. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9I8jA009463; Thu, 18 Nov 2004 01:18:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI9I8Bn009462; Thu, 18 Nov 2004 01:18:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9I3R9009072 for ; Thu, 18 Nov 2004 01:18:07 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 09C82154009; Thu, 18 Nov 2004 09:17:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Lyndon Nerenberg Cc: IMAP Extensions WG , Mark Crispin Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> In-Reply-To: <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> Message-ID: <20041118091742.21034.59915.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 09:17:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 02:18:55 2004, Lyndon Nerenberg wrote: > > --On 2004-11-17 5:58 PM -0800 Mark Crispin > wrote: > >> If we aren't certain, is it a mistake to have single-character >> rights? > > Not if they are UTF-8 characters :-P > > Rights are defined in 2086 as US-ASCII. Nice try, though. :-) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI2JGWl078805; Wed, 17 Nov 2004 18:19:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI2JGWk078804; Wed, 17 Nov 2004 18:19:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI2JFaZ078796 for ; Wed, 17 Nov 2004 18:19:15 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAI2IuOl057511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 19:18:59 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 17 Nov 2004 18:18:55 -0800 From: Lyndon Nerenberg To: Mark Crispin cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-MessageCare-Metrics: orthanc.ca 1108; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-17 5:58 PM -0800 Mark Crispin wrote: > If we aren't certain, is it a mistake to have single-character rights? Not if they are UTF-8 characters :-P > I agree that, because 2086 rights are an , IMAP's case > folding rules do not require 2806 rights to be case insensitive. I > disagree with your conclusion that they are required to be case > sensitive. I consider IMAP to be silent on this point. But I defer to ABNF, where everything is case-sensitive unless explicitly stated otherwise. (Yes, ACL predates ABNF spec.) No matter, I'm just issuing a heads-up. I won't go non-linear if case-folding is the consensus. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI20ncj071869; Wed, 17 Nov 2004 18:00:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI20nfH071868; Wed, 17 Nov 2004 18:00:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI20mGk071862 for ; Wed, 17 Nov 2004 18:00:48 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAI20sJP004966; Wed, 17 Nov 2004 18:00:54 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAI20r3I015178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2004 18:00:53 -0800 Date: Wed, 17 Nov 2004 17:58:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Lyndon Nerenberg cc: Jutta Degener , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 17 Nov 2004, Lyndon Nerenberg wrote: > 1) Are we sure 36 rights will be enough? I don't know. Are we? If we aren't certain, is it a mistake to have single-character rights? > 2) is not case-folded. Since are an I would > argue that MUST be case sensitive. (Nothing in 2086 calls out for > case-folding, therefore it cannot be assumed by any conforming > implementation.) I agree that, because 2086 rights are an , IMAP's case folding rules do not require 2806 rights to be case insensitive. I disagree with your conclusion that they are required to be case sensitive. I consider IMAP to be silent on this point. However, as the original architect of IMAP, I consider it to be a mistake that rights are an astring as opposed to an atom equivalent. That is, I think that it would have been closer to the "spirit of IMAP" if it were something like: mod_rights ::= ["+" / "-"] rights rights ::= 1*right / "-" right ::= ALPHA / DIGIT ; Case-insensitive where "-" means "empty rights", or (if 36 rights aren't enough): rights ::= 1*right / nil right ::= atom In fact, if it weren't for the "chattiness" objections that are commonly made about IMAP, I would consider the latter to be the True IMAP Way. However, I am just mumbling here. I am not seriously suggesting that it be changed at this late date, so everybody please lower your hackles... :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI1f1qk065366; Wed, 17 Nov 2004 17:41:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI1f1BC065365; Wed, 17 Nov 2004 17:41:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI1eufm065315 for ; Wed, 17 Nov 2004 17:40:56 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAI1eTGh054684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 18:40:34 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 17 Nov 2004 17:40:29 -0800 From: Lyndon Nerenberg To: Mark Crispin , Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-MessageCare-Metrics: orthanc.ca 1108; Body=3 Fuz1=3 Fuz2=3 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-17 2:24 PM -0800 Mark Crispin wrote: > Unless there is an intent to use upper-case rights in the future to > mean something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but > that clients MUST send rights as lowercase? Just to be Devil's Advocate: 1) Are we sure 36 rights will be enough? 2) is not case-folded. Since are an I would argue that MUST be case sensitive. (Nothing in 2086 calls out for case-folding, therefore it cannot be assumed by any conforming implementation.) --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMQX2V073718; Wed, 17 Nov 2004 14:26:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHMQXAn073715; Wed, 17 Nov 2004 14:26:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMQWcv073678 for ; Wed, 17 Nov 2004 14:26:32 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAHMQZmh014306; Wed, 17 Nov 2004 14:26:35 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAHMQXWB011659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2004 14:26:34 -0800 Date: Wed, 17 Nov 2004 14:24:30 -0800 (Pacific Standard Time) From: Mark Crispin To: Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041117221610.GA3376@jutta.sendmail.com> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 17 Nov 2004, Jutta Degener wrote: > (Personally, I'd prefer case-*in*sensitivity - I have trouble > remembering which case meant what, why shouldn't other people; > but our implementations don't behave like that now.) This is my preference as well, and is consistant with the rest of IMAP. Unless there is an intent to use upper-case rights in the future to mean something different, would it be possible to transit to a case insensitive regime by stating that rights are case-insensitive, but that clients MUST send rights as lowercase? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMGGfV070130; Wed, 17 Nov 2004 14:16:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHMGGYb070129; Wed, 17 Nov 2004 14:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from jutta.sendmail.com (natted.sendmail.com [63.211.143.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMGFZk070097 for ; Wed, 17 Nov 2004 14:16:15 -0800 (PST) (envelope-from jutta@sendmail.com) Received: by jutta.sendmail.com (Postfix, from userid 500) id 5DD3C179BB; Wed, 17 Nov 2004 14:16:10 -0800 (PST) Date: Wed, 17 Nov 2004 14:16:10 -0800 From: Jutta Degener To: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <20041117221610.GA3376@jutta.sendmail.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 17, 2004 at 03:43:07PM -0500, Cyrus Daboo wrote: > OK, well I guess we will have to find out what real implementations did and > make sure it is clear in 2086upd which way it should be. I can tell you > that my implementation treats the rights as case-sensitive. Sendmail's does, too. (Personally, I'd prefer case-*in*sensitivity - I have trouble remembering which case meant what, why shouldn't other people; but our implementations don't behave like that now.) Jutta Degener Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKh4YR038476; Wed, 17 Nov 2004 12:43:04 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKh4JD038475; Wed, 17 Nov 2004 12:43:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKh38K038469 for ; Wed, 17 Nov 2004 12:43:04 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAHJZG6E017581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 14:35:17 -0500 Date: Wed, 17 Nov 2004 15:43:07 -0500 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> In-Reply-To: <419BB437.2090500@isode.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On November 17, 2004 20:27:35 +0000 Alexey Melnikov wrote: >> Leave it the same as 2086 (original), but perhaps call extra attention >> to the fact that it is case-sensitive. > > RFC 2086 was silent on the issue. I believe the intention was to make > rights case-sensitive. OK, well I guess we will have to find out what real implementations did and make sure it is clear in 2086upd which way it should be. I can tell you that my implementation treats the rights as case-sensitive. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKRicq032324; Wed, 17 Nov 2004 12:27:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKRidb032323; Wed, 17 Nov 2004 12:27:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKRhQB032308 for ; Wed, 17 Nov 2004 12:27:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 20:27:35 +0000 Message-ID: <419BB437.2090500@isode.com> Date: Wed, 17 Nov 2004 20:27:35 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> In-Reply-To: <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Alexey, > > --On November 17, 2004 19:10:16 +0000 Alexey Melnikov > wrote: > >> The document says that all rights are case-sensitive, i.e. "r" is not >> the >> same as "R". Is this is problem? >> Currently there are not uppercase rights assigned. > > Leave it the same as 2086 (original), but perhaps call extra attention > to the fact that it is case-sensitive. RFC 2086 was silent on the issue. I believe the intention was to make rights case-sensitive. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKPXnI031471; Wed, 17 Nov 2004 12:25:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKPXBg031470; Wed, 17 Nov 2004 12:25:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKPRIW031405 for ; Wed, 17 Nov 2004 12:25:32 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAHJHZ6E017221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 14:17:36 -0500 Date: Wed, 17 Nov 2004 15:25:26 -0500 From: Cyrus Daboo To: Alexey Melnikov , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> In-Reply-To: <419BA218.4050000@isode.com> References: <419BA218.4050000@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On November 17, 2004 19:10:16 +0000 Alexey Melnikov wrote: > The document says that all rights are case-sensitive, i.e. "r" is not the > same as "R". Is this is problem? > Currently there are not uppercase rights assigned. Leave it the same as 2086 (original), but perhaps call extra attention to the fact that it is case-sensitive. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJAGdq097620; Wed, 17 Nov 2004 11:10:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHJAGXL097618; Wed, 17 Nov 2004 11:10:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJAFTH097608 for ; Wed, 17 Nov 2004 11:10:15 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 19:10:17 +0000 Message-ID: <419BA218.4050000@isode.com> Date: Wed, 17 Nov 2004 19:10:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: One remaining issue in draft-ietf-imapext-2086upd-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document says that all rights are case-sensitive, i.e. "r" is not the same as "R". Is this is problem? Currently there are not uppercase rights assigned. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHIBZ42077582; Wed, 17 Nov 2004 10:11:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHIBZ8A077581; Wed, 17 Nov 2004 10:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHIBTtI077557 for ; Wed, 17 Nov 2004 10:11:30 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 18:11:21 +0000 Message-ID: <419B9448.4040009@isode.com> Date: Wed, 17 Nov 2004 18:11:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: 2086upd + ANNOTATE dependency References: <4198FB05.40007@oceana.com> In-Reply-To: <4198FB05.40007@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Cyrus Daboo wrote: > >> What I propose is to remove all references to ANNOTATE in 2086upd. >> The ANNOTATE document will define the new ACL bits and have a >> normative reference to 2086upd. That way 2086upd can progress quickly >> without being blocked on ANNOTATE (which itself is blocked on >> SORT/THREAD/i18n). > > Agreed. If we are going this route, the ANNOTATE document must be updated to say that the "n" right (writing shared annotations) is a part of the "shared flag rights" as defined in section 5.2 of the 2086upd ("Mapping of ACL rights to READ-WRITE and READ-ONLY response codes"). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHECPpe096743; Wed, 17 Nov 2004 06:12:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHECPsR096742; Wed, 17 Nov 2004 06:12:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHECJ90096595 for ; Wed, 17 Nov 2004 06:12:23 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id DF45B154009; Wed, 17 Nov 2004 14:12:06 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG , Philip Guenther Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> In-Reply-To: <41991116.9010001@oceana.com> Message-ID: <20041117141206.21034.10575.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Wed, 17 Nov 2004 14:12:06 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 15 20:27:02 2004, Ken Murchison wrote: > Interop with both old and new clients will be a problem. I don't > have all of the answers yet, I'd have to discuss this with the > other Cyrus guys to see if we can work out a solution. I'm just > pointing out that the current wording in the draft doesn't work > with all implementations. My initial thought was that you'd be right, for two reasons: 1) Client authors may have independently made the same interpretation. 2) Client authors may have deliberately copied Cyrus IMAPd's interpretation, given that it's a widely known and used RFC2086 server implementation. To see if this was the case, I decided to read through several IMAP client implementations. My overall assumption was that open-sourced implementations would be most likely to show (2) above, and hence would be visible and a reasonable sample. I looked for two key features of the code: a) A suppression of the UI for folder deletion based on MYRIGHTS output. b) A suppression of actual deletion based on MYRIGHTS output. I read through the source code for Balsa, Mutt, and Mozilla. I have found no evidence for either happening. I'm also told that Evolution doesn't support RFC2086 at all. Documentation for APIs, however, suggests differently. Both Sun's JavaMail documentation and perl's IMAP::Admin module documentation makes the claim that the "c" right allows for DELETE (and RENAME) on submailboxes. Communigate Pro's documentation states that deleting a mailbox requires both the "c" right on the parent *and* the "d" right on the mailbox itself. Incidentally, Cyrus's major problem is that the "x" right needs to be granted, as I understand it, on all submailboxes of a parent which has the "c" right - "c" cannot therefore be a macro for "kx", where "k" is for CREATE (and is the current "c"). I have no real conclusions about this - I'd be interested in knowing what any other clients are doing. My general feeling is that the current draft can stand, but I'd appreciate knowing a little more about other implementations. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGLDM0M021788; Tue, 16 Nov 2004 13:13:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGLDMOF021787; Tue, 16 Nov 2004 13:13:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGLDLZo021774 for ; Tue, 16 Nov 2004 13:13:22 -0800 (PST) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14669; Tue, 16 Nov 2004 16:13:24 -0500 (EST) Message-Id: <200411162113.QAA14669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-2086upd-01.txt Date: Tue, 16 Nov 2004 16:13:24 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension - updated list of rights Author(s) : A. Melnikov Filename : draft-ietf-imapext-2086upd-01.txt Pages : 0 Date : 2004-11-16 The ACL (Access Control List) extension [RFC2086] of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. This document updates the list of rights defined in RFC 2086. It also clarifies which rights are required for different IMAP commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-2086upd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-2086upd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-16113044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-2086upd-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-2086upd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113044.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMbOQX033306; Mon, 15 Nov 2004 14:37:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMbOb6033305; Mon, 15 Nov 2004 14:37:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMbKX7033287 for ; Mon, 15 Nov 2004 14:37:20 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 781D6960B; Mon, 15 Nov 2004 17:37:24 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id 0E85A29F8B; Mon, 15 Nov 2004 17:37:21 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CTpT5-000P0y-6J; Mon, 15 Nov 2004 22:37:03 +0000 Date: Mon, 15 Nov 2004 22:37:03 +0000 From: Brian Candler To: Ken Murchison Cc: Philip Guenther , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) Message-ID: <20041115223703.GA96108@uk.tiscali.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41991116.9010001@oceana.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 03:27:02PM -0500, Ken Murchison wrote: > >So, would > >there be any way at all for the user of an old client to set or clear > >the "x" right? If setting or clearing the "c" right was to also affect > >the "x" right then how would a new (RIGHTS-aware) client set or clear > >the "c" right without affecting the "x" right? > > Interop with both old and new clients will be a problem. I don't have > all of the answers yet, I'd have to discuss this with the other Cyrus > guys to see if we can work out a solution. I'm just pointing out that > the current wording in the draft doesn't work with all implementations. > > One easy way to do this might be to make 'c' a macro in the new draft > just like 'd' and create a new bit for CREATE (e.g. 'k') Then the > mapping would be: > > Cyrus: 'c' -> "kx", 'd' -> "te" > Others: 'c' -> "k", 'd' -> "xte" Would it be a problem to make 'd' more permissive? Let me think aloud. For example: imagine for a moment that c and x are tied (which is in effect the current behaviour of Cyrus, IIUC) Now, suppose we defined the 'd' right as implying e,t,x plus any rights tied to those rights. Then if a client asked for 'd' they would get e+t+x+c. Now: a client which asks for 'd' (intending "delete or expunge mail") will find themselves also getting create submailbox and delete mailbox rights. I don't know if Cyrus has any policy engine which lets you control which rights requests are granted or refused; if it doesn't, then the worst that will happen is that the person administering the ACL will end up adding more rights to a particular user than they intended. And that will only happen if the software used to set up the ACL only understands RFC2086 flags. So what am I proposing? Maybe that the 'd' flag implies 'e','t','x' plus any other flags that the implementation considers necessary. Or maybe that the 'd' flag implies *any* implementation-defined set of flags, but where the recommended set is 'e','t' and 'x'; the goal being that the virtual 'd' flag implies whatever set of flags is necessary so that the client has no fewer rights than they would have had before when asking for 'd'. That's fine; then the problem with Cyrus is that if you ask for 'c', you still get fewer rights than you would have had before when asking for 'c'. If the client understand RFC-2086upd then it can ask for 'x'; if not then it can ask for 'd', although it will end up with perhaps more rights than are needed. Of course, if you are migrating from Cyrus version X (RFC-2086) to version Y (RFC-2086upd), then any existing mailbox rights can be changed as part of this migration. i.e. c becomes cx, d becomes xte. So this will only really affect *ACL administrators* who are using *RFC-2086 clients* which also *do not use LISTRIGHTS* to present the possible rights available to the end-user. Oh well, enough thinking aloud, as I don't seem to be getting very far :-) Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKPvQo098955; Mon, 15 Nov 2004 12:25:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFKPvfD098954; Mon, 15 Nov 2004 12:25:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKPucb098913 for ; Mon, 15 Nov 2004 12:25:56 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFKPr3d015432; Mon, 15 Nov 2004 15:25:53 -0500 (EST) Message-ID: <41991116.9010001@oceana.com> Date: Mon, 15 Nov 2004 15:27:02 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> In-Reply-To: <200411151957.iAFJvF66074656@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: > Ken Murchison writes: > ... > >>>The difference would be that the client would be required to request both >>>"c" and "x" in order to set this bit; but it would know that is necessary if >>>it made use of the LISTRIGHTS information which indicated they were tied. >> >>We don't want to do this. Spitting 'x' from 'c' is a migration issue >>specific to Cyrus, which we will have to handle. As soon as we >>implement this update any existing ACL which has "c" will have to be >>reported as "cx". The 'x' right will then have to be explicitly removed. > > > ...if they don't want the user to have both rights but only create. > > ... > >>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', >>which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server >>shouldn't have to set 'x' (because the draft says MUST) if it doesn't >>apply. I have no problem with 'd' being a macro for 'e' and 't', but >>whether this macro also includes 'd' should be implementation specific. > > > So you're proposing that an implementation (Cyrus) be allowed to not > set/clear the "x" right when the "d" right is set/cleared. Yes. The draft makes the false assumption that *all* existing implementations use the 'd' right to control DELETE. Cyrus made the decision a while back to separate mailbox ops (DELETE) from message ops (\Deleted and EXPUNGE). Its unfortunate that RFC 2086 was vague/ambiguous w.r.t. DELETE. > So, would > there be any way at all for the user of an old client to set or clear > the "x" right? If setting or clearing the "c" right was to also affect > the "x" right then how would a new (RIGHTS-aware) client set or clear > the "c" right without affecting the "x" right? Interop with both old and new clients will be a problem. I don't have all of the answers yet, I'd have to discuss this with the other Cyrus guys to see if we can work out a solution. I'm just pointing out that the current wording in the draft doesn't work with all implementations. One easy way to do this might be to make 'c' a macro in the new draft just like 'd' and create a new bit for CREATE (e.g. 'k') Then the mapping would be: Cyrus: 'c' -> "kx", 'd' -> "te" Others: 'c' -> "k", 'd' -> "xte" -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJvCfp091730; Mon, 15 Nov 2004 11:57:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFJvCO6091729; Mon, 15 Nov 2004 11:57:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJvCqa091710 for ; Mon, 15 Nov 2004 11:57:12 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFJvFJN011892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 11:57:16 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFJvFJN011892 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=QnKFF6ckyo+Od+D5eWNfpqibg9ztg3IS16amjEVSqjI24Lcpk60mIMm9yR9GJYklE VyapK0zGTQ0lOIPbnlexS/kCAk1svJo5CGiRNxVEseNBgbHPA92R/ngvOtPVHPA807L qSBLbmNSCMucxIiT+/DrTs4jJ+KQ3pzXR8Xoe6A= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFJvF66074656; Mon, 15 Nov 2004 11:57:15 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151957.iAFJvF66074656@lab.smi.sendmail.com> To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) In-reply-to: <419901B0.5080808@oceana.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> Date: Mon, 15 Nov 2004 11:57:15 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: ... >> The difference would be that the client would be required to request both >> "c" and "x" in order to set this bit; but it would know that is necessary if >> it made use of the LISTRIGHTS information which indicated they were tied. > >We don't want to do this. Spitting 'x' from 'c' is a migration issue >specific to Cyrus, which we will have to handle. As soon as we >implement this update any existing ACL which has "c" will have to be >reported as "cx". The 'x' right will then have to be explicitly removed. ...if they don't want the user to have both rights but only create. ... >My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', >which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server >shouldn't have to set 'x' (because the draft says MUST) if it doesn't >apply. I have no problem with 'd' being a macro for 'e' and 't', but >whether this macro also includes 'd' should be implementation specific. So you're proposing that an implementation (Cyrus) be allowed to not set/clear the "x" right when the "d" right is set/cleared. So, would there be any way at all for the user of an old client to set or clear the "x" right? If setting or clearing the "c" right was to also affect the "x" right then how would a new (RIGHTS-aware) client set or clear the "c" right without affecting the "x" right? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJKFHj080940; Mon, 15 Nov 2004 11:20:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFJKFbe080939; Mon, 15 Nov 2004 11:20:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJKFpV080919 for ; Mon, 15 Nov 2004 11:20:15 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFJKBGr014082; Mon, 15 Nov 2004 14:20:11 -0500 (EST) Message-ID: <419901B0.5080808@oceana.com> Date: Mon, 15 Nov 2004 14:21:20 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Brian Candler CC: Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> In-Reply-To: <20041115183222.GA95559@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler wrote: > On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote: > >>I think we need to add language that says that 'x' must be associated >>with whichever ACL bit was previously used for DELETE, and not assume >>that its 'd'. > > > I'm not sure there is a problem, because RFC2086 explicitly allows the > server to tie together whichever bits it likes in whichever way is > convenient to it: > > An implementation may tie rights together or may force rights to > always or never be granted to particular identifiers. For example, > in an implementation that uses unix mode bits, the rights "wisd" are > tied, the "a" right is always granted to the owner of a mailbox and > is never granted to another user. If rights are tied in an > implementation, the implementation must be conservative in granting > rights in response to SETACL commands--unless all rights in a tied > set are specified, none of that set should be included in the ACL > entry for that identifier. A client may discover the set of rights > which may be granted to a given identifier in the ACL for a given > mailbox by using the LISTRIGHTS command. I'm fully aware of this, but we don't want to tie any rights together. That's the whole point of the new specs. > So in Cyrus you can have a single bit internally, which (if set) is reported > to the client as "cx". We already have one and its 'c'. > The difference would be that the client would be required to request both > "c" and "x" in order to set this bit; but it would know that is necessary if > it made use of the LISTRIGHTS information which indicated they were tied. We don't want to do this. Spitting 'x' from 'c' is a migration issue specific to Cyrus, which we will have to handle. As soon as we implement this update any existing ACL which has "c" will have to be reported as "cx". The 'x' right will then have to be explicitly removed. > Now, "d" being an alias for e+t+x is a bit of a special case. But at least > it is a single, well-defined special case; and also note that "d" is not a > real bit in its own right, but a virtual bit synthesised from (e && t && x). > I can't see a clean way to do what you seem to be suggesting, which is to > associate "x" with another bit, apart from the mechanism which is already > there which allows bits to be tied together. > > Can you be more specific on what you are proposing? My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server shouldn't have to set 'x' (because the draft says MUST) if it doesn't apply. I have no problem with 'd' being a macro for 'e' and 't', but whether this macro also includes 'd' should be implementation specific. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIptXq073519; Mon, 15 Nov 2004 10:51:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFIptIA073518; Mon, 15 Nov 2004 10:51:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIpnvN073454 for ; Mon, 15 Nov 2004 10:51:50 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFIpiON013428; Mon, 15 Nov 2004 13:51:44 -0500 (EST) Message-ID: <4198FB05.40007@oceana.com> Date: Mon, 15 Nov 2004 13:52:53 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: 2086upd + ANNOTATE dependency References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > What I propose is to remove all references to ANNOTATE in 2086upd. The > ANNOTATE document will define the new ACL bits and have a normative > reference to 2086upd. That way 2086upd can progress quickly without > being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n). Agreed. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIWXgB069431; Mon, 15 Nov 2004 10:32:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFIWX9l069430; Mon, 15 Nov 2004 10:32:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIWWEZ069424 for ; Mon, 15 Nov 2004 10:32:32 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 01044ADC73; Mon, 15 Nov 2004 13:32:36 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 9C07C419B28; Mon, 15 Nov 2004 13:32:33 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CTleI-000Ort-6n; Mon, 15 Nov 2004 18:32:22 +0000 Date: Mon, 15 Nov 2004 18:32:22 +0000 From: Brian Candler To: Ken Murchison Cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) Message-ID: <20041115183222.GA95559@uk.tiscali.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4198EB4A.7020604@oceana.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote: > I think we need to add language that says that 'x' must be associated > with whichever ACL bit was previously used for DELETE, and not assume > that its 'd'. I'm not sure there is a problem, because RFC2086 explicitly allows the server to tie together whichever bits it likes in whichever way is convenient to it: An implementation may tie rights together or may force rights to always or never be granted to particular identifiers. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. So in Cyrus you can have a single bit internally, which (if set) is reported to the client as "cx". The difference would be that the client would be required to request both "c" and "x" in order to set this bit; but it would know that is necessary if it made use of the LISTRIGHTS information which indicated they were tied. Now, "d" being an alias for e+t+x is a bit of a special case. But at least it is a single, well-defined special case; and also note that "d" is not a real bit in its own right, but a virtual bit synthesised from (e && t && x). I can't see a clean way to do what you seem to be suggesting, which is to associate "x" with another bit, apart from the mechanism which is already there which allows bits to be tied together. Can you be more specific on what you are proposing? Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHlarv059125; Mon, 15 Nov 2004 09:47:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFHla0L059121; Mon, 15 Nov 2004 09:47:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHlVak059070 for ; Mon, 15 Nov 2004 09:47:35 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAFGe06E014843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Nov 2004 11:40:02 -0500 Date: Mon, 15 Nov 2004 12:47:31 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: 2086upd + ANNOTATE dependency Message-ID: X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should 2086upd mention ANNOTATE at all? Right now it does define the 'n' right but has very little to say about it, other than providing the informative reference to ANNOTATE. That reference really ought to be normative since the meaning of 'n' (and 'm') are important. However, this adds a two-way dependency between 2086upd and ANNOTATE. What I propose is to remove all references to ANNOTATE in 2086upd. The ANNOTATE document will define the new ACL bits and have a normative reference to 2086upd. That way 2086upd can progress quickly without being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n). -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHif5l058419; Mon, 15 Nov 2004 09:44:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFHifaf058418; Mon, 15 Nov 2004 09:44:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHieM2058397 for ; Mon, 15 Nov 2004 09:44:40 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFHibBG011904; Mon, 15 Nov 2004 12:44:37 -0500 (EST) Message-ID: <4198EB4A.7020604@oceana.com> Date: Mon, 15 Nov 2004 12:45:46 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> In-Reply-To: <418C19CC.3030600@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just noticed something in this draft, and ACL2 for that matter, which may cause problems with Cyrus. The draft seems to assume that the old 'd' right was used to allow the DELETE command, where RFC 2086 was vague on this (in fact it never mentions DELETE or RENAME). All current Cyrus code uses the 'c' right for both CREATE and DELETE. So for Cyrus, associating the new 'x' right with 'd' doesn't make any sense, it would probably be associated with 'c'. I think we need to add language that says that 'x' must be associated with whichever ACL bit was previously used for DELETE, and not assume that its 'd'. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFH7BZg043812; Mon, 15 Nov 2004 09:07:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFH7Bt2043809; Mon, 15 Nov 2004 09:07:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFH7A6t043735 for ; Mon, 15 Nov 2004 09:07:10 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFH74CF010916; Mon, 15 Nov 2004 12:07:05 -0500 (EST) Message-ID: <4198E27D.8060704@oceana.com> Date: Mon, 15 Nov 2004 12:08:13 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP Extensions WG CC: Alexey Melnikov Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> <4198A4EA.8090901@isode.com> <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: > > On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote: > >> Alexey Melnikov wrote: >> >>> The second issue: >>> >>> Which rights are required for the LISTRIGHTS command? >>> >>> Currently the document says: >>> >>> MYRIGHTS - any of the following rights is required to perform >>> the operation: "l", "r", "i", "c", "x", "a".* >>> >>> LISTRIGHTS - same as MYRIGHTS. >>> >>> Some of the existing servers follow this suggestion. Some allow for >>> LISTRIGHTS if "r" and/or "a" is granted. >>> >>> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" >>> right is granted, as LISTRIGHTS information is only useful >>> if you can also do SETACL. Also, such information shouldn't be disclosed >>> to users that have insufficient rights. >> >> >> So, any comments on changing LISTRIGHTS to require the "a" right? > > > As a client implementor of sorts, I can't see any reason for using > LISTRIGHTS if I didn't intend to use the results to frame a SETACL or > DELETEACL. > > Hence I'm in agreement - make it require "a". I'm also in agreement. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGpion033954; Mon, 15 Nov 2004 08:51:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGpict033953; Mon, 15 Nov 2004 08:51:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGphKv033937 for ; Mon, 15 Nov 2004 08:51:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 16:51:41 +0000 Message-ID: <4198DE9B.3080206@isode.com> Date: Mon, 15 Nov 2004 16:51:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198A1EB.3040107@isode.com> <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> In-Reply-To: <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: > > >>Philip Guenther wrote: >> >> >>>Please review the 2086upd draft as soon as possible, as it should be >>>going to working group last call Real Soon Now. Only one substantive >>>change was discussed at the IETF meeting last week: instead of returning >>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS >>>response _code_. So, for example, this line from the SELECT example in >>>section 7.1.1: >>> S: * MYRIGHTS INBOX rwis >>>will end up instead reading: >>> S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights >>> >>> >>The ACL2 document defines MYRIGHTS response code, but it doesn't include >>a mailbox name. Is it Ok? >> >> > >So it should instead read: > S: * OK [MYRIGHTS rwis] No more, no less > > >The Formal Syntax needs to define the syntax for that as an extension of >resp-text-code: > >resp-text-code =/ myrights_rspcod > >myrights_rspcod = "MYRIGHTS" SP rights > >rights = atom > ;; MUST NOT contain leading "+" or "-" > ;; MUST be treated as case-sensitive > >Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights. >Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no >point in allowing them here in the MYRIGHTS response code. > > I agree. >The UTF-8 reference should be updated the RFC 3629. > Done. >It should be noted >somewhere that an identifier containing non-US-ASCII characters MUST be >represented as a literal and not a quoted-string or atom. > > This just follows from rules for literals defined in RFC 3501. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGiqEU029170; Mon, 15 Nov 2004 08:44:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGiqGv029169; Mon, 15 Nov 2004 08:44:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGipGR028947 for ; Mon, 15 Nov 2004 08:44:51 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id BC703154009; Mon, 15 Nov 2004 16:44:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> <4198A4EA.8090901@isode.com> In-Reply-To: <4198A4EA.8090901@isode.com> Message-ID: <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 15 Nov 2004 16:44:33 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote: > Alexey Melnikov wrote: >> The second issue: >> >> Which rights are required for the LISTRIGHTS command? >> >> Currently the document says: >> >> MYRIGHTS - any of the following rights is required to perform >> the operation: "l", "r", "i", "c", "x", "a".* >> >> LISTRIGHTS - same as MYRIGHTS. >> >> Some of the existing servers follow this suggestion. Some allow for >> LISTRIGHTS if "r" and/or "a" is granted. >> >> Philip has suggested (and I agree) to only allow LISTRIGHTS when >> the "a" >> right is granted, as LISTRIGHTS information is only useful >> if you can also do SETACL. Also, such information shouldn't be >> disclosed >> to users that have insufficient rights. > > So, any comments on changing LISTRIGHTS to require the "a" right? As a client implementor of sorts, I can't see any reason for using LISTRIGHTS if I didn't intend to use the results to frame a SETACL or DELETEACL. Hence I'm in agreement - make it require "a". Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGHiap011154; Mon, 15 Nov 2004 08:17:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGHiZi011153; Mon, 15 Nov 2004 08:17:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGHien011144 for ; Mon, 15 Nov 2004 08:17:44 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFGHkqD000912 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 08:17:46 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFGHkqD000912 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cqCuL+jI5NDsrSRXmzldN/pcQl4ybC0Z2zZo3umE++1q4GFWeI36wjlO+X//xGrLe 9pCxn/p1hUgMo3lx/3Fxq1X/yokfV3oNSfY04FJKbdlIdmKZEOQct3FWX1JOf/pMu+C C3vxtdupT616+NxPVADOsH8LrMbLdnxTH9Ho3uY= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFGHkZa056209; Mon, 15 Nov 2004 08:17:46 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> To: Alexey Melnikov From: Philip Guenther Cc: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <4198A1EB.3040107@isode.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198A1EB.3040107@isode.com> Date: Mon, 15 Nov 2004 08:17:46 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: >>Please review the 2086upd draft as soon as possible, as it should be >>going to working group last call Real Soon Now. Only one substantive >>change was discussed at the IETF meeting last week: instead of returning >>a MYRIGHTS response, the SELECT command should return a MYRIGHTS >>response _code_. So, for example, this line from the SELECT example in >>section 7.1.1: >> S: * MYRIGHTS INBOX rwis >>will end up instead reading: >> S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights > >The ACL2 document defines MYRIGHTS response code, but it doesn't include >a mailbox name. Is it Ok? So it should instead read: S: * OK [MYRIGHTS rwis] No more, no less The Formal Syntax needs to define the syntax for that as an extension of resp-text-code: resp-text-code =/ myrights_rspcod myrights_rspcod = "MYRIGHTS" SP rights rights = atom ;; MUST NOT contain leading "+" or "-" ;; MUST be treated as case-sensitive Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights. Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no point in allowing them here in the MYRIGHTS response code. The UTF-8 reference should be updated the RFC 3629. It should be noted somewhere that an identifier containing non-US-ASCII characters MUST be represented as a literal and not a quoted-string or atom. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFaSI9089145; Mon, 15 Nov 2004 07:36:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFFaStQ089143; Mon, 15 Nov 2004 07:36:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFaRHo089134 for ; Mon, 15 Nov 2004 07:36:27 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFFaTB7021481 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 07:36:29 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFFaTB7021481 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=k2/fDOdtDxxd/64Mf9yct2Ge/sUHAwXGQ6maOF4v0cw/MjcbnaxXBVjcxydaSIGBN IJm5HmTeem3ISDgJrFRUgQtqUt9FP73r0TMKNLVt2qDOU0kse+92S1yF/Z4TO6JQ9C2 5MJQXQpuz/EgXf3SlVmddjh8AUO+dcFEmM6Y0fQ= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFFaS7i053352; Mon, 15 Nov 2004 07:36:28 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151536.iAFFaS7i053352@lab.smi.sendmail.com> To: Brian Candler Cc: Alexey Melnikov , ietf-imapext@imc.org From: Philip Guenther Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <20041115143919.GC65701@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198B5E1.4070405@isode.com> <20041115143919.GC65701@uk.tiscali.com> Date: Mon, 15 Nov 2004 07:36:28 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler writes: ... >I don't think it need be so complicated; how about just > > If a client includes the "d" right in a rights list, then it is to be > treated as if the client had included the "x", "e" and "t" rights. > >(You could add: It is not an error for a client to specify both "d" and one >or more of "x", "e" and "t", but the effect no different than if just "d" or >all of "x", "e" and "t" had been specified) I like this wording, including the parenthetical addition. ... >I don't like the wording "clears the "d" right from a rights list", because >IIUC you can't ask for individual flags to be set or cleared; you can only >ask for the entire set of flags to be replaced with a new set. ... If the third argument to SETACL starts with a "+" or "-" then it is a modification to the existing rights for that identifier and not a complete replacement. I think your wording above covers that sufficiently by virtue of not referring to the operation at all. Less is more... Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEdasF072977; Mon, 15 Nov 2004 06:39:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFEdajI072976; Mon, 15 Nov 2004 06:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEdZ2L072960 for ; Mon, 15 Nov 2004 06:39:35 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 65A589624; Mon, 15 Nov 2004 09:39:33 -0500 (EST) Received: from thinkdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id D92162742C; Mon, 15 Nov 2004 09:39:30 -0500 (EST) Received: from brian by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CTi0l-000H6h-4i; Mon, 15 Nov 2004 14:39:19 +0000 Date: Mon, 15 Nov 2004 14:39:19 +0000 From: Brian Candler To: Alexey Melnikov Cc: Philip Guenther , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl Message-ID: <20041115143919.GC65701@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198B5E1.4070405@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4198B5E1.4070405@isode.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 01:57:53PM +0000, Alexey Melnikov wrote: > I think the following text in the appendix B could have caused the > confusion: > > This document replaces the "d" right with 3 new different rights "x", > "t" and "e". > > Any suggestion how to improve this? I don't think that's necessarily the source of confusion, but it could be elaborated: This document splits the "d" right into 3 new different rights "x", "t" and "e". The "d" right remains for backwards-compatibility but it is a virtual right. If a client requests the "d" right, it is treated as if it requested all of "x", "t" and "e". The server returns the "d" right if and only if all of "x", "t" and "e" are set. > I've changed this to: > If a client request clears the "d" right from a rights lists, then > the server MUST also clear > any of the "x", "e", and "t" rights, unless one or more of them is > also specified in the same rights list. > > Is this any better? > > Or maybe even: > If a client request clears the "d" right from a rights lists, then > the server MUST first clear > all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" > rights are specified in the same rights list, they are then set as usual. > ? I don't think it need be so complicated; how about just If a client includes the "d" right in a rights list, then it is to be treated as if the client had included the "x", "e" and "t" rights. (You could add: It is not an error for a client to specify both "d" and one or more of "x", "e" and "t", but the effect no different than if just "d" or all of "x", "e" and "t" had been specified) I don't like the wording "clears the "d" right from a rights list", because IIUC you can't ask for individual flags to be set or cleared; you can only ask for the entire set of flags to be replaced with a new set. So the only issue is, if the replacement set contains "d", how is it to be handled? And I think the answer is, just as if "x", "e" and "t" had been specified. Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDwFZj060378; Mon, 15 Nov 2004 05:58:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFDwFFf060377; Mon, 15 Nov 2004 05:58:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDw91K060360 for ; Mon, 15 Nov 2004 05:58:10 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 13:57:55 +0000 Message-ID: <4198B5E1.4070405@isode.com> Date: Mon, 15 Nov 2004 13:57:53 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >>The one implementation I have access to is courier-imap, and that behaves as >>follows: >> >>- If e,t or x (but not all three) are set, return those flags for LIST (ACL) >> and none for GETACL >>- If all three are set, return only "d" for both LIST (ACL) and GETACL >> >> > >The description of the 'd' right in the ACL2 and RIGHTS drafts are the >same: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). If a client sets "d" right, the server MUST > set "x", "e" and "t" rights. When the client clears the "d" right, > the server MUST clear "x", "e" and "t" rights. When all three of "x", > "e" and "t" are set, the server MUST return "d" right in response to > a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, > "d" right MUST NOT be returned in a response. > >Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't >say that clients should treat the 'd' right as implying the "etx" >rights, I don't see how the text gives the server the license to leave >out the "etx" rights when returning the 'd' right in LIST (ACL). > I think the following text in the appendix B could have caused the confusion: This document replaces the "d" right with 3 new different rights "x", "t" and "e". Any suggestion how to improve this? > The >*server* must make the d->etx implication when changing rights, but the >client isn't required to make it when reading them. > > >Perhaps most of the the description of the 'd' right should be moved >out of the list into its own paragraph? The list of rights would just >say: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). See below for details on how servers > should interpret it in commands that alter ACLs and when it > should be included in responses that return ACLs or lists of > rights. > >Then later: > If a client request sets the "d" right in a rights list, the server > MUST set the "x", "e", and "t" rights. If a client request clears > the "d" right from a rights lists, then the server MUST also clear > any of the "x", "e", and "t" rights that are not simultaneously being > set. > I've changed this to: If a client request clears the "d" right from a rights lists, then the server MUST also clear any of the "x", "e", and "t" rights, unless one or more of them is also specified in the same rights list. Is this any better? Or maybe even: If a client request clears the "d" right from a rights lists, then the server MUST first clear all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" rights are specified in the same rights list, they are then set as usual. ? > When all three of the "x", "e", and "t" rights are set in a > list of rights, the server MUST also include the "d" right when > returning that list in a MYRIGHTS or ACL response. If the "x", "e", > and "t" rights are not tied together, the "d" right MUST NOT be > returned in a LISTRIGHTS response. > >(The phrasing about "simultaneously being set" is to make it clear that >even though the request > tag SETACL "foo" "guenther" "lrswt" >doesn't include (and may be clearing) the "d" right, the "t" right >should still be set.) > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCjXor024471; Mon, 15 Nov 2004 04:45:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCjXGW024470; Mon, 15 Nov 2004 04:45:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCjWg0024464 for ; Mon, 15 Nov 2004 04:45:33 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:45:32 +0000 Message-ID: <4198A4EA.8090901@isode.com> Date: Mon, 15 Nov 2004 12:45:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> In-Reply-To: <418CFBE9.1050308@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Actually, I believe there are only two. One relates to whether the "m" > right only controls writability of private annotations, or whether it > also controls readability. I've sent a separate message on this. I believe that this issue is closed now. > The second issue: > > Which rights are required for the LISTRIGHTS command? > > Currently the document says: > > MYRIGHTS - any of the following rights is required to perform > the operation: "l", "r", "i", "c", "x", "a".* > > LISTRIGHTS - same as MYRIGHTS. > > Some of the existing servers follow this suggestion. Some allow for > LISTRIGHTS if "r" and/or "a" is granted. > > Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" > right is granted, as LISTRIGHTS information is only useful > if you can also do SETACL. Also, such information shouldn't be disclosed > to users that have insufficient rights. So, any comments on changing LISTRIGHTS to require the "a" right? > Alexey > > * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are > not part of this list, because the client must be able to open a mailbox > (i.e. "r") before performing a STORE command. The list also used to > contain the "e" right (which controls EXPUNGE), I've deleted it for the > same reason. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCWqiU017284; Mon, 15 Nov 2004 04:32:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCWqX8017283; Mon, 15 Nov 2004 04:32:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCWpbE017257 for ; Mon, 15 Nov 2004 04:32:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:32:45 +0000 Message-ID: <4198A1EB.3040107@isode.com> Date: Mon, 15 Nov 2004 12:32:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Please review the 2086upd draft as soon as possible, as it should be >going to working group last call Real Soon Now. Only one substantive >change was discussed at the IETF meeting last week: instead of returning >a MYRIGHTS response, the SELECT command should return a MYRIGHTS >response _code_. So, for example, this line from the SELECT example in >section 7.1.1: > S: * MYRIGHTS INBOX rwis >will end up instead reading: > S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights >(Can't return a new response unless the client indicated it expected it >by using some new syntax. That's why the UNSEEN, UIDVALIDITY, UIDNEXT, >and PERMANENTFLAGS values are returned as response codes instead of >responses.) > > The ACL2 document defines MYRIGHTS response code, but it doesn't include a mailbox name. Is it Ok? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCHPEJ003422; Mon, 15 Nov 2004 04:17:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCHPh6003413; Mon, 15 Nov 2004 04:17:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCHFli003130 for ; Mon, 15 Nov 2004 04:17:15 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:16:45 +0000 Message-ID: <41989E2A.9030308@isode.com> Date: Mon, 15 Nov 2004 12:16:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <20041115083336.GB691@uk.tiscali.com> In-Reply-To: <20041115083336.GB691@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler wrote: >On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote: > > >>Perhaps most of the the description of the 'd' right should be moved >>out of the list into its own paragraph? The list of rights would just >>say: >> d - This right is defined for backward compatibility with ACL >> extension (RFC 2086). See below for details on how servers >> should interpret it in commands that alter ACLs and when it >> should be included in responses that return ACLs or lists of >> rights. >> >>Then later: >> If a client request sets the "d" right in a rights list, the server >> MUST set the "x", "e", and "t" rights. If a client request clears >> the "d" right from a rights lists, then the server MUST also clear >> any of the "x", "e", and "t" rights that are not simultaneously being >> set. When all three of the "x", "e", and "t" rights are set in a >> list of rights, the server MUST also include the "d" right when >> returning that list in a MYRIGHTS or ACL response. If the "x", "e", >> and "t" rights are not tied together, the "d" right MUST NOT be >> returned in a LISTRIGHTS response. >> >>(The phrasing about "simultaneously being set" is to make it clear that >>even though the request >> tag SETACL "foo" "guenther" "lrswt" >>doesn't include (and may be clearing) the "d" right, the "t" right >>should still be set.) >> >> > >Yes, that looks better. > > I think I want to rephrase the "simultaneously being set" part, but the idea looks good. >>A few more nits on the 2086upd draft: the reference to LISTEXT in the >>Formal Syntax should be removed. In Appendix B, replace "a LIST >>response" with "MYRIGHTS and ACL responses" and replace "ACL2" with >>"RIGHTS". >> >> > >I spotted those too :-) > > Fixed now. Thanks for spotting this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF8XvF4070586; Mon, 15 Nov 2004 00:33:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF8XvlC070585; Mon, 15 Nov 2004 00:33:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF8Xlki070490 for ; Mon, 15 Nov 2004 00:33:47 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 7E91FADCC7; Mon, 15 Nov 2004 03:33:46 -0500 (EST) Received: from thinkdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 0AEAF41B0E7; Mon, 15 Nov 2004 03:33:43 -0500 (EST) Received: from brian by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CTcIq-000LWJ-Fl; Mon, 15 Nov 2004 08:33:36 +0000 Date: Mon, 15 Nov 2004 08:33:36 +0000 From: Brian Candler To: Philip Guenther Cc: ietf-imapext@imc.org, Alexey Melnikov Subject: Re: Clarification of "d" right in imapext-acl Message-ID: <20041115083336.GB691@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote: > Perhaps most of the the description of the 'd' right should be moved > out of the list into its own paragraph? The list of rights would just > say: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). See below for details on how servers > should interpret it in commands that alter ACLs and when it > should be included in responses that return ACLs or lists of > rights. > > Then later: > If a client request sets the "d" right in a rights list, the server > MUST set the "x", "e", and "t" rights. If a client request clears > the "d" right from a rights lists, then the server MUST also clear > any of the "x", "e", and "t" rights that are not simultaneously being > set. When all three of the "x", "e", and "t" rights are set in a > list of rights, the server MUST also include the "d" right when > returning that list in a MYRIGHTS or ACL response. If the "x", "e", > and "t" rights are not tied together, the "d" right MUST NOT be > returned in a LISTRIGHTS response. > > (The phrasing about "simultaneously being set" is to make it clear that > even though the request > tag SETACL "foo" "guenther" "lrswt" > doesn't include (and may be clearing) the "d" right, the "t" right > should still be set.) Yes, that looks better. > A few more nits on the 2086upd draft: the reference to LISTEXT in the > Formal Syntax should be removed. In Appendix B, replace "a LIST > response" with "MYRIGHTS and ACL responses" and replace "ACL2" with > "RIGHTS". I spotted those too :-) Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAEN4Mfp074820; Sun, 14 Nov 2004 15:04:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAEN4Mwr074819; Sun, 14 Nov 2004 15:04:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAEN4Mnl074801 for ; Sun, 14 Nov 2004 15:04:22 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAEN4KjZ025451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 14 Nov 2004 15:04:20 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAEN4KjZ025451 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=VIALlyoSg4inqxMmb6/AcUQan+CsbzuFFw8Mj2yOqthLPHZXvQJWa6w/ZHoE2wW+7 0UCfJejbYkLOtx8UH1C70rxE0UXePNqhx4qbAMRcxO5BKuzD2moPg7erZ1lgL0+jJ7Q pw9hz1e1yaA4QceEU1/Ngx00MlnZHojSZRUzZuc= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAEN4J9C087820; Sun, 14 Nov 2004 15:04:20 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> To: Brian Candler Cc: ietf-imapext@imc.org, Alexey Melnikov From: Philip Guenther Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <20041113115206.GA854@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> Date: Sun, 14 Nov 2004 15:04:19 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler writes: >According to draft-ietf-imapext-acl-10.txt section 3.1: ... >RFC 2086 allows standards-track documents to define additional rights; if >the intention is that LIST (ACL) and GETACL are permitted to return exactly >the same set of flags under all circumstances, or not, then I think this >should be made explicit. At the San Diego meeting, the working group decided to put ACL2 on hold for a moment in favor of turning out a quick revision of RFC 2086 that added some additional rights (etxmn) and clarified exactly which rights were required for which commands. Alexey sent the current version of that doc, draft-ietf-imapext-2086upd-01.txt, to the list on Nov 7: http://www.imc.org/ietf-imapext/mail-archive/msg02242.html That revision isn't in the I-D repository yet. Now, this affects your question/query in that the "etx" rights are being added without changing the commands, so they will definitely be returned by the GETACL command in an implementation supporting the RIGHTS extension defined in the above draft. As for returning the 'd' right from LIST (ACL), the draft currently is specific about requiring it. Permitting the server to leave it out when GETACL is required to return it would make the text more complicated for, IMO, no real gain. (Once LISTEXT and RIGHTS are published, the ACL2 draft will shrink a *lot*) Please review the 2086upd draft as soon as possible, as it should be going to working group last call Real Soon Now. Only one substantive change was discussed at the IETF meeting last week: instead of returning a MYRIGHTS response, the SELECT command should return a MYRIGHTS response _code_. So, for example, this line from the SELECT example in section 7.1.1: S: * MYRIGHTS INBOX rwis will end up instead reading: S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights (Can't return a new response unless the client indicated it expected it by using some new syntax. That's why the UNSEEN, UIDVALIDITY, UIDNEXT, and PERMANENTFLAGS values are returned as response codes instead of responses.) >The one implementation I have access to is courier-imap, and that behaves as >follows: > >- If e,t or x (but not all three) are set, return those flags for LIST (ACL) > and none for GETACL >- If all three are set, return only "d" for both LIST (ACL) and GETACL The description of the 'd' right in the ACL2 and RIGHTS drafts are the same: d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, "d" right MUST NOT be returned in a response. Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't say that clients should treat the 'd' right as implying the "etx" rights, I don't see how the text gives the server the license to leave out the "etx" rights when returning the 'd' right in LIST (ACL). The *server* must make the d->etx implication when changing rights, but the client isn't required to make it when reading them. Perhaps most of the the description of the 'd' right should be moved out of the list into its own paragraph? The list of rights would just say: d - This right is defined for backward compatibility with ACL extension (RFC 2086). See below for details on how servers should interpret it in commands that alter ACLs and when it should be included in responses that return ACLs or lists of rights. Then later: If a client request sets the "d" right in a rights list, the server MUST set the "x", "e", and "t" rights. If a client request clears the "d" right from a rights lists, then the server MUST also clear any of the "x", "e", and "t" rights that are not simultaneously being set. When all three of the "x", "e", and "t" rights are set in a list of rights, the server MUST also include the "d" right when returning that list in a MYRIGHTS or ACL response. If the "x", "e", and "t" rights are not tied together, the "d" right MUST NOT be returned in a LISTRIGHTS response. (The phrasing about "simultaneously being set" is to make it clear that even though the request tag SETACL "foo" "guenther" "lrswt" doesn't include (and may be clearing) the "d" right, the "t" right should still be set.) A few more nits on the 2086upd draft: the reference to LISTEXT in the Formal Syntax should be removed. In Appendix B, replace "a LIST response" with "MYRIGHTS and ACL responses" and replace "ACL2" with "RIGHTS". There are also a few remaining places where <"foo" right> should be changed to (e.g., in the last paragraph of section 6). >Whether or not that's the intention of the draft, IMO the wording could be >made clearer. Would the above text do so? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADBqA3m022094; Sat, 13 Nov 2004 03:52:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADBqA1A022093; Sat, 13 Nov 2004 03:52:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADBqAJc022083 for ; Sat, 13 Nov 2004 03:52:10 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 46ADAADC38 for ; Sat, 13 Nov 2004 06:52:11 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 046B841AD7C for ; Sat, 13 Nov 2004 06:52:09 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CSwRq-0000Ej-Lb for ietf-imapext@imc.org; Sat, 13 Nov 2004 11:52:06 +0000 Date: Sat, 13 Nov 2004 11:52:06 +0000 From: Brian Candler To: ietf-imapext@imc.org Subject: Clarification of "d" right in imapext-acl Message-ID: <20041113115206.GA854@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: According to draft-ietf-imapext-acl-10.txt section 3.1: d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. and later in section 9.1: b). Implement separate "x", "t" and "e". Return "d" right in a LIST response containing ACL information when all three of "x", "t" and "e" are granted. However I don't think it's clear whether this means that the LIST (ACL) command should return the d flag *in addition* to etx, or *instead of* etx. Also, it's not clear to me whether the old GETACL command is permitted to return the e, t or x flags separately if they exist, or hide them. But if it has to hide them, i.e. GETACL is supposed to be implemented differently to LIST (ACL) for the benefit of RFC 2086 clients, then is there any need for LIST (ACL) to return a "d" flag at all? LIST (ACL) is an ACL2 command, so any ACL2 client should understand 'e','t' and 'x' separately anyway. RFC 2086 allows standards-track documents to define additional rights; if the intention is that LIST (ACL) and GETACL are permitted to return exactly the same set of flags under all circumstances, or not, then I think this should be made explicit. The one implementation I have access to is courier-imap, and that behaves as follows: - If e,t or x (but not all three) are set, return those flags for LIST (ACL) and none for GETACL - If all three are set, return only "d" for both LIST (ACL) and GETACL Whether or not that's the intention of the draft, IMO the wording could be made clearer. Regards, Brian Candler. * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information. a login fred@flintstone.org XXXXXXXX a OK LOGIN Ok. a acl store "INBOX.mytest" "user=wilma@flintstone.org" "et" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "et")))) a OK ACL STORE completed. a list (acl) "" "INBOX.mytest" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "et")))) a OK LIST completed a getacl "INBOX.mytest" * ACL "INBOX.mytest" "owner" "acdilrsw" "wilma@flintstone.org" "" a OK GETACL completed. a acl store "INBOX.mytest" "user=wilma@flintstone.org" "etx" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "d")))) a OK ACL STORE completed. a list (acl) "" "INBOX.mytest" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "d")))) a OK LIST completed a getacl "INBOX.mytest" * ACL "INBOX.mytest" "owner" "acdilrsw" "wilma@flintstone.org" "d" a OK GETACL completed. a logout * BYE Courier-IMAP server shutting down a OK LOGOUT completed Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJVsJl016065; Fri, 12 Nov 2004 11:31:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACJVsY2016053; Fri, 12 Nov 2004 11:31:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJVjPY015980 for ; Fri, 12 Nov 2004 11:31:49 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.67.86.117] ([12.160.57.182]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iACIOB6E017888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 13:24:15 -0500 Date: Fri, 12 Nov 2004 14:30:20 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Notes for IMAPEXT WG meeting at IETF61 Message-ID: <24568FAE8A60AA819BF2D212@ninevah.local> In-Reply-To: References: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, November 12, 2004 17:53:02 EST +0100 Arnt Gulbrandsen wrote: >> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add >> it. We will take this to the list to see if there's any objectors on >> the list. > > There's me, sort of. But if it's okay to send two responses when a > mailbox matches two patterns, I'll be quiet. (I don't remember right now. > There was some discussion, wasn't there?) Clients have to potential cope with that situation today with regular LIST so having the server do it with LISTEXT, whilst not ideal, should not cause problems. I think we ought to say 'servers SHOULD suppress duplicate mailboxes in the response' and leave it at that. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGwRhM068455; Fri, 12 Nov 2004 08:58:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACGwR7P068454; Fri, 12 Nov 2004 08:58:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iACGwLt6068360 for ; Fri, 12 Nov 2004 08:58:26 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id EC1C81BDEB6; Fri, 12 Nov 2004 17:58:09 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 4F6781BDEB4 for ; Fri, 12 Nov 2004 17:58:09 +0100 (CET) Message-Id: Date: Fri, 12 Nov 2004 17:53:02 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Notes for IMAPEXT WG meeting at IETF61 References: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> In-Reply-To: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault writes: > Multiple-mailbox-match in LISTEXT: looks like there's consensus to add > it. We will take this to the list to see if there's any objectors on > the list. There's me, sort of. But if it's okay to send two responses when a mailbox matches two patterns, I'll be quiet. (I don't remember right now. There was some discussion, wasn't there?) Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGEuIl058337; Fri, 12 Nov 2004 08:14:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACGEuXt058336; Fri, 12 Nov 2004 08:14:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGEteH058328 for ; Fri, 12 Nov 2004 08:14:55 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [130.129.135.17] ([130.129.135.17]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iACGEuZe012733 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 12 Nov 2004 08:14:58 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Notes location Date: Fri, 12 Nov 2004 08:14:46 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I forwarded the notes to the WG and also uploaded them to http://ietf.webdav.org/imapext/. I also added a link there to the Jabber room logs. There were no presentations at this meeting. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACFo83r049604; Fri, 12 Nov 2004 07:50:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACFo81N049603; Fri, 12 Nov 2004 07:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACFo87X049556 for ; Fri, 12 Nov 2004 07:50:08 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [130.129.135.17] ([130.129.135.17]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iACFo3Ze011947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 12 Nov 2004 07:50:05 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: proceedings@ietf.org, IMAP Extensions WG From: Lisa Dusseault Subject: Notes for IMAPEXT WG meeting at IETF61 Date: Fri, 12 Nov 2004 07:49:55 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LISTEXT STATUS Discussion of /Placeholder: Philip promised to send a mail about a simplification of /Placeholder. Cyrus and Barry agree that LISTEXT is too complicated and we need to back off that. Question about which client people initially asked for features in LISTEXT (prompted by observation that LISTEXT has now become rather complex)? Cyrus, David Cridland, Mark Crispin.. who else? Suggestion that the /matchparent stuff may be simplifiable -- get rid of it. Any wildcard query (%) could be seen as a request for matchparent -- otherwise the server must not return it. Multiple-mailbox-match in LISTEXT: looks like there's consensus to add it. We will take this to the list to see if there's any objectors on the list. We will defer to the mailing list for what to do with /NOSELECT, /NONEXISTENT, /DELETED... Cyrus and Philip are on the hook to suggest a simplified model to Alexey and Barry for matchparent... the next version of this may get last-called. --- ACL STATUS Discussion on 2086 upd: Looks good, needs to be kept simple and finished soon. Scott and Chris promise to review 2086upd --- ANNOTATE STATUS Discussion on Annotate: lots of discussion over what rights to use for private and public annotations. Proposal: that the ability to read private annotations is controlled by the 'r' ACL bit, and the ability to write private annotations is controlled by the new 'm' ACL bit. This means that 'r' controls readability for both private and shared annotations. There were no sticking objections to this proposal (however Barry and Chris would prefer another proposal.) 2nd issue with ANNOTATE: Interactions with the CATENATE draft. Resolution: Cyrus will add text to deal with this and there will be a new dependency of Annotate on Catenate 3rd issue: APPEND: a slight interaction here with annotate, which Cyrus will add to the draft. We plan to last call the next version of Annotate on the day it comes out. --- ANNOTATEMORE Plug for AnnotateMore -- Chris and Philip promised to review, Cyrus will ask LEMONADE list for review. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABCL5fj084654; Thu, 11 Nov 2004 04:21:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABCL5LQ084653; Thu, 11 Nov 2004 04:21:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABCKxRv084566 for ; Thu, 11 Nov 2004 04:21:00 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCKhE21966; Thu, 11 Nov 2004 14:20:44 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 14:20:36 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iABCKa3A012188; Thu, 11 Nov 2004 14:20:36 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00MR7nOf; Thu, 11 Nov 2004 14:20:34 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCKRa15250; Thu, 11 Nov 2004 14:20:27 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 06:20:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Thu, 11 Nov 2004 06:20:24 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B87@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHtA2QOu7XKjXZRMSRoBjVBVDw6wAMkU1A From: To: , X-OriginalArrivalTime: 11 Nov 2004 12:20:26.0402 (UTC) FILETIME=[D3443820:01C4C7E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iABCL0Rv084586 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Cyrus Daboo [mailto:daboo@isamet.com] > Sent: Thursday, November 11, 2004 1:01 AM ... > > The ANNOTATE draft does allow for attribute value pairs to be sent > > in unsolicited responses with the SELECT parameter "(ANNOTATE)". > > There does not seem to be an analog in ANNOTATEMORE. > > No, that's not the case. Section 3.2 of ANNOTATE states that Which statement are you refuting the first or the second? Both maybe? > the (ANNOTATE) > parameter on SELECT turns on unsolicited annotation responses > as defined by > Section 3.4. Section 3.4 states that unsolicited responses > MUST NOT include > the annotation data. i.e. the ANNOTATION responses resulting from > (ANNOTATE) on SELECT do not include the annotation values. I'm confused. Here is an excerpt from draft-ietf-imapext-annotate-11.txt sec 3.4. Servers MUST NOT include ANNOTATION data in unsolicited responses unless the client used the ANNOTATE select parameter when it issued the last SELECT or EXAMINE command. This restriction avoids sending ANNOTATION data to a client unless the client explicitly asks for it. Servers SHOULD send ANNOTATION message data items in unsolicited FETCH responses if an annotation entry is changed by a third-party, and the ANNOTATE select parameter was used. This allows servers to keep clients updated with changes to annotations by other clients. This seems clear to me. I must be missing something about your point. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB60qoY021682; Wed, 10 Nov 2004 22:00:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB60qrC021681; Wed, 10 Nov 2004 22:00:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB60lif021607 for ; Wed, 10 Nov 2004 22:00:51 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.67.86.4] ([130.129.97.127]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAB4ru6E018894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 23:53:59 -0500 Date: Thu, 11 Nov 2004 01:00:46 -0500 From: Cyrus Daboo To: Michael.Wener@nokia.com, ietf-imapext@imc.org Subject: RE: Comments on ANNOTATEMORE Message-ID: <8EA283886467F41ED4FFA81D@ninevah.local> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.noki a.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Wednesday, November 10, 2004 14:49:06 EST -0600 Michael.Wener@nokia.com wrote: >> This behaves the same way as unsolicited ANNOTATE responses >> in the ANNOTATE >> extension. The reason for this behaviour is that clients may > > The ANNOTATE draft does allow for attribute value pairs to be sent > in unsolicited responses with the SELECT parameter "(ANNOTATE)". > There does not seem to be an analog in ANNOTATEMORE. No, that's not the case. Section 3.2 of ANNOTATE states that the (ANNOTATE) parameter on SELECT turns on unsolicited annotation responses as defined by Section 3.4. Section 3.4 states that unsolicited responses MUST NOT include the annotation data. i.e. the ANNOTATION responses resulting from (ANNOTATE) on SELECT do not include the annotation values. Perhaps this needs to be made more explicit? -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB353SC055995; Wed, 10 Nov 2004 19:05:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB353NK055994; Wed, 10 Nov 2004 19:05:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB351mh055973 for ; Wed, 10 Nov 2004 19:05:02 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAB350F12826; Thu, 11 Nov 2004 05:05:01 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 05:03:15 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAB33FUC016032; Thu, 11 Nov 2004 05:03:15 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00huHzSl; Thu, 11 Nov 2004 05:03:15 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAB33ES06233; Thu, 11 Nov 2004 05:03:14 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 21:03:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 21:03:12 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B86@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHdaDf/syRhWVoTLCmZEOUjpws9QAJA3Aw From: To: Cc: X-OriginalArrivalTime: 11 Nov 2004 03:03:13.0734 (UTC) FILETIME=[FBD7EE60:01C4C79A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAB353mh055987 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Philip Guenther [mailto:guenther@sendmail.com] > Sent: Wednesday, November 10, 2004 5:35 PM ... > >> /checkperiod is meant to be the user preference for polling > >> interval. i.e. > >> the client will use that value to determine what interval it > >> should poll > >> the mailbox (using STATUS or NOOP). It is not under control > >> of the server > >> and is not used by the server. I can add text to clarify that. > > > >As described I don't see it having much value. I see it having > >much more value as a server set value. So I would suggest you > >don't add the clarification and leave it as either client or > >server set. > > What would a server-set version of checkperiod tell the client? I'm > trying to envision an interpretation that wouldn't imply that > the server > can see into the future. A server can see into the future. It is called extrapolation. > >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 > >last two paragraphs. These would not be redundant. I could see them > >as being uninteresting to some clients, but for the same reason you > >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be > >interesting to some clients. To those clients it would be nice to > >have the data contained in the response. > > Given the possible size of annotations (as compared to the > size of flags > updates), defaulting to not sending values seems wise to me. I agree. I understand that point. You do agree the ANNOTATE draft does have a way to allow data to be included in unsolicited responses? Why would it not be wise to allow such a capability to be turned on for non-message annotations? Note, I'm not talking about the default. Maybe the answer is there is no clean way to do it. Message annotations have the SELECT (ANNOTATE) switch. Where you would hang such a switch with non-message annotations I'm not sure. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMYrxl039101; Wed, 10 Nov 2004 14:34:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAMYrNv039100; Wed, 10 Nov 2004 14:34:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMYrlV039018 for ; Wed, 10 Nov 2004 14:34:53 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAAMYnZj010400 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 10 Nov 2004 14:34:49 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAAMYnZj010400 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=QGCkFPvgANSlGtob9nfgWFheMd9rwndGklH+B2z7YHt85GsL9yx4gDfjWB6M/dN87 JN5q3YU3N8zMTKjiypn+UUpETpECLXY+F17ShPAHeyweim6/7p+2yH8OmyG2IlRs1WF p114q/QyaRuBq/5IHyaw4cx5A9xwEpjX+nG+suA= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAAMYnE5090745; Wed, 10 Nov 2004 14:34:49 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411102234.iAAMYnE5090745@lab.smi.sendmail.com> To: Michael.Wener@nokia.com Cc: ietf-imapext@imc.org Subject: Re: Comments on ANNOTATEMORE In-reply-to: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> Date: Wed, 10 Nov 2004 14:34:49 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael.Wener@nokia.com writes: >Cyrus Daboo writes: ... >> /checkperiod is meant to be the user preference for polling >> interval. i.e. >> the client will use that value to determine what interval it >> should poll >> the mailbox (using STATUS or NOOP). It is not under control >> of the server >> and is not used by the server. I can add text to clarify that. > >As described I don't see it having much value. I see it having >much more value as a server set value. So I would suggest you >don't add the clarification and leave it as either client or >server set. What would a server-set version of checkperiod tell the client? I'm trying to envision an interpretation that wouldn't imply that the server can see into the future. Note that ANNOTATEMORE arose in part from the difficulties in implementing ACAP and several of the initial entries are there to take over for ACAP profiles of client configuration. ... >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 >last two paragraphs. These would not be redundant. I could see them >as being uninteresting to some clients, but for the same reason you >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be >interesting to some clients. To those clients it would be nice to >have the data contained in the response. Given the possible size of annotations (as compared to the size of flags updates), defaulting to not sending values seems wise to me. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAKnfrZ093568; Wed, 10 Nov 2004 12:49:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAKnfVc093565; Wed, 10 Nov 2004 12:49:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAKnZ7b093487 for ; Wed, 10 Nov 2004 12:49:36 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAKnPv18884; Wed, 10 Nov 2004 22:49:26 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 22:49:11 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAAKnBZf009781; Wed, 10 Nov 2004 22:49:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00GyXsvD; Wed, 10 Nov 2004 22:49:11 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAKnAS00662; Wed, 10 Nov 2004 22:49:10 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:49:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 14:49:06 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHPlEkFcUV71rpQFuj6ZsV1tErGAAIvhyg From: To: , X-OriginalArrivalTime: 10 Nov 2004 20:49:09.0625 (UTC) FILETIME=[BA1CAE90:01C4C766] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAKna7b093520 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Cyrus Daboo [mailto:daboo@isamet.com] > Sent: Wednesday, November 10, 2004 10:58 AM > > Section 2.2.1.2 > > > > I don't understand the usefulness of /check and /checkperiod. > > Who sets checkperiod? Mail arrival is variable so the only ... > /checkperiod is meant to be the user preference for polling > interval. i.e. > the client will use that value to determine what interval it > should poll > the mailbox (using STATUS or NOOP). It is not under control > of the server > and is not used by the server. I can add text to clarify that. As described I don't see it having much value. I see it having much more value as a server set value. So I would suggest you don't add the clarification and leave it as either client or server set. > > It is sometimes useful to be able to 'suspend' checking of a > mailbox, hence ... Agreed. > > Section 3.3 ... > i.e. there is no need for the server to send back the > annotation data that > the client has just set using SETANNOTATION - that > information is redundant > as the OK response implies those changes have succeeded. Agreed. > > > > > Section 3.4.2 > > > > Why do unsolicited ANNOTATION responses not contain attributes > > and values? Wouldn't they be more useful if they contained the > > new data? Maybe they MAY as descibed in section 3.3? > > This behaves the same way as unsolicited ANNOTATE responses > in the ANNOTATE > extension. The reason for this behaviour is that clients may The ANNOTATE draft does allow for attribute value pairs to be sent in unsolicited responses with the SELECT parameter "(ANNOTATE)". There does not seem to be an analog in ANNOTATEMORE. > not care about > some annotations and therefore sending the data is redundant ande > potentially wastes bandwidth. It is more efficient to tell > the client that > some changes have happened and then have the client go and > fetch the data > for only the ones it is really interested in. i.e. we are > trying to prevent > the server forcing data on the client that it does not need. I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 last two paragraphs. These would not be redundant. I could see them as being uninteresting to some clients, but for the same reason you allow unsolicited responses with data in ANNOTATE sec 3.4 they may be interesting to some clients. To those clients it would be nice to have the data contained in the response. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFvnKf081332; Wed, 10 Nov 2004 07:57:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFvnfB081331; Wed, 10 Nov 2004 07:57:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFviF3081248 for ; Wed, 10 Nov 2004 07:57:48 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [130.129.135.95] ([130.129.135.95]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAAEos6E023494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 09:50:57 -0500 Date: Wed, 10 Nov 2004 10:57:39 -0500 From: Cyrus Daboo To: Michael.Wener@nokia.com, ietf-imapext@imc.org Subject: Re: Comments on ANNOTATEMORE Message-ID: In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.noki a.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael.Wener@nokia.com, --On Wednesday, November 10, 2004 9:17:31 EST -0600 Michael.Wener@nokia.com wrote: > Section 2.2.1.2 > > I don't understand the usefulness of /check and /checkperiod. > Who sets checkperiod? Mail arrival is variable so the only > reasonable thing to do is to have it modified by the server > using some learning algorithm that changed the value as the > inter-mail arrival times changed. > > Or maybe you were thinking about some server imposed polling > throttle? > > /check is redundant. The existence of /checkperiod implies > /check=true. /checkperiod is meant to be the user preference for polling interval. i.e. the client will use that value to determine what interval it should poll the mailbox (using STATUS or NOOP). It is not under control of the server and is not used by the server. I can add text to clarify that. It is sometimes useful to be able to 'suspend' checking of a mailbox, hence having a separate 'turn check on/off' value that does not affect the period is useful. i.e. you don't have to remember what the last period when restoring checking after it has been suspended. > > Section 3.3 > > The paragraph immediately following the "Result:" section > describes behavior for unsolicited responses. I'm unclear if > this is referring to the potential untagged responses returned > due to the SETANNOTATION, or to unsolicited responses in general, > for example, during a NOOP. The first paragraph in section 3.3 is confusing. The policy is that unsolicited responses can be sent at any appropriate time (including during SETANNOTATION), however the server does not need to send ANNOTATION responses that are the direct result of the SETANNOTATION command itself - i.e. there is no need for the server to send back the annotation data that the client has just set using SETANNOTATION - that information is redundant as the OK response implies those changes have succeeded. > > Section 3.4.2 > > Why do unsolicited ANNOTATION responses not contain attributes > and values? Wouldn't they be more useful if they contained the > new data? Maybe they MAY as descibed in section 3.3? This behaves the same way as unsolicited ANNOTATE responses in the ANNOTATE extension. The reason for this behaviour is that clients may not care about some annotations and therefore sending the data is redundant ande potentially wastes bandwidth. It is more efficient to tell the client that some changes have happened and then have the client go and fetch the data for only the ones it is really interested in. i.e. we are trying to prevent the server forcing data on the client that it does not need. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFIlIU065083; Wed, 10 Nov 2004 07:18:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFIlZR065082; Wed, 10 Nov 2004 07:18:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFIkR5065065 for ; Wed, 10 Nov 2004 07:18:46 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFIkF19314 for ; Wed, 10 Nov 2004 17:18:47 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 17:19:41 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAAFJflK030692 for ; Wed, 10 Nov 2004 17:19:41 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LCgyl5; Wed, 10 Nov 2004 17:19:38 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFIHS21748 for ; Wed, 10 Nov 2004 17:18:17 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 09:17:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 09:17:31 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHOGXjy9+etzyARZ2TZzNMAdBLyA== From: To: X-OriginalArrivalTime: 10 Nov 2004 15:17:32.0983 (UTC) FILETIME=[66CA0C70:01C4C738] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAFIlR5065076 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 2.2.1.2 I don't understand the usefulness of /check and /checkperiod. Who sets checkperiod? Mail arrival is variable so the only reasonable thing to do is to have it modified by the server using some learning algorithm that changed the value as the inter-mail arrival times changed. Or maybe you were thinking about some server imposed polling throttle? /check is redundant. The existence of /checkperiod implies /check=true. Section 3.3 The paragraph immediately following the "Result:" section describes behavior for unsolicited responses. I'm unclear if this is referring to the potential untagged responses returned due to the SETANNOTATION, or to unsolicited responses in general, for example, during a NOOP. Section 3.4.2 Why do unsolicited ANNOTATION responses not contain attributes and values? Wouldn't they be more useful if they contained the new data? Maybe they MAY as descibed in section 3.3? Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GvcxX010420; Tue, 9 Nov 2004 08:57:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9Gvcbd010418; Tue, 9 Nov 2004 08:57:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GvbZ7010348 for ; Tue, 9 Nov 2004 08:57:37 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iA9GuuFd025372; Tue, 9 Nov 2004 08:56:57 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iA9GuuLS017883; Tue, 9 Nov 2004 08:56:56 -0800 Date: Tue, 9 Nov 2004 08:56:56 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Arnt Gulbrandsen , Alexey Melnikov , kael , ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions In-Reply-To: <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> Message-ID: References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 9 Nov 2004, Dave Cridland wrote: > I confess to being totally bewildered by the FROM, TO and CC sort keys, as > they all appear to only sort on the local-part of the email address - that > *is* the "bit before the @", right? So different domains collate equally? I > can't understand why this should be the case. In practice, not all that many people use those keys. The idea is to tend to collect messages from a single person together, based upon the tendency of people to have the same local-part for his email address even though they may use many different sites. Note that word "tend". It's useful, in some very limited cases. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GCgtF095730; Tue, 9 Nov 2004 08:12:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9GCgLn095729; Tue, 9 Nov 2004 08:12:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GCajR095667 for ; Tue, 9 Nov 2004 08:12:37 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D2C9C154009; Tue, 9 Nov 2004 16:12:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Arnt Gulbrandsen Cc: Alexey Melnikov , kael , Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 09 Nov 2004 16:12:33 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Nov 9 12:25:17 2004, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> For an actual SORT, no matter how quick the sort implementation on >> the server is, for large mailboxes that's still a noticeable chunk >> of bandwidth chewage for the result - the sort results for a 50k >> message folder weigh in at 282k[1]. > > "sort (subject date) charset us-ascii since 2004-11-08 not since > 2004-11-09" should have only a small response, even if the mailbox > is big. > > You mentioned timezones being problematic, but I'll just clarify - the DATE and ARRIVAL sort keys sort by first normalizing the relevant date (RFC2822 header and INTERNALDATE respectively) into UTC. The date-orientated search keys (In this case SINCE) search by discarding the time and timezone, which can result in a different date. But back to the point... Yes, you can chop up SORT results for a "group by" style feature using the SEARCH key, and this will, in general, reduce the number of numbers given in the SORT response. But realistically, only for date/time related metadata. For a sort or group by sender, or subject, this wouldn't be possible: SUBJECT search keys use a substring match of the full header value - using a US-ASCII charset does this without MIME decoding. SUBJECT sort key uses the base subject, not the real one, and always decodes. Hence it's impossible to, for instance, divide the messages up into chunks with subjects beginning "a", etc, because: a) The "base subject", which you actually want, isn't being searched, so you need to SORT the full mailbox. b) You can't do a prefix search anyway. FROM is just as curious, sorting as it does only on the local-part of the From address, but substring searching throughout the entire header, optionally MIME decoding as above. I confess to being totally bewildered by the FROM, TO and CC sort keys, as they all appear to only sort on the local-part of the email address - that *is* the "bit before the @", right? So different domains collate equally? I can't understand why this should be the case. This would appear to mean that it's totally impossible to use SORT to generate the collation from which a group by sender listing could actually be generated. This seems intuitively wrong to me, but accurate according to the specification. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9CMaNn097027; Tue, 9 Nov 2004 04:22:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9CMaL6097021; Tue, 9 Nov 2004 04:22:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA9CMUkF096796 for ; Tue, 9 Nov 2004 04:22:33 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id E8C1D1BDECC; Tue, 9 Nov 2004 13:22:18 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id F3CF21BDEB4; Tue, 9 Nov 2004 13:22:16 +0100 (CET) Message-Id: Date: Tue, 9 Nov 2004 13:25:17 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions Cc: Alexey Melnikov , Dave Cridland , kael@alussinan.org References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > For an actual SORT, no matter how quick the sort implementation on the > server is, for large mailboxes that's still a noticeable chunk of > bandwidth chewage for the result - the sort results for a 50k message > folder weigh in at 282k[1]. "sort (subject date) charset us-ascii since 2004-11-08 not since 2004-11-09" should have only a small response, even if the mailbox is big. (Kael: When you implement the "yesterday" group, remember to consider the timezone issues. I think that command doesn't quite match what you want.) Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9AeUSm027795; Tue, 9 Nov 2004 02:40:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9AeUBb027794; Tue, 9 Nov 2004 02:40:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9AeNjU027623 for ; Tue, 9 Nov 2004 02:40:23 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 70AA7154009; Tue, 9 Nov 2004 10:40:18 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: kael Cc: IMAP extensions Mailing List , Alexey Melnikov Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> In-Reply-To: <418FAB01.5010505@alussinan.org> Message-ID: <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 09 Nov 2004 10:40:18 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 8 17:21:05 2004, kael wrote: > > On 08.11.2004 17:55, Alexey Melnikov wrote: > >> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: >> delivery date or the Date header)... > > I deduce that, except for keywords, the implementation of the IMAP > SORT and THREAD extensions for Mozilla/Thunderbird could be done in > consideration of the new _Message Grouping_ feature > http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, > couldn't it. That would be great ! Well, yes and no, really. On the one hand, messages can be sorted by *all* the criteria listed in that webpage, on the (minor) assumption that labels could be implemented as annotations rather than keywords. (I'm assuming here that it's one label per message, which many possible labels, in which case keywords could become problematic - servers don't always support an infinite number of keywords, so annotations would be a better fit.) On the other hand, every time a new message arrived, it would have to be sorted. Currently, that can either be done by re-sorting the entire folder server-side, or else sorting locally. For an actual SORT, no matter how quick the sort implementation on the server is, for large mailboxes that's still a noticeable chunk of bandwidth chewage for the result - the sort results for a 50k message folder weigh in at 282k[1]. For client-side sorts, you can't actually give a straight figure for the transfer, but it's likely to tend towards something much smaller as time passes and data is cached - ultimately down to the size of the data used as a sort key for the new message, usually quite small. So in actual practise, it's probably not worthwhile using the SORT except, possibly, for the first hit, depending on how much data is cached client-side to begin with. Dave. Footnote: 1) In Python: len('* SORT' + ''.join( [str(x) for x in range(1,50000)] ))/1024.0 - across a fairly typical 512kbit/s DSL line, that's about 4.5 seconds of *transfer* time alone. Of course, I might have mucked up the calculation. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8HKsve028197; Mon, 8 Nov 2004 09:20:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8HKsul028196; Mon, 8 Nov 2004 09:20:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8HKruh028124 for ; Mon, 8 Nov 2004 09:20:54 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix4-1.free.fr (Postfix) with ESMTP id E2E3C1F3462; Mon, 8 Nov 2004 18:20:44 +0100 (CET) Message-ID: <418FAB01.5010505@alussinan.org> Date: Mon, 08 Nov 2004 18:21:05 +0100 From: kael User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041103 Thunderbird/0.9 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Melnikov Cc: IMAP extensions Mailing List Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> In-Reply-To: <418FA4FF.1040409@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 08.11.2004 17:55, Alexey Melnikov wrote: > Yes (ARRIVAL or DATE sort criterion, depending on what you mean: > delivery date or the Date header)... I deduce that, except for keywords, the implementation of the IMAP SORT and THREAD extensions for Mozilla/Thunderbird could be done in consideration of the new _Message Grouping_ feature http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, couldn't it. That would be great ! Thanks for your replies. -- kael Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GthvE018145; Mon, 8 Nov 2004 08:55:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8GthPR018144; Mon, 8 Nov 2004 08:55:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8Gtfvs018138 for ; Mon, 8 Nov 2004 08:55:42 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 16:55:28 +0000 Message-ID: <418FA4FF.1040409@isode.com> Date: Mon, 08 Nov 2004 16:55:27 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kael CC: IMAP extensions Mailing List Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> In-Reply-To: <418F8927.6070704@alussinan.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: kael wrote: > On 08.11.2004 14:56, Alexey Melnikov wrote: > >> If you asking about grouping by message age, than the answer is >> "yes". The SORT extension would be sufficient for this. > > Does the SORT extension allow to group messages by date, Yes (ARRIVAL or DATE sort criterion, depending on what you mean: delivery date or the Date header) > keywords, No. > senders, subject, Yes and yes. > etc like Thunderbird 0.9 does - please, look at the > attachments ? I have never been able to sort messages like this with > Mulberry. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FwspL097958; Mon, 8 Nov 2004 07:58:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FwsFM097956; Mon, 8 Nov 2004 07:58:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FwjCL097892 for ; Mon, 8 Nov 2004 07:58:45 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id A8FBC154009; Mon, 8 Nov 2004 15:58:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: IMAP Extensions WG , Alexey Melnikov , Philip Guenther Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> <418F889B.3050004@isode.com> <2BB41FFE4611703F11592582@ninevah.local> In-Reply-To: <2BB41FFE4611703F11592582@ninevah.local> Message-ID: <20041108155842.11253.26989.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 08 Nov 2004 15:58:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 8 15:17:11 2004, Cyrus Daboo wrote: > --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov > wrote: >>>> I'd personally suggest that if the server supports read-write >>>> annotations, it MUST support creation of arbitrary, >>>> non-operational >>>> attributes. >>> Is a server that only supports preconfigured namespaces an active >>> danger >>> to interoperability? If not, then I think "MUST" is >>> inappropriate. >> Unfortunately, there is no way to distinguish a read-write ANNOTATE >> server that supports reconfigured namespaces from a full read-write >> server. So yes, this might be a problem. At least it makes writing >> client >> more difficult. > I think servers SHOULD allow clients to create and use arbitrary > annotation entries be they in the vendor namespace or elsewhere > (the later being e.g. new standard annotations that have been > defined since the server was deployed). However, as with everything > in IMAP, the client MUST be prepared to handle the server saying NO. > > So I think what we say is: 'servers SHOULD allow creation and use > of arbitrary annotation entries in the vendor namespace or > elsewhere, but client MUST handle the case where a server prevents > that and responds with a NO response', or something to that effect. I'll certainly agree, of course, that any STORE to annotation may result in a NO, and of course, a client has to handle this. To my mind, not allowing arbitrary attributes ranks at near the same level as not having persistent UIDs for a mailbox. It's something a client has to cope with, but shouldn't ever have to experience in the field. I'll concede that even this makes a MUST too strong, but perhaps a SHOULD with a note? Philip used the phrase "active danger to interoperability" - a server which does not support storage of arbitrary attributes against a message in a mailbox for which the client has the rights required isn't actively endangering interoperability because, of course, it's acting so close to a server which doesn't support ANNOTATE at all. What it is doing is missing out on a golden opportunity to provide a method for new features - such as, maybe, a resent-to attribute - to be created by one client, used by another, and standardized quickly and rapidly based on real operational experience. That's hurting interoperability badly, in my opinion. As well as that, it's losing the ability to transfer mailboxes from one IMAP server to another without losing potentially highly valuable metadata, especially in the case where multiple clients are used. If persistent UIDs aren't available, then the message store is badly designed for use with IMAP. If arbitrary annotations aren't supported, then the message store is badly designed for use with ANNOTATE. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FHUfi085071; Mon, 8 Nov 2004 07:17:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FHUbL085070; Mon, 8 Nov 2004 07:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FHTim085044 for ; Mon, 8 Nov 2004 07:17:30 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [130.129.135.95] ([130.129.135.95]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA8EAj6E008922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2004 09:10:47 -0500 Date: Mon, 08 Nov 2004 10:17:11 -0500 From: Cyrus Daboo To: Alexey Melnikov , Philip Guenther cc: Dave Cridland , IMAP Extensions WG Subject: Re: Annotate Message-ID: <2BB41FFE4611703F11592582@ninevah.local> In-Reply-To: <418F889B.3050004@isode.com> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> <418F889B.3050004@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov wrote: >>> I'd personally suggest that if the server supports read-write >>> annotations, it MUST support creation of arbitrary, non-operational >>> attributes. >>> >>> >> Is a server that only supports preconfigured namespaces an active danger >> to interoperability? If not, then I think "MUST" is inappropriate. >> >> > Unfortunately, there is no way to distinguish a read-write ANNOTATE > server that supports reconfigured namespaces from a full read-write > server. So yes, this might be a problem. At least it makes writing client > more difficult. I think servers SHOULD allow clients to create and use arbitrary annotation entries be they in the vendor namespace or elsewhere (the later being e.g. new standard annotations that have been defined since the server was deployed). However, as with everything in IMAP, the client MUST be prepared to handle the server saying NO. So I think what we say is: 'servers SHOULD allow creation and use of arbitrary annotation entries in the vendor namespace or elsewhere, but client MUST handle the case where a server prevents that and responds with a NO response', or something to that effect. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EsURb079358; Mon, 8 Nov 2004 06:54:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8EsUna079357; Mon, 8 Nov 2004 06:54:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EsTD0079351 for ; Mon, 8 Nov 2004 06:54:29 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 14:54:20 +0000 Message-ID: <418F889B.3050004@isode.com> Date: Mon, 08 Nov 2004 14:54:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Dave Cridland , IMAP Extensions WG Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> In-Reply-To: <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >>I'd personally suggest that if the server supports read-write >>annotations, it MUST support creation of arbitrary, non-operational >>attributes. >> >> >Is a server that only supports preconfigured namespaces an active danger >to interoperability? If not, then I think "MUST" is inappropriate. > > Unfortunately, there is no way to distinguish a read-write ANNOTATE server that supports reconfigured namespaces from a full read-write server. So yes, this might be a problem. At least it makes writing client more difficult. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EThg2069486; Mon, 8 Nov 2004 06:29:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8ETh23069485; Mon, 8 Nov 2004 06:29:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8ETg6A069458 for ; Mon, 8 Nov 2004 06:29:42 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iA8ETSdU016139 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 8 Nov 2004 06:29:28 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iA8ETSdU016139 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=XumIaZ5IoJQ8aWBy/FVRZxfsR32+PIMuG6Cyr1qPknlaXjgJb6LRb0+iBVqmhpJpT bLq5U/+/icc0j6jHMuqRxZy1jfVqJVjJOUaUW84OPUzpFaVlYybHh5Qe86FBMcv0dua hXbbMzdbEwS0EgmBAR4suN4Rz8qD+XlGbsrKbGs= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iA8ETSZk038432; Mon, 8 Nov 2004 06:29:28 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> To: Dave Cridland Cc: IMAP Extensions WG Subject: Re: Annotate In-reply-to: <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> Date: Mon, 08 Nov 2004 06:29:28 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: >On Sat Nov 6 12:55:43 2004, Alexey Melnikov wrote: >> Timo Sirainen wrote: ... >>> Servers MUST(?) support new namespaces created by clients. >> >> I think this should be "SHOULD". We want to encourage ANNOTATE >> servers. Implementing a read-only ANNOTATE is much easier. >> >> >Yes, but the need for clients to store vendor-private stuff in a >nice, neat, semi-interoperable manner really shouldn't be >underestimated. Dropping this to a SHOULD is perhaps too far. As described in RFC 2119, "SHOULD" is a fairly strong statement, with "MUST" being for the do-or-die stuff only. A quick scan of the IMAP RFC finds a goodly number of uses of "SHOULD" that a server or client would be very unwise to blithely disregard. >I'd personally suggest that if the server supports read-write >annotations, it MUST support creation of arbitrary, non-operational >attributes. Is a server that only supports preconfigured namespaces an active danger to interoperability? If not, then I think "MUST" is inappropriate. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8DuDua058660; Mon, 8 Nov 2004 05:56:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8DuD3h058659; Mon, 8 Nov 2004 05:56:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8DuCRR058649 for ; Mon, 8 Nov 2004 05:56:12 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 13:56:05 +0000 Message-ID: <418F7AF4.6040203@isode.com> Date: Mon, 08 Nov 2004 13:56:04 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kael CC: ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> In-Reply-To: <418CD4D1.1010902@alussinan.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: kael wrote: > Hello, > > Can [could] the SORT and THREAD extensions handle messages like this > http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html > ? If you asking about grouping by message age, than the answer is "yes". The SORT extension would be sufficient for this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8APP3q034630; Mon, 8 Nov 2004 02:25:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8APPVM034629; Mon, 8 Nov 2004 02:25:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8APJw4034482 for ; Mon, 8 Nov 2004 02:25:20 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 25EDF154009; Mon, 8 Nov 2004 10:25:08 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: Cyrus Daboo , IMAP Extensions WG , Timo Sirainen Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> In-Reply-To: <418CC9CF.9000103@isode.com> Message-ID: <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 08 Nov 2004 10:25:08 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat Nov 6 12:55:43 2004, Alexey Melnikov wrote: > Timo Sirainen wrote: >> On 1.11.2004, at 20:09, Cyrus Daboo wrote: >>>> I thought clients weren't allowed to make up their own >>>> annotation entry >>>> names? Or what does this mean? >>> >>> >>> If a client wants to create a 'boolean' (on/off) type property >>> associated with a message it has two options: use an IMAP keyword >>> (either private or registered), or create a vendor (or new >>> standard) annotation entry. The former gives no control over >>> private/shared state, whereas the latter does. So if there is a >>> specific need for such a property that does need explicit >>> private/shared behavior then the client can use annotations in >>> lieu of IMAP keywords. >> >> >> I thought vendor namespaces meant that servers could create them, >> not clients. Maybe put at the beginning of 2.2.1 something like: >> >> Vendor namespaces can be created by either clients or servers. > > Yes. > >> Servers MUST(?) support new namespaces created by clients. > > I think this should be "SHOULD". We want to encourage ANNOTATE > servers. Implementing a read-only ANNOTATE is much easier. > > Yes, but the need for clients to store vendor-private stuff in a nice, neat, semi-interoperable manner really shouldn't be underestimated. Dropping this to a SHOULD is perhaps too far. I'd personally suggest that if the server supports read-write annotations, it MUST support creation of arbitrary, non-operational attributes. The alternative is to encourage clients to avoid them entirely, either via keywords, which, having no namespace, have the potential to clash, or via messages containing client-specific data within. Both are effectively a poor emulation of ANNOTATE. I said "semi-interoperable" earlier, and this is such an awful term it probably needs some explanation. What I mean is that: a) The various client-specific annotations don't actually interfere with each other. You're not faced with keywords that your client might intend using for something else, you're not faced with mailboxes containing "special" messages. b) It's a lot easier to switch a client from using a client-specific usage of ANNOTATE into a standard usage of ANNOTATE, than to switch a client from using Something Weird to ANNOTATE. c) Chances are that several clients will spontaneously interoperate by deliberately using each other's client-specific extensions. (They do this with their local configurations already, remember - this would be a lot easier.) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA80SgEB025870; Sun, 7 Nov 2004 16:28:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA80SgxM025869; Sun, 7 Nov 2004 16:28:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA80SfWR025850 for ; Sun, 7 Nov 2004 16:28:41 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA80STOO079934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2004 17:28:31 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Sun, 07 Nov 2004 16:28:28 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org, IMAP Extensions WG Subject: Re: Comments about CLEARIDLE Message-ID: In-Reply-To: <418E58DE.4000401@isode.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.n okia.com> <418E4C25.6090103@isode.com> <418E58DE.4000401@isode.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-7 5:18 PM +0000 Alexey Melnikov wrote: > > One thing the needs discussing is whether the problem of receiving > flag changes/new mail notifications for multiple mailboxes (over a > single connection) is worth solving. I frankly don't know for sure. It has been brought up enough times over the last five years that I am convinced it is. I wrote a non-published draft a few years back that proposed a solution to the multiple-mailbox newmail notification problem. And since the issue has come up once again over the last few months I have updated the draft and will submit it after the IETF. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7HIkal051435; Sun, 7 Nov 2004 09:18:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7HIk2O051434; Sun, 7 Nov 2004 09:18:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7HIi4G051391 for ; Sun, 7 Nov 2004 09:18:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 17:18:23 +0000 Message-ID: <418E58DE.4000401@isode.com> Date: Sun, 07 Nov 2004 17:18:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Michael.Wener@nokia.com CC: lemonade@ietf.org, IMAP Extensions WG Subject: Comments about CLEARIDLE References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.nokia.com> <418E4C25.6090103@isode.com> In-Reply-To: <418E4C25.6090103@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Also crossposting this to IMAPEXT.] > Clearidle (See attached) > The IMAPRev4 specification supports unsolicited responses being sent > to a client at any time. The IDLE specification defines a way for a > client to sit in an idle connection waiting to receive these > responses. This document clarifies and extends the set of responses > that a client may receive while in the idle state. The desire is to > allow a client to predict exactly what set of unsolicited responses > it can rely on receiving when listening on an idle connection. One thing the needs discussing is whether the problem of receiving flag changes/new mail notifications for multiple mailboxes (over a single connection) is worth solving. I frankly don't know for sure. I will try to emphasize some specific technical issues with this document. >2.1 LIST Response > > Currently the LIST response occurs as the result of a LIST command. > This document modifies the syntax of a LIST response and also defines > it's occurrence as a legal unsolicited response that could be received > on IDLE connections associated with a user. > > Two new name attributes are defined: > > \Deleted > The mailbox has been deleted and no longer exists. After a LIST > response with this attribute is seen the server will no longer > show the named folder in any LIST commands. There MUST NOT be > any other name attributes sent along with this attribute. I suggest you review the LISTEXT extension (currently draft-ietf-imapext-list-extensions-10.txt). \Deleted is the same as \NonExistent. > \Renamed > The mailbox has been renamed. A second LIST response MUST > immediately follow indicating the new name. [...] > 3) If a folder is renamed two LIST responses are sent. The first > indicating the old name and a \Renamed attribute and a second > response MUST immediately follow the first indicating the new name. This might be less obvious for people not following IMAPEXT, but there was a proposal to have REFERRAL data returned in LIST responses. It serves exactly this purpose. See , item # 5. It also avoids the proposed hack (sorry, I can't find a better word) of tying two LIST responses together. >2.2 FETCH Response > > Currently the FETCH response occurs as the result of a FETCH command > or as an unsolicited response on an IDLE connection. This document > clarifies exactly what form of response should be sent when the > specified events occur on the server. [...] > New Message Arrival > An unsolicited FETCH response with envelope, body, flag and uid > data MUST be sent on all IDLE connections. > > Example: > S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...)) Actually no, BODY must not be in this list, as it is potentially very big. You surely wouldn't want to push a 10Mb message to you cell phone. I also suggest to replace the ENVELOPE with the BODYSTRUCTURE. >3.1.1 Mailbox Identification Syntax > > While in the Authenticated state there is no way to implicitly > determine which mailbox the response applies to. While this is not a > problem for some responses such as the LIST response it does pose a > problem for responses that are mail message specific. [...] > Example: > S: * 22 EXISTS (imap://mail/inbox) Why can't we just you the STATUS response? S: * STATUS INBOX (MESSAGES 231 RECENT 7) Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA74aOSH089038; Sat, 6 Nov 2004 20:36:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA74aOQS089037; Sat, 6 Nov 2004 20:36:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from s-utl01-dcpop.stsn.com (s-utl01-dcpop.stsn.com [63.240.218.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA74aMTU089018 for ; Sat, 6 Nov 2004 20:36:23 -0800 (PST) (envelope-from lisa@osafoundation.org) Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110623362713290 for ; Sat, 06 Nov 2004 23:36:27 -0500 Received: from [10.67.86.24] ([10.67.86.24]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Nov 2004 23:36:26 -0500 In-Reply-To: <418D1854.10304@isode.com> References: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> <418D1854.10304@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9050E7CC-3076-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Proposed agenda for IMAPEXT Date: Sat, 6 Nov 2004 20:36:16 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 07 Nov 2004 04:36:27.0085 (UTC) FILETIME=[58168FD0:01C4C483] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Nov 6, 2004, at 10:30 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > ... >> >> 1. Sorting, threading, and viewing (to be dealt with by one or more >> mechanisms) >> - >> >> status: still blocked on comparator (as is i18n draft) > > Are you proposing that the WG discusses the i18 draft? Not really -- just to explain the status, because I dont' think there's anything to discuss. (Let me know if I'm wrong!) lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6IVCPf012317; Sat, 6 Nov 2004 10:31:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6IVCeN012316; Sat, 6 Nov 2004 10:31:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6IVBka012310 for ; Sat, 6 Nov 2004 10:31:12 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [62.188.134.182] (1Cust182.tnt5.lnd4.gbr.da.uu.net [62.188.134.182]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 18:31:06 +0000 Message-ID: <418D1854.10304@isode.com> Date: Sat, 06 Nov 2004 18:30:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Proposed agenda for IMAPEXT References: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> In-Reply-To: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'm sorry this is so late, but here it is anyway. Suggestions > welcome. Note the new ACL draft link which hasn't been commented on > here on the list -- if you get a chance to read that draft by Monday > that would be super. > > Agenda for IMAPEXT meeting at 61st IETF > Monday, Nov 8, 1530-1730 > > 0. Agenda bashing, find note taker and jabber scribe: > (10 minutes) > > 1. Sorting, threading, and viewing (to be dealt with by one or more > mechanisms) > - > status: still blocked on comparator (as is i18n draft) Are you proposing that the WG discusses the i18 draft? > - extensions-10.txt> > Barry Leiba will discuss > Still issues on /Placeholder from last meeting, which Alexey and > Cyrus were tasked with resolving > (40 minutes) > > 2. Access Control Lists > - > Not updated since last meeting -- probably still blocked on LISTEXT. Yes. I have some local changes, but LISTEXT and draft-ietf-imapext-2086upd-00.txt take higher priorities right now. > - > > READ THIS if you're coming to the meeting! Or even if you're not. Yes, please. > It hasn't been discussed on the list yet. > (30 minutes) I am not sure that it will take that long, I think the document is pretty much done. > 3. Message-level annotations > - -11.txt> > Changes since last meeting... > Open issue: use of the 'm' bit for ACL of private annotations More specifically use of the "m" bit for reading of private annotations. > At least one more draft required > (40 minutes) Hopefully this discussion would be short as well. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GU8HT056221; Sat, 6 Nov 2004 08:30:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GU8gH056220; Sat, 6 Nov 2004 08:30:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GU7xG056202 for ; Sat, 6 Nov 2004 08:30:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:30:06 +0000 Message-ID: <418CFC05.5030903@isode.com> Date: Sat, 06 Nov 2004 16:29:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: STATUS command as an LISTEXT extension Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't want to start a religious war on whether STATUS should be allowed to be a LISTEXT extension (because it can be as slow as SELECT for some mailstores/implementations), but below I have an example of how this might look like using existing LISTEXT syntax: ABNF: return-option =/ status-option status-option = "STATUS=" status-att-comlist status-att-comlist = status-att *("," status-att) ;; Comma separated list of status-att status-item-data = "STATUS" SP "(" status-att-list ")" ;; conforms to the mbox-list-extended-item-data ;; syntax Example: C: CA3 LIST "" "%" RETURN (STATUS=UIDVALIDITY,UIDNEXT,MESSAGES) S: * LIST (\Marked \NoInferiors) "/" "inbox" ((STATUS (UIDVALIDITY 50505050 MESSAGES 231 UIDNEXT 44292))) S: * LIST () "/" "Foo" ((STATUS (UIDVALIDITY 467676708 MESSAGES 12 UIDNEXT 100))) S: * LIST () "/" "Moo" ((STATUS (UIDVALIDITY 32 MESSAGES 711 UIDNEXT 9560))) S: CA3 OK done Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTj70056010; Sat, 6 Nov 2004 08:29:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GTjwa056009; Sat, 6 Nov 2004 08:29:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTdoL055954 for ; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:29:40 +0000 Message-ID: <418CFBE9.1050308@isode.com> Date: Sat, 06 Nov 2004 16:29:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , "Vladimir A. Butenko" Subject: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> In-Reply-To: <41596D6E.3060308@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, I believe there are only two. One relates to whether the "m" right only controls writability of private annotations, or whether it also controls readability. I've sent a separate message on this. The second issue: Which rights are required for the LISTRIGHTS command? Currently the document says: MYRIGHTS - any of the following rights is required to perform the operation: "l", "r", "i", "c", "x", "a".* LISTRIGHTS - same as MYRIGHTS. Some of the existing servers follow this suggestion. Some allow for LISTRIGHTS if "r" and/or "a" is granted. Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" right is granted, as LISTRIGHTS information is only useful if you can also do SETACL. Also, such information shouldn't be disclosed to users that have insufficient rights. Alexey * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are not part of this list, because the client must be able to open a mailbox (i.e. "r") before performing a STORE command. The list also used to contain the "e" right (which controls EXPUNGE), I've deleted it for the same reason. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTeEl055962; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GTeM0055961; Sat, 6 Nov 2004 08:29:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTdoK055954 for ; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:29:28 +0000 Message-ID: <418CFBDE.9030308@isode.com> Date: Sat, 06 Nov 2004 16:29:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: IMAP Extensions WG Subject: Re: Listext References: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> In-Reply-To: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > > 3.1. General principles for returning LIST responses > > Are these a MUST? Especially the "don't return mailbox more than once" > rule? I would like to make the one you've mentioned a MUST. However it is not going to be practical. I think they all SHOULDs. However, if a single LIST command returns more than one extended LIST response for a mailbox, we need to state some safe assumptions for clients, e.g. the client can use mailbox flags from the latest LIST response (and ignore all previous). I don't think many existing client will be able to cope with multiple LIST responses for the same mailbox. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GNUKl052770; Sat, 6 Nov 2004 08:23:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GNURF052765; Sat, 6 Nov 2004 08:23:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GNTSr052756 for ; Sat, 6 Nov 2004 08:23:29 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:23:00 +0000 Message-ID: <418CCC8B.4080907@isode.com> Date: Sat, 06 Nov 2004 13:07:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Cyrus Daboo CC: Randall Gellens , IMAP Extensions WG Subject: Re: Moving the ANNOTATE document forward References: <417A9D2F.7090509@isode.com> <6DE76EE79E8374F1DDE56E06@ninevah.local> <0640B86069A1D898E91AE955@ninevah.cyrusoft.com> <417E4A9A.10505@isode.com> In-Reply-To: <417E4A9A.10505@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > The 'm' right controls both read and write access to .priv annotation > > values. When it is on, access to .priv annotations is allowed, when > > it is off, access to .priv annotations is disallowed. > > I still don't like using the "m" right for reading private > annotations, but we can discuss this during face to face meeting. Ok, let me try to describe my concern. From the table in the ANNOTATE document: +===============+===============+===================================+ | | | | | No ACL | read .priv | Any mailbox that can be SELECTED | | | values | or EXAMINED. | | | | | +---------------+---------------+-----------------------------------+ | | | | | With ACL | read .priv | Any mailbox with the 'm' | | | values | ACL right. | | | | | +---------------+---------------+-----------------------------------+ Which means that a well behaving ANNOTATE&ACL-aware client needs to know whether the server supports ACL or not. Why? Because when the client opens a mailbox, it can't assume that private annotations are readable, because for the ACL-aware server the "m" right doesn't control if the mailbox can be SELECT/EXAMINEd or not. Now, if we just say that both private and shared annotations are readable if the mailbox can be SELECT/EXAMINEd (i.e. the ACL "r" right), everything becomes much simpler (and consistent). Cyrus has said: >The other benefit of 'm' as it stands now is that it gives servers a way >to optimise their storage because users without 'm' will never need a >private annotation store for that mailbox. This may be true only for certain types of mailstores, but in general this is not true. Reporting any kind of annotations is trivial, whether the server can store them, or it just generates them on the fly (i.e. read-only private annotations). Checking the right "m" on FETCH just to make sure that private annotations can be read is just more work for the server. Most servers cache user's rights upon mailbox open and never try to refetch ACL for the selected mailbox. I.e. most servers never check ACLs on FETCH. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GMdWm052405; Sat, 6 Nov 2004 08:22:39 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GMdNT052404; Sat, 6 Nov 2004 08:22:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GMY1X052359 for ; Sat, 6 Nov 2004 08:22:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:22:07 +0000 Message-ID: <418CC9CF.9000103@isode.com> Date: Sat, 06 Nov 2004 12:55:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Timo Sirainen CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> In-Reply-To: <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 1.11.2004, at 20:09, Cyrus Daboo wrote: > >>> The 'm' right controls both read and write access to .priv >>> annotation >>> values. When it is on, access to .priv annotations is allowed, >>> when >>> it is off, access to .priv annotations is disallowed. >>> >>> Is this really needed? I think private annotations should work the same >>> way as private flags. You can always read them, and you can write >>> them if >>> it's possible to permanently save flags. >> >> In an ACL-aware server there are different ways to control the flag >> state 's' and 'w' bits. As a result I think there should also be a >> way to enable/disable private annotations independently - hence the >> 'm' bit. I know Alexey had some concerns with 'm' too so this is >> still an open issue. > > Well, perhaps it would be useful to have "m" for writing because of > that, but I think "r" would be more logical for reading private > annotations. I agree (a separate message on this is coming). >>> I thought clients weren't allowed to make up their own annotation entry >>> names? Or what does this mean? >> >> >> If a client wants to create a 'boolean' (on/off) type property >> associated with a message it has two options: use an IMAP keyword >> (either private or registered), or create a vendor (or new standard) >> annotation entry. The former gives no control over private/shared >> state, whereas the latter does. So if there is a specific need for >> such a property that does need explicit private/shared behavior then >> the client can use annotations in lieu of IMAP keywords. > > > I thought vendor namespaces meant that servers could create them, not > clients. Maybe put at the beginning of 2.2.1 something like: > > Vendor namespaces can be created by either clients or servers. Yes. > Servers MUST(?) support new namespaces created by clients. I think this should be "SHOULD". We want to encourage ANNOTATE servers. Implementing a read-only ANNOTATE is much easier. >> Here is some alternate text for the above paragraph that I am >> proposing to use instead. Note this also includes a sentence to >> address the first point you made: >> >> Clients that need to implement a property on a message that is >> either 'on' or 'off' and which requires separate private and shared >> state can use an annotation to represent that property as opposed >> to using IMAP Keywords, which cannot reliably discriminate the >> private and shared state. However, clients MUST NOT use annotations >> to replace existing IMAP flag behavior, which would cause >> interoperability problems with non-ANNOTATE aware clients. >> >> If that is not suitable, please suggest some other text or >> clarifications. > > Looks good to me. Looks good to me too. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GD5Ye047177; Sat, 6 Nov 2004 08:13:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GD5Eu047170; Sat, 6 Nov 2004 08:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GD2P6047128 for ; Sat, 6 Nov 2004 08:13:03 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:12:22 +0000 Message-ID: <418C19CC.3030600@isode.com> Date: Sat, 06 Nov 2004 00:24:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Updated draft-ietf-imapext-2086upd (ACL) Content-Type: multipart/mixed; boundary="------------010108000909080309050706" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------010108000909080309050706 Content-type: text/plain; charset="us-ascii" I forgot to submit it. I think I've addressed all but one issue raised by Philip. I will send a separate message on this. Apart from the issue, I think the document is ready for Last Call. Alexey --------------010108000909080309050706 Content-type: text/plain; name="draft-ietf-imapext-2086upd-01.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="draft-ietf-imapext-2086upd-01.txt" IMAPEXT Working Group A. Melnikov Internet Draft Editor Document: draft-ietf-imapext-2086upd-01.txt November 2004 Updates: 2086, <<3501?>> Expires: May 2005 IMAP4 ACL extension - updated list of rights Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Distribution of this draft is unlimited. Abstract The ACL (Access Control List) extension [RFC2086] of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. This document updates the list of rights defined in RFC 2086. It also clarifies which rights are required for different IMAP commands. 1. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. In all examples "/" character is used as hierarchy separator. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 2. Introduction and Overview The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document updates Section 3 of the RFC 2086. It also clarifies different aspects of the RFC 2086, in particular use of UTF-8 in identifiers, which rights are required for different IMAP4 commands; how READ-WRITE/READ-ONLY response codes are related to ACL>> 3. Access Control This section replaces Section 3 of the RFC 2086. The ACL extension is present in any IMAP4 implementation which returns "ACL" as one of the supported capabilities to the CAPABILITY command. A server implementation conformant to this document MUST also return rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability response. An access control list is a set of pairs. An ACL applies to a mailbox. Identifier is a UTF-8 string. The identifier "anyone" is reserved to refer to the universal identity (all authentications, including anonymous). All user name strings accepted by the LOGIN or AUTHENTICATE commands to authenticate to the IMAP server are reserved as identifiers for the corresponding user. Identifiers starting with a dash ("-") are reserved for "negative rights", described below. All other identifier strings are interpreted in an implementation- defined manner. Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Letters are reserved for ''standard'' rights, listed below. The set of standard rights may only be extended by a standards-track document. Digits are reserved for implementation or site defined rights. The currently defined standard rights are (note, that the list below doesn't list all commands that use a particular right): l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) r - read (SELECT the mailbox, perform STATUS) s - keep seen/unseen information across sessions (set or clear \SEEN flag via STORE, APPEND or COPY) w - write (set or clear flags other than \SEEN and \DELETED via STORE, APPEND or COPY) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP4 itself. c - create mailboxes (CREATE new sub-mailboxes in any implementation-defined hierarchy, parent mailbox for the new mailbox name in RENAME) x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag during APPEND/COPY) e - perform EXPUNGE and expunge as a part of CLOSE d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, "d" right MUST NOT be returned in a LISTRIGHTS response. a - administer (perform SETACL/DELETEACL/GETACL) m - <>write private annotations [ANNOTATE] n - write shared annotations [ANNOTATE] An implementation may tie rights together or may force rights to always or never be granted to particular identifiers. For example, in an implementation that uses unix mode bits, the rights "swite" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. It is possible for multiple identifiers in an access control list to apply to a given user (or other authentication identity). For example, an ACL may include rights to be granted to the identifier matching the user, one or more implementation-defined identifiers matching groups which include the user, and/or the identifier "anyone". How these rights are combined to determine the user's access is implementation-defined. An implementation may choose, for example, to use the union of the rights granted to the applicable identifiers. An implementation may instead choose, for example, to only use those rights granted to the most specific identifier present in the ACL. A client may determine the set of rights granted to the logged-in user for a given mailbox by using the MYRIGHTS command. When an identifier in an ACL starts with a dash ("-"), that indicates that associated rights are to be removed from the identifier that is prefixed by the dash. This is referred to as a "negative right". This differs from DELETEACL in that a negative right is added to the ACL, and is a part of the calculation of the rights. Let's assume that an identifier "fred" refers to a user with login "fred". If the identifier "-fred" is granted the "w" right, that indicates that the "w" right is to be removed from users matching the identifier "fred", even though the user "fred" might have the "w" right as a consequence of some other identifier in the ACL. A DELETEACL of "fred" simply deletes the identifier "fred" from the ACL; it does not affect any rights that the user "fred" may get from another entry in the ACL. Server implementations are not required to support "negative right" identifiers. 4. Rights required to perform different IMAP4rev1 commands Before executing a command an ACL compliant server must check which rights are required to perform it. This section groups command by functions they perform and list the rights required. It also gives the detailed description of any special processing required. The table below summarizes different rights or their combinations that are required in order to perform different IMAP operations. As it is not always possible to express complex right checking and interactions, the description after the table should be used as the primary reference. +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | LIST | + | | | | | | | | | | | | | SUBSCRIBE | * | | | | | | | | | | | * | | UNSUBSCRIBE | | | | | | | | | | | | + | | LSUB | * | | | | | | | | | | | * | | CREATE (for parent) | | | | | | + | | | | | | | | DELETE | | | | | | | + | | | | | | | RENAME | | | | | | + | + | | | | | | | COPY/APPEND | | | ? | ? | + | | | ? | | | | | | EXPUNGE/CLOSE | | | | | | | | | + | | | | |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | | FETCH | | | ? | | | | | | | | | | | STORE flags | | | ? | ? | | | | ? | | | | | | SETACL/DELETEACL | | | | | | | | | | + | | | | GETACL | | | | | | | | | | + | | | | MYRIGHTS/LISTRIGHTS | | | | | | | | | | | + | | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ Legend: + - The right is required * - Only one of the rights marked with * is required (see description below) ? - The right is optional (see description below) "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is required "None" - No rights required to perform the command Listing and subscribing/unsubscribing mailboxes: LIST - "l" right is required. Note, that if the user has "l" right to a mailbox "A/B", but not to its parent mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, for example: C: A777 LIST "" * S: * LIST (\NoInferiors) "/" "A/B" S: * LIST () "/" "C" S: * LIST (\NoInferiors) "/" "C/D" S: A777 OK LIST completed SUBSCRIBE - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. UNSUBSCRIBE - no rights required to perform this operation. LSUB - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. Mailbox management: CREATE - "c" right on a nearest existing parent mailbox. When a new mailbox is created it SHOULD inherit the ACL from the parent mailbox (if one exists) in the defined hierarchy. DELETE - "x" right on the mailbox. RENAME - Moving a mailbox from one parent to another requires "x" right on the mailbox itself and "c" right for the new parent. For example, if the user wants to rename mailbox named "A/B/C" to "D/E", the user must have "x" right for the mailbox "A/B/C" and "c" right for the mailbox "D". The RENAME command SHOULD NOT change the ACLs on the renamed mailbox and submailboxes. Copying or appending messages: Before performing a COPY/APPEND command the server MUST check if the user has "i" right for the target mailbox. If the user doesn't have "i" right, the operation fails. Otherwise for each copied/appended message the server MUST check if the user has "t" right - when the message has \Deleted flag set "s" right - when the message has \Seen flag set "w" right for all other message flags. Only when the user has a particular right the corresponding flags are stored for the newly created message. The server MUST NOT fail a COPY/APPEND if the user has no rights to set a particular flag. Example: C: A003 MYRIGHTS TargetMailbox S: * MYRIGHTS TargetMailbox rwis S: A003 OK Myrights complete C: A004 FETCH 1:3 (FLAGS) S: * 1 FETCH (FLAGS (\Draft \Deleted) S: * 2 FETCH (FLAGS (\Answered) S: * 3 FETCH (FLAGS ($Forwarded \Seen) S: A004 OK Fetch Completed C: A005 COPY 1:3 TargetMailbox S: A005 OK Copy completed C: A006 SELECT TargetMailbox ... S: A006 Select Completed Let's assume that the copied messages received message numbers 77:79. C: A007 FETCH 77:79 (FLAGS) S: * 77 FETCH (FLAGS (\Draft)) S: * 78 FETCH (FLAGS (\Answered)) S: * 79 FETCH (FLAGS ($Forwarded \Seen)) S: A007 OK Fetch Completed \Deleted flag was lost on COPY, as the user has no "t" right in the target mailbox. If the MYRIGHTS command with the tag A003 would have returned: S: * MYRIGHTS TargetMailbox rsti the response from the FETCH with the tag A007 would have been: C: A007 FETCH 77:79 (FLAGS) S: * 77 FETCH (FLAGS (\Deleted)) S: * 78 FETCH (FLAGS ()) S: * 79 FETCH (FLAGS (\Seen)) S: A007 OK Fetch Completed In the latter case \Answered, $Forwarded and \Draft flags were lost on COPY, as the user has no "w" right in the target mailbox. Expunging the selected mailbox: EXPUNGE - "e" right on the selected mailbox. CLOSE - "e" right on the selected mailbox. If the server is unable to expunge the mailbox because the user doesn't have the "e" right, the server MUST ignore expunge request, close the mailbox and return tagged OK response. Fetch information about a mailbox and its messages: SELECT/EXAMINE/STATUS - "r" right on the mailbox. FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, if the current user doesn't have "s" right. Changing flags: STORE - the server MUST check if the user has "t" right - when the user modifies \Deleted flag "s" right - when the user modifies \Seen flag "w" right for all other message flags. STORE operation SHOULD NOT fail if the user has rights to modify at least one flag specified in the STORE, as the tagged NO response to a STORE command is not handled very well by deployed clients. Changing ACLs: SETACL/DELETEACL - "a" right on the mailbox. Reading ACLs: GETACL - "a" right on the mailbox. MYRIGHTS - any of the following rights is required to perform the operation: "l", "r", "i", "c", "x", "a". <> LISTRIGHTS - same as MYRIGHTS. <> <> 5. Formal Syntax This document doesn't change the formal syntax of commands/ responses defined in the Section 6 of RFC 2086. However, the "identifier" production is now allowed to carry any UTF-8 string. Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4] or [LISTEXT]. Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. rights_capa = "RIGHTS=" new_rights ;; RIGHTS=... capability new_rights = atom ;; MUST include "t", "e", "x", "m" and "n" 6. Security Considerations An implementation must make sure the ACL commands themselves do not give information about mailboxes with appropriately restricted ACL's. For example, a GETACL command on a mailbox for which the user has insufficient rights should not admit that the mailbox exists, much less return the mailbox's ACL. LISTRIGHTS command MUST NOT check that a particular identifier exists, however it SHOULD recognize special identifiers like "anyone". IMAP clients implementing ACL that are able to modify ACLs SHOULD warn a user that wants to give full access (or even just "a" right) to the special identifier "anyone". 7. Other considerations 7.1. Additional requirements and Implementation notes 7.1.1. Servers This document defines an additional capability that is used to announce the list of extra rights (excluding the ones defined in the RFC 2086) supported by the server. The set of rights MUST include "t", "e", "x", "m" and "n". Note, that the extra rights can appear in any order. Example: C: 1 capability S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texnm S: 1 OK completed The presence of the "RIGHTS=" capability also declares that the server always returns the MYRIGHTS untagged response upon SELECT/EXAMINE. The MYRIGHTS response SHOULD also be sent any time when the server detects that the set of rights allowed for the logged in user in the opened mailbox has changed. Any server implementing an ACL extension MUST accurately reflect the current user's rights in FLAGS and PERMANENTFLAGS responses. Example: C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * MYRIGHTS INBOX rwis S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited S: A142 OK [READ-WRITE] SELECT completed Servers MAY cache the rights a user has on a mailbox when the mailbox is selected, so that if a client's rights on a mailbox are changed with SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, EXPUNGE) might not reflect the changed rights until the mailbox is re-selected. If the server checks the rights on each command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if they have changed. An ACL server MAY modify one or more ACL for one or more identifier as a side effect of modifying the ACL specified in a SETACL/DELETEACL. If the server does that it MUST send untagged ACL response to notify the client about the changes made. 7.1.2. Clients A client implementation that allows a user to read and update ACLs MUST preserve unrecognized rights that it doesn't allow the user to change when updating the rights. Otherwise the client may unintentionally remove permissions. 7.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes A particular ACL server implementation may allow "shared multiuser access" to some mailboxes. "Shared multiuser access" to a mailbox means that multiple different users are able to access the same mailbox, if they have proper access rights. "Shared multiuser access" to the mailbox doesn't mean that the ACL for the mailbox is currently set to allow access by multiple users. Let's denote a "shared multiuser write access" as a "shared multiuser access" when a user may be granted flag modification rights (any of "w", "s" or "t"). Section 4 describes which rights are required for modifying different flags. If the ACL server implements some flags as shared for a mailbox (i.e., the ACL for the mailbox may be set up so that changes to those flags are visible to another user), let's call the set of rights associated with these flags (as described in Section 4) for that mailbox collectively as "shared flag rights". Note, that "shared flag rights" set MAY be different for different mailboxes. If the server doesn't support "shared multiuser write access" to a mailbox or doesn't implement shared flags on the mailbox, "shared flag rights" for the mailbox is defined to be the empty set. Example 1: Mailbox "banan" allows "shared multiuser write access" and implements flags \Deleted, \Answered and $MDNSent as shared flags. "Shared flag rights" for the mailbox "banan" is a set containing flags "t" (because system flag \Deleted requires "t" right) and "w" (because both \Answered and $MDNSent require "w" right). Example 2: Mailbox "apple" allows "shared multiuser write access" and implements \Seen system flag as shared flag. "Shared flag rights" for the mailbox "apple" contains "s" right, because system flag \Seen requires "s" right. Example 3: Mailbox "pear" allows "shared multiuser write access" and implements flags \Seen, \Draft as shared flags. "Shared flag rights" for the mailbox "apple" is a set containing flags "s" (because system flag \Seen requires "s" right) and "w" (because system flag \Draft requires "w" right). The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if none of the following rights is granted to the current user: "i", "e" and "shared flag rights". The server SHOULD include a READ-WRITE prefix in the tagged OK response if at least one of the "i", "e" or "shared flag rights" is granted to the current user. Example 1 (continued): The user that has "lrs" rights for the mailbox "banan". The server returns READ-ONLY response code on SELECT, as none of "iewt" rights is granted to the user. Example 2 (continued): The user that has "rit" rights for the mailbox "apple". The server returns READ-WRITE response code on SELECT, as the user has "i" right. Example 3 (continued): The user that has "rset" rights for the mailbox "pear". The server returns READ-WRITE response code on SELECT, as the user has "e" and "s" rights. 8. References 8.1. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, January 1997 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", RFC 2279, Alis Technologies, January 1998. 8.2. Informative References [ANNOTATE] Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", work in progress, draft-ietf-imapext-annotate-XX.txt 9. Acknowledgment This document is an update to the RFC 2086 written by John G. Myers. Editor appreciates comments received from Mark Crispin, Chris Newman, Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg, Larry Greenfield, Robert Siemborski, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel, Philip Guenther and other participants of the IMAPEXT working group. 10. Editor's Address Alexey Melnikov email: alexey.melnikov@isode.com Isode Limited 11. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Appendix A. Changes since RFC 2086 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 2. Specified that mailbox deletion is controled by the "x" right and EXPUNGE is controlled by the "e" right. 3. Clarified that RENAME requires the "c" right for the new parent and the "x" right for the old name. 4. Added the "t" right that controls STORE \Deleted. Redefined "d" to be a macro for "e", "x" and "t". 5. Specified that the "a" right also controls DELETEACL. 6. Specified that the "r" right also controls STATUS. 7. Removed the requirement to check the "r" right for CHECK, SEARCH and FETCH, as this is required for SELECT/EXAMINE to be successful. 8. LISTRIGHTS requires same rights as MYRIGHTS. 9. Deleted "PARTIAL", this is a deprecated feature of RFC1730. 10. Specified that the "w" right controls setting flags other than \Seen and \Deleted on APPEND. Also specified that the "s" right controls the \Seen flag and that the "t" right controls the \Deleted flag. 11. SUBSCRIBE is NOT allowed with the "r" right. 12. Specified that the "l" right controls SUBSCRIBE. 13. GETACL is NOT allowed with the "r" right, even though there are several implementations that allows that. If a user only has "r" right, GETACL can disclose information about identifiers existing on the mail system. 14. Added new section that describes which rights are required and/or checked when performing various IMAP commands. 15. Added mail client security considerations when dealing with special identifier "anyone". 16. Clarified that negative rights are not the same as DELETEACL. 17. Added note that a server can modify an ACL for any identifier(s) as a side effect of performing SETACL/DELETEACL. Also specified that the server MUST send untagged ACL response if it does that. 18. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY response codes. 19. Added "Compatibility with RFC 2086" section. 20. Added "Implementation Notes" section. 21. Updated "References" section. 22. Added requirement for a SELECT/EXAMINE to return the MYRIGHTS response. 23. Added the "m" and "n" rights for ANNOTATE. Appendix B. Compatibility with RFC 2086 This section gives guidelines how an existing RFC 2086 server implementation may be updated to comply with this document. This document replaces the "d" right with 3 new different rights "x", "t" and "e". The server should implement one of the following two approaches to handle "d" and the new rights that have replaced it. a). Tie "x", "t" and "e" together - almost no changes. b). Implement separate "x", "t" and "e". Return "d" right in a LIST response containing ACL information when all three of "x", "t" and "e" are granted. Additional work required to implement ACL2 when RFC 2086 is already implemented: 1). Send the MYRIGHTS untagged response on a successful SELECT/EXAMINE. Also check Sections 7.1 and 7.2, as well as the appendix A to see other changes required. Server implementors should check which rights are required to invoke different IMAP4 commands as described in Section 4. --------------010108000909080309050706-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DgCms081182; Sat, 6 Nov 2004 05:42:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6DgCbf081181; Sat, 6 Nov 2004 05:42:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DgBcf081173 for ; Sat, 6 Nov 2004 05:42:12 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix4-2.free.fr (Postfix) with ESMTP id D0D6B23579A for ; Sat, 6 Nov 2004 14:42:12 +0100 (CET) Message-ID: <418CD4D1.1010902@alussinan.org> Date: Sat, 06 Nov 2004 14:42:41 +0100 From: kael User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Question about the SORT and THREAD extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Can [could] the SORT and THREAD extensions handle messages like this http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html ? -- kael http://del.icio.us/ubi.quito.us Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LAVu1047545; Fri, 5 Nov 2004 13:10:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5LAVi6047544; Fri, 5 Nov 2004 13:10:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LAU8C047509 for ; Fri, 5 Nov 2004 13:10:30 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iA5LAAZe031233 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 5 Nov 2004 13:10:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: agenda@ietf.org, IMAP Extensions WG From: Lisa Dusseault Subject: Proposed agenda for IMAPEXT Date: Fri, 5 Nov 2004 13:10:04 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm sorry this is so late, but here it is anyway. Suggestions welcome. Note the new ACL draft link which hasn't been commented on here on the list -- if you get a chance to read that draft by Monday that would be super. Agenda for IMAPEXT meeting at 61st IETF Monday, Nov 8, 1530-1730 0. Agenda bashing, find note taker and jabber scribe: (10 minutes) 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) - status: still blocked on comparator (as is i18n draft) - Barry Leiba will discuss Still issues on /Placeholder from last meeting, which Alexey and Cyrus were tasked with resolving (40 minutes) 2. Access Control Lists - Not updated since last meeting -- probably still blocked on LISTEXT. - READ THIS if you're coming to the meeting! Or even if you're not. It hasn't been discussed on the list yet. (30 minutes) 3. Message-level annotations - Changes since last meeting... Open issue: use of the 'm' bit for ACL of private annotations At least one more draft required (40 minutes) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5GQfmg028445; Fri, 5 Nov 2004 08:26:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5GQf2F028444; Fri, 5 Nov 2004 08:26:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5GQeWl028435 for ; Fri, 5 Nov 2004 08:26:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 5 Nov 2004 16:26:41 +0000 Message-ID: <418BA9BF.4060906@isode.com> Date: Fri, 05 Nov 2004 16:26:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , lemonade@ietf.org Subject: Not being able to attend IMAPEXT/Lemonade Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Due to little trick that UK Home Office has played on me, I am still not in possession of my passport. My flight is tomorrow at noon. So I will most likely miss the IMAPEXT and Lemonade meetings. I will try to participate in jabber. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IiMWo041202; Mon, 1 Nov 2004 10:44:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1IiMOS041201; Mon, 1 Nov 2004 10:44:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IiLbI041089 for ; Mon, 1 Nov 2004 10:44:21 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 165971CACC81; Mon, 1 Nov 2004 20:44:13 +0200 (EET) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id AA0DE1C13488; Mon, 1 Nov 2004 20:44:06 +0200 (EET) In-Reply-To: <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16-768365339" Message-Id: <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: Annotate Date: Mon, 1 Nov 2004 20:44:09 +0200 To: Cyrus Daboo X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-16-768365339 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 1.11.2004, at 20:09, Cyrus Daboo wrote: >> The 'm' right controls both read and write access to .priv >> annotation >> values. When it is on, access to .priv annotations is allowed, >> when >> it is off, access to .priv annotations is disallowed. >> >> Is this really needed? I think private annotations should work the >> same >> way as private flags. You can always read them, and you can write >> them if >> it's possible to permanently save flags. > > In an ACL-aware server there are different ways to control the flag > state 's' and 'w' bits. As a result I think there should also be a way > to enable/disable private annotations independently - hence the 'm' > bit. I know Alexey had some concerns with 'm' too so this is still an > open issue. Well, perhaps it would be useful to have "m" for writing because of that, but I think "r" would be more logical for reading private annotations. >> I thought clients weren't allowed to make up their own annotation >> entry >> names? Or what does this mean? > > If a client wants to create a 'boolean' (on/off) type property > associated with a message it has two options: use an IMAP keyword > (either private or registered), or create a vendor (or new standard) > annotation entry. The former gives no control over private/shared > state, whereas the latter does. So if there is a specific need for > such a property that does need explicit private/shared behavior then > the client can use annotations in lieu of IMAP keywords. I thought vendor namespaces meant that servers could create them, not clients. Maybe put at the beginning of 2.2.1 something like: Vendor namespaces can be created by either clients or servers. Servers MUST(?) support new namespaces created by clients. > Here is some alternate text for the above paragraph that I am > proposing to use instead. Note this also includes a sentence to > address the first point you made: > > Clients that need to implement a property on a message that is > either 'on' or 'off' and which requires separate private and shared > state can use an annotation to represent that property as opposed > to using IMAP Keywords, which cannot reliably discriminate the > private and shared state. However, clients MUST NOT use annotations > to replace existing IMAP flag behavior, which would cause > interoperability problems with non-ANNOTATE aware clients. > > If that is not suitable, please suggest some other text or > clarifications. Looks good to me. --Apple-Mail-16-768365339 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBhoP5yUhSUUBViskRAh+PAKCCId8BaxYaoIcNXuF8FIvgqYHpCwCfQRJI GHzf0eAaHqgR8gWem/qbgJ0= =ZhJZ -----END PGP SIGNATURE----- --Apple-Mail-16-768365339-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I9PTj021240; Mon, 1 Nov 2004 10:09:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1I9Pit021239; Mon, 1 Nov 2004 10:09:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I9KOF021185 for ; Mon, 1 Nov 2004 10:09:24 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA1H3g6E015095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2004 12:03:44 -0500 Date: Mon, 01 Nov 2004 13:09:06 -0500 From: Cyrus Daboo To: Timo Sirainen , IMAP Extensions WG Subject: Re: Annotate Message-ID: <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> In-Reply-To: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Monday, November 1, 2004 7:27:45 PM EST +0200 Timo Sirainen wrote: > Some comments: > > Clients MUST NOT use annotations in lieu of equivalent IMAP base > specification facilities. For example, use of a "seen" flag in the > vendor namespace together with ".PEEK" in fetches. Such behaviour > would significantly reduce IMAP interoperability. > > I don't understand the example. What does .PEEK fetches have to do with > \Seen flag, except without it the \Seen flag might change? In this example we are saying that a 'rogue' client might choose to bypass the standard IMAP seen behavior by using .PEEK fetches (that do not change the IMAP \Seen flag) and instead use their own private seen annotation that is used to indicate seen state in that client. That hurts interop because a message that appears seen in one client, does not appear seen in another. What I think will be best is to remove the text you quoted, and instead insert a comment in the flags section (actually this will appear in the new text I propose below in response to your last point). > If a server supports annotations, then it MUST store all annotation > data permanently, i.e. there is no concept of 'session only' > annotations that would correspond to the behaviour of 'session' flags > as defined in the IMAP base specification. The exception to this is > IMAP flags (which are accessible directly through annotations) which > may be 'session only' as determined by the FLAGS and PERMANENTFLAGS > responses to a SELECT or EXAMINE command. > > Since IMAP flags can no longer be modified with ANNOTATE, the exception > should probably be removed. OK, I will remove that last sentence. > The 'm' right controls both read and write access to .priv annotation > values. When it is on, access to .priv annotations is allowed, when > it is off, access to .priv annotations is disallowed. > > Is this really needed? I think private annotations should work the same > way as private flags. You can always read them, and you can write them if > it's possible to permanently save flags. In an ACL-aware server there are different ways to control the flag state 's' and 'w' bits. As a result I think there should also be a way to enable/disable private annotations independently - hence the 'm' bit. I know Alexey had some concerns with 'm' too so this is still an open issue. > /flags > Defines the top-level of entries for flags associated with an > entire message. The "value" attribute of each of the entries > described below must be either "1", "0" or NIL. "1" corresponds > to the flag being set. > > NIL isn't defined here. Does it mean "not set"? For example: NIL should be removed. The flag value must be either 1 or 0, and both .priv and .shared will be the same. NIL only made sense when annotate was discriminating between private/shared flag behavior, which it no longer does. > Clients that need to implement shared and private 'flags' can create > their own annotation entries for those, completely bypassing the base > IMAP flag/keyword behaviour. > > I thought clients weren't allowed to make up their own annotation entry > names? Or what does this mean? If a client wants to create a 'boolean' (on/off) type property associated with a message it has two options: use an IMAP keyword (either private or registered), or create a vendor (or new standard) annotation entry. The former gives no control over private/shared state, whereas the latter does. So if there is a specific need for such a property that does need explicit private/shared behavior then the client can use annotations in lieu of IMAP keywords. Here is some alternate text for the above paragraph that I am proposing to use instead. Note this also includes a sentence to address the first point you made: Clients that need to implement a property on a message that is either 'on' or 'off' and which requires separate private and shared state can use an annotation to represent that property as opposed to using IMAP Keywords, which cannot reliably discriminate the private and shared state. However, clients MUST NOT use annotations to replace existing IMAP flag behavior, which would cause interoperability problems with non-ANNOTATE aware clients. If that is not suitable, please suggest some other text or clarifications. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HRwPE000857; Mon, 1 Nov 2004 09:27:58 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HRwIM000856; Mon, 1 Nov 2004 09:27:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HRvbA000795 for ; Mon, 1 Nov 2004 09:27:57 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 2E9D01CACC81; Mon, 1 Nov 2004 19:27:48 +0200 (EET) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id F305E1C13481 for ; Mon, 1 Nov 2004 19:27:42 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15-763781542" To: IMAP Extensions WG From: Timo Sirainen Subject: Annotate Date: Mon, 1 Nov 2004 19:27:45 +0200 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-15-763781542 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Some comments: Clients MUST NOT use annotations in lieu of equivalent IMAP base specification facilities. For example, use of a "seen" flag in the vendor namespace together with ".PEEK" in fetches. Such behaviour would significantly reduce IMAP interoperability. I don't understand the example. What does .PEEK fetches have to do with \Seen flag, except without it the \Seen flag might change? If a server supports annotations, then it MUST store all annotation data permanently, i.e. there is no concept of 'session only' annotations that would correspond to the behaviour of 'session' flags as defined in the IMAP base specification. The exception to this is IMAP flags (which are accessible directly through annotations) which may be 'session only' as determined by the FLAGS and PERMANENTFLAGS responses to a SELECT or EXAMINE command. Since IMAP flags can no longer be modified with ANNOTATE, the exception should probably be removed. The 'm' right controls both read and write access to .priv annotation values. When it is on, access to .priv annotations is allowed, when it is off, access to .priv annotations is disallowed. Is this really needed? I think private annotations should work the same way as private flags. You can always read them, and you can write them if it's possible to permanently save flags. /flags Defines the top-level of entries for flags associated with an entire message. The "value" attribute of each of the entries described below must be either "1", "0" or NIL. "1" corresponds to the flag being set. NIL isn't defined here. Does it mean "not set"? For example: /flags/\Seen.shared = 1 /flags/\Seen.private = NIL -> private \Seen flag set /flags/\Seen.shared = 1 /flags/\Seen.private = 0 -> private \Seen flag not set Or should server do this internally and always return 1/0 seen flag? So NIL would only be useful for shared? Or should it also there default to 1/0? Clients that need to implement shared and private 'flags' can create their own annotation entries for those, completely bypassing the base IMAP flag/keyword behaviour. I thought clients weren't allowed to make up their own annotation entry names? Or what does this mean? --Apple-Mail-15-763781542 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBhnIRyUhSUUBViskRAmTaAJ9oxEM6bGk9chBLXeP5d2EU1V5LBQCfUU12 vQUXkwmsCngRfTAlboB6X+4= =65oO -----END PGP SIGNATURE----- --Apple-Mail-15-763781542-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9sr2C070865; Tue, 30 Nov 2004 01:54:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAU9srf1070864; Tue, 30 Nov 2004 01:54:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9sq4h070759 for ; Tue, 30 Nov 2004 01:54:52 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 822C0154009; Tue, 30 Nov 2004 09:54:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Philip Guenther Cc: Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> <200411292223.iATMNjTP062535@lab.smi.sendmail.com> In-Reply-To: <200411292223.iATMNjTP062535@lab.smi.sendmail.com> Message-ID: <20041130095434.13627.39231.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 30 Nov 2004 09:54:34 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 29 22:23:45 2004, Philip Guenther wrote: > > Ken Murchison writes: > ... > >Yes. The draft makes the false assumption that *all* existing > >implementations use the 'd' right to control DELETE. Cyrus made > the >decision a while back to separate mailbox ops (DELETE) from > message ops >(\Deleted and EXPUNGE). Its unfortunate that RFC 2086 > was >vague/ambiguous w.r.t. DELETE. > ... > >One easy way to do this might be to make 'c' a macro in the new > draft >just like 'd' and create a new bit for CREATE (e.g. 'k') > Then the >mapping would be: > > > >Cyrus: 'c' -> "kx", 'd' -> "te" > >Others: 'c' -> "k", 'd' -> "xte" > > This makes sense to me, but our server has this problem too, being > distantly derived from Cyrus. Does anyone actually know of a server > that controls DELETE with the 'd' right? CommunigatePro does, but *also* controls it with the "c" right on the parent. (In other words, given A/B, issuing DELETE A/B requires "c" right in A and "d" right in B) I would guess that Sun's implementation might require the parent "c" right, as well, given that their JavaMail [client] API documents that as required, but that's pure speculation on my part - I can't access their server implementation's documentation. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATMNlEE050556; Mon, 29 Nov 2004 14:23:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATMNlQd050555; Mon, 29 Nov 2004 14:23:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATMNkCa050546 for ; Mon, 29 Nov 2004 14:23:46 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iATMNkEU012024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 29 Nov 2004 14:23:46 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iATMNkEU012024 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=ROyfw0bP6jfTkpK19lgv5l/ILzsvjk31AJ7fJtD2hO0nwKtoZHI9hpO7SPUR5gV1m vRtGF1PCebdwQtsqvSv+xVfjlSaEZFC6NQVFeA49PE/fpZBwNf2q7I51RtRWx9c6wf1 cJU9rSW/pNASsh2whVpgW/GUbR7BMvb2QsvNqfE= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iATMNjTP062535; Mon, 29 Nov 2004 14:23:45 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411292223.iATMNjTP062535@lab.smi.sendmail.com> To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG From: Philip Guenther Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) In-reply-to: <41991116.9010001@oceana.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> Date: Mon, 29 Nov 2004 14:23:45 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: ... >Yes. The draft makes the false assumption that *all* existing >implementations use the 'd' right to control DELETE. Cyrus made the >decision a while back to separate mailbox ops (DELETE) from message ops >(\Deleted and EXPUNGE). Its unfortunate that RFC 2086 was >vague/ambiguous w.r.t. DELETE. ... >One easy way to do this might be to make 'c' a macro in the new draft >just like 'd' and create a new bit for CREATE (e.g. 'k') Then the >mapping would be: > >Cyrus: 'c' -> "kx", 'd' -> "te" >Others: 'c' -> "k", 'd' -> "xte" This makes sense to me, but our server has this problem too, being distantly derived from Cyrus. Does anyone actually know of a server that controls DELETE with the 'd' right? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPDEUUB081513; Thu, 25 Nov 2004 05:14:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPDEUTs081511; Thu, 25 Nov 2004 05:14:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPDEP6M080856 for ; Thu, 25 Nov 2004 05:14:29 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id AAA42154009; Thu, 25 Nov 2004 13:14:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG , Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> <41A3AE85.3030109@isode.com> In-Reply-To: <41A3AE85.3030109@isode.com> Message-ID: <20041125131410.29723.97056.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 25 Nov 2004 13:14:10 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Nov 23 21:41:25 2004, Alexey Melnikov wrote: > Suggested text: > Rights is a string listing a (possibly empty) set of alphanumeric > characters, each character listing a set of operations which is > being > controlled. Lowercase letters are reserved for ''standard'' > rights, listed > below. (Note that for compatibility with deployed clients and > servers uppercase rights are not allowed). > > And update ABNF to enforce this. > > That's fine by me. > In the ACL2 document we should say something like this: > Unlike the RFC 2086, the letter rights are case-insensitive, so > the right "R" is the same as the right "r". > > That's also fine by me. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOIv2Uv074198; Wed, 24 Nov 2004 10:57:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOIv2gc074197; Wed, 24 Nov 2004 10:57:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOIux89074100 for ; Wed, 24 Nov 2004 10:57:01 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAOIuqPB010197 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 24 Nov 2004 10:56:52 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAOIuqPB010197 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=rU5Im1WByzv+2vQC6eLHKW16Ur5R8U4wataHxMdUlArzXschUvJ5OtdCi69NTYzNa pUHa7cS3ClsOUIlWy6FqZV3QBatFDYT9xYHK+Yu9400MoY6dSvUM/3msl317KYlGYlz gJ4lIKTFEub53YGOdwlCny9mk6u/vk5yHe4Ru2E= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAOIuq5U071235; Wed, 24 Nov 2004 10:56:52 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411241856.iAOIuq5U071235@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <41A3AE85.3030109@isode.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> <41A3AE85.3030109@isode.com> Date: Wed, 24 Nov 2004 10:56:52 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Suggested text: > Rights is a string listing a (possibly empty) set of alphanumeric > characters, each character listing a set of operations which is being > controlled. Lowercase letters are reserved for ''standard'' rights, > listed below. (Note that for compatibility with deployed clients and > servers uppercase rights are not allowed). I can live with this. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBLBA7081032; Wed, 24 Nov 2004 03:21:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAOBLBwT081031; Wed, 24 Nov 2004 03:21:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAOBL6lD080631 for ; Wed, 24 Nov 2004 03:21:09 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 24 Nov 2004 11:20:36 +0000 Message-ID: <41A3AE85.3030109@isode.com> Date: Tue, 23 Nov 2004 21:41:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > Looks like there was actually unanimity among seven voters to require > both clients and servers to send only lower-case rights in 2086upd, > but some quibbling about other details (whether to accept upper-case, > what precise wording to use). Cyrus' proposed wording was: > >> 'Rights in 2086upd are case-insenstive, however clients and servers >> MUST use lower-case rights to be compatible with clients or servers >> supporting the original 2086 specification.' > > Philip suggested a slight modification that servers that advertise > support for 2086upd should be able to accept upper-case rights as well > (but not send them, if I understand). > > Alexey and Dave suggested that the spec not even use the word > "case-insensitive" to not confuse people. > > So Alexey, how about you propose new text for 2086upd? Suggested text: Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Lowercase letters are reserved for ''standard'' rights, listed below. (Note that for compatibility with deployed clients and servers uppercase rights are not allowed). And update ABNF to enforce this. In the ACL2 document we should say something like this: Unlike the RFC 2086, the letter rights are case-insensitive, so the right "R" is the same as the right "r". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI1H80070315; Tue, 23 Nov 2004 10:01:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANI1HnN070314; Tue, 23 Nov 2004 10:01:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI1GN9070255 for ; Tue, 23 Nov 2004 10:01:16 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iANI1C97024149 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 23 Nov 2004 10:01:13 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Tue, 23 Nov 2004 10:01:01 -0800 To: IMAP Extensions WG X-Mailer: Apple Mail (2.619) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looks like there was actually unanimity among seven voters to require both clients and servers to send only lower-case rights in 2086upd, but some quibbling about other details (whether to accept upper-case, what precise wording to use). Cyrus' proposed wording was: > 'Rights in 2086upd are case-insenstive, however clients and servers > MUST use lower-case rights to be compatible with clients or servers > supporting the original 2086 specification.' Philip suggested a slight modification that servers that advertise support for 2086upd should be able to accept upper-case rights as well (but not send them, if I understand). Alexey and Dave suggested that the spec not even use the word "case-insensitive" to not confuse people. So Alexey, how about you propose new text for 2086upd? Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANFJDQw021359; Tue, 23 Nov 2004 07:19:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANFJDci021358; Tue, 23 Nov 2004 07:19:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iANFJAgo021196 for ; Tue, 23 Nov 2004 07:19:11 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id F300B1BDE90; Tue, 23 Nov 2004 16:18:45 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id CFDBB1BDE87; Tue, 23 Nov 2004 16:18:44 +0100 (CET) Message-Id: Date: Tue, 23 Nov 2004 16:14:40 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Alexey Melnikov , Philip Guenther , Lisa Dusseault References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <200411230204.iAN248jq002789@lab.smi.sendmail.com> <41A35121.5030602@isode.com> In-Reply-To: <41A35121.5030602@isode.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > So I am in favor of saying that upper-case rights in 2086upd are not allowed. > > And I agree that ACL2 should relax this to make rights case-insensitive. I'm happy with that. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANF3Kjq015866; Tue, 23 Nov 2004 07:03:20 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANF3KPx015865; Tue, 23 Nov 2004 07:03:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANF3JXH015796 for ; Tue, 23 Nov 2004 07:03:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 23 Nov 2004 15:02:58 +0000 Message-ID: <41A35121.5030602@isode.com> Date: Tue, 23 Nov 2004 15:02:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Lisa Dusseault , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <200411230204.iAN248jq002789@lab.smi.sendmail.com> In-Reply-To: <200411230204.iAN248jq002789@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >I'm in favor of requiring servers that advertise the RIGHTS capability >to treat rights as case-insensitive. This requirement would (obviously) >not be retroactive to implementation that only support ACL and not >RIGHTS, so it does not invalidate any implementations. I find the >described behavior of existing implementations largely irrelevant to >this decision: upgrading an implementation from just ACL to ACL+RIGHTS >is clearly going to require code changes for the new rights; adding a >"tolower()" call would just be one of those changes. > >For the benefit of client implementors, a note could be added that warns >that there exist common ACL implementations that predate this >requirement and therefore that clients MUST send the standard rights as >lowercase letters when talking to a server that does not support the >RIGHTS extension. > > As there is no way for a client to announce its capabilities, the server MUST always send rights in lower-case. I just really see no point of saying that rights are case-insensitive when there are effectively case-sensitive for existing ACL implementations. >Leaving the meaning of uppercase rights implementation defined doesn't >help anyone and means we simply get to have this same discussion all >over again come ACL2. > > I agree, we need to either disallow upper-case rights or make them equal to the lower-case counterparts. I don't think anybody has presented a good argument for making upper-case and lower-case rights different. However, I share David's concern that even mentioning the word "case-insensitive" will mislead some implementors. So I am in favor of saying that upper-case rights in 2086upd are not allowed. And I agree that ACL2 should relax this to make rights case-insensitive. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAN24901038494; Mon, 22 Nov 2004 18:04:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAN249N1038493; Mon, 22 Nov 2004 18:04:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAN249Rk038442 for ; Mon, 22 Nov 2004 18:04:09 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAN248Jw024619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 22 Nov 2004 18:04:08 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAN248Jw024619 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=G40sxHcV7XeDKFnI2lE4eCU48W6Z6i34p+iykcIbiCyYdbxuw1+sIKFrEJOZtCnsq HLobpGmBVTaUweMQqFDiS9SPnow8w6ru++Ux3jqbDhGJcLE//XDgm6GqbcooH+qCyY9 8ussYjrhrwjyvBKhWfeNe9osR9f4AOOU9cHw09w= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAN248jq002789; Mon, 22 Nov 2004 18:04:08 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411230204.iAN248jq002789@lab.smi.sendmail.com> To: Lisa Dusseault Cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Date: Mon, 22 Nov 2004 18:04:08 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm in favor of requiring servers that advertise the RIGHTS capability to treat rights as case-insensitive. This requirement would (obviously) not be retroactive to implementation that only support ACL and not RIGHTS, so it does not invalidate any implementations. I find the described behavior of existing implementations largely irrelevant to this decision: upgrading an implementation from just ACL to ACL+RIGHTS is clearly going to require code changes for the new rights; adding a "tolower()" call would just be one of those changes. For the benefit of client implementors, a note could be added that warns that there exist common ACL implementations that predate this requirement and therefore that clients MUST send the standard rights as lowercase letters when talking to a server that does not support the RIGHTS extension. Leaving the meaning of uppercase rights implementation defined doesn't help anyone and means we simply get to have this same discussion all over again come ACL2. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMATRRY047909; Mon, 22 Nov 2004 02:29:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMATROk047908; Mon, 22 Nov 2004 02:29:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMATQEC047802 for ; Mon, 22 Nov 2004 02:29:27 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id A2ADB154009; Mon, 22 Nov 2004 10:29:22 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Philip Guenther Cc: Mark Crispin , Alexey Melnikov , , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <200411192350.iAJNo48o001654@lab.smi.sendmail.com> In-Reply-To: <200411192350.iAJNo48o001654@lab.smi.sendmail.com> Message-ID: <20041122102922.21034.86175.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 22 Nov 2004 10:29:22 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 23:50:04 2004, Philip Guenther wrote: > Furthermore, I would suggest that servers SHOULD return a BAD > response > if a client specifies an unknown right. Silently ignoring part of > what > a client says is a recipe for later dissension...like the current > discussion. Indeed. That doesn't solve the existing problem, though. > On one point: > > Dave Cridland writes: > ... > >And ACL2 is a total replacement, in effect. RFC2086 will die out, > >along with this specification too, and while there will be a > >compatibility option in most implementations, that's something > that >will fall out of use quite happily by itself. > > I disagree that ACL2 should be a complete replacement; with the > possible > exception of adding another right or two, ACL2 should simply refer > to > 2086upd for their definition and syntax. ACL2 implementations are > going > to need to support plain ACL for a goodly time to come; we should do > everything we can to avoid unnecessary incompatibilities between > them. > > (Even simply repeating the text from 2086upd in ACL2 would be error > prone. Would a latter erratum automatically apply to both? What > if the > text got editted slightly differently when republished?) No, agreed. So we stick to the rights letters and definitions, but ACL2 simply makes them case-insensitive for its interface. 2086upd issues a blanket-ban on uppercase rights being defined, in preparation for this. This should result in simpler language, and I believe greater interoperability. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMAPplM044037; Mon, 22 Nov 2004 02:25:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMAPpUc044036; Mon, 22 Nov 2004 02:25:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMAPgao043752 for ; Mon, 22 Nov 2004 02:25:42 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 13C94154009; Mon, 22 Nov 2004 10:25:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Lisa Dusseault Cc: Jutta Degener , IMAP Extensions WG , Mark Crispin , Arnt Gulbrandsen , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> In-Reply-To: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: <20041122102532.21034.48798.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 22 Nov 2004 10:25:32 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat Nov 20 17:25:43 2004, Lisa Dusseault wrote: > Ok, can we get summarizing arguments from the different positions > here (case-sensitive v. case-insensitive ACL tokens) and tell me > your vote? I can't see a clear consensus yet despite a fair amount > of discussion over this choice. Summary: 1) Existing RFC2086 implementations assume case-sensitivity: Refs: See source code of implementations. 2) Existing, widely deployed implementations break silently when case-insensitivity is assumed. Refs: Tested against Cyrus IMAPd. SETACL with uppercase rights discards those rights, returns OK. 3) Definition of rights as case-insensitive is more likely to lead to clients which send uppercase rights - even though against the standard, the resultant wording has considerable scope to confuse. If broken implementations sending uppercase rights to existing implementations received a BAD in return, I'd vote for this. However, they don't, and a silent discarding of rights is likely to cause newly released software to fail to interoperate with existing implementations. Therefore, as much as I would personally like case-insensitive right letters, I have to vote against changing the existing syntax, on the basis of interoperability. In ACL2, I'd be happy to see the ACL SET/STORE/DELETE syntax use case-insensitive rights - I'm not against the change, merely the timing of it. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKKxFXK004078; Sat, 20 Nov 2004 12:59:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKKxFKV004077; Sat, 20 Nov 2004 12:59:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKKxACM004054 for ; Sat, 20 Nov 2004 12:59:10 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAKKxE9N021844; Sat, 20 Nov 2004 12:59:14 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAKKxDBI013230; Sat, 20 Nov 2004 12:59:13 -0800 Date: Sat, 20 Nov 2004 12:59:13 -0800 (PST) From: Mark Crispin To: Cyrus Daboo cc: Lisa Dusseault , IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 20 Nov 2004, Cyrus Daboo wrote: > 'Rights in 2086upd are case-insenstive, however clients and servers MUST use > lower-case rights to be compatible with clients or servers supporting the > original 2086 specification.' OK. > As long as the lower-case requirement applies to servers as well as clients I > vote for case-insensitivity. I agree to this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJh4JA082107; Sat, 20 Nov 2004 11:43:04 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKJh4Ix082106; Sat, 20 Nov 2004 11:43:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJgxY4082042 for ; Sat, 20 Nov 2004 11:43:03 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.0.1.3] (pool-68-162-181-10.pitt.east.verizon.net [68.162.181.10]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAKIYc6E012269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Nov 2004 13:34:39 -0500 Date: Sat, 20 Nov 2004 14:42:54 -0500 From: Cyrus Daboo To: Mark Crispin , Lisa Dusseault cc: IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <34CF0DE1DE07F9B6C0A6BD87@ninevah.local> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On November 20, 2004 11:09:44 -0800 Mark Crispin wrote: > On Sat, 20 Nov 2004, Lisa Dusseault wrote: >> Ok, can we get summarizing arguments from the different positions here >> (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? >> I can't see a clear consensus yet despite a fair amount of discussion >> over this choice. > > Mark votes for mandatory case-insensitivity in servers which claim to be > 2086upd compliant (ACL2 goes without saying), and for a prohibition on > clients sending upper-case to 2086 and 2086upd servers. The latter > provision is subject to review in ACL2. > That's not good enough because it potentially breaks existing clients which expect case-sensitive (lower-case) values from the server. The proper way to do this is: 'Rights in 2086upd are case-insenstive, however clients and servers MUST use lower-case rights to be compatible with clients or servers supporting the original 2086 specification.' As long as the lower-case requirement applies to servers as well as clients I vote for case-insensitivity. However, if that requirement on the server is not applied, then I vote for case-sensitivity in 2086upd. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ9pbU071485; Sat, 20 Nov 2004 11:09:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKJ9pu3071484; Sat, 20 Nov 2004 11:09:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ9o50071469 for ; Sat, 20 Nov 2004 11:09:51 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAKJ9ivw011236; Sat, 20 Nov 2004 11:09:45 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAKJ9i7I011253; Sat, 20 Nov 2004 11:09:44 -0800 Date: Sat, 20 Nov 2004 11:09:44 -0800 (PST) From: Mark Crispin To: Lisa Dusseault cc: Jutta Degener , IMAP Extensions WG , Arnt Gulbrandsen , Alexey Melnikov , Dave Cridland Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 20 Nov 2004, Lisa Dusseault wrote: > Ok, can we get summarizing arguments from the different positions here > (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? I > can't see a clear consensus yet despite a fair amount of discussion over this > choice. Mark votes for mandatory case-insensitivity in servers which claim to be 2086upd compliant (ACL2 goes without saying), and for a prohibition on clients sending upper-case to 2086 and 2086upd servers. The latter provision is subject to review in ACL2. The intent is to install case-insensitivity by transition; by putting servers on notice that they must fix any case-sensitivity to be 2086upd compliant, without breaking any existing behavior. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKHQRC8036915; Sat, 20 Nov 2004 09:26:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKHQRO9036914; Sat, 20 Nov 2004 09:26:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKHQMn3036856 for ; Sat, 20 Nov 2004 09:26:22 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAKHPtZe009410 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 20 Nov 2004 09:26:00 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <352452A4-3B19-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Sat, 20 Nov 2004 09:25:43 -0800 To: Jutta Degener , IMAP Extensions WG , Mark Crispin , Arnt Gulbrandsen , Alexey Melnikov , Dave Cridland X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ok, can we get summarizing arguments from the different positions here (case-sensitive v. case-insensitive ACL tokens) and tell me your vote? I can't see a clear consensus yet despite a fair amount of discussion over this choice. I need to know your vote even if you've already stated your position because some opinions were given before much discussion happened, and I need to know if the discussion changed anybody's mind. Also welcoming input from those who've stayed silent so far. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKFtbBa001950; Sat, 20 Nov 2004 07:55:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKFtb09001948; Sat, 20 Nov 2004 07:55:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKFtZ5s001889 for ; Sat, 20 Nov 2004 07:55:36 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [192.168.0.7] ([62.3.217.253]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 20 Nov 2004 15:55:24 +0000 Message-ID: <419F68E6.9000808@isode.com> Date: Sat, 20 Nov 2004 15:55:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: >> However, do you honestly think that client authors will change their >> code to send uppercase rights? (I mean, discounting the kinds of >> authors who deliberately do weird things because they can.) > > I don't think that; I *know* that. Mark, can you elaborate? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK0GMIh059705; Fri, 19 Nov 2004 16:16:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAK0GMfW059688; Fri, 19 Nov 2004 16:16:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK0GKSW059627 for ; Fri, 19 Nov 2004 16:16:20 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAK0GLMs016985; Fri, 19 Nov 2004 16:16:21 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAK0GK38032199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Nov 2004 16:16:20 -0800 Date: Fri, 19 Nov 2004 16:14:18 -0800 (Pacific Standard Time) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Dave Cridland wrote: > Nor will they use 2086upd servers either. As I understand things, 2086upd is > fully intended to be a stopgap until ACL2. Let's treat it like one. If the transition isn't started with 2086upd, it won't happen. > Wait... You "know" client authors will actively edit their code and put in > uppercase rights, then lowercase them for backwards compatibility with "pure" > RFC2086 servers if/when they encounter them? > Why? Yes, I know. There are a number of reasons of doing this, few of which have anything to do with technical excellence. For example, some client authors intentionally build software that works differentially with specific servers. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJNorvG050572; Fri, 19 Nov 2004 15:50:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJNorYQ050571; Fri, 19 Nov 2004 15:50:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJNolk8050521 for ; Fri, 19 Nov 2004 15:50:48 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAJNo9fQ019241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 19 Nov 2004 15:50:10 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAJNo9fQ019241 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=uYcIhXISlTJSPU3kby3umcfdxm5mIec+GuA81P8KHJ0S4uK1mRpYnXL62lRTjhgR2 TV2SAfGPFbqsJD5dPLHsFo169KNHORDI0AEqOmbDeu73DXBROcsxc8nOWp61ZXyN0ty uGjs58v5dTFe51kfViPsfgRDcBBhTlRLZ39hkd4= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAJNo48o001654; Fri, 19 Nov 2004 15:50:05 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411192350.iAJNo48o001654@lab.smi.sendmail.com> To: Dave Cridland Cc: Mark Crispin , Alexey Melnikov , ietf-imapext@imc.org, Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-reply-to: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> Date: Fri, 19 Nov 2004 15:50:04 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm in favor of Mark's proposed clarification that rights MUST be treated as case-insensitive. Furthermore, I would suggest that servers SHOULD return a BAD response if a client specifies an unknown right. Silently ignoring part of what a client says is a recipe for later dissension...like the current discussion. On one point: Dave Cridland writes: ... >And ACL2 is a total replacement, in effect. RFC2086 will die out, >along with this specification too, and while there will be a >compatibility option in most implementations, that's something that >will fall out of use quite happily by itself. I disagree that ACL2 should be a complete replacement; with the possible exception of adding another right or two, ACL2 should simply refer to 2086upd for their definition and syntax. ACL2 implementations are going to need to support plain ACL for a goodly time to come; we should do everything we can to avoid unnecessary incompatibilities between them. (Even simply repeating the text from 2086upd in ACL2 would be error prone. Would a latter erratum automatically apply to both? What if the text got editted slightly differently when republished?) Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJxnmA047805; Fri, 19 Nov 2004 11:59:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJJxnWM047804; Fri, 19 Nov 2004 11:59:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJxmrH047752 for ; Fri, 19 Nov 2004 11:59:49 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6F415154009; Fri, 19 Nov 2004 19:59:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen , Brian Candler Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> In-Reply-To: Message-ID: <20041119195947.21034.42728.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 19:59:47 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 17:48:33 2004, Mark Crispin wrote: > On Fri, 19 Nov 2004, Brian Candler wrote: >> That's if I understand correctly: the ACL2 proposal is being >> dropped. > > Is ACL2 being dropped? > > I oppose that. Likewise. ACL2 isn't being dropped, at least not unless we can't last-call it by 2005/02/05, as far as I'm aware. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJumiY045622; Fri, 19 Nov 2004 11:56:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJJumYI045621; Fri, 19 Nov 2004 11:56:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJJul2D045539 for ; Fri, 19 Nov 2004 11:56:48 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 1165E154009; Fri, 19 Nov 2004 19:56:46 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041119195646.21034.75706.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 19:56:46 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri Nov 19 16:41:53 2004, Mark Crispin wrote: > On Fri, 19 Nov 2004, Dave Cridland wrote: >> It solves no problems, it adds complexity. >> Adding complexity has a history of adding problems. >> Therefore we cannot (or, if you prefer, should not) make this >> change. >> What's there to understand? This isn't rocket science... > > IMAP is a protocol which stipulates case-independence in its tokens > throughout. Only data, such as message data or (optionally) > mailbox names are case-dependent, but even then INBOX is > case-independent. > > ACL rights are an IMAP token. The only reason why anyone ever > thought that they would be case-dependent was that the syntax rule > used was astring in order to avoid having to decide upon a syntax > for empty rights. This was a design mistake in 2086. I have been > objecting to 2086's design mistakes repeatedly for many years. > > Therefore, ACL rights are the only IMAP token which is > case-dependent. This solves no problems (the additional 26 rights > are not needed), it adds complexity. Adding complexity has a > history of adding problems. Therefore we cannnot (or, if you > prefer, should not) make this change. What's there to understand? > This isn't rocket science... > > I agree with all of that, which may surprise you. It's an argument *against* RFC2086, however, and not an argument *for* changing it now. In fact, the text you copied from my email stipulates "[...] make this change [...]". RFC2086 has *made* a change, a bad one I agree, but it's one we should live with until ACL2. >> I've yet to see *any* technical argument for (a) here - lots of >> discussion about whether it's more in the "spirit of IMAP", etc. >> Nothing about whether it's actually a useful or sensible thing to >> do, especially in this specification. > > The best way to ruin a technical specification is to ignore the > original spirit and graft on something that is totally foreign. > > And again, I agree - RFC2086 wasn't a terribly good way of handling ACLs. It was under-specified, has a confusing array of rights, and is generally against the spirit of IMAP. I can't stand many things about it, and this includes the way that rights are named right at the top of the list. But the spirit of RFC2086 - in fact, more than that, the actual implementations - use a case-sensitive interpretation throughout. > C++ is an excellent example. > > Well, I personally like the language, but I'll raise you Perl, although arguably that didn't have a spirit to be broken when OO was grafted on. Perhaps XLISP? >>> Simply define that any 2086upd (and ACL2) compliant server MUST >>> have case-insensitive rights,... >>> *AND* >>> define that servers MUST send rights as lower case (MUST NOT send >>> rights >>> as upper case) >> The two above suggest that rights remain case-sensitive to all >> intents and purposes. >> I fail to see any practical difference that this makes. > > Not quite. They establish the framework for the future. In > particular, they instruct new implementations to read > case-insensitive, even though at present they must only send > lowercase. Some time in the future, the latter part of the > previous sentence will be moot; nobody will use pre-2086upd servers > any more. > > Nor will they use 2086upd servers either. As I understand things, 2086upd is fully intended to be a stopgap until ACL2. Let's treat it like one. >> However, do you honestly think that client authors will change >> their code to send uppercase rights? (I mean, discounting the >> kinds of authors who deliberately do weird things because they >> can.) > > I don't think that; I *know* that. > > Wait... You "know" client authors will actively edit their code and put in uppercase rights, then lowercase them for backwards compatibility with "pure" RFC2086 servers if/when they encounter them? Why? >> Now, on the contrary position, will there be new client authors >> who misunderstand, or simply fail to read, the specification, hear >> that "rights are case-insensitive", and break interoperability >> with older servers? I believe this will be the case - hence the >> reason why additional complexity tends to cause problems. > > Pre-2086upd servers will rapidly become extinct, and clients will > be written that can only handle 2086upd. > > Otherwise, there is no point to 2086upd, and this entire effort > should be abandoned as a waste of time. It's not a waste of time - it clarifies 2086 enormously, sets down useful rules (rather than inferences) for what rights control what, and transitioning from 2086upd to ACL2 should prove much simpler. And ACL2 is a total replacement, in effect. RFC2086 will die out, along with this specification too, and while there will be a compatibility option in most implementations, that's something that will fall out of use quite happily by itself. The *only* thing we need to do to ensure that we can have case-insensitive rights in the future - should we want them, and not simply replace them with a much more IMAP-like syntax[*] - is to stress that rights are all lowercase - at least for now. Banning them outright would be simpler: The sentence beginning "Rights is a string listing..." in section 3 gets replaced with "Rights is a string listing a (possibly empty) set of lower case US-ASCII letters and digits, each character listing a set of operations which is being controlled." The ANBF gets adjusted accordingly to rule out uppercase rights. That's a simple clarification of RFC2086, well within the scope of this draft, perfectly sensible, won't break anything even if misread, leaves all our options open. Dave. * - Think syntax like A002 ACL SET (INBOX Personal/*) user=Fred (\Read \Write \Insert \Seen \Deleted) - although I've not thought about a clearer syntax for the user=Fred ugliness, nor the flag names. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIXl4h094204; Fri, 19 Nov 2004 10:33:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJIXlkg094203; Fri, 19 Nov 2004 10:33:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIXgMN094149 for ; Fri, 19 Nov 2004 10:33:43 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJIXfUg006977; Fri, 19 Nov 2004 10:33:41 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJIXeuI027500; Fri, 19 Nov 2004 10:33:40 -0800 Date: Fri, 19 Nov 2004 10:33:40 -0800 (PST) From: Mark Crispin To: Lisa Dusseault cc: Jutta Degener , Arnt Gulbrandsen , ietf-imapext@imc.org, Brian Candler , Alexey Melnikov , Dave Cridland Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> Message-ID: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Lisa Dusseault wrote: > That's not the plan... the plan is to get 2086upd done quickly then get back > to ACL2. That's what I had been led to believe. Thank you Lisa for restating this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJINAkJ088596; Fri, 19 Nov 2004 10:23:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJINAji088593; Fri, 19 Nov 2004 10:23:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIN6tt088517 for ; Fri, 19 Nov 2004 10:23:06 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAJIMnZe030496 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 Nov 2004 10:22:51 -0800 In-Reply-To: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00E02C96-3A58-11D9-81D1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Jutta Degener , Arnt Gulbrandsen , ietf-imapext@imc.org, Brian Candler , Alexey Melnikov , Dave Cridland From: Lisa Dusseault Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Date: Fri, 19 Nov 2004 10:22:43 -0800 To: Mark Crispin X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That's not the plan... the plan is to get 2086upd done quickly then get back to ACL2. lisa On Nov 19, 2004, at 9:48 AM, Mark Crispin wrote: > > On Fri, 19 Nov 2004, Brian Candler wrote: >> That's if I understand correctly: the ACL2 proposal is being dropped. > > Is ACL2 being dropped? > > I oppose that. > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHmgrv066417; Fri, 19 Nov 2004 09:48:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHmg6Y066416; Fri, 19 Nov 2004 09:48:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHmbLk066353 for ; Fri, 19 Nov 2004 09:48:41 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJHmYIo001108; Fri, 19 Nov 2004 09:48:34 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJHmXrh024495; Fri, 19 Nov 2004 09:48:33 -0800 Date: Fri, 19 Nov 2004 09:48:33 -0800 (PST) From: Mark Crispin To: Brian Candler cc: Dave Cridland , Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119171901.GA2629@uk.tiscali.com> Message-ID: References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> <20041119171901.GA2629@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Brian Candler wrote: > That's if I understand correctly: the ACL2 proposal is being dropped. Is ACL2 being dropped? I oppose that. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHJHEK048271; Fri, 19 Nov 2004 09:19:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHJHWA048270; Fri, 19 Nov 2004 09:19:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHJ7sc048128 for ; Fri, 19 Nov 2004 09:19:08 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 9ADAF13C85; Fri, 19 Nov 2004 12:19:04 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id 0CD752ABF1; Fri, 19 Nov 2004 12:18:58 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CVCPV-0000h4-Hm; Fri, 19 Nov 2004 17:19:01 +0000 Date: Fri, 19 Nov 2004 17:19:01 +0000 From: Brian Candler To: Mark Crispin Cc: Dave Cridland , Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <20041119171901.GA2629@uk.tiscali.com> References: <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Nov 19, 2004 at 08:41:53AM -0800, Mark Crispin wrote: > Therefore, ACL rights are the only IMAP token which is case-dependent. > This solves no problems (the additional 26 rights are not needed), it > adds complexity. I can't see any complexity with the one-to-one mapping of US-ASCII characters to rights; a two-to-one mapping looks more complex to me. It adds complexity in servers parsing commands, and clients parsing responses. A server, after all, may not be able to lowercase the entire line which comes in, so it still has to do this token by token. Mailbox names, apart from [Ii][Nn][Bb][Oo][Xx], are permitted to be case-sensitive, but clients have to be aware that they could also be case-insensitive. Now *that* added a hell of a lot of complexity; with UTF-7 encoded Unicode mailbox names, determining whether two characters are the same disregarding case is a non-trivial task. > >However, do you honestly think that client authors will change their code > >to send uppercase rights? (I mean, discounting the kinds of authors who > >deliberately do weird things because they can.) > > I don't think that; I *know* that. Sure, give them the option and at least one person will. But I don't see what benefit would have accrued by giving them the ability to do so, when you could just say that they can't. > Pre-2086upd servers will rapidly become extinct, and clients will be > written that can only handle 2086upd. > > Otherwise, there is no point to 2086upd, and this entire effort should be > abandoned as a waste of time. I don't see the logic there. There clearly are things that are broken in rfc 2086 in the sense that they need clarifying - the rights needed to delete mailboxes, for instance. Some or indeed most existing applications may already behave "correctly", due to luck or telepathy in interpreting the original interpretation, and therefore not need changing. That's if I understand correctly: the ACL2 proposal is being dropped. *That* would have been a replacement, leading to three types of clients/servers: those that do ACL1, those that do ACL2, and those which do both. Making 2086upd instead should leave the majority of existing 2086 implementations compliant with 2086upd; that is, in most cases they should not need to be changed to become 2086upd compliant. Or am I misunderstanding the thrust of the 2086upd concept? Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGg3uu025475; Fri, 19 Nov 2004 08:42:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJGg3PN025474; Fri, 19 Nov 2004 08:42:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGfw1s025404 for ; Fri, 19 Nov 2004 08:41:58 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAJGfs9v021002; Fri, 19 Nov 2004 08:41:54 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAJGfrC1030835; Fri, 19 Nov 2004 08:41:53 -0800 Date: Fri, 19 Nov 2004 08:41:53 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 19 Nov 2004, Dave Cridland wrote: > It solves no problems, it adds complexity. > Adding complexity has a history of adding problems. > Therefore we cannot (or, if you prefer, should not) make this change. > What's there to understand? This isn't rocket science... IMAP is a protocol which stipulates case-independence in its tokens throughout. Only data, such as message data or (optionally) mailbox names are case-dependent, but even then INBOX is case-independent. ACL rights are an IMAP token. The only reason why anyone ever thought that they would be case-dependent was that the syntax rule used was astring in order to avoid having to decide upon a syntax for empty rights. This was a design mistake in 2086. I have been objecting to 2086's design mistakes repeatedly for many years. Therefore, ACL rights are the only IMAP token which is case-dependent. This solves no problems (the additional 26 rights are not needed), it adds complexity. Adding complexity has a history of adding problems. Therefore we cannnot (or, if you prefer, should not) make this change. What's there to understand? This isn't rocket science... > I've yet to see *any* technical argument for (a) here - lots of discussion > about whether it's more in the "spirit of IMAP", etc. Nothing about whether > it's actually a useful or sensible thing to do, especially in this > specification. The best way to ruin a technical specification is to ignore the original spirit and graft on something that is totally foreign. C++ is an excellent example. >> Simply define that any 2086upd (and ACL2) compliant server MUST have >> case-insensitive rights,... >> *AND* >> define that servers MUST send rights as lower case (MUST NOT send rights >> as upper case) > The two above suggest that rights remain case-sensitive to all intents and > purposes. > I fail to see any practical difference that this makes. Not quite. They establish the framework for the future. In particular, they instruct new implementations to read case-insensitive, even though at present they must only send lowercase. Some time in the future, the latter part of the previous sentence will be moot; nobody will use pre-2086upd servers any more. > However, do you honestly think that client authors will change their code to > send uppercase rights? (I mean, discounting the kinds of authors who > deliberately do weird things because they can.) I don't think that; I *know* that. > Now, on the contrary position, will there be new client authors who > misunderstand, or simply fail to read, the specification, hear that "rights > are case-insensitive", and break interoperability with older servers? I > believe this will be the case - hence the reason why additional complexity > tends to cause problems. Pre-2086upd servers will rapidly become extinct, and clients will be written that can only handle 2086upd. Otherwise, there is no point to 2086upd, and this entire effort should be abandoned as a waste of time. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJG5JOI008745; Fri, 19 Nov 2004 08:05:19 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJG5Jqq008743; Fri, 19 Nov 2004 08:05:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJG5EZ5008700 for ; Fri, 19 Nov 2004 08:05:19 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id F0143154009; Fri, 19 Nov 2004 16:05:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Mark Crispin Cc: Alexey Melnikov , , Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041119160510.21034.52806.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 19 Nov 2004 16:05:10 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 16:01:47 2004, Mark Crispin wrote: > On Thu, 18 Nov 2004, Dave Cridland wrote: >> Therefore, we cannot make rights case-insensitive. Any attempt to >> do so would appear to create more problems than it could possibly >> solve. > > I don't understand why. > > It solves no problems, it adds complexity. Adding complexity has a history of adding problems. Therefore we cannot (or, if you prefer, should not) make this change. What's there to understand? This isn't rocket science... > You identified that there is a problem that would be caused by an > abrupt transition. So don't have an abrupt transition. This isn't > rocket science; we know how to do this. > > [As an aside, all abrupt transitions in protocols cause problems...] Indeed - but there are two ways of avoiding an abrupt transition. Either: a) Use some careful language in the specification, defining a set of rules by which there is, in effect, no transition apparent for innocent implementations. b) Not have a transition at all. (a) can be done - I appreciate that changes are possible, and indeed sometimes needed to further the protocol. The outlined rules you state do indeed provide this. I think (b) has more technical merit in this circumstance, however. In fact, I've yet to see *any* technical argument for (a) here - lots of discussion about whether it's more in the "spirit of IMAP", etc. Nothing about whether it's actually a useful or sensible thing to do, especially in this specification. > Simply define that any 2086upd (and ACL2) compliant server MUST > have case-insensitive rights,... > *AND* > define that servers MUST send rights as lower case (MUST NOT send > rights > as upper case) The two above suggest that rights remain case-sensitive to all intents and purposes. I fail to see any practical difference that this makes. I see an aesthetic difference - we can now say "They're case-insensitive", but I don't see any *real* difference. This *is* adding complexity, to the language used if nothing else. Case-insensitive means "upper and lower case are treated identically". This says "upper and lower case are treated identically, except that you can't use upper case". Some cases are less insensitive than others, if you like literary paraphrasing. > *AND* > define that clients MUST send rights as lower case (MUST NOT send > rights as upper case) to pre-2086upd servers. > > If there is no way for a client to detect a pre-2086upd server, > then simply remove "to pre-2086upd servers" in the last part. > > There is a way to detirmine if the server supports the extra rights, and, by inference, is RFC2086-upd or not, true. However, do you honestly think that client authors will change their code to send uppercase rights? (I mean, discounting the kinds of authors who deliberately do weird things because they can.) The only circumstance I can think of is clients which send XET rather than xet - the new rights being added as capitals. I can't really see this being an advantage to the author to do so, and I strongly suspect that all existent implementations of RFC2086 will use the lowercase characters for consistency anyway. Now, on the contrary position, will there be new client authors who misunderstand, or simply fail to read, the specification, hear that "rights are case-insensitive", and break interoperability with older servers? I believe this will be the case - hence the reason why additional complexity tends to cause problems. The interoperability break is particularly disturbing - it's a silent breakage in at least one widely deployed implementation, for example: C: A01 SETACL INBOX foo lrS S: A01 OK Completed C: A02 GETACL INBOX S: * ACL INBOX dwd lrswipcda foo lr S: A02 OK Completed > In ACL2, this can be removed entirely, at least for ACL2 only > software. > > For ACL2, which is now a long way off, we can make different decisions. It's worth reserving all uppercase rights in this specification to keep the options open. >> lswiPda is currently treated by many clients and servers as lswida. > > How many clients rely upon this behavior by sending lswiPda > assuming that the server will see it as lswida? None, because P isn't a defined right. However, if we wave some mythical case-insensitivity at client authors, somebody somewhere *will* misread (or not read) this, and get very, very confused about why their rights aren't being set by the server. (Apologies for answering your rhetorical question.) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIQN5o070198; Thu, 18 Nov 2004 10:26:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIIQNp3070197; Thu, 18 Nov 2004 10:26:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIQHl0070168 for ; Thu, 18 Nov 2004 10:26:22 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAIHIE6E012489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 12:18:14 -0500 Date: Thu, 18 Nov 2004 13:26:13 -0500 From: Cyrus Daboo To: Mark Crispin , Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On November 17, 2004 14:24:30 -0800 Mark Crispin wrote: >> (Personally, I'd prefer case-*in*sensitivity - I have trouble >> remembering which case meant what, why shouldn't other people; >> but our implementations don't behave like that now.) > > This is my preference as well, and is consistant with the rest of IMAP. > > Unless there is an intent to use upper-case rights in the future to mean > something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but that > clients MUST send rights as lowercase? My client will not recognize rights from a server if they are upper case, so the server would have to send lowercase rights as well to be backwards compatible, at which point the rights are effectively case sensitive. WRT use of upper-case, I know at some point in the ACL2 debate we had talked about a simplified model of rights for 'simple' clients: e.g. 'RWX' style rights that would be tied in some well-defined way to the underlying lower case rights. So my feeling is we should reserve uppercase rights for now. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAII0vIF062326; Thu, 18 Nov 2004 10:00:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAII0v05062325; Thu, 18 Nov 2004 10:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAII0uNu062318 for ; Thu, 18 Nov 2004 10:00:57 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 18:00:57 +0000 Message-ID: <419CE358.1030107@isode.com> Date: Thu, 18 Nov 2004 18:00:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: >> Having said that I have to admit that I don't have a strong opinion >> on the issue. I would slightly prefere prohibiting uppercase rights - >> many existing clients will not treat them the same way as their >> lowercase counterparts. > > Indeed, Arnt has to start begging for mercy right now, it seems - > lswiPda is currently treated by many clients and servers as lswida. > > Cyrus IMAPd, Which is arguably a bug. > as well as every client I've examined the source for (not many) ignore > unrecognised rights, which include all uppercase ones. 2086upd requires that all clients that can do SETACL preserve unrecognized rights. For clients that only use GETACL/MYRIGHTS, it is ok to ignore unrecognized rights. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHn8B0058418; Thu, 18 Nov 2004 09:49:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIHn86E058417; Thu, 18 Nov 2004 09:49:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHn79k058401 for ; Thu, 18 Nov 2004 09:49:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 17:49:04 +0000 Message-ID: <419CE08E.3090207@isode.com> Date: Thu, 18 Nov 2004 17:49:02 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin CC: Dave Cridland , ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Thu, 18 Nov 2004, Dave Cridland wrote: > >> Therefore, we cannot make rights case-insensitive. Any attempt to do >> so would appear to create more problems than it could possibly solve. > > I don't understand why. > > You identified that there is a problem that would be caused by an > abrupt transition. So don't have an abrupt transition. This isn't > rocket science; we know how to do this. > > Simply define that any 2086upd (and ACL2) compliant server MUST have > case-insensitive rights,... > *AND* > define that servers MUST send rights as lower case (MUST NOT send rights > as upper case) > *AND* > define that clients MUST send rights as lower case (MUST NOT send > rights as upper case) to pre-2086upd servers. The 2086upd document defines a new capability, so we can do that. And the client will be able to detect pre-2086upd servers. > If there is no way for a client to detect a pre-2086upd server, then > simply remove "to pre-2086upd servers" in the last part. > > In ACL2, this can be removed entirely, at least for ACL2 only software. Yes. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1r5j022300; Thu, 18 Nov 2004 08:01:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIG1rCV022299; Thu, 18 Nov 2004 08:01:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1qu5022283 for ; Thu, 18 Nov 2004 08:01:52 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAIG1lEF024607; Thu, 18 Nov 2004 08:01:47 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iAIG1lkF008190; Thu, 18 Nov 2004 08:01:47 -0800 Date: Thu, 18 Nov 2004 08:01:47 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Alexey Melnikov , ietf-imapext@imc.org, Jutta Degener , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 18 Nov 2004, Dave Cridland wrote: > Therefore, we cannot make rights case-insensitive. Any attempt to do so would > appear to create more problems than it could possibly solve. I don't understand why. You identified that there is a problem that would be caused by an abrupt transition. So don't have an abrupt transition. This isn't rocket science; we know how to do this. Simply define that any 2086upd (and ACL2) compliant server MUST have case-insensitive rights,... *AND* define that servers MUST send rights as lower case (MUST NOT send rights as upper case) *AND* define that clients MUST send rights as lower case (MUST NOT send rights as upper case) to pre-2086upd servers. If there is no way for a client to detect a pre-2086upd server, then simply remove "to pre-2086upd servers" in the last part. In ACL2, this can be removed entirely, at least for ACL2 only software. > lswiPda is currently treated by many clients and servers as lswida. How many clients rely upon this behavior by sending lswiPda assuming that the server will see it as lswida? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFcpqe014151; Thu, 18 Nov 2004 07:38:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIFcpII014150; Thu, 18 Nov 2004 07:38:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFcjGQ014125 for ; Thu, 18 Nov 2004 07:38:46 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6BEFC154009; Thu, 18 Nov 2004 15:38:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: , Jutta Degener , Mark Crispin , Arnt Gulbrandsen Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> <419CA15D.9010300@isode.com> In-Reply-To: <419CA15D.9010300@isode.com> Message-ID: <20041118153842.21034.22999.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 15:38:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 13:19:25 2004, Alexey Melnikov wrote: > Arnt Gulbrandsen wrote: >> Mark Crispin writes: >>> On Wed, 17 Nov 2004, Jutta Degener wrote: >>> >>>> (Personally, I'd prefer case-*in*sensitivity - I have trouble >>>> remembering which case meant what, why shouldn't other people; >>>> but our implementations don't behave like that now.) >>> >>> This is my preference as well, and is consistant with the rest of >>> IMAP. >>> >>> Unless there is an intent to use upper-case rights in the future >>> to mean something different, would it be possible to transit to a >>> case insensitive regime by stating that rights are >>> case-insensitive, but that clients MUST send rights as lowercase? >> >> >> I strongly agree. It's hard enough to remember lswipda, if lswiPda >> were someday to be different I'd have to beg for mercy. Mark's >> suggestion is a good way forward, IMO. > > I remember we were using "S" as as an example, i.e. "s" controls > the private \Seen and "S" might control the shared \Seen flag. > So if we are going to allow for upper case rights, they have to be > somehow related to the corresponding lowercase ones. > > That seems fair, though we'd have to try to ensure that they followed the same relationship where possible, hence "n" would become "N", and "m" would become "n". I'm not fussed on using uppercase rights at all, though. > Having said that I have to admit that I don't have a strong opinion > on the issue. I would slightly prefere prohibiting uppercase rights > - many existing clients will not treat them the same way as their > lowercase counterparts. Indeed, Arnt has to start begging for mercy right now, it seems - lswiPda is currently treated by many clients and servers as lswida. Cyrus IMAPd, as well as every client I've examined the source for (not many) ignore unrecognised rights, which include all uppercase ones. They all appear to transform the rights string into a bitfield using code very similar to: { char * p( rights ); /* assuming rights is a char * */ unsigned rights_bitfield( 0 ); while( *p ) { switch( *p ) { case 'a': rights_bitfield |= IMAP_ACL_ADMIN; break; /* etc, without a default: */ } } } Hence unknown rights are completely ignored (good for clients, not so sure this is correct for a server) and this includes uppercase rights. Therefore, we cannot make rights case-insensitive. Any attempt to do so would appear to create more problems than it could possibly solve. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDJSFP065294; Thu, 18 Nov 2004 05:19:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIDJSQV065293; Thu, 18 Nov 2004 05:19:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDJR6O065278 for ; Thu, 18 Nov 2004 05:19:27 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 13:19:26 +0000 Message-ID: <419CA15D.9010300@isode.com> Date: Thu, 18 Nov 2004 13:19:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org, Jutta Degener , Mark Crispin Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> In-Reply-To: <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Mark Crispin writes: > >> On Wed, 17 Nov 2004, Jutta Degener wrote: >> >>> (Personally, I'd prefer case-*in*sensitivity - I have trouble >>> remembering which case meant what, why shouldn't other people; but >>> our implementations don't behave like that now.) >> >> This is my preference as well, and is consistant with the rest of IMAP. >> >> Unless there is an intent to use upper-case rights in the future to >> mean something different, would it be possible to transit to a case >> insensitive regime by stating that rights are case-insensitive, but >> that clients MUST send rights as lowercase? > > > I strongly agree. It's hard enough to remember lswipda, if lswiPda > were someday to be different I'd have to beg for mercy. Mark's > suggestion is a good way forward, IMO. I remember we were using "S" as as an example, i.e. "s" controls the private \Seen and "S" might control the shared \Seen flag. So if we are going to allow for upper case rights, they have to be somehow related to the corresponding lowercase ones. Having said that I have to admit that I don't have a strong opinion on the issue. I would slightly prefere prohibiting uppercase rights - many existing clients will not treat them the same way as their lowercase counterparts. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDGqs5064659; Thu, 18 Nov 2004 05:16:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIDGqWK064658; Thu, 18 Nov 2004 05:16:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDGkOE064563 for ; Thu, 18 Nov 2004 05:16:47 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 18 Nov 2004 13:16:38 +0000 Message-ID: <419CA0B5.7060302@isode.com> Date: Thu, 18 Nov 2004 13:16:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Lyndon Nerenberg writes: > >> Just to be Devil's Advocate: >> >> 1) Are we sure 36 rights will be enough? > > Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the > standard ever becomes that complex and finegrained, then IMO, even > sane and reasonable client developers may develop specifically for the > two most common servers. I agree that 36 rights is too much. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIB7m0J087283; Thu, 18 Nov 2004 03:07:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIB7mIJ087282; Thu, 18 Nov 2004 03:07:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAIB7l65087267 for ; Thu, 18 Nov 2004 03:07:48 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 02F091A70F; Thu, 18 Nov 2004 12:07:47 +0100 (CET) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 37B7F1A6D0; Thu, 18 Nov 2004 12:05:26 +0100 (CET) Message-Id: Date: Thu, 18 Nov 2004 12:05:05 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Lyndon Nerenberg , Jutta Degener , Mark Crispin References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg writes: > Just to be Devil's Advocate: > > 1) Are we sure 36 rights will be enough? Viewed from an i14y/testing viewpoint, 36 rights is Too Much. If the standard ever becomes that complex and finegrained, then IMO, even sane and reasonable client developers may develop specifically for the two most common servers. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIB0kBK081267; Thu, 18 Nov 2004 03:00:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIB0kcD081263; Thu, 18 Nov 2004 03:00:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAIB0f8R081082 for ; Thu, 18 Nov 2004 03:00:45 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id D70EF1A713; Thu, 18 Nov 2004 12:00:29 +0100 (CET) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 6CD4B1A6D0; Thu, 18 Nov 2004 12:00:06 +0100 (CET) Message-Id: <8kYi4XOK9VdzaFxvTSeojw.md5@prosecco.oryx.com> Date: Thu, 18 Nov 2004 11:59:45 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Cc: Jutta Degener , Mark Crispin References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Wed, 17 Nov 2004, Jutta Degener wrote: >> (Personally, I'd prefer case-*in*sensitivity - I have trouble >> remembering which case meant what, why shouldn't other people; but >> our implementations don't behave like that now.) > > This is my preference as well, and is consistant with the rest of IMAP. > > Unless there is an intent to use upper-case rights in the future to > mean something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but > that clients MUST send rights as lowercase? I strongly agree. It's hard enough to remember lswipda, if lswiPda were someday to be different I'd have to beg for mercy. Mark's suggestion is a good way forward, IMO. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIA1Hm8043547; Thu, 18 Nov 2004 02:01:17 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIA1HJF043546; Thu, 18 Nov 2004 02:01:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIA1Clv043373 for ; Thu, 18 Nov 2004 02:01:12 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 945E6154009; Thu, 18 Nov 2004 10:01:07 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: IMAP Extensions WG , Alexey Melnikov Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> In-Reply-To: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> Message-ID: <20041118100107.21034.37810.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 10:01:07 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed Nov 17 20:43:07 2004, Cyrus Daboo wrote: > --On November 17, 2004 20:27:35 +0000 Alexey Melnikov > wrote: > >>> Leave it the same as 2086 (original), but perhaps call extra >>> attention >>> to the fact that it is case-sensitive. >> >> RFC 2086 was silent on the issue. I believe the intention was to >> make >> rights case-sensitive. > > OK, well I guess we will have to find out what real implementations > did and make sure it is clear in 2086upd which way it should be. I > can tell you that my implementation treats the rights as > case-sensitive. I can tell you that Mutt and Mozilla Mail/News also both appear to treat rights as case-sensitive. I could be wrong, but it looks that way. I can't tell you what the server implementations do, although I know Cyrus IMAPd just ignores any unknown rights, including upper-case ones. I strongly suspect that everything treats them as case-sensitive. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9I8jA009463; Thu, 18 Nov 2004 01:18:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI9I8Bn009462; Thu, 18 Nov 2004 01:18:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9I3R9009072 for ; Thu, 18 Nov 2004 01:18:07 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 09C82154009; Thu, 18 Nov 2004 09:17:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Lyndon Nerenberg Cc: IMAP Extensions WG , Mark Crispin Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> In-Reply-To: <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> Message-ID: <20041118091742.21034.59915.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 18 Nov 2004 09:17:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Nov 18 02:18:55 2004, Lyndon Nerenberg wrote: > > --On 2004-11-17 5:58 PM -0800 Mark Crispin > wrote: > >> If we aren't certain, is it a mistake to have single-character >> rights? > > Not if they are UTF-8 characters :-P > > Rights are defined in 2086 as US-ASCII. Nice try, though. :-) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI2JGWl078805; Wed, 17 Nov 2004 18:19:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI2JGWk078804; Wed, 17 Nov 2004 18:19:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI2JFaZ078796 for ; Wed, 17 Nov 2004 18:19:15 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAI2IuOl057511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 19:18:59 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 17 Nov 2004 18:18:55 -0800 From: Lyndon Nerenberg To: Mark Crispin cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <2894D1F8EF4BD29E6CCB494D@peregrin.orthanc.ca> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-MessageCare-Metrics: orthanc.ca 1108; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-17 5:58 PM -0800 Mark Crispin wrote: > If we aren't certain, is it a mistake to have single-character rights? Not if they are UTF-8 characters :-P > I agree that, because 2086 rights are an , IMAP's case > folding rules do not require 2806 rights to be case insensitive. I > disagree with your conclusion that they are required to be case > sensitive. I consider IMAP to be silent on this point. But I defer to ABNF, where everything is case-sensitive unless explicitly stated otherwise. (Yes, ACL predates ABNF spec.) No matter, I'm just issuing a heads-up. I won't go non-linear if case-folding is the consensus. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI20ncj071869; Wed, 17 Nov 2004 18:00:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI20nfH071868; Wed, 17 Nov 2004 18:00:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI20mGk071862 for ; Wed, 17 Nov 2004 18:00:48 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAI20sJP004966; Wed, 17 Nov 2004 18:00:54 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAI20r3I015178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2004 18:00:53 -0800 Date: Wed, 17 Nov 2004 17:58:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Lyndon Nerenberg cc: Jutta Degener , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 17 Nov 2004, Lyndon Nerenberg wrote: > 1) Are we sure 36 rights will be enough? I don't know. Are we? If we aren't certain, is it a mistake to have single-character rights? > 2) is not case-folded. Since are an I would > argue that MUST be case sensitive. (Nothing in 2086 calls out for > case-folding, therefore it cannot be assumed by any conforming > implementation.) I agree that, because 2086 rights are an , IMAP's case folding rules do not require 2806 rights to be case insensitive. I disagree with your conclusion that they are required to be case sensitive. I consider IMAP to be silent on this point. However, as the original architect of IMAP, I consider it to be a mistake that rights are an astring as opposed to an atom equivalent. That is, I think that it would have been closer to the "spirit of IMAP" if it were something like: mod_rights ::= ["+" / "-"] rights rights ::= 1*right / "-" right ::= ALPHA / DIGIT ; Case-insensitive where "-" means "empty rights", or (if 36 rights aren't enough): rights ::= 1*right / nil right ::= atom In fact, if it weren't for the "chattiness" objections that are commonly made about IMAP, I would consider the latter to be the True IMAP Way. However, I am just mumbling here. I am not seriously suggesting that it be changed at this late date, so everybody please lower your hackles... :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI1f1qk065366; Wed, 17 Nov 2004 17:41:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI1f1BC065365; Wed, 17 Nov 2004 17:41:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI1eufm065315 for ; Wed, 17 Nov 2004 17:40:56 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iAI1eTGh054684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 18:40:34 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 17 Nov 2004 17:40:29 -0800 From: Lyndon Nerenberg To: Mark Crispin , Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <19E9983F44E0DB208CAC46EE@peregrin.orthanc.ca> In-Reply-To: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-MessageCare-Metrics: orthanc.ca 1108; Body=3 Fuz1=3 Fuz2=3 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-17 2:24 PM -0800 Mark Crispin wrote: > Unless there is an intent to use upper-case rights in the future to > mean something different, would it be possible to transit to a case > insensitive regime by stating that rights are case-insensitive, but > that clients MUST send rights as lowercase? Just to be Devil's Advocate: 1) Are we sure 36 rights will be enough? 2) is not case-folded. Since are an I would argue that MUST be case sensitive. (Nothing in 2086 calls out for case-folding, therefore it cannot be assumed by any conforming implementation.) --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMQX2V073718; Wed, 17 Nov 2004 14:26:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHMQXAn073715; Wed, 17 Nov 2004 14:26:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMQWcv073678 for ; Wed, 17 Nov 2004 14:26:32 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iAHMQZmh014306; Wed, 17 Nov 2004 14:26:35 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.11) with ESMTP id iAHMQXWB011659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2004 14:26:34 -0800 Date: Wed, 17 Nov 2004 14:24:30 -0800 (Pacific Standard Time) From: Mark Crispin To: Jutta Degener cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt In-Reply-To: <20041117221610.GA3376@jutta.sendmail.com> Message-ID: References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> <20041117221610.GA3376@jutta.sendmail.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 17 Nov 2004, Jutta Degener wrote: > (Personally, I'd prefer case-*in*sensitivity - I have trouble > remembering which case meant what, why shouldn't other people; > but our implementations don't behave like that now.) This is my preference as well, and is consistant with the rest of IMAP. Unless there is an intent to use upper-case rights in the future to mean something different, would it be possible to transit to a case insensitive regime by stating that rights are case-insensitive, but that clients MUST send rights as lowercase? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMGGfV070130; Wed, 17 Nov 2004 14:16:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHMGGYb070129; Wed, 17 Nov 2004 14:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from jutta.sendmail.com (natted.sendmail.com [63.211.143.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMGFZk070097 for ; Wed, 17 Nov 2004 14:16:15 -0800 (PST) (envelope-from jutta@sendmail.com) Received: by jutta.sendmail.com (Postfix, from userid 500) id 5DD3C179BB; Wed, 17 Nov 2004 14:16:10 -0800 (PST) Date: Wed, 17 Nov 2004 14:16:10 -0800 From: Jutta Degener To: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <20041117221610.GA3376@jutta.sendmail.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Nov 17, 2004 at 03:43:07PM -0500, Cyrus Daboo wrote: > OK, well I guess we will have to find out what real implementations did and > make sure it is clear in 2086upd which way it should be. I can tell you > that my implementation treats the rights as case-sensitive. Sendmail's does, too. (Personally, I'd prefer case-*in*sensitivity - I have trouble remembering which case meant what, why shouldn't other people; but our implementations don't behave like that now.) Jutta Degener Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKh4YR038476; Wed, 17 Nov 2004 12:43:04 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKh4JD038475; Wed, 17 Nov 2004 12:43:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKh38K038469 for ; Wed, 17 Nov 2004 12:43:04 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAHJZG6E017581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 14:35:17 -0500 Date: Wed, 17 Nov 2004 15:43:07 -0500 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <223A1BB78C77F414369D0D50@ninevah.cyrusoft.com> In-Reply-To: <419BB437.2090500@isode.com> References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> <419BB437.2090500@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On November 17, 2004 20:27:35 +0000 Alexey Melnikov wrote: >> Leave it the same as 2086 (original), but perhaps call extra attention >> to the fact that it is case-sensitive. > > RFC 2086 was silent on the issue. I believe the intention was to make > rights case-sensitive. OK, well I guess we will have to find out what real implementations did and make sure it is clear in 2086upd which way it should be. I can tell you that my implementation treats the rights as case-sensitive. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKRicq032324; Wed, 17 Nov 2004 12:27:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKRidb032323; Wed, 17 Nov 2004 12:27:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKRhQB032308 for ; Wed, 17 Nov 2004 12:27:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 20:27:35 +0000 Message-ID: <419BB437.2090500@isode.com> Date: Wed, 17 Nov 2004 20:27:35 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt References: <419BA218.4050000@isode.com> <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> In-Reply-To: <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi Alexey, > > --On November 17, 2004 19:10:16 +0000 Alexey Melnikov > wrote: > >> The document says that all rights are case-sensitive, i.e. "r" is not >> the >> same as "R". Is this is problem? >> Currently there are not uppercase rights assigned. > > Leave it the same as 2086 (original), but perhaps call extra attention > to the fact that it is case-sensitive. RFC 2086 was silent on the issue. I believe the intention was to make rights case-sensitive. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKPXnI031471; Wed, 17 Nov 2004 12:25:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKPXBg031470; Wed, 17 Nov 2004 12:25:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKPRIW031405 for ; Wed, 17 Nov 2004 12:25:32 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAHJHZ6E017221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 14:17:36 -0500 Date: Wed, 17 Nov 2004 15:25:26 -0500 From: Cyrus Daboo To: Alexey Melnikov , IMAP Extensions WG Subject: Re: One remaining issue in draft-ietf-imapext-2086upd-01.txt Message-ID: <7299D938E6EC6AF1FAF9633F@ninevah.cyrusoft.com> In-Reply-To: <419BA218.4050000@isode.com> References: <419BA218.4050000@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On November 17, 2004 19:10:16 +0000 Alexey Melnikov wrote: > The document says that all rights are case-sensitive, i.e. "r" is not the > same as "R". Is this is problem? > Currently there are not uppercase rights assigned. Leave it the same as 2086 (original), but perhaps call extra attention to the fact that it is case-sensitive. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJAGdq097620; Wed, 17 Nov 2004 11:10:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHJAGXL097618; Wed, 17 Nov 2004 11:10:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJAFTH097608 for ; Wed, 17 Nov 2004 11:10:15 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 19:10:17 +0000 Message-ID: <419BA218.4050000@isode.com> Date: Wed, 17 Nov 2004 19:10:16 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: One remaining issue in draft-ietf-imapext-2086upd-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document says that all rights are case-sensitive, i.e. "r" is not the same as "R". Is this is problem? Currently there are not uppercase rights assigned. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHIBZ42077582; Wed, 17 Nov 2004 10:11:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHIBZ8A077581; Wed, 17 Nov 2004 10:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHIBTtI077557 for ; Wed, 17 Nov 2004 10:11:30 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 18:11:21 +0000 Message-ID: <419B9448.4040009@isode.com> Date: Wed, 17 Nov 2004 18:11:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: 2086upd + ANNOTATE dependency References: <4198FB05.40007@oceana.com> In-Reply-To: <4198FB05.40007@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Cyrus Daboo wrote: > >> What I propose is to remove all references to ANNOTATE in 2086upd. >> The ANNOTATE document will define the new ACL bits and have a >> normative reference to 2086upd. That way 2086upd can progress quickly >> without being blocked on ANNOTATE (which itself is blocked on >> SORT/THREAD/i18n). > > Agreed. If we are going this route, the ANNOTATE document must be updated to say that the "n" right (writing shared annotations) is a part of the "shared flag rights" as defined in section 5.2 of the 2086upd ("Mapping of ACL rights to READ-WRITE and READ-ONLY response codes"). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHECPpe096743; Wed, 17 Nov 2004 06:12:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHECPsR096742; Wed, 17 Nov 2004 06:12:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHECJ90096595 for ; Wed, 17 Nov 2004 06:12:23 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id DF45B154009; Wed, 17 Nov 2004 14:12:06 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG , Philip Guenther Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> In-Reply-To: <41991116.9010001@oceana.com> Message-ID: <20041117141206.21034.10575.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Wed, 17 Nov 2004 14:12:06 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 15 20:27:02 2004, Ken Murchison wrote: > Interop with both old and new clients will be a problem. I don't > have all of the answers yet, I'd have to discuss this with the > other Cyrus guys to see if we can work out a solution. I'm just > pointing out that the current wording in the draft doesn't work > with all implementations. My initial thought was that you'd be right, for two reasons: 1) Client authors may have independently made the same interpretation. 2) Client authors may have deliberately copied Cyrus IMAPd's interpretation, given that it's a widely known and used RFC2086 server implementation. To see if this was the case, I decided to read through several IMAP client implementations. My overall assumption was that open-sourced implementations would be most likely to show (2) above, and hence would be visible and a reasonable sample. I looked for two key features of the code: a) A suppression of the UI for folder deletion based on MYRIGHTS output. b) A suppression of actual deletion based on MYRIGHTS output. I read through the source code for Balsa, Mutt, and Mozilla. I have found no evidence for either happening. I'm also told that Evolution doesn't support RFC2086 at all. Documentation for APIs, however, suggests differently. Both Sun's JavaMail documentation and perl's IMAP::Admin module documentation makes the claim that the "c" right allows for DELETE (and RENAME) on submailboxes. Communigate Pro's documentation states that deleting a mailbox requires both the "c" right on the parent *and* the "d" right on the mailbox itself. Incidentally, Cyrus's major problem is that the "x" right needs to be granted, as I understand it, on all submailboxes of a parent which has the "c" right - "c" cannot therefore be a macro for "kx", where "k" is for CREATE (and is the current "c"). I have no real conclusions about this - I'd be interested in knowing what any other clients are doing. My general feeling is that the current draft can stand, but I'd appreciate knowing a little more about other implementations. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGLDM0M021788; Tue, 16 Nov 2004 13:13:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGLDMOF021787; Tue, 16 Nov 2004 13:13:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGLDLZo021774 for ; Tue, 16 Nov 2004 13:13:22 -0800 (PST) (envelope-from rbunch@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14669; Tue, 16 Nov 2004 16:13:24 -0500 (EST) Message-Id: <200411162113.QAA14669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-2086upd-01.txt Date: Tue, 16 Nov 2004 16:13:24 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension - updated list of rights Author(s) : A. Melnikov Filename : draft-ietf-imapext-2086upd-01.txt Pages : 0 Date : 2004-11-16 The ACL (Access Control List) extension [RFC2086] of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. This document updates the list of rights defined in RFC 2086. It also clarifies which rights are required for different IMAP commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-2086upd-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-2086upd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-2086upd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-16113044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-2086upd-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-2086upd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113044.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMbOQX033306; Mon, 15 Nov 2004 14:37:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMbOb6033305; Mon, 15 Nov 2004 14:37:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMbKX7033287 for ; Mon, 15 Nov 2004 14:37:20 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 781D6960B; Mon, 15 Nov 2004 17:37:24 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id 0E85A29F8B; Mon, 15 Nov 2004 17:37:21 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CTpT5-000P0y-6J; Mon, 15 Nov 2004 22:37:03 +0000 Date: Mon, 15 Nov 2004 22:37:03 +0000 From: Brian Candler To: Ken Murchison Cc: Philip Guenther , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) Message-ID: <20041115223703.GA96108@uk.tiscali.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> <41991116.9010001@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41991116.9010001@oceana.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 03:27:02PM -0500, Ken Murchison wrote: > >So, would > >there be any way at all for the user of an old client to set or clear > >the "x" right? If setting or clearing the "c" right was to also affect > >the "x" right then how would a new (RIGHTS-aware) client set or clear > >the "c" right without affecting the "x" right? > > Interop with both old and new clients will be a problem. I don't have > all of the answers yet, I'd have to discuss this with the other Cyrus > guys to see if we can work out a solution. I'm just pointing out that > the current wording in the draft doesn't work with all implementations. > > One easy way to do this might be to make 'c' a macro in the new draft > just like 'd' and create a new bit for CREATE (e.g. 'k') Then the > mapping would be: > > Cyrus: 'c' -> "kx", 'd' -> "te" > Others: 'c' -> "k", 'd' -> "xte" Would it be a problem to make 'd' more permissive? Let me think aloud. For example: imagine for a moment that c and x are tied (which is in effect the current behaviour of Cyrus, IIUC) Now, suppose we defined the 'd' right as implying e,t,x plus any rights tied to those rights. Then if a client asked for 'd' they would get e+t+x+c. Now: a client which asks for 'd' (intending "delete or expunge mail") will find themselves also getting create submailbox and delete mailbox rights. I don't know if Cyrus has any policy engine which lets you control which rights requests are granted or refused; if it doesn't, then the worst that will happen is that the person administering the ACL will end up adding more rights to a particular user than they intended. And that will only happen if the software used to set up the ACL only understands RFC2086 flags. So what am I proposing? Maybe that the 'd' flag implies 'e','t','x' plus any other flags that the implementation considers necessary. Or maybe that the 'd' flag implies *any* implementation-defined set of flags, but where the recommended set is 'e','t' and 'x'; the goal being that the virtual 'd' flag implies whatever set of flags is necessary so that the client has no fewer rights than they would have had before when asking for 'd'. That's fine; then the problem with Cyrus is that if you ask for 'c', you still get fewer rights than you would have had before when asking for 'c'. If the client understand RFC-2086upd then it can ask for 'x'; if not then it can ask for 'd', although it will end up with perhaps more rights than are needed. Of course, if you are migrating from Cyrus version X (RFC-2086) to version Y (RFC-2086upd), then any existing mailbox rights can be changed as part of this migration. i.e. c becomes cx, d becomes xte. So this will only really affect *ACL administrators* who are using *RFC-2086 clients* which also *do not use LISTRIGHTS* to present the possible rights available to the end-user. Oh well, enough thinking aloud, as I don't seem to be getting very far :-) Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKPvQo098955; Mon, 15 Nov 2004 12:25:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFKPvfD098954; Mon, 15 Nov 2004 12:25:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKPucb098913 for ; Mon, 15 Nov 2004 12:25:56 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFKPr3d015432; Mon, 15 Nov 2004 15:25:53 -0500 (EST) Message-ID: <41991116.9010001@oceana.com> Date: Mon, 15 Nov 2004 15:27:02 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> <200411151957.iAFJvF66074656@lab.smi.sendmail.com> In-Reply-To: <200411151957.iAFJvF66074656@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: > Ken Murchison writes: > ... > >>>The difference would be that the client would be required to request both >>>"c" and "x" in order to set this bit; but it would know that is necessary if >>>it made use of the LISTRIGHTS information which indicated they were tied. >> >>We don't want to do this. Spitting 'x' from 'c' is a migration issue >>specific to Cyrus, which we will have to handle. As soon as we >>implement this update any existing ACL which has "c" will have to be >>reported as "cx". The 'x' right will then have to be explicitly removed. > > > ...if they don't want the user to have both rights but only create. > > ... > >>My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', >>which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server >>shouldn't have to set 'x' (because the draft says MUST) if it doesn't >>apply. I have no problem with 'd' being a macro for 'e' and 't', but >>whether this macro also includes 'd' should be implementation specific. > > > So you're proposing that an implementation (Cyrus) be allowed to not > set/clear the "x" right when the "d" right is set/cleared. Yes. The draft makes the false assumption that *all* existing implementations use the 'd' right to control DELETE. Cyrus made the decision a while back to separate mailbox ops (DELETE) from message ops (\Deleted and EXPUNGE). Its unfortunate that RFC 2086 was vague/ambiguous w.r.t. DELETE. > So, would > there be any way at all for the user of an old client to set or clear > the "x" right? If setting or clearing the "c" right was to also affect > the "x" right then how would a new (RIGHTS-aware) client set or clear > the "c" right without affecting the "x" right? Interop with both old and new clients will be a problem. I don't have all of the answers yet, I'd have to discuss this with the other Cyrus guys to see if we can work out a solution. I'm just pointing out that the current wording in the draft doesn't work with all implementations. One easy way to do this might be to make 'c' a macro in the new draft just like 'd' and create a new bit for CREATE (e.g. 'k') Then the mapping would be: Cyrus: 'c' -> "kx", 'd' -> "te" Others: 'c' -> "k", 'd' -> "xte" -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJvCfp091730; Mon, 15 Nov 2004 11:57:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFJvCO6091729; Mon, 15 Nov 2004 11:57:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJvCqa091710 for ; Mon, 15 Nov 2004 11:57:12 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFJvFJN011892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 11:57:16 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFJvFJN011892 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=QnKFF6ckyo+Od+D5eWNfpqibg9ztg3IS16amjEVSqjI24Lcpk60mIMm9yR9GJYklE VyapK0zGTQ0lOIPbnlexS/kCAk1svJo5CGiRNxVEseNBgbHPA92R/ngvOtPVHPA807L qSBLbmNSCMucxIiT+/DrTs4jJ+KQ3pzXR8Xoe6A= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFJvF66074656; Mon, 15 Nov 2004 11:57:15 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151957.iAFJvF66074656@lab.smi.sendmail.com> To: Ken Murchison Cc: Brian Candler , Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) In-reply-to: <419901B0.5080808@oceana.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> <419901B0.5080808@oceana.com> Date: Mon, 15 Nov 2004 11:57:15 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison writes: ... >> The difference would be that the client would be required to request both >> "c" and "x" in order to set this bit; but it would know that is necessary if >> it made use of the LISTRIGHTS information which indicated they were tied. > >We don't want to do this. Spitting 'x' from 'c' is a migration issue >specific to Cyrus, which we will have to handle. As soon as we >implement this update any existing ACL which has "c" will have to be >reported as "cx". The 'x' right will then have to be explicitly removed. ...if they don't want the user to have both rights but only create. ... >My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', >which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server >shouldn't have to set 'x' (because the draft says MUST) if it doesn't >apply. I have no problem with 'd' being a macro for 'e' and 't', but >whether this macro also includes 'd' should be implementation specific. So you're proposing that an implementation (Cyrus) be allowed to not set/clear the "x" right when the "d" right is set/cleared. So, would there be any way at all for the user of an old client to set or clear the "x" right? If setting or clearing the "c" right was to also affect the "x" right then how would a new (RIGHTS-aware) client set or clear the "c" right without affecting the "x" right? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJKFHj080940; Mon, 15 Nov 2004 11:20:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFJKFbe080939; Mon, 15 Nov 2004 11:20:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFJKFpV080919 for ; Mon, 15 Nov 2004 11:20:15 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFJKBGr014082; Mon, 15 Nov 2004 14:20:11 -0500 (EST) Message-ID: <419901B0.5080808@oceana.com> Date: Mon, 15 Nov 2004 14:21:20 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Brian Candler CC: Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> <20041115183222.GA95559@uk.tiscali.com> In-Reply-To: <20041115183222.GA95559@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler wrote: > On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote: > >>I think we need to add language that says that 'x' must be associated >>with whichever ACL bit was previously used for DELETE, and not assume >>that its 'd'. > > > I'm not sure there is a problem, because RFC2086 explicitly allows the > server to tie together whichever bits it likes in whichever way is > convenient to it: > > An implementation may tie rights together or may force rights to > always or never be granted to particular identifiers. For example, > in an implementation that uses unix mode bits, the rights "wisd" are > tied, the "a" right is always granted to the owner of a mailbox and > is never granted to another user. If rights are tied in an > implementation, the implementation must be conservative in granting > rights in response to SETACL commands--unless all rights in a tied > set are specified, none of that set should be included in the ACL > entry for that identifier. A client may discover the set of rights > which may be granted to a given identifier in the ACL for a given > mailbox by using the LISTRIGHTS command. I'm fully aware of this, but we don't want to tie any rights together. That's the whole point of the new specs. > So in Cyrus you can have a single bit internally, which (if set) is reported > to the client as "cx". We already have one and its 'c'. > The difference would be that the client would be required to request both > "c" and "x" in order to set this bit; but it would know that is necessary if > it made use of the LISTRIGHTS information which indicated they were tied. We don't want to do this. Spitting 'x' from 'c' is a migration issue specific to Cyrus, which we will have to handle. As soon as we implement this update any existing ACL which has "c" will have to be reported as "cx". The 'x' right will then have to be explicitly removed. > Now, "d" being an alias for e+t+x is a bit of a special case. But at least > it is a single, well-defined special case; and also note that "d" is not a > real bit in its own right, but a virtual bit synthesised from (e && t && x). > I can't see a clean way to do what you seem to be suggesting, which is to > associate "x" with another bit, apart from the mechanism which is already > there which allows bits to be tied together. > > Can you be more specific on what you are proposing? My problem is that the draft assumes that 'x' is a "sub-ACL" of 'd', which is not the case in Cyrus. If a user sets 'd' in Cyrus, the server shouldn't have to set 'x' (because the draft says MUST) if it doesn't apply. I have no problem with 'd' being a macro for 'e' and 't', but whether this macro also includes 'd' should be implementation specific. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIptXq073519; Mon, 15 Nov 2004 10:51:55 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFIptIA073518; Mon, 15 Nov 2004 10:51:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIpnvN073454 for ; Mon, 15 Nov 2004 10:51:50 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFIpiON013428; Mon, 15 Nov 2004 13:51:44 -0500 (EST) Message-ID: <4198FB05.40007@oceana.com> Date: Mon, 15 Nov 2004 13:52:53 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: 2086upd + ANNOTATE dependency References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > What I propose is to remove all references to ANNOTATE in 2086upd. The > ANNOTATE document will define the new ACL bits and have a normative > reference to 2086upd. That way 2086upd can progress quickly without > being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n). Agreed. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIWXgB069431; Mon, 15 Nov 2004 10:32:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFIWX9l069430; Mon, 15 Nov 2004 10:32:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFIWWEZ069424 for ; Mon, 15 Nov 2004 10:32:32 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 01044ADC73; Mon, 15 Nov 2004 13:32:36 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 9C07C419B28; Mon, 15 Nov 2004 13:32:33 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CTleI-000Ort-6n; Mon, 15 Nov 2004 18:32:22 +0000 Date: Mon, 15 Nov 2004 18:32:22 +0000 From: Brian Candler To: Ken Murchison Cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) Message-ID: <20041115183222.GA95559@uk.tiscali.com> References: <418C19CC.3030600@isode.com> <4198EB4A.7020604@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4198EB4A.7020604@oceana.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 12:45:46PM -0500, Ken Murchison wrote: > I think we need to add language that says that 'x' must be associated > with whichever ACL bit was previously used for DELETE, and not assume > that its 'd'. I'm not sure there is a problem, because RFC2086 explicitly allows the server to tie together whichever bits it likes in whichever way is convenient to it: An implementation may tie rights together or may force rights to always or never be granted to particular identifiers. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. So in Cyrus you can have a single bit internally, which (if set) is reported to the client as "cx". The difference would be that the client would be required to request both "c" and "x" in order to set this bit; but it would know that is necessary if it made use of the LISTRIGHTS information which indicated they were tied. Now, "d" being an alias for e+t+x is a bit of a special case. But at least it is a single, well-defined special case; and also note that "d" is not a real bit in its own right, but a virtual bit synthesised from (e && t && x). I can't see a clean way to do what you seem to be suggesting, which is to associate "x" with another bit, apart from the mechanism which is already there which allows bits to be tied together. Can you be more specific on what you are proposing? Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHlarv059125; Mon, 15 Nov 2004 09:47:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFHla0L059121; Mon, 15 Nov 2004 09:47:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHlVak059070 for ; Mon, 15 Nov 2004 09:47:35 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAFGe06E014843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Nov 2004 11:40:02 -0500 Date: Mon, 15 Nov 2004 12:47:31 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: 2086upd + ANNOTATE dependency Message-ID: X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should 2086upd mention ANNOTATE at all? Right now it does define the 'n' right but has very little to say about it, other than providing the informative reference to ANNOTATE. That reference really ought to be normative since the meaning of 'n' (and 'm') are important. However, this adds a two-way dependency between 2086upd and ANNOTATE. What I propose is to remove all references to ANNOTATE in 2086upd. The ANNOTATE document will define the new ACL bits and have a normative reference to 2086upd. That way 2086upd can progress quickly without being blocked on ANNOTATE (which itself is blocked on SORT/THREAD/i18n). -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHif5l058419; Mon, 15 Nov 2004 09:44:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFHifaf058418; Mon, 15 Nov 2004 09:44:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFHieM2058397 for ; Mon, 15 Nov 2004 09:44:40 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFHibBG011904; Mon, 15 Nov 2004 12:44:37 -0500 (EST) Message-ID: <4198EB4A.7020604@oceana.com> Date: Mon, 15 Nov 2004 12:45:46 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Updated draft-ietf-imapext-2086upd (ACL) References: <418C19CC.3030600@isode.com> In-Reply-To: <418C19CC.3030600@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just noticed something in this draft, and ACL2 for that matter, which may cause problems with Cyrus. The draft seems to assume that the old 'd' right was used to allow the DELETE command, where RFC 2086 was vague on this (in fact it never mentions DELETE or RENAME). All current Cyrus code uses the 'c' right for both CREATE and DELETE. So for Cyrus, associating the new 'x' right with 'd' doesn't make any sense, it would probably be associated with 'c'. I think we need to add language that says that 'x' must be associated with whichever ACL bit was previously used for DELETE, and not assume that its 'd'. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFH7BZg043812; Mon, 15 Nov 2004 09:07:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFH7Bt2043809; Mon, 15 Nov 2004 09:07:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFH7A6t043735 for ; Mon, 15 Nov 2004 09:07:10 -0800 (PST) (envelope-from ken@oceana.com) Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.1/8.13.1) with ESMTP id iAFH74CF010916; Mon, 15 Nov 2004 12:07:05 -0500 (EST) Message-ID: <4198E27D.8060704@oceana.com> Date: Mon, 15 Nov 2004 12:08:13 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP Extensions WG CC: Alexey Melnikov Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> <4198A4EA.8090901@isode.com> <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: > > On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote: > >> Alexey Melnikov wrote: >> >>> The second issue: >>> >>> Which rights are required for the LISTRIGHTS command? >>> >>> Currently the document says: >>> >>> MYRIGHTS - any of the following rights is required to perform >>> the operation: "l", "r", "i", "c", "x", "a".* >>> >>> LISTRIGHTS - same as MYRIGHTS. >>> >>> Some of the existing servers follow this suggestion. Some allow for >>> LISTRIGHTS if "r" and/or "a" is granted. >>> >>> Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" >>> right is granted, as LISTRIGHTS information is only useful >>> if you can also do SETACL. Also, such information shouldn't be disclosed >>> to users that have insufficient rights. >> >> >> So, any comments on changing LISTRIGHTS to require the "a" right? > > > As a client implementor of sorts, I can't see any reason for using > LISTRIGHTS if I didn't intend to use the results to frame a SETACL or > DELETEACL. > > Hence I'm in agreement - make it require "a". I'm also in agreement. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGpion033954; Mon, 15 Nov 2004 08:51:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGpict033953; Mon, 15 Nov 2004 08:51:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGphKv033937 for ; Mon, 15 Nov 2004 08:51:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 16:51:41 +0000 Message-ID: <4198DE9B.3080206@isode.com> Date: Mon, 15 Nov 2004 16:51:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198A1EB.3040107@isode.com> <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> In-Reply-To: <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Alexey Melnikov writes: > > >>Philip Guenther wrote: >> >> >>>Please review the 2086upd draft as soon as possible, as it should be >>>going to working group last call Real Soon Now. Only one substantive >>>change was discussed at the IETF meeting last week: instead of returning >>>a MYRIGHTS response, the SELECT command should return a MYRIGHTS >>>response _code_. So, for example, this line from the SELECT example in >>>section 7.1.1: >>> S: * MYRIGHTS INBOX rwis >>>will end up instead reading: >>> S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights >>> >>> >>The ACL2 document defines MYRIGHTS response code, but it doesn't include >>a mailbox name. Is it Ok? >> >> > >So it should instead read: > S: * OK [MYRIGHTS rwis] No more, no less > > >The Formal Syntax needs to define the syntax for that as an extension of >resp-text-code: > >resp-text-code =/ myrights_rspcod > >myrights_rspcod = "MYRIGHTS" SP rights > >rights = atom > ;; MUST NOT contain leading "+" or "-" > ;; MUST be treated as case-sensitive > >Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights. >Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no >point in allowing them here in the MYRIGHTS response code. > > I agree. >The UTF-8 reference should be updated the RFC 3629. > Done. >It should be noted >somewhere that an identifier containing non-US-ASCII characters MUST be >represented as a literal and not a quoted-string or atom. > > This just follows from rules for literals defined in RFC 3501. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGiqEU029170; Mon, 15 Nov 2004 08:44:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGiqGv029169; Mon, 15 Nov 2004 08:44:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGipGR028947 for ; Mon, 15 Nov 2004 08:44:51 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id BC703154009; Mon, 15 Nov 2004 16:44:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> <4198A4EA.8090901@isode.com> In-Reply-To: <4198A4EA.8090901@isode.com> Message-ID: <20041115164433.14132.67958.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 15 Nov 2004 16:44:33 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 15 12:45:30 2004, Alexey Melnikov wrote: > Alexey Melnikov wrote: >> The second issue: >> >> Which rights are required for the LISTRIGHTS command? >> >> Currently the document says: >> >> MYRIGHTS - any of the following rights is required to perform >> the operation: "l", "r", "i", "c", "x", "a".* >> >> LISTRIGHTS - same as MYRIGHTS. >> >> Some of the existing servers follow this suggestion. Some allow for >> LISTRIGHTS if "r" and/or "a" is granted. >> >> Philip has suggested (and I agree) to only allow LISTRIGHTS when >> the "a" >> right is granted, as LISTRIGHTS information is only useful >> if you can also do SETACL. Also, such information shouldn't be >> disclosed >> to users that have insufficient rights. > > So, any comments on changing LISTRIGHTS to require the "a" right? As a client implementor of sorts, I can't see any reason for using LISTRIGHTS if I didn't intend to use the results to frame a SETACL or DELETEACL. Hence I'm in agreement - make it require "a". Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGHiap011154; Mon, 15 Nov 2004 08:17:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFGHiZi011153; Mon, 15 Nov 2004 08:17:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFGHien011144 for ; Mon, 15 Nov 2004 08:17:44 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFGHkqD000912 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 08:17:46 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFGHkqD000912 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cqCuL+jI5NDsrSRXmzldN/pcQl4ybC0Z2zZo3umE++1q4GFWeI36wjlO+X//xGrLe 9pCxn/p1hUgMo3lx/3Fxq1X/yokfV3oNSfY04FJKbdlIdmKZEOQct3FWX1JOf/pMu+C C3vxtdupT616+NxPVADOsH8LrMbLdnxTH9Ho3uY= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFGHkZa056209; Mon, 15 Nov 2004 08:17:46 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151617.iAFGHkZa056209@lab.smi.sendmail.com> To: Alexey Melnikov From: Philip Guenther Cc: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <4198A1EB.3040107@isode.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198A1EB.3040107@isode.com> Date: Mon, 15 Nov 2004 08:17:46 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: >>Please review the 2086upd draft as soon as possible, as it should be >>going to working group last call Real Soon Now. Only one substantive >>change was discussed at the IETF meeting last week: instead of returning >>a MYRIGHTS response, the SELECT command should return a MYRIGHTS >>response _code_. So, for example, this line from the SELECT example in >>section 7.1.1: >> S: * MYRIGHTS INBOX rwis >>will end up instead reading: >> S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights > >The ACL2 document defines MYRIGHTS response code, but it doesn't include >a mailbox name. Is it Ok? So it should instead read: S: * OK [MYRIGHTS rwis] No more, no less The Formal Syntax needs to define the syntax for that as an extension of resp-text-code: resp-text-code =/ myrights_rspcod myrights_rspcod = "MYRIGHTS" SP rights rights = atom ;; MUST NOT contain leading "+" or "-" ;; MUST be treated as case-sensitive Hmm, interesting: ACL2 used 'quoted' instead of 'atom' for rights. Since a non-ATOM-CHAR right can't appear in the RIGHT=... capability, no point in allowing them here in the MYRIGHTS response code. The UTF-8 reference should be updated the RFC 3629. It should be noted somewhere that an identifier containing non-US-ASCII characters MUST be represented as a literal and not a quoted-string or atom. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFaSI9089145; Mon, 15 Nov 2004 07:36:28 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFFaStQ089143; Mon, 15 Nov 2004 07:36:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFaRHo089134 for ; Mon, 15 Nov 2004 07:36:27 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAFFaTB7021481 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 Nov 2004 07:36:29 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAFFaTB7021481 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=k2/fDOdtDxxd/64Mf9yct2Ge/sUHAwXGQ6maOF4v0cw/MjcbnaxXBVjcxydaSIGBN IJm5HmTeem3ISDgJrFRUgQtqUt9FP73r0TMKNLVt2qDOU0kse+92S1yF/Z4TO6JQ9C2 5MJQXQpuz/EgXf3SlVmddjh8AUO+dcFEmM6Y0fQ= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAFFaS7i053352; Mon, 15 Nov 2004 07:36:28 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411151536.iAFFaS7i053352@lab.smi.sendmail.com> To: Brian Candler Cc: Alexey Melnikov , ietf-imapext@imc.org From: Philip Guenther Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <20041115143919.GC65701@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198B5E1.4070405@isode.com> <20041115143919.GC65701@uk.tiscali.com> Date: Mon, 15 Nov 2004 07:36:28 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler writes: ... >I don't think it need be so complicated; how about just > > If a client includes the "d" right in a rights list, then it is to be > treated as if the client had included the "x", "e" and "t" rights. > >(You could add: It is not an error for a client to specify both "d" and one >or more of "x", "e" and "t", but the effect no different than if just "d" or >all of "x", "e" and "t" had been specified) I like this wording, including the parenthetical addition. ... >I don't like the wording "clears the "d" right from a rights list", because >IIUC you can't ask for individual flags to be set or cleared; you can only >ask for the entire set of flags to be replaced with a new set. ... If the third argument to SETACL starts with a "+" or "-" then it is a modification to the existing rights for that identifier and not a complete replacement. I think your wording above covers that sufficiently by virtue of not referring to the operation at all. Less is more... Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEdasF072977; Mon, 15 Nov 2004 06:39:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFEdajI072976; Mon, 15 Nov 2004 06:39:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gold.pobox.com (gold.pobox.com [208.210.124.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFEdZ2L072960 for ; Mon, 15 Nov 2004 06:39:35 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from gold (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id 65A589624; Mon, 15 Nov 2004 09:39:33 -0500 (EST) Received: from thinkdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gold.sasl.smtp.pobox.com (Postfix) with ESMTP id D92162742C; Mon, 15 Nov 2004 09:39:30 -0500 (EST) Received: from brian by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CTi0l-000H6h-4i; Mon, 15 Nov 2004 14:39:19 +0000 Date: Mon, 15 Nov 2004 14:39:19 +0000 From: Brian Candler To: Alexey Melnikov Cc: Philip Guenther , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl Message-ID: <20041115143919.GC65701@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <4198B5E1.4070405@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4198B5E1.4070405@isode.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 15, 2004 at 01:57:53PM +0000, Alexey Melnikov wrote: > I think the following text in the appendix B could have caused the > confusion: > > This document replaces the "d" right with 3 new different rights "x", > "t" and "e". > > Any suggestion how to improve this? I don't think that's necessarily the source of confusion, but it could be elaborated: This document splits the "d" right into 3 new different rights "x", "t" and "e". The "d" right remains for backwards-compatibility but it is a virtual right. If a client requests the "d" right, it is treated as if it requested all of "x", "t" and "e". The server returns the "d" right if and only if all of "x", "t" and "e" are set. > I've changed this to: > If a client request clears the "d" right from a rights lists, then > the server MUST also clear > any of the "x", "e", and "t" rights, unless one or more of them is > also specified in the same rights list. > > Is this any better? > > Or maybe even: > If a client request clears the "d" right from a rights lists, then > the server MUST first clear > all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" > rights are specified in the same rights list, they are then set as usual. > ? I don't think it need be so complicated; how about just If a client includes the "d" right in a rights list, then it is to be treated as if the client had included the "x", "e" and "t" rights. (You could add: It is not an error for a client to specify both "d" and one or more of "x", "e" and "t", but the effect no different than if just "d" or all of "x", "e" and "t" had been specified) I don't like the wording "clears the "d" right from a rights list", because IIUC you can't ask for individual flags to be set or cleared; you can only ask for the entire set of flags to be replaced with a new set. So the only issue is, if the replacement set contains "d", how is it to be handled? And I think the answer is, just as if "x", "e" and "t" had been specified. Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDwFZj060378; Mon, 15 Nov 2004 05:58:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFDwFFf060377; Mon, 15 Nov 2004 05:58:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDw91K060360 for ; Mon, 15 Nov 2004 05:58:10 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 13:57:55 +0000 Message-ID: <4198B5E1.4070405@isode.com> Date: Mon, 15 Nov 2004 13:57:53 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >>The one implementation I have access to is courier-imap, and that behaves as >>follows: >> >>- If e,t or x (but not all three) are set, return those flags for LIST (ACL) >> and none for GETACL >>- If all three are set, return only "d" for both LIST (ACL) and GETACL >> >> > >The description of the 'd' right in the ACL2 and RIGHTS drafts are the >same: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). If a client sets "d" right, the server MUST > set "x", "e" and "t" rights. When the client clears the "d" right, > the server MUST clear "x", "e" and "t" rights. When all three of "x", > "e" and "t" are set, the server MUST return "d" right in response to > a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, > "d" right MUST NOT be returned in a response. > >Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't >say that clients should treat the 'd' right as implying the "etx" >rights, I don't see how the text gives the server the license to leave >out the "etx" rights when returning the 'd' right in LIST (ACL). > I think the following text in the appendix B could have caused the confusion: This document replaces the "d" right with 3 new different rights "x", "t" and "e". Any suggestion how to improve this? > The >*server* must make the d->etx implication when changing rights, but the >client isn't required to make it when reading them. > > >Perhaps most of the the description of the 'd' right should be moved >out of the list into its own paragraph? The list of rights would just >say: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). See below for details on how servers > should interpret it in commands that alter ACLs and when it > should be included in responses that return ACLs or lists of > rights. > >Then later: > If a client request sets the "d" right in a rights list, the server > MUST set the "x", "e", and "t" rights. If a client request clears > the "d" right from a rights lists, then the server MUST also clear > any of the "x", "e", and "t" rights that are not simultaneously being > set. > I've changed this to: If a client request clears the "d" right from a rights lists, then the server MUST also clear any of the "x", "e", and "t" rights, unless one or more of them is also specified in the same rights list. Is this any better? Or maybe even: If a client request clears the "d" right from a rights lists, then the server MUST first clear all of the "x", "e", and "t" rights. If all of the "x", "e", and "t" rights are specified in the same rights list, they are then set as usual. ? > When all three of the "x", "e", and "t" rights are set in a > list of rights, the server MUST also include the "d" right when > returning that list in a MYRIGHTS or ACL response. If the "x", "e", > and "t" rights are not tied together, the "d" right MUST NOT be > returned in a LISTRIGHTS response. > >(The phrasing about "simultaneously being set" is to make it clear that >even though the request > tag SETACL "foo" "guenther" "lrswt" >doesn't include (and may be clearing) the "d" right, the "t" right >should still be set.) > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCjXor024471; Mon, 15 Nov 2004 04:45:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCjXGW024470; Mon, 15 Nov 2004 04:45:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCjWg0024464 for ; Mon, 15 Nov 2004 04:45:33 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:45:32 +0000 Message-ID: <4198A4EA.8090901@isode.com> Date: Mon, 15 Nov 2004 12:45:30 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: IMAP Extensions WG Subject: Re: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> <418CFBE9.1050308@isode.com> In-Reply-To: <418CFBE9.1050308@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Actually, I believe there are only two. One relates to whether the "m" > right only controls writability of private annotations, or whether it > also controls readability. I've sent a separate message on this. I believe that this issue is closed now. > The second issue: > > Which rights are required for the LISTRIGHTS command? > > Currently the document says: > > MYRIGHTS - any of the following rights is required to perform > the operation: "l", "r", "i", "c", "x", "a".* > > LISTRIGHTS - same as MYRIGHTS. > > Some of the existing servers follow this suggestion. Some allow for > LISTRIGHTS if "r" and/or "a" is granted. > > Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" > right is granted, as LISTRIGHTS information is only useful > if you can also do SETACL. Also, such information shouldn't be disclosed > to users that have insufficient rights. So, any comments on changing LISTRIGHTS to require the "a" right? > Alexey > > * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are > not part of this list, because the client must be able to open a mailbox > (i.e. "r") before performing a STORE command. The list also used to > contain the "e" right (which controls EXPUNGE), I've deleted it for the > same reason. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCWqiU017284; Mon, 15 Nov 2004 04:32:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCWqX8017283; Mon, 15 Nov 2004 04:32:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCWpbE017257 for ; Mon, 15 Nov 2004 04:32:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:32:45 +0000 Message-ID: <4198A1EB.3040107@isode.com> Date: Mon, 15 Nov 2004 12:32:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >Please review the 2086upd draft as soon as possible, as it should be >going to working group last call Real Soon Now. Only one substantive >change was discussed at the IETF meeting last week: instead of returning >a MYRIGHTS response, the SELECT command should return a MYRIGHTS >response _code_. So, for example, this line from the SELECT example in >section 7.1.1: > S: * MYRIGHTS INBOX rwis >will end up instead reading: > S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights >(Can't return a new response unless the client indicated it expected it >by using some new syntax. That's why the UNSEEN, UIDVALIDITY, UIDNEXT, >and PERMANENTFLAGS values are returned as response codes instead of >responses.) > > The ACL2 document defines MYRIGHTS response code, but it doesn't include a mailbox name. Is it Ok? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCHPEJ003422; Mon, 15 Nov 2004 04:17:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFCHPh6003413; Mon, 15 Nov 2004 04:17:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFCHFli003130 for ; Mon, 15 Nov 2004 04:17:15 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 15 Nov 2004 12:16:45 +0000 Message-ID: <41989E2A.9030308@isode.com> Date: Mon, 15 Nov 2004 12:16:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Brian Candler , ietf-imapext@imc.org Subject: Re: Clarification of "d" right in imapext-acl References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> <20041115083336.GB691@uk.tiscali.com> In-Reply-To: <20041115083336.GB691@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler wrote: >On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote: > > >>Perhaps most of the the description of the 'd' right should be moved >>out of the list into its own paragraph? The list of rights would just >>say: >> d - This right is defined for backward compatibility with ACL >> extension (RFC 2086). See below for details on how servers >> should interpret it in commands that alter ACLs and when it >> should be included in responses that return ACLs or lists of >> rights. >> >>Then later: >> If a client request sets the "d" right in a rights list, the server >> MUST set the "x", "e", and "t" rights. If a client request clears >> the "d" right from a rights lists, then the server MUST also clear >> any of the "x", "e", and "t" rights that are not simultaneously being >> set. When all three of the "x", "e", and "t" rights are set in a >> list of rights, the server MUST also include the "d" right when >> returning that list in a MYRIGHTS or ACL response. If the "x", "e", >> and "t" rights are not tied together, the "d" right MUST NOT be >> returned in a LISTRIGHTS response. >> >>(The phrasing about "simultaneously being set" is to make it clear that >>even though the request >> tag SETACL "foo" "guenther" "lrswt" >>doesn't include (and may be clearing) the "d" right, the "t" right >>should still be set.) >> >> > >Yes, that looks better. > > I think I want to rephrase the "simultaneously being set" part, but the idea looks good. >>A few more nits on the 2086upd draft: the reference to LISTEXT in the >>Formal Syntax should be removed. In Appendix B, replace "a LIST >>response" with "MYRIGHTS and ACL responses" and replace "ACL2" with >>"RIGHTS". >> >> > >I spotted those too :-) > > Fixed now. Thanks for spotting this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF8XvF4070586; Mon, 15 Nov 2004 00:33:57 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF8XvlC070585; Mon, 15 Nov 2004 00:33:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF8Xlki070490 for ; Mon, 15 Nov 2004 00:33:47 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 7E91FADCC7; Mon, 15 Nov 2004 03:33:46 -0500 (EST) Received: from thinkdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 0AEAF41B0E7; Mon, 15 Nov 2004 03:33:43 -0500 (EST) Received: from brian by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1CTcIq-000LWJ-Fl; Mon, 15 Nov 2004 08:33:36 +0000 Date: Mon, 15 Nov 2004 08:33:36 +0000 From: Brian Candler To: Philip Guenther Cc: ietf-imapext@imc.org, Alexey Melnikov Subject: Re: Clarification of "d" right in imapext-acl Message-ID: <20041115083336.GB691@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Nov 14, 2004 at 03:04:19PM -0800, Philip Guenther wrote: > Perhaps most of the the description of the 'd' right should be moved > out of the list into its own paragraph? The list of rights would just > say: > d - This right is defined for backward compatibility with ACL > extension (RFC 2086). See below for details on how servers > should interpret it in commands that alter ACLs and when it > should be included in responses that return ACLs or lists of > rights. > > Then later: > If a client request sets the "d" right in a rights list, the server > MUST set the "x", "e", and "t" rights. If a client request clears > the "d" right from a rights lists, then the server MUST also clear > any of the "x", "e", and "t" rights that are not simultaneously being > set. When all three of the "x", "e", and "t" rights are set in a > list of rights, the server MUST also include the "d" right when > returning that list in a MYRIGHTS or ACL response. If the "x", "e", > and "t" rights are not tied together, the "d" right MUST NOT be > returned in a LISTRIGHTS response. > > (The phrasing about "simultaneously being set" is to make it clear that > even though the request > tag SETACL "foo" "guenther" "lrswt" > doesn't include (and may be clearing) the "d" right, the "t" right > should still be set.) Yes, that looks better. > A few more nits on the 2086upd draft: the reference to LISTEXT in the > Formal Syntax should be removed. In Appendix B, replace "a LIST > response" with "MYRIGHTS and ACL responses" and replace "ACL2" with > "RIGHTS". I spotted those too :-) Regards, Brian. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAEN4Mfp074820; Sun, 14 Nov 2004 15:04:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAEN4Mwr074819; Sun, 14 Nov 2004 15:04:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAEN4Mnl074801 for ; Sun, 14 Nov 2004 15:04:22 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAEN4KjZ025451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 14 Nov 2004 15:04:20 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAEN4KjZ025451 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=VIALlyoSg4inqxMmb6/AcUQan+CsbzuFFw8Mj2yOqthLPHZXvQJWa6w/ZHoE2wW+7 0UCfJejbYkLOtx8UH1C70rxE0UXePNqhx4qbAMRcxO5BKuzD2moPg7erZ1lgL0+jJ7Q pw9hz1e1yaA4QceEU1/Ngx00MlnZHojSZRUzZuc= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAEN4J9C087820; Sun, 14 Nov 2004 15:04:20 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411142304.iAEN4J9C087820@lab.smi.sendmail.com> To: Brian Candler Cc: ietf-imapext@imc.org, Alexey Melnikov From: Philip Guenther Subject: Re: Clarification of "d" right in imapext-acl In-reply-to: <20041113115206.GA854@uk.tiscali.com> References: <20041113115206.GA854@uk.tiscali.com> Date: Sun, 14 Nov 2004 15:04:19 -0800 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Candler writes: >According to draft-ietf-imapext-acl-10.txt section 3.1: ... >RFC 2086 allows standards-track documents to define additional rights; if >the intention is that LIST (ACL) and GETACL are permitted to return exactly >the same set of flags under all circumstances, or not, then I think this >should be made explicit. At the San Diego meeting, the working group decided to put ACL2 on hold for a moment in favor of turning out a quick revision of RFC 2086 that added some additional rights (etxmn) and clarified exactly which rights were required for which commands. Alexey sent the current version of that doc, draft-ietf-imapext-2086upd-01.txt, to the list on Nov 7: http://www.imc.org/ietf-imapext/mail-archive/msg02242.html That revision isn't in the I-D repository yet. Now, this affects your question/query in that the "etx" rights are being added without changing the commands, so they will definitely be returned by the GETACL command in an implementation supporting the RIGHTS extension defined in the above draft. As for returning the 'd' right from LIST (ACL), the draft currently is specific about requiring it. Permitting the server to leave it out when GETACL is required to return it would make the text more complicated for, IMO, no real gain. (Once LISTEXT and RIGHTS are published, the ACL2 draft will shrink a *lot*) Please review the 2086upd draft as soon as possible, as it should be going to working group last call Real Soon Now. Only one substantive change was discussed at the IETF meeting last week: instead of returning a MYRIGHTS response, the SELECT command should return a MYRIGHTS response _code_. So, for example, this line from the SELECT example in section 7.1.1: S: * MYRIGHTS INBOX rwis will end up instead reading: S: * OK [MYRIGHTS INBOX rwis] Blah blah your rights (Can't return a new response unless the client indicated it expected it by using some new syntax. That's why the UNSEEN, UIDVALIDITY, UIDNEXT, and PERMANENTFLAGS values are returned as response codes instead of responses.) >The one implementation I have access to is courier-imap, and that behaves as >follows: > >- If e,t or x (but not all three) are set, return those flags for LIST (ACL) > and none for GETACL >- If all three are set, return only "d" for both LIST (ACL) and GETACL The description of the 'd' right in the ACL2 and RIGHTS drafts are the same: d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, "d" right MUST NOT be returned in a response. Since it doesn't say "...MUST _instead_ return "d" right..." and doesn't say that clients should treat the 'd' right as implying the "etx" rights, I don't see how the text gives the server the license to leave out the "etx" rights when returning the 'd' right in LIST (ACL). The *server* must make the d->etx implication when changing rights, but the client isn't required to make it when reading them. Perhaps most of the the description of the 'd' right should be moved out of the list into its own paragraph? The list of rights would just say: d - This right is defined for backward compatibility with ACL extension (RFC 2086). See below for details on how servers should interpret it in commands that alter ACLs and when it should be included in responses that return ACLs or lists of rights. Then later: If a client request sets the "d" right in a rights list, the server MUST set the "x", "e", and "t" rights. If a client request clears the "d" right from a rights lists, then the server MUST also clear any of the "x", "e", and "t" rights that are not simultaneously being set. When all three of the "x", "e", and "t" rights are set in a list of rights, the server MUST also include the "d" right when returning that list in a MYRIGHTS or ACL response. If the "x", "e", and "t" rights are not tied together, the "d" right MUST NOT be returned in a LISTRIGHTS response. (The phrasing about "simultaneously being set" is to make it clear that even though the request tag SETACL "foo" "guenther" "lrswt" doesn't include (and may be clearing) the "d" right, the "t" right should still be set.) A few more nits on the 2086upd draft: the reference to LISTEXT in the Formal Syntax should be removed. In Appendix B, replace "a LIST response" with "MYRIGHTS and ACL responses" and replace "ACL2" with "RIGHTS". There are also a few remaining places where <"foo" right> should be changed to (e.g., in the last paragraph of section 6). >Whether or not that's the intention of the draft, IMO the wording could be >made clearer. Would the above text do so? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADBqA3m022094; Sat, 13 Nov 2004 03:52:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADBqA1A022093; Sat, 13 Nov 2004 03:52:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADBqAJc022083 for ; Sat, 13 Nov 2004 03:52:10 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from boggle (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 46ADAADC38 for ; Sat, 13 Nov 2004 06:52:11 -0500 (EST) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by boggle.sasl.smtp.pobox.com (Postfix) with ESMTP id 046B841AD7C for ; Sat, 13 Nov 2004 06:52:09 -0500 (EST) Received: from brian by billdog.local.linnet.org with local (Exim 4.31) id 1CSwRq-0000Ej-Lb for ietf-imapext@imc.org; Sat, 13 Nov 2004 11:52:06 +0000 Date: Sat, 13 Nov 2004 11:52:06 +0000 From: Brian Candler To: ietf-imapext@imc.org Subject: Clarification of "d" right in imapext-acl Message-ID: <20041113115206.GA854@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: According to draft-ietf-imapext-acl-10.txt section 3.1: d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. and later in section 9.1: b). Implement separate "x", "t" and "e". Return "d" right in a LIST response containing ACL information when all three of "x", "t" and "e" are granted. However I don't think it's clear whether this means that the LIST (ACL) command should return the d flag *in addition* to etx, or *instead of* etx. Also, it's not clear to me whether the old GETACL command is permitted to return the e, t or x flags separately if they exist, or hide them. But if it has to hide them, i.e. GETACL is supposed to be implemented differently to LIST (ACL) for the benefit of RFC 2086 clients, then is there any need for LIST (ACL) to return a "d" flag at all? LIST (ACL) is an ACL2 command, so any ACL2 client should understand 'e','t' and 'x' separately anyway. RFC 2086 allows standards-track documents to define additional rights; if the intention is that LIST (ACL) and GETACL are permitted to return exactly the same set of flags under all circumstances, or not, then I think this should be made explicit. The one implementation I have access to is courier-imap, and that behaves as follows: - If e,t or x (but not all three) are set, return those flags for LIST (ACL) and none for GETACL - If all three are set, return only "d" for both LIST (ACL) and GETACL Whether or not that's the intention of the draft, IMO the wording could be made clearer. Regards, Brian Candler. * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information. a login fred@flintstone.org XXXXXXXX a OK LOGIN Ok. a acl store "INBOX.mytest" "user=wilma@flintstone.org" "et" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "et")))) a OK ACL STORE completed. a list (acl) "" "INBOX.mytest" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "et")))) a OK LIST completed a getacl "INBOX.mytest" * ACL "INBOX.mytest" "owner" "acdilrsw" "wilma@flintstone.org" "" a OK GETACL completed. a acl store "INBOX.mytest" "user=wilma@flintstone.org" "etx" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "d")))) a OK ACL STORE completed. a list (acl) "" "INBOX.mytest" * LIST (\HasNoChildren) "." "INBOX.mytest" (("ACL" (("owner" "acdilrsw")("user=wilma@flintstone.org" "d")))) a OK LIST completed a getacl "INBOX.mytest" * ACL "INBOX.mytest" "owner" "acdilrsw" "wilma@flintstone.org" "d" a OK GETACL completed. a logout * BYE Courier-IMAP server shutting down a OK LOGOUT completed Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJVsJl016065; Fri, 12 Nov 2004 11:31:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACJVsY2016053; Fri, 12 Nov 2004 11:31:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJVjPY015980 for ; Fri, 12 Nov 2004 11:31:49 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.67.86.117] ([12.160.57.182]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iACIOB6E017888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 13:24:15 -0500 Date: Fri, 12 Nov 2004 14:30:20 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: Notes for IMAPEXT WG meeting at IETF61 Message-ID: <24568FAE8A60AA819BF2D212@ninevah.local> In-Reply-To: References: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, November 12, 2004 17:53:02 EST +0100 Arnt Gulbrandsen wrote: >> Multiple-mailbox-match in LISTEXT: looks like there's consensus to add >> it. We will take this to the list to see if there's any objectors on >> the list. > > There's me, sort of. But if it's okay to send two responses when a > mailbox matches two patterns, I'll be quiet. (I don't remember right now. > There was some discussion, wasn't there?) Clients have to potential cope with that situation today with regular LIST so having the server do it with LISTEXT, whilst not ideal, should not cause problems. I think we ought to say 'servers SHOULD suppress duplicate mailboxes in the response' and leave it at that. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGwRhM068455; Fri, 12 Nov 2004 08:58:27 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACGwR7P068454; Fri, 12 Nov 2004 08:58:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iACGwLt6068360 for ; Fri, 12 Nov 2004 08:58:26 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id EC1C81BDEB6; Fri, 12 Nov 2004 17:58:09 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 4F6781BDEB4 for ; Fri, 12 Nov 2004 17:58:09 +0100 (CET) Message-Id: Date: Fri, 12 Nov 2004 17:53:02 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Notes for IMAPEXT WG meeting at IETF61 References: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> In-Reply-To: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault writes: > Multiple-mailbox-match in LISTEXT: looks like there's consensus to add > it. We will take this to the list to see if there's any objectors on > the list. There's me, sort of. But if it's okay to send two responses when a mailbox matches two patterns, I'll be quiet. (I don't remember right now. There was some discussion, wasn't there?) Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGEuIl058337; Fri, 12 Nov 2004 08:14:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACGEuXt058336; Fri, 12 Nov 2004 08:14:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACGEteH058328 for ; Fri, 12 Nov 2004 08:14:55 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [130.129.135.17] ([130.129.135.17]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iACGEuZe012733 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 12 Nov 2004 08:14:58 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Notes location Date: Fri, 12 Nov 2004 08:14:46 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I forwarded the notes to the WG and also uploaded them to http://ietf.webdav.org/imapext/. I also added a link there to the Jabber room logs. There were no presentations at this meeting. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACFo83r049604; Fri, 12 Nov 2004 07:50:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACFo81N049603; Fri, 12 Nov 2004 07:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACFo87X049556 for ; Fri, 12 Nov 2004 07:50:08 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [130.129.135.17] ([130.129.135.17]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iACFo3Ze011947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 12 Nov 2004 07:50:05 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <7FA7EBAD-34C2-11D9-9C2F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: proceedings@ietf.org, IMAP Extensions WG From: Lisa Dusseault Subject: Notes for IMAPEXT WG meeting at IETF61 Date: Fri, 12 Nov 2004 07:49:55 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LISTEXT STATUS Discussion of /Placeholder: Philip promised to send a mail about a simplification of /Placeholder. Cyrus and Barry agree that LISTEXT is too complicated and we need to back off that. Question about which client people initially asked for features in LISTEXT (prompted by observation that LISTEXT has now become rather complex)? Cyrus, David Cridland, Mark Crispin.. who else? Suggestion that the /matchparent stuff may be simplifiable -- get rid of it. Any wildcard query (%) could be seen as a request for matchparent -- otherwise the server must not return it. Multiple-mailbox-match in LISTEXT: looks like there's consensus to add it. We will take this to the list to see if there's any objectors on the list. We will defer to the mailing list for what to do with /NOSELECT, /NONEXISTENT, /DELETED... Cyrus and Philip are on the hook to suggest a simplified model to Alexey and Barry for matchparent... the next version of this may get last-called. --- ACL STATUS Discussion on 2086 upd: Looks good, needs to be kept simple and finished soon. Scott and Chris promise to review 2086upd --- ANNOTATE STATUS Discussion on Annotate: lots of discussion over what rights to use for private and public annotations. Proposal: that the ability to read private annotations is controlled by the 'r' ACL bit, and the ability to write private annotations is controlled by the new 'm' ACL bit. This means that 'r' controls readability for both private and shared annotations. There were no sticking objections to this proposal (however Barry and Chris would prefer another proposal.) 2nd issue with ANNOTATE: Interactions with the CATENATE draft. Resolution: Cyrus will add text to deal with this and there will be a new dependency of Annotate on Catenate 3rd issue: APPEND: a slight interaction here with annotate, which Cyrus will add to the draft. We plan to last call the next version of Annotate on the day it comes out. --- ANNOTATEMORE Plug for AnnotateMore -- Chris and Philip promised to review, Cyrus will ask LEMONADE list for review. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABCL5fj084654; Thu, 11 Nov 2004 04:21:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABCL5LQ084653; Thu, 11 Nov 2004 04:21:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABCKxRv084566 for ; Thu, 11 Nov 2004 04:21:00 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCKhE21966; Thu, 11 Nov 2004 14:20:44 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 14:20:36 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iABCKa3A012188; Thu, 11 Nov 2004 14:20:36 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00MR7nOf; Thu, 11 Nov 2004 14:20:34 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCKRa15250; Thu, 11 Nov 2004 14:20:27 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 06:20:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Thu, 11 Nov 2004 06:20:24 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B87@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHtA2QOu7XKjXZRMSRoBjVBVDw6wAMkU1A From: To: , X-OriginalArrivalTime: 11 Nov 2004 12:20:26.0402 (UTC) FILETIME=[D3443820:01C4C7E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iABCL0Rv084586 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Cyrus Daboo [mailto:daboo@isamet.com] > Sent: Thursday, November 11, 2004 1:01 AM ... > > The ANNOTATE draft does allow for attribute value pairs to be sent > > in unsolicited responses with the SELECT parameter "(ANNOTATE)". > > There does not seem to be an analog in ANNOTATEMORE. > > No, that's not the case. Section 3.2 of ANNOTATE states that Which statement are you refuting the first or the second? Both maybe? > the (ANNOTATE) > parameter on SELECT turns on unsolicited annotation responses > as defined by > Section 3.4. Section 3.4 states that unsolicited responses > MUST NOT include > the annotation data. i.e. the ANNOTATION responses resulting from > (ANNOTATE) on SELECT do not include the annotation values. I'm confused. Here is an excerpt from draft-ietf-imapext-annotate-11.txt sec 3.4. Servers MUST NOT include ANNOTATION data in unsolicited responses unless the client used the ANNOTATE select parameter when it issued the last SELECT or EXAMINE command. This restriction avoids sending ANNOTATION data to a client unless the client explicitly asks for it. Servers SHOULD send ANNOTATION message data items in unsolicited FETCH responses if an annotation entry is changed by a third-party, and the ANNOTATE select parameter was used. This allows servers to keep clients updated with changes to annotations by other clients. This seems clear to me. I must be missing something about your point. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB60qoY021682; Wed, 10 Nov 2004 22:00:52 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB60qrC021681; Wed, 10 Nov 2004 22:00:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB60lif021607 for ; Wed, 10 Nov 2004 22:00:51 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [10.67.86.4] ([130.129.97.127]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAB4ru6E018894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 23:53:59 -0500 Date: Thu, 11 Nov 2004 01:00:46 -0500 From: Cyrus Daboo To: Michael.Wener@nokia.com, ietf-imapext@imc.org Subject: RE: Comments on ANNOTATEMORE Message-ID: <8EA283886467F41ED4FFA81D@ninevah.local> In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.noki a.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Wednesday, November 10, 2004 14:49:06 EST -0600 Michael.Wener@nokia.com wrote: >> This behaves the same way as unsolicited ANNOTATE responses >> in the ANNOTATE >> extension. The reason for this behaviour is that clients may > > The ANNOTATE draft does allow for attribute value pairs to be sent > in unsolicited responses with the SELECT parameter "(ANNOTATE)". > There does not seem to be an analog in ANNOTATEMORE. No, that's not the case. Section 3.2 of ANNOTATE states that the (ANNOTATE) parameter on SELECT turns on unsolicited annotation responses as defined by Section 3.4. Section 3.4 states that unsolicited responses MUST NOT include the annotation data. i.e. the ANNOTATION responses resulting from (ANNOTATE) on SELECT do not include the annotation values. Perhaps this needs to be made more explicit? -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB353SC055995; Wed, 10 Nov 2004 19:05:03 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB353NK055994; Wed, 10 Nov 2004 19:05:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB351mh055973 for ; Wed, 10 Nov 2004 19:05:02 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAB350F12826; Thu, 11 Nov 2004 05:05:01 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 05:03:15 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAB33FUC016032; Thu, 11 Nov 2004 05:03:15 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00huHzSl; Thu, 11 Nov 2004 05:03:15 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAB33ES06233; Thu, 11 Nov 2004 05:03:14 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 21:03:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 21:03:12 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B86@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHdaDf/syRhWVoTLCmZEOUjpws9QAJA3Aw From: To: Cc: X-OriginalArrivalTime: 11 Nov 2004 03:03:13.0734 (UTC) FILETIME=[FBD7EE60:01C4C79A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAB353mh055987 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Philip Guenther [mailto:guenther@sendmail.com] > Sent: Wednesday, November 10, 2004 5:35 PM ... > >> /checkperiod is meant to be the user preference for polling > >> interval. i.e. > >> the client will use that value to determine what interval it > >> should poll > >> the mailbox (using STATUS or NOOP). It is not under control > >> of the server > >> and is not used by the server. I can add text to clarify that. > > > >As described I don't see it having much value. I see it having > >much more value as a server set value. So I would suggest you > >don't add the clarification and leave it as either client or > >server set. > > What would a server-set version of checkperiod tell the client? I'm > trying to envision an interpretation that wouldn't imply that > the server > can see into the future. A server can see into the future. It is called extrapolation. > >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 > >last two paragraphs. These would not be redundant. I could see them > >as being uninteresting to some clients, but for the same reason you > >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be > >interesting to some clients. To those clients it would be nice to > >have the data contained in the response. > > Given the possible size of annotations (as compared to the > size of flags > updates), defaulting to not sending values seems wise to me. I agree. I understand that point. You do agree the ANNOTATE draft does have a way to allow data to be included in unsolicited responses? Why would it not be wise to allow such a capability to be turned on for non-message annotations? Note, I'm not talking about the default. Maybe the answer is there is no clean way to do it. Message annotations have the SELECT (ANNOTATE) switch. Where you would hang such a switch with non-message annotations I'm not sure. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMYrxl039101; Wed, 10 Nov 2004 14:34:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAMYrNv039100; Wed, 10 Nov 2004 14:34:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMYrlV039018 for ; Wed, 10 Nov 2004 14:34:53 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iAAMYnZj010400 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 10 Nov 2004 14:34:49 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iAAMYnZj010400 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=QGCkFPvgANSlGtob9nfgWFheMd9rwndGklH+B2z7YHt85GsL9yx4gDfjWB6M/dN87 JN5q3YU3N8zMTKjiypn+UUpETpECLXY+F17ShPAHeyweim6/7p+2yH8OmyG2IlRs1WF p114q/QyaRuBq/5IHyaw4cx5A9xwEpjX+nG+suA= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iAAMYnE5090745; Wed, 10 Nov 2004 14:34:49 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411102234.iAAMYnE5090745@lab.smi.sendmail.com> To: Michael.Wener@nokia.com Cc: ietf-imapext@imc.org Subject: Re: Comments on ANNOTATEMORE In-reply-to: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> Date: Wed, 10 Nov 2004 14:34:49 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael.Wener@nokia.com writes: >Cyrus Daboo writes: ... >> /checkperiod is meant to be the user preference for polling >> interval. i.e. >> the client will use that value to determine what interval it >> should poll >> the mailbox (using STATUS or NOOP). It is not under control >> of the server >> and is not used by the server. I can add text to clarify that. > >As described I don't see it having much value. I see it having >much more value as a server set value. So I would suggest you >don't add the clarification and leave it as either client or >server set. What would a server-set version of checkperiod tell the client? I'm trying to envision an interpretation that wouldn't imply that the server can see into the future. Note that ANNOTATEMORE arose in part from the difficulties in implementing ACAP and several of the initial entries are there to take over for ACAP profiles of client configuration. ... >I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 >last two paragraphs. These would not be redundant. I could see them >as being uninteresting to some clients, but for the same reason you >allow unsolicited responses with data in ANNOTATE sec 3.4 they may be >interesting to some clients. To those clients it would be nice to >have the data contained in the response. Given the possible size of annotations (as compared to the size of flags updates), defaulting to not sending values seems wise to me. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAKnfrZ093568; Wed, 10 Nov 2004 12:49:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAKnfVc093565; Wed, 10 Nov 2004 12:49:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAKnZ7b093487 for ; Wed, 10 Nov 2004 12:49:36 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAKnPv18884; Wed, 10 Nov 2004 22:49:26 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 22:49:11 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAAKnBZf009781; Wed, 10 Nov 2004 22:49:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00GyXsvD; Wed, 10 Nov 2004 22:49:11 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAKnAS00662; Wed, 10 Nov 2004 22:49:10 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 14:49:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 14:49:06 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B84@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHPlEkFcUV71rpQFuj6ZsV1tErGAAIvhyg From: To: , X-OriginalArrivalTime: 10 Nov 2004 20:49:09.0625 (UTC) FILETIME=[BA1CAE90:01C4C766] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAKna7b093520 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: ext Cyrus Daboo [mailto:daboo@isamet.com] > Sent: Wednesday, November 10, 2004 10:58 AM > > Section 2.2.1.2 > > > > I don't understand the usefulness of /check and /checkperiod. > > Who sets checkperiod? Mail arrival is variable so the only ... > /checkperiod is meant to be the user preference for polling > interval. i.e. > the client will use that value to determine what interval it > should poll > the mailbox (using STATUS or NOOP). It is not under control > of the server > and is not used by the server. I can add text to clarify that. As described I don't see it having much value. I see it having much more value as a server set value. So I would suggest you don't add the clarification and leave it as either client or server set. > > It is sometimes useful to be able to 'suspend' checking of a > mailbox, hence ... Agreed. > > Section 3.3 ... > i.e. there is no need for the server to send back the > annotation data that > the client has just set using SETANNOTATION - that > information is redundant > as the OK response implies those changes have succeeded. Agreed. > > > > > Section 3.4.2 > > > > Why do unsolicited ANNOTATION responses not contain attributes > > and values? Wouldn't they be more useful if they contained the > > new data? Maybe they MAY as descibed in section 3.3? > > This behaves the same way as unsolicited ANNOTATE responses > in the ANNOTATE > extension. The reason for this behaviour is that clients may The ANNOTATE draft does allow for attribute value pairs to be sent in unsolicited responses with the SELECT parameter "(ANNOTATE)". There does not seem to be an analog in ANNOTATEMORE. > not care about > some annotations and therefore sending the data is redundant ande > potentially wastes bandwidth. It is more efficient to tell > the client that > some changes have happened and then have the client go and > fetch the data > for only the ones it is really interested in. i.e. we are > trying to prevent > the server forcing data on the client that it does not need. I'm talking about 3rd party changes as described in ANNOTATE sec 3.4 last two paragraphs. These would not be redundant. I could see them as being uninteresting to some clients, but for the same reason you allow unsolicited responses with data in ANNOTATE sec 3.4 they may be interesting to some clients. To those clients it would be nice to have the data contained in the response. Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFvnKf081332; Wed, 10 Nov 2004 07:57:49 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFvnfB081331; Wed, 10 Nov 2004 07:57:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFviF3081248 for ; Wed, 10 Nov 2004 07:57:48 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [130.129.135.95] ([130.129.135.95]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iAAEos6E023494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2004 09:50:57 -0500 Date: Wed, 10 Nov 2004 10:57:39 -0500 From: Cyrus Daboo To: Michael.Wener@nokia.com, ietf-imapext@imc.org Subject: Re: Comments on ANNOTATEMORE Message-ID: In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.noki a.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael.Wener@nokia.com, --On Wednesday, November 10, 2004 9:17:31 EST -0600 Michael.Wener@nokia.com wrote: > Section 2.2.1.2 > > I don't understand the usefulness of /check and /checkperiod. > Who sets checkperiod? Mail arrival is variable so the only > reasonable thing to do is to have it modified by the server > using some learning algorithm that changed the value as the > inter-mail arrival times changed. > > Or maybe you were thinking about some server imposed polling > throttle? > > /check is redundant. The existence of /checkperiod implies > /check=true. /checkperiod is meant to be the user preference for polling interval. i.e. the client will use that value to determine what interval it should poll the mailbox (using STATUS or NOOP). It is not under control of the server and is not used by the server. I can add text to clarify that. It is sometimes useful to be able to 'suspend' checking of a mailbox, hence having a separate 'turn check on/off' value that does not affect the period is useful. i.e. you don't have to remember what the last period when restoring checking after it has been suspended. > > Section 3.3 > > The paragraph immediately following the "Result:" section > describes behavior for unsolicited responses. I'm unclear if > this is referring to the potential untagged responses returned > due to the SETANNOTATION, or to unsolicited responses in general, > for example, during a NOOP. The first paragraph in section 3.3 is confusing. The policy is that unsolicited responses can be sent at any appropriate time (including during SETANNOTATION), however the server does not need to send ANNOTATION responses that are the direct result of the SETANNOTATION command itself - i.e. there is no need for the server to send back the annotation data that the client has just set using SETANNOTATION - that information is redundant as the OK response implies those changes have succeeded. > > Section 3.4.2 > > Why do unsolicited ANNOTATION responses not contain attributes > and values? Wouldn't they be more useful if they contained the > new data? Maybe they MAY as descibed in section 3.3? This behaves the same way as unsolicited ANNOTATE responses in the ANNOTATE extension. The reason for this behaviour is that clients may not care about some annotations and therefore sending the data is redundant ande potentially wastes bandwidth. It is more efficient to tell the client that some changes have happened and then have the client go and fetch the data for only the ones it is really interested in. i.e. we are trying to prevent the server forcing data on the client that it does not need. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFIlIU065083; Wed, 10 Nov 2004 07:18:47 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFIlZR065082; Wed, 10 Nov 2004 07:18:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFIkR5065065 for ; Wed, 10 Nov 2004 07:18:46 -0800 (PST) (envelope-from Michael.Wener@nokia.com) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFIkF19314 for ; Wed, 10 Nov 2004 17:18:47 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 17:19:41 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAAFJflK030692 for ; Wed, 10 Nov 2004 17:19:41 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LCgyl5; Wed, 10 Nov 2004 17:19:38 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFIHS21748 for ; Wed, 10 Nov 2004 17:18:17 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 09:17:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Comments on ANNOTATEMORE Date: Wed, 10 Nov 2004 09:17:31 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3B82@daebe005.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ANNOTATEMORE thread-index: AcTHOGXjy9+etzyARZ2TZzNMAdBLyA== From: To: X-OriginalArrivalTime: 10 Nov 2004 15:17:32.0983 (UTC) FILETIME=[66CA0C70:01C4C738] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAFIlR5065076 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 2.2.1.2 I don't understand the usefulness of /check and /checkperiod. Who sets checkperiod? Mail arrival is variable so the only reasonable thing to do is to have it modified by the server using some learning algorithm that changed the value as the inter-mail arrival times changed. Or maybe you were thinking about some server imposed polling throttle? /check is redundant. The existence of /checkperiod implies /check=true. Section 3.3 The paragraph immediately following the "Result:" section describes behavior for unsolicited responses. I'm unclear if this is referring to the potential untagged responses returned due to the SETANNOTATION, or to unsolicited responses in general, for example, during a NOOP. Section 3.4.2 Why do unsolicited ANNOTATION responses not contain attributes and values? Wouldn't they be more useful if they contained the new data? Maybe they MAY as descibed in section 3.3? Mike Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GvcxX010420; Tue, 9 Nov 2004 08:57:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9Gvcbd010418; Tue, 9 Nov 2004 08:57:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GvbZ7010348 for ; Tue, 9 Nov 2004 08:57:37 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.09) with ESMTP id iA9GuuFd025372; Tue, 9 Nov 2004 08:56:57 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id iA9GuuLS017883; Tue, 9 Nov 2004 08:56:56 -0800 Date: Tue, 9 Nov 2004 08:56:56 -0800 (PST) From: Mark Crispin To: Dave Cridland cc: Arnt Gulbrandsen , Alexey Melnikov , kael , ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions In-Reply-To: <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> Message-ID: References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 9 Nov 2004, Dave Cridland wrote: > I confess to being totally bewildered by the FROM, TO and CC sort keys, as > they all appear to only sort on the local-part of the email address - that > *is* the "bit before the @", right? So different domains collate equally? I > can't understand why this should be the case. In practice, not all that many people use those keys. The idea is to tend to collect messages from a single person together, based upon the tendency of people to have the same local-part for his email address even though they may use many different sites. Note that word "tend". It's useful, in some very limited cases. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GCgtF095730; Tue, 9 Nov 2004 08:12:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9GCgLn095729; Tue, 9 Nov 2004 08:12:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GCajR095667 for ; Tue, 9 Nov 2004 08:12:37 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D2C9C154009; Tue, 9 Nov 2004 16:12:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Arnt Gulbrandsen Cc: Alexey Melnikov , kael , Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> In-Reply-To: Message-ID: <20041109161233.14132.44705.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 09 Nov 2004 16:12:33 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Nov 9 12:25:17 2004, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> For an actual SORT, no matter how quick the sort implementation on >> the server is, for large mailboxes that's still a noticeable chunk >> of bandwidth chewage for the result - the sort results for a 50k >> message folder weigh in at 282k[1]. > > "sort (subject date) charset us-ascii since 2004-11-08 not since > 2004-11-09" should have only a small response, even if the mailbox > is big. > > You mentioned timezones being problematic, but I'll just clarify - the DATE and ARRIVAL sort keys sort by first normalizing the relevant date (RFC2822 header and INTERNALDATE respectively) into UTC. The date-orientated search keys (In this case SINCE) search by discarding the time and timezone, which can result in a different date. But back to the point... Yes, you can chop up SORT results for a "group by" style feature using the SEARCH key, and this will, in general, reduce the number of numbers given in the SORT response. But realistically, only for date/time related metadata. For a sort or group by sender, or subject, this wouldn't be possible: SUBJECT search keys use a substring match of the full header value - using a US-ASCII charset does this without MIME decoding. SUBJECT sort key uses the base subject, not the real one, and always decodes. Hence it's impossible to, for instance, divide the messages up into chunks with subjects beginning "a", etc, because: a) The "base subject", which you actually want, isn't being searched, so you need to SORT the full mailbox. b) You can't do a prefix search anyway. FROM is just as curious, sorting as it does only on the local-part of the From address, but substring searching throughout the entire header, optionally MIME decoding as above. I confess to being totally bewildered by the FROM, TO and CC sort keys, as they all appear to only sort on the local-part of the email address - that *is* the "bit before the @", right? So different domains collate equally? I can't understand why this should be the case. This would appear to mean that it's totally impossible to use SORT to generate the collation from which a group by sender listing could actually be generated. This seems intuitively wrong to me, but accurate according to the specification. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9CMaNn097027; Tue, 9 Nov 2004 04:22:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9CMaL6097021; Tue, 9 Nov 2004 04:22:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA9CMUkF096796 for ; Tue, 9 Nov 2004 04:22:33 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id E8C1D1BDECC; Tue, 9 Nov 2004 13:22:18 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id F3CF21BDEB4; Tue, 9 Nov 2004 13:22:16 +0100 (CET) Message-Id: Date: Tue, 9 Nov 2004 13:25:17 +0100 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions Cc: Alexey Melnikov , Dave Cridland , kael@alussinan.org References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> In-Reply-To: <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > For an actual SORT, no matter how quick the sort implementation on the > server is, for large mailboxes that's still a noticeable chunk of > bandwidth chewage for the result - the sort results for a 50k message > folder weigh in at 282k[1]. "sort (subject date) charset us-ascii since 2004-11-08 not since 2004-11-09" should have only a small response, even if the mailbox is big. (Kael: When you implement the "yesterday" group, remember to consider the timezone issues. I think that command doesn't quite match what you want.) Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9AeUSm027795; Tue, 9 Nov 2004 02:40:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9AeUBb027794; Tue, 9 Nov 2004 02:40:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9AeNjU027623 for ; Tue, 9 Nov 2004 02:40:23 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 70AA7154009; Tue, 9 Nov 2004 10:40:18 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: kael Cc: IMAP extensions Mailing List , Alexey Melnikov Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> <418FAB01.5010505@alussinan.org> In-Reply-To: <418FAB01.5010505@alussinan.org> Message-ID: <20041109104018.11253.25950.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 09 Nov 2004 10:40:18 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 8 17:21:05 2004, kael wrote: > > On 08.11.2004 17:55, Alexey Melnikov wrote: > >> Yes (ARRIVAL or DATE sort criterion, depending on what you mean: >> delivery date or the Date header)... > > I deduce that, except for keywords, the implementation of the IMAP > SORT and THREAD extensions for Mozilla/Thunderbird could be done in > consideration of the new _Message Grouping_ feature > http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, > couldn't it. That would be great ! Well, yes and no, really. On the one hand, messages can be sorted by *all* the criteria listed in that webpage, on the (minor) assumption that labels could be implemented as annotations rather than keywords. (I'm assuming here that it's one label per message, which many possible labels, in which case keywords could become problematic - servers don't always support an infinite number of keywords, so annotations would be a better fit.) On the other hand, every time a new message arrived, it would have to be sorted. Currently, that can either be done by re-sorting the entire folder server-side, or else sorting locally. For an actual SORT, no matter how quick the sort implementation on the server is, for large mailboxes that's still a noticeable chunk of bandwidth chewage for the result - the sort results for a 50k message folder weigh in at 282k[1]. For client-side sorts, you can't actually give a straight figure for the transfer, but it's likely to tend towards something much smaller as time passes and data is cached - ultimately down to the size of the data used as a sort key for the new message, usually quite small. So in actual practise, it's probably not worthwhile using the SORT except, possibly, for the first hit, depending on how much data is cached client-side to begin with. Dave. Footnote: 1) In Python: len('* SORT' + ''.join( [str(x) for x in range(1,50000)] ))/1024.0 - across a fairly typical 512kbit/s DSL line, that's about 4.5 seconds of *transfer* time alone. Of course, I might have mucked up the calculation. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8HKsve028197; Mon, 8 Nov 2004 09:20:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8HKsul028196; Mon, 8 Nov 2004 09:20:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8HKruh028124 for ; Mon, 8 Nov 2004 09:20:54 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix4-1.free.fr (Postfix) with ESMTP id E2E3C1F3462; Mon, 8 Nov 2004 18:20:44 +0100 (CET) Message-ID: <418FAB01.5010505@alussinan.org> Date: Mon, 08 Nov 2004 18:21:05 +0100 From: kael User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041103 Thunderbird/0.9 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Melnikov Cc: IMAP extensions Mailing List Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> <418FA4FF.1040409@isode.com> In-Reply-To: <418FA4FF.1040409@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 08.11.2004 17:55, Alexey Melnikov wrote: > Yes (ARRIVAL or DATE sort criterion, depending on what you mean: > delivery date or the Date header)... I deduce that, except for keywords, the implementation of the IMAP SORT and THREAD extensions for Mozilla/Thunderbird could be done in consideration of the new _Message Grouping_ feature http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Message_Grouping, couldn't it. That would be great ! Thanks for your replies. -- kael Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GthvE018145; Mon, 8 Nov 2004 08:55:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8GthPR018144; Mon, 8 Nov 2004 08:55:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8Gtfvs018138 for ; Mon, 8 Nov 2004 08:55:42 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 16:55:28 +0000 Message-ID: <418FA4FF.1040409@isode.com> Date: Mon, 08 Nov 2004 16:55:27 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kael CC: IMAP extensions Mailing List Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> <418F7AF4.6040203@isode.com> <418F8927.6070704@alussinan.org> In-Reply-To: <418F8927.6070704@alussinan.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: kael wrote: > On 08.11.2004 14:56, Alexey Melnikov wrote: > >> If you asking about grouping by message age, than the answer is >> "yes". The SORT extension would be sufficient for this. > > Does the SORT extension allow to group messages by date, Yes (ARRIVAL or DATE sort criterion, depending on what you mean: delivery date or the Date header) > keywords, No. > senders, subject, Yes and yes. > etc like Thunderbird 0.9 does - please, look at the > attachments ? I have never been able to sort messages like this with > Mulberry. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FwspL097958; Mon, 8 Nov 2004 07:58:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FwsFM097956; Mon, 8 Nov 2004 07:58:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FwjCL097892 for ; Mon, 8 Nov 2004 07:58:45 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id A8FBC154009; Mon, 8 Nov 2004 15:58:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Cyrus Daboo Cc: IMAP Extensions WG , Alexey Melnikov , Philip Guenther Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> <418F889B.3050004@isode.com> <2BB41FFE4611703F11592582@ninevah.local> In-Reply-To: <2BB41FFE4611703F11592582@ninevah.local> Message-ID: <20041108155842.11253.26989.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 08 Nov 2004 15:58:42 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Nov 8 15:17:11 2004, Cyrus Daboo wrote: > --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov > wrote: >>>> I'd personally suggest that if the server supports read-write >>>> annotations, it MUST support creation of arbitrary, >>>> non-operational >>>> attributes. >>> Is a server that only supports preconfigured namespaces an active >>> danger >>> to interoperability? If not, then I think "MUST" is >>> inappropriate. >> Unfortunately, there is no way to distinguish a read-write ANNOTATE >> server that supports reconfigured namespaces from a full read-write >> server. So yes, this might be a problem. At least it makes writing >> client >> more difficult. > I think servers SHOULD allow clients to create and use arbitrary > annotation entries be they in the vendor namespace or elsewhere > (the later being e.g. new standard annotations that have been > defined since the server was deployed). However, as with everything > in IMAP, the client MUST be prepared to handle the server saying NO. > > So I think what we say is: 'servers SHOULD allow creation and use > of arbitrary annotation entries in the vendor namespace or > elsewhere, but client MUST handle the case where a server prevents > that and responds with a NO response', or something to that effect. I'll certainly agree, of course, that any STORE to annotation may result in a NO, and of course, a client has to handle this. To my mind, not allowing arbitrary attributes ranks at near the same level as not having persistent UIDs for a mailbox. It's something a client has to cope with, but shouldn't ever have to experience in the field. I'll concede that even this makes a MUST too strong, but perhaps a SHOULD with a note? Philip used the phrase "active danger to interoperability" - a server which does not support storage of arbitrary attributes against a message in a mailbox for which the client has the rights required isn't actively endangering interoperability because, of course, it's acting so close to a server which doesn't support ANNOTATE at all. What it is doing is missing out on a golden opportunity to provide a method for new features - such as, maybe, a resent-to attribute - to be created by one client, used by another, and standardized quickly and rapidly based on real operational experience. That's hurting interoperability badly, in my opinion. As well as that, it's losing the ability to transfer mailboxes from one IMAP server to another without losing potentially highly valuable metadata, especially in the case where multiple clients are used. If persistent UIDs aren't available, then the message store is badly designed for use with IMAP. If arbitrary annotations aren't supported, then the message store is badly designed for use with ANNOTATE. Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FHUfi085071; Mon, 8 Nov 2004 07:17:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FHUbL085070; Mon, 8 Nov 2004 07:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FHTim085044 for ; Mon, 8 Nov 2004 07:17:30 -0800 (PST) (envelope-from daboo@isamet.com) Received: from [130.129.135.95] ([130.129.135.95]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA8EAj6E008922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2004 09:10:47 -0500 Date: Mon, 08 Nov 2004 10:17:11 -0500 From: Cyrus Daboo To: Alexey Melnikov , Philip Guenther cc: Dave Cridland , IMAP Extensions WG Subject: Re: Annotate Message-ID: <2BB41FFE4611703F11592582@ninevah.local> In-Reply-To: <418F889B.3050004@isode.com> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> <418F889B.3050004@isode.com> X-Mailer: Mulberry/4.0.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Monday, November 8, 2004 14:54:19 EST +0000 Alexey Melnikov wrote: >>> I'd personally suggest that if the server supports read-write >>> annotations, it MUST support creation of arbitrary, non-operational >>> attributes. >>> >>> >> Is a server that only supports preconfigured namespaces an active danger >> to interoperability? If not, then I think "MUST" is inappropriate. >> >> > Unfortunately, there is no way to distinguish a read-write ANNOTATE > server that supports reconfigured namespaces from a full read-write > server. So yes, this might be a problem. At least it makes writing client > more difficult. I think servers SHOULD allow clients to create and use arbitrary annotation entries be they in the vendor namespace or elsewhere (the later being e.g. new standard annotations that have been defined since the server was deployed). However, as with everything in IMAP, the client MUST be prepared to handle the server saying NO. So I think what we say is: 'servers SHOULD allow creation and use of arbitrary annotation entries in the vendor namespace or elsewhere, but client MUST handle the case where a server prevents that and responds with a NO response', or something to that effect. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EsURb079358; Mon, 8 Nov 2004 06:54:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8EsUna079357; Mon, 8 Nov 2004 06:54:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EsTD0079351 for ; Mon, 8 Nov 2004 06:54:29 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 14:54:20 +0000 Message-ID: <418F889B.3050004@isode.com> Date: Mon, 08 Nov 2004 14:54:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: Dave Cridland , IMAP Extensions WG Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> In-Reply-To: <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther wrote: >>I'd personally suggest that if the server supports read-write >>annotations, it MUST support creation of arbitrary, non-operational >>attributes. >> >> >Is a server that only supports preconfigured namespaces an active danger >to interoperability? If not, then I think "MUST" is inappropriate. > > Unfortunately, there is no way to distinguish a read-write ANNOTATE server that supports reconfigured namespaces from a full read-write server. So yes, this might be a problem. At least it makes writing client more difficult. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EThg2069486; Mon, 8 Nov 2004 06:29:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8ETh23069485; Mon, 8 Nov 2004 06:29:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8ETg6A069458 for ; Mon, 8 Nov 2004 06:29:42 -0800 (PST) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id iA8ETSdU016139 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 8 Nov 2004 06:29:28 -0800 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com iA8ETSdU016139 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=XumIaZ5IoJQ8aWBy/FVRZxfsR32+PIMuG6Cyr1qPknlaXjgJb6LRb0+iBVqmhpJpT bLq5U/+/icc0j6jHMuqRxZy1jfVqJVjJOUaUW84OPUzpFaVlYybHh5Qe86FBMcv0dua hXbbMzdbEwS0EgmBAR4suN4Rz8qD+XlGbsrKbGs= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id iA8ETSZk038432; Mon, 8 Nov 2004 06:29:28 -0800 (PST) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200411081429.iA8ETSZk038432@lab.smi.sendmail.com> To: Dave Cridland Cc: IMAP Extensions WG Subject: Re: Annotate In-reply-to: <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> Date: Mon, 08 Nov 2004 06:29:28 -0800 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: >On Sat Nov 6 12:55:43 2004, Alexey Melnikov wrote: >> Timo Sirainen wrote: ... >>> Servers MUST(?) support new namespaces created by clients. >> >> I think this should be "SHOULD". We want to encourage ANNOTATE >> servers. Implementing a read-only ANNOTATE is much easier. >> >> >Yes, but the need for clients to store vendor-private stuff in a >nice, neat, semi-interoperable manner really shouldn't be >underestimated. Dropping this to a SHOULD is perhaps too far. As described in RFC 2119, "SHOULD" is a fairly strong statement, with "MUST" being for the do-or-die stuff only. A quick scan of the IMAP RFC finds a goodly number of uses of "SHOULD" that a server or client would be very unwise to blithely disregard. >I'd personally suggest that if the server supports read-write >annotations, it MUST support creation of arbitrary, non-operational >attributes. Is a server that only supports preconfigured namespaces an active danger to interoperability? If not, then I think "MUST" is inappropriate. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8DuDua058660; Mon, 8 Nov 2004 05:56:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8DuD3h058659; Mon, 8 Nov 2004 05:56:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8DuCRR058649 for ; Mon, 8 Nov 2004 05:56:12 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 8 Nov 2004 13:56:05 +0000 Message-ID: <418F7AF4.6040203@isode.com> Date: Mon, 08 Nov 2004 13:56:04 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kael CC: ietf-imapext@imc.org Subject: Re: Question about the SORT and THREAD extensions References: <418CD4D1.1010902@alussinan.org> In-Reply-To: <418CD4D1.1010902@alussinan.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: kael wrote: > Hello, > > Can [could] the SORT and THREAD extensions handle messages like this > http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html > ? If you asking about grouping by message age, than the answer is "yes". The SORT extension would be sufficient for this. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8APP3q034630; Mon, 8 Nov 2004 02:25:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8APPVM034629; Mon, 8 Nov 2004 02:25:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8APJw4034482 for ; Mon, 8 Nov 2004 02:25:20 -0800 (PST) (envelope-from dave@cridland.net) Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 25EDF154009; Mon, 8 Nov 2004 10:25:08 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Alexey Melnikov Cc: Cyrus Daboo , IMAP Extensions WG , Timo Sirainen Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> <418CC9CF.9000103@isode.com> In-Reply-To: <418CC9CF.9000103@isode.com> Message-ID: <20041108102508.6002.72763.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 08 Nov 2004 10:25:08 +0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat Nov 6 12:55:43 2004, Alexey Melnikov wrote: > Timo Sirainen wrote: >> On 1.11.2004, at 20:09, Cyrus Daboo wrote: >>>> I thought clients weren't allowed to make up their own >>>> annotation entry >>>> names? Or what does this mean? >>> >>> >>> If a client wants to create a 'boolean' (on/off) type property >>> associated with a message it has two options: use an IMAP keyword >>> (either private or registered), or create a vendor (or new >>> standard) annotation entry. The former gives no control over >>> private/shared state, whereas the latter does. So if there is a >>> specific need for such a property that does need explicit >>> private/shared behavior then the client can use annotations in >>> lieu of IMAP keywords. >> >> >> I thought vendor namespaces meant that servers could create them, >> not clients. Maybe put at the beginning of 2.2.1 something like: >> >> Vendor namespaces can be created by either clients or servers. > > Yes. > >> Servers MUST(?) support new namespaces created by clients. > > I think this should be "SHOULD". We want to encourage ANNOTATE > servers. Implementing a read-only ANNOTATE is much easier. > > Yes, but the need for clients to store vendor-private stuff in a nice, neat, semi-interoperable manner really shouldn't be underestimated. Dropping this to a SHOULD is perhaps too far. I'd personally suggest that if the server supports read-write annotations, it MUST support creation of arbitrary, non-operational attributes. The alternative is to encourage clients to avoid them entirely, either via keywords, which, having no namespace, have the potential to clash, or via messages containing client-specific data within. Both are effectively a poor emulation of ANNOTATE. I said "semi-interoperable" earlier, and this is such an awful term it probably needs some explanation. What I mean is that: a) The various client-specific annotations don't actually interfere with each other. You're not faced with keywords that your client might intend using for something else, you're not faced with mailboxes containing "special" messages. b) It's a lot easier to switch a client from using a client-specific usage of ANNOTATE into a standard usage of ANNOTATE, than to switch a client from using Something Weird to ANNOTATE. c) Chances are that several clients will spontaneously interoperate by deliberately using each other's client-specific extensions. (They do this with their local configurations already, remember - this would be a lot easier.) Dave. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA80SgEB025870; Sun, 7 Nov 2004 16:28:42 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA80SgxM025869; Sun, 7 Nov 2004 16:28:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA80SfWR025850 for ; Sun, 7 Nov 2004 16:28:41 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-25-163.bchsia.telus.net (d154-5-25-163.bchsia.telus.net [154.5.25.163]) (authenticated bits=0) by orthanc.ca (8.13.1/8.13.1) with ESMTP id iA80STOO079934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2004 17:28:31 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Sun, 07 Nov 2004 16:28:28 -0800 From: Lyndon Nerenberg To: lemonade@ietf.org, IMAP Extensions WG Subject: Re: Comments about CLEARIDLE Message-ID: In-Reply-To: <418E58DE.4000401@isode.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.n okia.com> <418E4C25.6090103@isode.com> <418E58DE.4000401@isode.com> X-Mailer: Mulberry/4.0.0a2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-WEiAPG-Metrics: orthanc.ca 1072; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-11-7 5:18 PM +0000 Alexey Melnikov wrote: > > One thing the needs discussing is whether the problem of receiving > flag changes/new mail notifications for multiple mailboxes (over a > single connection) is worth solving. I frankly don't know for sure. It has been brought up enough times over the last five years that I am convinced it is. I wrote a non-published draft a few years back that proposed a solution to the multiple-mailbox newmail notification problem. And since the issue has come up once again over the last few months I have updated the draft and will submit it after the IETF. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7HIkal051435; Sun, 7 Nov 2004 09:18:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7HIk2O051434; Sun, 7 Nov 2004 09:18:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7HIi4G051391 for ; Sun, 7 Nov 2004 09:18:45 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 7 Nov 2004 17:18:23 +0000 Message-ID: <418E58DE.4000401@isode.com> Date: Sun, 07 Nov 2004 17:18:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Michael.Wener@nokia.com CC: lemonade@ietf.org, IMAP Extensions WG Subject: Comments about CLEARIDLE References: <225A4E03D0EE5245A5C5F7E7B7C1F27A015EAA94@daebe005.americas.nokia.com> <418E4C25.6090103@isode.com> In-Reply-To: <418E4C25.6090103@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Also crossposting this to IMAPEXT.] > Clearidle (See attached) > The IMAPRev4 specification supports unsolicited responses being sent > to a client at any time. The IDLE specification defines a way for a > client to sit in an idle connection waiting to receive these > responses. This document clarifies and extends the set of responses > that a client may receive while in the idle state. The desire is to > allow a client to predict exactly what set of unsolicited responses > it can rely on receiving when listening on an idle connection. One thing the needs discussing is whether the problem of receiving flag changes/new mail notifications for multiple mailboxes (over a single connection) is worth solving. I frankly don't know for sure. I will try to emphasize some specific technical issues with this document. >2.1 LIST Response > > Currently the LIST response occurs as the result of a LIST command. > This document modifies the syntax of a LIST response and also defines > it's occurrence as a legal unsolicited response that could be received > on IDLE connections associated with a user. > > Two new name attributes are defined: > > \Deleted > The mailbox has been deleted and no longer exists. After a LIST > response with this attribute is seen the server will no longer > show the named folder in any LIST commands. There MUST NOT be > any other name attributes sent along with this attribute. I suggest you review the LISTEXT extension (currently draft-ietf-imapext-list-extensions-10.txt). \Deleted is the same as \NonExistent. > \Renamed > The mailbox has been renamed. A second LIST response MUST > immediately follow indicating the new name. [...] > 3) If a folder is renamed two LIST responses are sent. The first > indicating the old name and a \Renamed attribute and a second > response MUST immediately follow the first indicating the new name. This might be less obvious for people not following IMAPEXT, but there was a proposal to have REFERRAL data returned in LIST responses. It serves exactly this purpose. See , item # 5. It also avoids the proposed hack (sorry, I can't find a better word) of tying two LIST responses together. >2.2 FETCH Response > > Currently the FETCH response occurs as the result of a FETCH command > or as an unsolicited response on an IDLE connection. This document > clarifies exactly what form of response should be sent when the > specified events occur on the server. [...] > New Message Arrival > An unsolicited FETCH response with envelope, body, flag and uid > data MUST be sent on all IDLE connections. > > Example: > S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...)) Actually no, BODY must not be in this list, as it is potentially very big. You surely wouldn't want to push a 10Mb message to you cell phone. I also suggest to replace the ENVELOPE with the BODYSTRUCTURE. >3.1.1 Mailbox Identification Syntax > > While in the Authenticated state there is no way to implicitly > determine which mailbox the response applies to. While this is not a > problem for some responses such as the LIST response it does pose a > problem for responses that are mail message specific. [...] > Example: > S: * 22 EXISTS (imap://mail/inbox) Why can't we just you the STATUS response? S: * STATUS INBOX (MESSAGES 231 RECENT 7) Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA74aOSH089038; Sat, 6 Nov 2004 20:36:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA74aOQS089037; Sat, 6 Nov 2004 20:36:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from s-utl01-dcpop.stsn.com (s-utl01-dcpop.stsn.com [63.240.218.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA74aMTU089018 for ; Sat, 6 Nov 2004 20:36:23 -0800 (PST) (envelope-from lisa@osafoundation.org) Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110623362713290 for ; Sat, 06 Nov 2004 23:36:27 -0500 Received: from [10.67.86.24] ([10.67.86.24]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Nov 2004 23:36:26 -0500 In-Reply-To: <418D1854.10304@isode.com> References: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> <418D1854.10304@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9050E7CC-3076-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Proposed agenda for IMAPEXT Date: Sat, 6 Nov 2004 20:36:16 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 07 Nov 2004 04:36:27.0085 (UTC) FILETIME=[58168FD0:01C4C483] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Nov 6, 2004, at 10:30 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > ... >> >> 1. Sorting, threading, and viewing (to be dealt with by one or more >> mechanisms) >> - >> >> status: still blocked on comparator (as is i18n draft) > > Are you proposing that the WG discusses the i18 draft? Not really -- just to explain the status, because I dont' think there's anything to discuss. (Let me know if I'm wrong!) lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6IVCPf012317; Sat, 6 Nov 2004 10:31:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6IVCeN012316; Sat, 6 Nov 2004 10:31:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6IVBka012310 for ; Sat, 6 Nov 2004 10:31:12 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [62.188.134.182] (1Cust182.tnt5.lnd4.gbr.da.uu.net [62.188.134.182]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 18:31:06 +0000 Message-ID: <418D1854.10304@isode.com> Date: Sat, 06 Nov 2004 18:30:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Proposed agenda for IMAPEXT References: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> In-Reply-To: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'm sorry this is so late, but here it is anyway. Suggestions > welcome. Note the new ACL draft link which hasn't been commented on > here on the list -- if you get a chance to read that draft by Monday > that would be super. > > Agenda for IMAPEXT meeting at 61st IETF > Monday, Nov 8, 1530-1730 > > 0. Agenda bashing, find note taker and jabber scribe: > (10 minutes) > > 1. Sorting, threading, and viewing (to be dealt with by one or more > mechanisms) > - > status: still blocked on comparator (as is i18n draft) Are you proposing that the WG discusses the i18 draft? > - extensions-10.txt> > Barry Leiba will discuss > Still issues on /Placeholder from last meeting, which Alexey and > Cyrus were tasked with resolving > (40 minutes) > > 2. Access Control Lists > - > Not updated since last meeting -- probably still blocked on LISTEXT. Yes. I have some local changes, but LISTEXT and draft-ietf-imapext-2086upd-00.txt take higher priorities right now. > - > > READ THIS if you're coming to the meeting! Or even if you're not. Yes, please. > It hasn't been discussed on the list yet. > (30 minutes) I am not sure that it will take that long, I think the document is pretty much done. > 3. Message-level annotations > - -11.txt> > Changes since last meeting... > Open issue: use of the 'm' bit for ACL of private annotations More specifically use of the "m" bit for reading of private annotations. > At least one more draft required > (40 minutes) Hopefully this discussion would be short as well. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GU8HT056221; Sat, 6 Nov 2004 08:30:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GU8gH056220; Sat, 6 Nov 2004 08:30:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GU7xG056202 for ; Sat, 6 Nov 2004 08:30:07 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:30:06 +0000 Message-ID: <418CFC05.5030903@isode.com> Date: Sat, 06 Nov 2004 16:29:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: STATUS command as an LISTEXT extension Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't want to start a religious war on whether STATUS should be allowed to be a LISTEXT extension (because it can be as slow as SELECT for some mailstores/implementations), but below I have an example of how this might look like using existing LISTEXT syntax: ABNF: return-option =/ status-option status-option = "STATUS=" status-att-comlist status-att-comlist = status-att *("," status-att) ;; Comma separated list of status-att status-item-data = "STATUS" SP "(" status-att-list ")" ;; conforms to the mbox-list-extended-item-data ;; syntax Example: C: CA3 LIST "" "%" RETURN (STATUS=UIDVALIDITY,UIDNEXT,MESSAGES) S: * LIST (\Marked \NoInferiors) "/" "inbox" ((STATUS (UIDVALIDITY 50505050 MESSAGES 231 UIDNEXT 44292))) S: * LIST () "/" "Foo" ((STATUS (UIDVALIDITY 467676708 MESSAGES 12 UIDNEXT 100))) S: * LIST () "/" "Moo" ((STATUS (UIDVALIDITY 32 MESSAGES 711 UIDNEXT 9560))) S: CA3 OK done Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTj70056010; Sat, 6 Nov 2004 08:29:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GTjwa056009; Sat, 6 Nov 2004 08:29:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTdoL055954 for ; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:29:40 +0000 Message-ID: <418CFBE9.1050308@isode.com> Date: Sat, 06 Nov 2004 16:29:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , "Vladimir A. Butenko" Subject: Outstanding issues for draft-ietf-imapext-2086upd-00 (ACL) References: <200409281246.i8SCkVwb074417@lab.smi.sendmail.com> <41596D6E.3060308@isode.com> In-Reply-To: <41596D6E.3060308@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, I believe there are only two. One relates to whether the "m" right only controls writability of private annotations, or whether it also controls readability. I've sent a separate message on this. The second issue: Which rights are required for the LISTRIGHTS command? Currently the document says: MYRIGHTS - any of the following rights is required to perform the operation: "l", "r", "i", "c", "x", "a".* LISTRIGHTS - same as MYRIGHTS. Some of the existing servers follow this suggestion. Some allow for LISTRIGHTS if "r" and/or "a" is granted. Philip has suggested (and I agree) to only allow LISTRIGHTS when the "a" right is granted, as LISTRIGHTS information is only useful if you can also do SETACL. Also, such information shouldn't be disclosed to users that have insufficient rights. Alexey * - Note, that the STORE related rights ("w", "s", "t", "m" and "n") are not part of this list, because the client must be able to open a mailbox (i.e. "r") before performing a STORE command. The list also used to contain the "e" right (which controls EXPUNGE), I've deleted it for the same reason. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTeEl055962; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GTeM0055961; Sat, 6 Nov 2004 08:29:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GTdoK055954 for ; Sat, 6 Nov 2004 08:29:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:29:28 +0000 Message-ID: <418CFBDE.9030308@isode.com> Date: Sat, 06 Nov 2004 16:29:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: IMAP Extensions WG Subject: Re: Listext References: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> In-Reply-To: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > > 3.1. General principles for returning LIST responses > > Are these a MUST? Especially the "don't return mailbox more than once" > rule? I would like to make the one you've mentioned a MUST. However it is not going to be practical. I think they all SHOULDs. However, if a single LIST command returns more than one extended LIST response for a mailbox, we need to state some safe assumptions for clients, e.g. the client can use mailbox flags from the latest LIST response (and ignore all previous). I don't think many existing client will be able to cope with multiple LIST responses for the same mailbox. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GNUKl052770; Sat, 6 Nov 2004 08:23:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GNURF052765; Sat, 6 Nov 2004 08:23:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GNTSr052756 for ; Sat, 6 Nov 2004 08:23:29 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:23:00 +0000 Message-ID: <418CCC8B.4080907@isode.com> Date: Sat, 06 Nov 2004 13:07:23 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Cyrus Daboo CC: Randall Gellens , IMAP Extensions WG Subject: Re: Moving the ANNOTATE document forward References: <417A9D2F.7090509@isode.com> <6DE76EE79E8374F1DDE56E06@ninevah.local> <0640B86069A1D898E91AE955@ninevah.cyrusoft.com> <417E4A9A.10505@isode.com> In-Reply-To: <417E4A9A.10505@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > The 'm' right controls both read and write access to .priv annotation > > values. When it is on, access to .priv annotations is allowed, when > > it is off, access to .priv annotations is disallowed. > > I still don't like using the "m" right for reading private > annotations, but we can discuss this during face to face meeting. Ok, let me try to describe my concern. From the table in the ANNOTATE document: +===============+===============+===================================+ | | | | | No ACL | read .priv | Any mailbox that can be SELECTED | | | values | or EXAMINED. | | | | | +---------------+---------------+-----------------------------------+ | | | | | With ACL | read .priv | Any mailbox with the 'm' | | | values | ACL right. | | | | | +---------------+---------------+-----------------------------------+ Which means that a well behaving ANNOTATE&ACL-aware client needs to know whether the server supports ACL or not. Why? Because when the client opens a mailbox, it can't assume that private annotations are readable, because for the ACL-aware server the "m" right doesn't control if the mailbox can be SELECT/EXAMINEd or not. Now, if we just say that both private and shared annotations are readable if the mailbox can be SELECT/EXAMINEd (i.e. the ACL "r" right), everything becomes much simpler (and consistent). Cyrus has said: >The other benefit of 'm' as it stands now is that it gives servers a way >to optimise their storage because users without 'm' will never need a >private annotation store for that mailbox. This may be true only for certain types of mailstores, but in general this is not true. Reporting any kind of annotations is trivial, whether the server can store them, or it just generates them on the fly (i.e. read-only private annotations). Checking the right "m" on FETCH just to make sure that private annotations can be read is just more work for the server. Most servers cache user's rights upon mailbox open and never try to refetch ACL for the selected mailbox. I.e. most servers never check ACLs on FETCH. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GMdWm052405; Sat, 6 Nov 2004 08:22:39 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GMdNT052404; Sat, 6 Nov 2004 08:22:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GMY1X052359 for ; Sat, 6 Nov 2004 08:22:34 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:22:07 +0000 Message-ID: <418CC9CF.9000103@isode.com> Date: Sat, 06 Nov 2004 12:55:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Timo Sirainen CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Annotate References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> In-Reply-To: <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 1.11.2004, at 20:09, Cyrus Daboo wrote: > >>> The 'm' right controls both read and write access to .priv >>> annotation >>> values. When it is on, access to .priv annotations is allowed, >>> when >>> it is off, access to .priv annotations is disallowed. >>> >>> Is this really needed? I think private annotations should work the same >>> way as private flags. You can always read them, and you can write >>> them if >>> it's possible to permanently save flags. >> >> In an ACL-aware server there are different ways to control the flag >> state 's' and 'w' bits. As a result I think there should also be a >> way to enable/disable private annotations independently - hence the >> 'm' bit. I know Alexey had some concerns with 'm' too so this is >> still an open issue. > > Well, perhaps it would be useful to have "m" for writing because of > that, but I think "r" would be more logical for reading private > annotations. I agree (a separate message on this is coming). >>> I thought clients weren't allowed to make up their own annotation entry >>> names? Or what does this mean? >> >> >> If a client wants to create a 'boolean' (on/off) type property >> associated with a message it has two options: use an IMAP keyword >> (either private or registered), or create a vendor (or new standard) >> annotation entry. The former gives no control over private/shared >> state, whereas the latter does. So if there is a specific need for >> such a property that does need explicit private/shared behavior then >> the client can use annotations in lieu of IMAP keywords. > > > I thought vendor namespaces meant that servers could create them, not > clients. Maybe put at the beginning of 2.2.1 something like: > > Vendor namespaces can be created by either clients or servers. Yes. > Servers MUST(?) support new namespaces created by clients. I think this should be "SHOULD". We want to encourage ANNOTATE servers. Implementing a read-only ANNOTATE is much easier. >> Here is some alternate text for the above paragraph that I am >> proposing to use instead. Note this also includes a sentence to >> address the first point you made: >> >> Clients that need to implement a property on a message that is >> either 'on' or 'off' and which requires separate private and shared >> state can use an annotation to represent that property as opposed >> to using IMAP Keywords, which cannot reliably discriminate the >> private and shared state. However, clients MUST NOT use annotations >> to replace existing IMAP flag behavior, which would cause >> interoperability problems with non-ANNOTATE aware clients. >> >> If that is not suitable, please suggest some other text or >> clarifications. > > Looks good to me. Looks good to me too. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GD5Ye047177; Sat, 6 Nov 2004 08:13:05 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GD5Eu047170; Sat, 6 Nov 2004 08:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GD2P6047128 for ; Sat, 6 Nov 2004 08:13:03 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.58.150] (1Cust150.tnt105.lnd4.gbr.da.uu.net [213.116.58.150]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 6 Nov 2004 16:12:22 +0000 Message-ID: <418C19CC.3030600@isode.com> Date: Sat, 06 Nov 2004 00:24:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Updated draft-ietf-imapext-2086upd (ACL) Content-Type: multipart/mixed; boundary="------------010108000909080309050706" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------010108000909080309050706 Content-type: text/plain; charset="us-ascii" I forgot to submit it. I think I've addressed all but one issue raised by Philip. I will send a separate message on this. Apart from the issue, I think the document is ready for Last Call. Alexey --------------010108000909080309050706 Content-type: text/plain; name="draft-ietf-imapext-2086upd-01.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="draft-ietf-imapext-2086upd-01.txt" IMAPEXT Working Group A. Melnikov Internet Draft Editor Document: draft-ietf-imapext-2086upd-01.txt November 2004 Updates: 2086, <<3501?>> Expires: May 2005 IMAP4 ACL extension - updated list of rights Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Distribution of this draft is unlimited. Abstract The ACL (Access Control List) extension [RFC2086] of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be manipulated through the IMAP protocol. This document updates the list of rights defined in RFC 2086. It also clarifies which rights are required for different IMAP commands. 1. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. In all examples "/" character is used as hierarchy separator. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 2. Introduction and Overview The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document updates Section 3 of the RFC 2086. It also clarifies different aspects of the RFC 2086, in particular use of UTF-8 in identifiers, which rights are required for different IMAP4 commands; how READ-WRITE/READ-ONLY response codes are related to ACL>> 3. Access Control This section replaces Section 3 of the RFC 2086. The ACL extension is present in any IMAP4 implementation which returns "ACL" as one of the supported capabilities to the CAPABILITY command. A server implementation conformant to this document MUST also return rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability response. An access control list is a set of pairs. An ACL applies to a mailbox. Identifier is a UTF-8 string. The identifier "anyone" is reserved to refer to the universal identity (all authentications, including anonymous). All user name strings accepted by the LOGIN or AUTHENTICATE commands to authenticate to the IMAP server are reserved as identifiers for the corresponding user. Identifiers starting with a dash ("-") are reserved for "negative rights", described below. All other identifier strings are interpreted in an implementation- defined manner. Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Letters are reserved for ''standard'' rights, listed below. The set of standard rights may only be extended by a standards-track document. Digits are reserved for implementation or site defined rights. The currently defined standard rights are (note, that the list below doesn't list all commands that use a particular right): l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) r - read (SELECT the mailbox, perform STATUS) s - keep seen/unseen information across sessions (set or clear \SEEN flag via STORE, APPEND or COPY) w - write (set or clear flags other than \SEEN and \DELETED via STORE, APPEND or COPY) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP4 itself. c - create mailboxes (CREATE new sub-mailboxes in any implementation-defined hierarchy, parent mailbox for the new mailbox name in RENAME) x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag during APPEND/COPY) e - perform EXPUNGE and expunge as a part of CLOSE d - This right is defined for backward compatibility with ACL extension (RFC 2086). If a client sets "d" right, the server MUST set "x", "e" and "t" rights. When the client clears the "d" right, the server MUST clear "x", "e" and "t" rights. When all three of "x", "e" and "t" are set, the server MUST return "d" right in response to a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, "d" right MUST NOT be returned in a LISTRIGHTS response. a - administer (perform SETACL/DELETEACL/GETACL) m - <>write private annotations [ANNOTATE] n - write shared annotations [ANNOTATE] An implementation may tie rights together or may force rights to always or never be granted to particular identifiers. For example, in an implementation that uses unix mode bits, the rights "swite" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. It is possible for multiple identifiers in an access control list to apply to a given user (or other authentication identity). For example, an ACL may include rights to be granted to the identifier matching the user, one or more implementation-defined identifiers matching groups which include the user, and/or the identifier "anyone". How these rights are combined to determine the user's access is implementation-defined. An implementation may choose, for example, to use the union of the rights granted to the applicable identifiers. An implementation may instead choose, for example, to only use those rights granted to the most specific identifier present in the ACL. A client may determine the set of rights granted to the logged-in user for a given mailbox by using the MYRIGHTS command. When an identifier in an ACL starts with a dash ("-"), that indicates that associated rights are to be removed from the identifier that is prefixed by the dash. This is referred to as a "negative right". This differs from DELETEACL in that a negative right is added to the ACL, and is a part of the calculation of the rights. Let's assume that an identifier "fred" refers to a user with login "fred". If the identifier "-fred" is granted the "w" right, that indicates that the "w" right is to be removed from users matching the identifier "fred", even though the user "fred" might have the "w" right as a consequence of some other identifier in the ACL. A DELETEACL of "fred" simply deletes the identifier "fred" from the ACL; it does not affect any rights that the user "fred" may get from another entry in the ACL. Server implementations are not required to support "negative right" identifiers. 4. Rights required to perform different IMAP4rev1 commands Before executing a command an ACL compliant server must check which rights are required to perform it. This section groups command by functions they perform and list the rights required. It also gives the detailed description of any special processing required. The table below summarizes different rights or their combinations that are required in order to perform different IMAP operations. As it is not always possible to express complex right checking and interactions, the description after the table should be used as the primary reference. +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ | LIST | + | | | | | | | | | | | | | SUBSCRIBE | * | | | | | | | | | | | * | | UNSUBSCRIBE | | | | | | | | | | | | + | | LSUB | * | | | | | | | | | | | * | | CREATE (for parent) | | | | | | + | | | | | | | | DELETE | | | | | | | + | | | | | | | RENAME | | | | | | + | + | | | | | | | COPY/APPEND | | | ? | ? | + | | | ? | | | | | | EXPUNGE/CLOSE | | | | | | | | | + | | | | |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | | FETCH | | | ? | | | | | | | | | | | STORE flags | | | ? | ? | | | | ? | | | | | | SETACL/DELETEACL | | | | | | | | | | + | | | | GETACL | | | | | | | | | | + | | | | MYRIGHTS/LISTRIGHTS | | | | | | | | | | | + | | +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ Legend: + - The right is required * - Only one of the rights marked with * is required (see description below) ? - The right is optional (see description below) "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is required "None" - No rights required to perform the command Listing and subscribing/unsubscribing mailboxes: LIST - "l" right is required. Note, that if the user has "l" right to a mailbox "A/B", but not to its parent mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, for example: C: A777 LIST "" * S: * LIST (\NoInferiors) "/" "A/B" S: * LIST () "/" "C" S: * LIST (\NoInferiors) "/" "C/D" S: A777 OK LIST completed SUBSCRIBE - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. UNSUBSCRIBE - no rights required to perform this operation. LSUB - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. Mailbox management: CREATE - "c" right on a nearest existing parent mailbox. When a new mailbox is created it SHOULD inherit the ACL from the parent mailbox (if one exists) in the defined hierarchy. DELETE - "x" right on the mailbox. RENAME - Moving a mailbox from one parent to another requires "x" right on the mailbox itself and "c" right for the new parent. For example, if the user wants to rename mailbox named "A/B/C" to "D/E", the user must have "x" right for the mailbox "A/B/C" and "c" right for the mailbox "D". The RENAME command SHOULD NOT change the ACLs on the renamed mailbox and submailboxes. Copying or appending messages: Before performing a COPY/APPEND command the server MUST check if the user has "i" right for the target mailbox. If the user doesn't have "i" right, the operation fails. Otherwise for each copied/appended message the server MUST check if the user has "t" right - when the message has \Deleted flag set "s" right - when the message has \Seen flag set "w" right for all other message flags. Only when the user has a particular right the corresponding flags are stored for the newly created message. The server MUST NOT fail a COPY/APPEND if the user has no rights to set a particular flag. Example: C: A003 MYRIGHTS TargetMailbox S: * MYRIGHTS TargetMailbox rwis S: A003 OK Myrights complete C: A004 FETCH 1:3 (FLAGS) S: * 1 FETCH (FLAGS (\Draft \Deleted) S: * 2 FETCH (FLAGS (\Answered) S: * 3 FETCH (FLAGS ($Forwarded \Seen) S: A004 OK Fetch Completed C: A005 COPY 1:3 TargetMailbox S: A005 OK Copy completed C: A006 SELECT TargetMailbox ... S: A006 Select Completed Let's assume that the copied messages received message numbers 77:79. C: A007 FETCH 77:79 (FLAGS) S: * 77 FETCH (FLAGS (\Draft)) S: * 78 FETCH (FLAGS (\Answered)) S: * 79 FETCH (FLAGS ($Forwarded \Seen)) S: A007 OK Fetch Completed \Deleted flag was lost on COPY, as the user has no "t" right in the target mailbox. If the MYRIGHTS command with the tag A003 would have returned: S: * MYRIGHTS TargetMailbox rsti the response from the FETCH with the tag A007 would have been: C: A007 FETCH 77:79 (FLAGS) S: * 77 FETCH (FLAGS (\Deleted)) S: * 78 FETCH (FLAGS ()) S: * 79 FETCH (FLAGS (\Seen)) S: A007 OK Fetch Completed In the latter case \Answered, $Forwarded and \Draft flags were lost on COPY, as the user has no "w" right in the target mailbox. Expunging the selected mailbox: EXPUNGE - "e" right on the selected mailbox. CLOSE - "e" right on the selected mailbox. If the server is unable to expunge the mailbox because the user doesn't have the "e" right, the server MUST ignore expunge request, close the mailbox and return tagged OK response. Fetch information about a mailbox and its messages: SELECT/EXAMINE/STATUS - "r" right on the mailbox. FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, if the current user doesn't have "s" right. Changing flags: STORE - the server MUST check if the user has "t" right - when the user modifies \Deleted flag "s" right - when the user modifies \Seen flag "w" right for all other message flags. STORE operation SHOULD NOT fail if the user has rights to modify at least one flag specified in the STORE, as the tagged NO response to a STORE command is not handled very well by deployed clients. Changing ACLs: SETACL/DELETEACL - "a" right on the mailbox. Reading ACLs: GETACL - "a" right on the mailbox. MYRIGHTS - any of the following rights is required to perform the operation: "l", "r", "i", "c", "x", "a". <> LISTRIGHTS - same as MYRIGHTS. <> <> 5. Formal Syntax This document doesn't change the formal syntax of commands/ responses defined in the Section 6 of RFC 2086. However, the "identifier" production is now allowed to carry any UTF-8 string. Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4] or [LISTEXT]. Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. rights_capa = "RIGHTS=" new_rights ;; RIGHTS=... capability new_rights = atom ;; MUST include "t", "e", "x", "m" and "n" 6. Security Considerations An implementation must make sure the ACL commands themselves do not give information about mailboxes with appropriately restricted ACL's. For example, a GETACL command on a mailbox for which the user has insufficient rights should not admit that the mailbox exists, much less return the mailbox's ACL. LISTRIGHTS command MUST NOT check that a particular identifier exists, however it SHOULD recognize special identifiers like "anyone". IMAP clients implementing ACL that are able to modify ACLs SHOULD warn a user that wants to give full access (or even just "a" right) to the special identifier "anyone". 7. Other considerations 7.1. Additional requirements and Implementation notes 7.1.1. Servers This document defines an additional capability that is used to announce the list of extra rights (excluding the ones defined in the RFC 2086) supported by the server. The set of rights MUST include "t", "e", "x", "m" and "n". Note, that the extra rights can appear in any order. Example: C: 1 capability S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texnm S: 1 OK completed The presence of the "RIGHTS=" capability also declares that the server always returns the MYRIGHTS untagged response upon SELECT/EXAMINE. The MYRIGHTS response SHOULD also be sent any time when the server detects that the set of rights allowed for the logged in user in the opened mailbox has changed. Any server implementing an ACL extension MUST accurately reflect the current user's rights in FLAGS and PERMANENTFLAGS responses. Example: C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * MYRIGHTS INBOX rwis S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited S: A142 OK [READ-WRITE] SELECT completed Servers MAY cache the rights a user has on a mailbox when the mailbox is selected, so that if a client's rights on a mailbox are changed with SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, EXPUNGE) might not reflect the changed rights until the mailbox is re-selected. If the server checks the rights on each command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if they have changed. An ACL server MAY modify one or more ACL for one or more identifier as a side effect of modifying the ACL specified in a SETACL/DELETEACL. If the server does that it MUST send untagged ACL response to notify the client about the changes made. 7.1.2. Clients A client implementation that allows a user to read and update ACLs MUST preserve unrecognized rights that it doesn't allow the user to change when updating the rights. Otherwise the client may unintentionally remove permissions. 7.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes A particular ACL server implementation may allow "shared multiuser access" to some mailboxes. "Shared multiuser access" to a mailbox means that multiple different users are able to access the same mailbox, if they have proper access rights. "Shared multiuser access" to the mailbox doesn't mean that the ACL for the mailbox is currently set to allow access by multiple users. Let's denote a "shared multiuser write access" as a "shared multiuser access" when a user may be granted flag modification rights (any of "w", "s" or "t"). Section 4 describes which rights are required for modifying different flags. If the ACL server implements some flags as shared for a mailbox (i.e., the ACL for the mailbox may be set up so that changes to those flags are visible to another user), let's call the set of rights associated with these flags (as described in Section 4) for that mailbox collectively as "shared flag rights". Note, that "shared flag rights" set MAY be different for different mailboxes. If the server doesn't support "shared multiuser write access" to a mailbox or doesn't implement shared flags on the mailbox, "shared flag rights" for the mailbox is defined to be the empty set. Example 1: Mailbox "banan" allows "shared multiuser write access" and implements flags \Deleted, \Answered and $MDNSent as shared flags. "Shared flag rights" for the mailbox "banan" is a set containing flags "t" (because system flag \Deleted requires "t" right) and "w" (because both \Answered and $MDNSent require "w" right). Example 2: Mailbox "apple" allows "shared multiuser write access" and implements \Seen system flag as shared flag. "Shared flag rights" for the mailbox "apple" contains "s" right, because system flag \Seen requires "s" right. Example 3: Mailbox "pear" allows "shared multiuser write access" and implements flags \Seen, \Draft as shared flags. "Shared flag rights" for the mailbox "apple" is a set containing flags "s" (because system flag \Seen requires "s" right) and "w" (because system flag \Draft requires "w" right). The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if none of the following rights is granted to the current user: "i", "e" and "shared flag rights". The server SHOULD include a READ-WRITE prefix in the tagged OK response if at least one of the "i", "e" or "shared flag rights" is granted to the current user. Example 1 (continued): The user that has "lrs" rights for the mailbox "banan". The server returns READ-ONLY response code on SELECT, as none of "iewt" rights is granted to the user. Example 2 (continued): The user that has "rit" rights for the mailbox "apple". The server returns READ-WRITE response code on SELECT, as the user has "i" right. Example 3 (continued): The user that has "rset" rights for the mailbox "pear". The server returns READ-WRITE response code on SELECT, as the user has "e" and "s" rights. 8. References 8.1. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, January 1997 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", RFC 2279, Alis Technologies, January 1998. 8.2. Informative References [ANNOTATE] Gellens, R. and C. Daboo, "IMAP ANNOTATE Extension", work in progress, draft-ietf-imapext-annotate-XX.txt 9. Acknowledgment This document is an update to the RFC 2086 written by John G. Myers. Editor appreciates comments received from Mark Crispin, Chris Newman, Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg, Larry Greenfield, Robert Siemborski, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel, Philip Guenther and other participants of the IMAPEXT working group. 10. Editor's Address Alexey Melnikov email: alexey.melnikov@isode.com Isode Limited 11. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Appendix A. Changes since RFC 2086 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 2. Specified that mailbox deletion is controled by the "x" right and EXPUNGE is controlled by the "e" right. 3. Clarified that RENAME requires the "c" right for the new parent and the "x" right for the old name. 4. Added the "t" right that controls STORE \Deleted. Redefined "d" to be a macro for "e", "x" and "t". 5. Specified that the "a" right also controls DELETEACL. 6. Specified that the "r" right also controls STATUS. 7. Removed the requirement to check the "r" right for CHECK, SEARCH and FETCH, as this is required for SELECT/EXAMINE to be successful. 8. LISTRIGHTS requires same rights as MYRIGHTS. 9. Deleted "PARTIAL", this is a deprecated feature of RFC1730. 10. Specified that the "w" right controls setting flags other than \Seen and \Deleted on APPEND. Also specified that the "s" right controls the \Seen flag and that the "t" right controls the \Deleted flag. 11. SUBSCRIBE is NOT allowed with the "r" right. 12. Specified that the "l" right controls SUBSCRIBE. 13. GETACL is NOT allowed with the "r" right, even though there are several implementations that allows that. If a user only has "r" right, GETACL can disclose information about identifiers existing on the mail system. 14. Added new section that describes which rights are required and/or checked when performing various IMAP commands. 15. Added mail client security considerations when dealing with special identifier "anyone". 16. Clarified that negative rights are not the same as DELETEACL. 17. Added note that a server can modify an ACL for any identifier(s) as a side effect of performing SETACL/DELETEACL. Also specified that the server MUST send untagged ACL response if it does that. 18. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY response codes. 19. Added "Compatibility with RFC 2086" section. 20. Added "Implementation Notes" section. 21. Updated "References" section. 22. Added requirement for a SELECT/EXAMINE to return the MYRIGHTS response. 23. Added the "m" and "n" rights for ANNOTATE. Appendix B. Compatibility with RFC 2086 This section gives guidelines how an existing RFC 2086 server implementation may be updated to comply with this document. This document replaces the "d" right with 3 new different rights "x", "t" and "e". The server should implement one of the following two approaches to handle "d" and the new rights that have replaced it. a). Tie "x", "t" and "e" together - almost no changes. b). Implement separate "x", "t" and "e". Return "d" right in a LIST response containing ACL information when all three of "x", "t" and "e" are granted. Additional work required to implement ACL2 when RFC 2086 is already implemented: 1). Send the MYRIGHTS untagged response on a successful SELECT/EXAMINE. Also check Sections 7.1 and 7.2, as well as the appendix A to see other changes required. Server implementors should check which rights are required to invoke different IMAP4 commands as described in Section 4. --------------010108000909080309050706-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DgCms081182; Sat, 6 Nov 2004 05:42:12 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6DgCbf081181; Sat, 6 Nov 2004 05:42:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DgBcf081173 for ; Sat, 6 Nov 2004 05:42:12 -0800 (PST) (envelope-from kael@alussinan.org) Received: from [82.224.193.175] (bobillot-5-82-224-193-175.fbx.proxad.net [82.224.193.175]) by postfix4-2.free.fr (Postfix) with ESMTP id D0D6B23579A for ; Sat, 6 Nov 2004 14:42:12 +0100 (CET) Message-ID: <418CD4D1.1010902@alussinan.org> Date: Sat, 06 Nov 2004 14:42:41 +0100 From: kael User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Question about the SORT and THREAD extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Can [could] the SORT and THREAD extensions handle messages like this http://www.deftone.com/blogzilla/archives/new_thunderbird_feature_message_grouping.html ? -- kael http://del.icio.us/ubi.quito.us Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LAVu1047545; Fri, 5 Nov 2004 13:10:31 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5LAVi6047544; Fri, 5 Nov 2004 13:10:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LAU8C047509 for ; Fri, 5 Nov 2004 13:10:30 -0800 (PST) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iA5LAAZe031233 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 5 Nov 2004 13:10:12 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <1028D855-2F6F-11D9-87AD-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: agenda@ietf.org, IMAP Extensions WG From: Lisa Dusseault Subject: Proposed agenda for IMAPEXT Date: Fri, 5 Nov 2004 13:10:04 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm sorry this is so late, but here it is anyway. Suggestions welcome. Note the new ACL draft link which hasn't been commented on here on the list -- if you get a chance to read that draft by Monday that would be super. Agenda for IMAPEXT meeting at 61st IETF Monday, Nov 8, 1530-1730 0. Agenda bashing, find note taker and jabber scribe: (10 minutes) 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) - status: still blocked on comparator (as is i18n draft) - Barry Leiba will discuss Still issues on /Placeholder from last meeting, which Alexey and Cyrus were tasked with resolving (40 minutes) 2. Access Control Lists - Not updated since last meeting -- probably still blocked on LISTEXT. - READ THIS if you're coming to the meeting! Or even if you're not. It hasn't been discussed on the list yet. (30 minutes) 3. Message-level annotations - Changes since last meeting... Open issue: use of the 'm' bit for ACL of private annotations At least one more draft required (40 minutes) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5GQfmg028445; Fri, 5 Nov 2004 08:26:41 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5GQf2F028444; Fri, 5 Nov 2004 08:26:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5GQeWl028435 for ; Fri, 5 Nov 2004 08:26:40 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 5 Nov 2004 16:26:41 +0000 Message-ID: <418BA9BF.4060906@isode.com> Date: Fri, 05 Nov 2004 16:26:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , lemonade@ietf.org Subject: Not being able to attend IMAPEXT/Lemonade Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Due to little trick that UK Home Office has played on me, I am still not in possession of my passport. My flight is tomorrow at noon. So I will most likely miss the IMAPEXT and Lemonade meetings. I will try to participate in jabber. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IiMWo041202; Mon, 1 Nov 2004 10:44:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1IiMOS041201; Mon, 1 Nov 2004 10:44:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IiLbI041089 for ; Mon, 1 Nov 2004 10:44:21 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 165971CACC81; Mon, 1 Nov 2004 20:44:13 +0200 (EET) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id AA0DE1C13488; Mon, 1 Nov 2004 20:44:06 +0200 (EET) In-Reply-To: <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16-768365339" Message-Id: <04443C18-2C36-11D9-A114-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: Annotate Date: Mon, 1 Nov 2004 20:44:09 +0200 To: Cyrus Daboo X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-16-768365339 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 1.11.2004, at 20:09, Cyrus Daboo wrote: >> The 'm' right controls both read and write access to .priv >> annotation >> values. When it is on, access to .priv annotations is allowed, >> when >> it is off, access to .priv annotations is disallowed. >> >> Is this really needed? I think private annotations should work the >> same >> way as private flags. You can always read them, and you can write >> them if >> it's possible to permanently save flags. > > In an ACL-aware server there are different ways to control the flag > state 's' and 'w' bits. As a result I think there should also be a way > to enable/disable private annotations independently - hence the 'm' > bit. I know Alexey had some concerns with 'm' too so this is still an > open issue. Well, perhaps it would be useful to have "m" for writing because of that, but I think "r" would be more logical for reading private annotations. >> I thought clients weren't allowed to make up their own annotation >> entry >> names? Or what does this mean? > > If a client wants to create a 'boolean' (on/off) type property > associated with a message it has two options: use an IMAP keyword > (either private or registered), or create a vendor (or new standard) > annotation entry. The former gives no control over private/shared > state, whereas the latter does. So if there is a specific need for > such a property that does need explicit private/shared behavior then > the client can use annotations in lieu of IMAP keywords. I thought vendor namespaces meant that servers could create them, not clients. Maybe put at the beginning of 2.2.1 something like: Vendor namespaces can be created by either clients or servers. Servers MUST(?) support new namespaces created by clients. > Here is some alternate text for the above paragraph that I am > proposing to use instead. Note this also includes a sentence to > address the first point you made: > > Clients that need to implement a property on a message that is > either 'on' or 'off' and which requires separate private and shared > state can use an annotation to represent that property as opposed > to using IMAP Keywords, which cannot reliably discriminate the > private and shared state. However, clients MUST NOT use annotations > to replace existing IMAP flag behavior, which would cause > interoperability problems with non-ANNOTATE aware clients. > > If that is not suitable, please suggest some other text or > clarifications. Looks good to me. --Apple-Mail-16-768365339 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBhoP5yUhSUUBViskRAh+PAKCCId8BaxYaoIcNXuF8FIvgqYHpCwCfQRJI GHzf0eAaHqgR8gWem/qbgJ0= =ZhJZ -----END PGP SIGNATURE----- --Apple-Mail-16-768365339-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I9PTj021240; Mon, 1 Nov 2004 10:09:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1I9Pit021239; Mon, 1 Nov 2004 10:09:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I9KOF021185 for ; Mon, 1 Nov 2004 10:09:24 -0800 (PST) (envelope-from daboo@isamet.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id iA1H3g6E015095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2004 12:03:44 -0500 Date: Mon, 01 Nov 2004 13:09:06 -0500 From: Cyrus Daboo To: Timo Sirainen , IMAP Extensions WG Subject: Re: Annotate Message-ID: <9B7E8DA7E98A6ABF7ADB73CC@ninevah.cyrusoft.com> In-Reply-To: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> References: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> X-Mailer: Mulberry/4.0.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Monday, November 1, 2004 7:27:45 PM EST +0200 Timo Sirainen wrote: > Some comments: > > Clients MUST NOT use annotations in lieu of equivalent IMAP base > specification facilities. For example, use of a "seen" flag in the > vendor namespace together with ".PEEK" in fetches. Such behaviour > would significantly reduce IMAP interoperability. > > I don't understand the example. What does .PEEK fetches have to do with > \Seen flag, except without it the \Seen flag might change? In this example we are saying that a 'rogue' client might choose to bypass the standard IMAP seen behavior by using .PEEK fetches (that do not change the IMAP \Seen flag) and instead use their own private seen annotation that is used to indicate seen state in that client. That hurts interop because a message that appears seen in one client, does not appear seen in another. What I think will be best is to remove the text you quoted, and instead insert a comment in the flags section (actually this will appear in the new text I propose below in response to your last point). > If a server supports annotations, then it MUST store all annotation > data permanently, i.e. there is no concept of 'session only' > annotations that would correspond to the behaviour of 'session' flags > as defined in the IMAP base specification. The exception to this is > IMAP flags (which are accessible directly through annotations) which > may be 'session only' as determined by the FLAGS and PERMANENTFLAGS > responses to a SELECT or EXAMINE command. > > Since IMAP flags can no longer be modified with ANNOTATE, the exception > should probably be removed. OK, I will remove that last sentence. > The 'm' right controls both read and write access to .priv annotation > values. When it is on, access to .priv annotations is allowed, when > it is off, access to .priv annotations is disallowed. > > Is this really needed? I think private annotations should work the same > way as private flags. You can always read them, and you can write them if > it's possible to permanently save flags. In an ACL-aware server there are different ways to control the flag state 's' and 'w' bits. As a result I think there should also be a way to enable/disable private annotations independently - hence the 'm' bit. I know Alexey had some concerns with 'm' too so this is still an open issue. > /flags > Defines the top-level of entries for flags associated with an > entire message. The "value" attribute of each of the entries > described below must be either "1", "0" or NIL. "1" corresponds > to the flag being set. > > NIL isn't defined here. Does it mean "not set"? For example: NIL should be removed. The flag value must be either 1 or 0, and both .priv and .shared will be the same. NIL only made sense when annotate was discriminating between private/shared flag behavior, which it no longer does. > Clients that need to implement shared and private 'flags' can create > their own annotation entries for those, completely bypassing the base > IMAP flag/keyword behaviour. > > I thought clients weren't allowed to make up their own annotation entry > names? Or what does this mean? If a client wants to create a 'boolean' (on/off) type property associated with a message it has two options: use an IMAP keyword (either private or registered), or create a vendor (or new standard) annotation entry. The former gives no control over private/shared state, whereas the latter does. So if there is a specific need for such a property that does need explicit private/shared behavior then the client can use annotations in lieu of IMAP keywords. Here is some alternate text for the above paragraph that I am proposing to use instead. Note this also includes a sentence to address the first point you made: Clients that need to implement a property on a message that is either 'on' or 'off' and which requires separate private and shared state can use an annotation to represent that property as opposed to using IMAP Keywords, which cannot reliably discriminate the private and shared state. However, clients MUST NOT use annotations to replace existing IMAP flag behavior, which would cause interoperability problems with non-ANNOTATE aware clients. If that is not suitable, please suggest some other text or clarifications. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HRwPE000857; Mon, 1 Nov 2004 09:27:58 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HRwIM000856; Mon, 1 Nov 2004 09:27:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HRvbA000795 for ; Mon, 1 Nov 2004 09:27:57 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 2E9D01CACC81; Mon, 1 Nov 2004 19:27:48 +0200 (EET) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id F305E1C13481 for ; Mon, 1 Nov 2004 19:27:42 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <581C61C2-2C2B-11D9-A114-000393CC2E90@iki.fi> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15-763781542" To: IMAP Extensions WG From: Timo Sirainen Subject: Annotate Date: Mon, 1 Nov 2004 19:27:45 +0200 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-15-763781542 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Some comments: Clients MUST NOT use annotations in lieu of equivalent IMAP base specification facilities. For example, use of a "seen" flag in the vendor namespace together with ".PEEK" in fetches. Such behaviour would significantly reduce IMAP interoperability. I don't understand the example. What does .PEEK fetches have to do with \Seen flag, except without it the \Seen flag might change? If a server supports annotations, then it MUST store all annotation data permanently, i.e. there is no concept of 'session only' annotations that would correspond to the behaviour of 'session' flags as defined in the IMAP base specification. The exception to this is IMAP flags (which are accessible directly through annotations) which may be 'session only' as determined by the FLAGS and PERMANENTFLAGS responses to a SELECT or EXAMINE command. Since IMAP flags can no longer be modified with ANNOTATE, the exception should probably be removed. The 'm' right controls both read and write access to .priv annotation values. When it is on, access to .priv annotations is allowed, when it is off, access to .priv annotations is disallowed. Is this really needed? I think private annotations should work the same way as private flags. You can always read them, and you can write them if it's possible to permanently save flags. /flags Defines the top-level of entries for flags associated with an entire message. The "value" attribute of each of the entries described below must be either "1", "0" or NIL. "1" corresponds to the flag being set. NIL isn't defined here. Does it mean "not set"? For example: /flags/\Seen.shared = 1 /flags/\Seen.private = NIL -> private \Seen flag set /flags/\Seen.shared = 1 /flags/\Seen.private = 0 -> private \Seen flag not set Or should server do this internally and always return 1/0 seen flag? So NIL would only be useful for shared? Or should it also there default to 1/0? Clients that need to implement shared and private 'flags' can create their own annotation entries for those, completely bypassing the base IMAP flag/keyword behaviour. I thought clients weren't allowed to make up their own annotation entry names? Or what does this mean? --Apple-Mail-15-763781542 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBhnIRyUhSUUBViskRAmTaAJ9oxEM6bGk9chBLXeP5d2EU1V5LBQCfUU12 vQUXkwmsCngRfTAlboB6X+4= =65oO -----END PGP SIGNATURE----- --Apple-Mail-15-763781542--