From morg-bounces@ietf.org Tue Jun 17 06:28:33 2008 Return-Path: X-Original-To: morg-archive@optimus.ietf.org Delivered-To: ietfarch-morg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4B528C18A; Tue, 17 Jun 2008 06:28:33 -0700 (PDT) X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679493A6A92 for ; Tue, 17 Jun 2008 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC81+ZEVk5MX for ; Tue, 17 Jun 2008 06:28:30 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 38E203A698A for ; Tue, 17 Jun 2008 06:28:30 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 9328C16471E4; Tue, 17 Jun 2008 16:28:40 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <4857982D.1050502@isode.com> References: <4856205B.2060806@oryx.com> <4857982D.1050502@isode.com> Date: Tue, 17 Jun 2008 16:28:40 +0300 Message-Id: <1213709320.3904.1418.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: IMAP Extensions , morg@ietf.org Subject: Re: [MORG] IMAPEXT prepared for shutdown X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1785502745==" Sender: morg-bounces@ietf.org Errors-To: morg-bounces@ietf.org --===============1785502745== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CBnkm6bNwNz7kKUlfUm1" --=-CBnkm6bNwNz7kKUlfUm1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-17 at 11:55 +0100, Alexey Melnikov wrote: > Timo Sirainen wrote: >=20 > > One thing somewhat related to ACLs that could be useful is the=20 > > ability to find out and specify which message flags and keywords are=20 > > shared and which are private (on per-flag level, not on per-message=20 > > level). Perhaps with the ability to create/delete keywords with=20 > > explicit commands.. Anyone else interested (for morg)? >=20 > I am interested. I think I even had a pro-draft for this at some point. I remember you had a new untagged reply listing shared flags: * OK [SHAREDFLAGS (\Seen \Answered $hello $world)] The commands could be something like: 1 FLAGS ADD PRIVATE ($pvt1 $pvt2 $foo) SHARED (\Seen \Answered) * FLAGS .. * OK [PERMANENTFLAGS ..] =EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered)] 1 OK =EF=BB=BF2 FLAGS ADD SHARED ($shared1 $foo $shared2) =EF=BB=BF=EF=BB=BF=EF=BB=BF* FLAGS .. * OK [PERMANENTFLAGS ..] =EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered $foo $shared1)] 2 NO [TOOMANYKEYWORDS] $shared2 not added 3 FLAGS REMOVE ($pvt1) * FLAGS .. * OK [PERMANENTFLAGS ..] 3 OK 4 FLAGS REMOVE ($shared1 \seen $shared2) =EF=BB=BF* FLAGS .. * OK [PERMANENTFLAGS ..] =EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Answered $foo)] 4 NO Unknown keyword $shared2 5 FLAGS ADD PRIVATE (\hello) 5 BAD Adding and updating could be done with the same command. I don't think there's much point in having them be separate. --=-CBnkm6bNwNz7kKUlfUm1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIV7wHyUhSUUBViskRAoBEAJ95G0p2c6E30veTytpMG9MJ6mKEowCggqrj MIQxIJNBjXN/MgpyBL+WrQ8= =B62Z -----END PGP SIGNATURE----- --=-CBnkm6bNwNz7kKUlfUm1-- --===============1785502745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MORG mailing list MORG@ietf.org https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html --===============1785502745==-- From morg-bounces@ietf.org Tue Jun 17 06:48:57 2008 Return-Path: X-Original-To: morg-archive@optimus.ietf.org Delivered-To: ietfarch-morg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369773A69F1; Tue, 17 Jun 2008 06:48:57 -0700 (PDT) X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC38A3A69AD for ; Tue, 17 Jun 2008 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtbscCdJqDWG for ; Tue, 17 Jun 2008 06:48:52 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 9B1D63A69B7 for ; Tue, 17 Jun 2008 06:48:51 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id AD61416471E4; Tue, 17 Jun 2008 16:49:05 +0300 (EEST) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <1213709320.3904.1418.camel@hurina> References: <4856205B.2060806@oryx.com> <4857982D.1050502@isode.com> <1213709320.3904.1418.camel@hurina> Date: Tue, 17 Jun 2008 16:49:05 +0300 Message-Id: <1213710545.3904.1433.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: morg@ietf.org Subject: [MORG] Message flags extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172797881==" Sender: morg-bounces@ietf.org Errors-To: morg-bounces@ietf.org --===============1172797881== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5mRna96cbZwcg08jYyLE" --=-5mRna96cbZwcg08jYyLE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2008-06-17 at 16:28 +0300, Timo Sirainen wrote: > On Tue, 2008-06-17 at 11:55 +0100, Alexey Melnikov wrote: > > Timo Sirainen wrote: > >=20 > > > One thing somewhat related to ACLs that could be useful is the=20 > > > ability to find out and specify which message flags and keywords are= =20 > > > shared and which are private (on per-flag level, not on per-message=20 > > > level). Perhaps with the ability to create/delete keywords with=20 > > > explicit commands.. Anyone else interested (for morg)? > >=20 > > I am interested. I think I even had a pro-draft for this at some point. >=20 > I remember you had a new untagged reply listing shared flags: >=20 > * OK [SHAREDFLAGS (\Seen \Answered $hello $world)] >=20 > The commands could be something like: A few more things came to my mind: Servers would be allowed to handle keywords created with STORE and with FLAGS ADD differently. If server runs out of keywords while adding new ones or otherwise decides that there are too many of them, it would be allowed to remove the unused keywords created with STORE, but not keywords created with FLAGS ADD. I guess this would mostly be for backwards compatibility, because it's possible to accidentally =EF=BB=BFcre= ate new keywords with old clients but possible to remove them. So the server could decide to drop keywords after they've been unused for n days. Interaction with ACL? Since "w" right already allows creating new keywords, I guess that should be enough to be able to modify/remove them. But is "s" then enough to modify \Seen's shared state and "t" to modify \Deleted's shared state? Doesn't seem that good of an idea. Perhaps "a" right would be needed to modify \flags, but "w" would be ok for keywords? Or perhaps this is implementation-defined behavior ("a" MAY be required, "w" MAY be enough). Should user be able to override shared flag state? So that admin specifies only the defaults, but user is allowed to mark any one of the shared flags as private. This would at least reduce accidental/intentional conflicts with keywords. --=-5mRna96cbZwcg08jYyLE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIV8DRyUhSUUBViskRAsQfAJwK1oIemc/xEVh1MwNlF5vZg1YeYACdHUXq BWIH/ZGMMXD/VDrawkEOsFw= =3L8S -----END PGP SIGNATURE----- --=-5mRna96cbZwcg08jYyLE-- --===============1172797881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MORG mailing list MORG@ietf.org https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html --===============1172797881==-- From morg-bounces@ietf.org Thu Jun 19 19:56:09 2008 Return-Path: X-Original-To: morg-archive@optimus.ietf.org Delivered-To: ietfarch-morg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB083A67F8; Thu, 19 Jun 2008 19:56:09 -0700 (PDT) X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1253A67F8 for ; Thu, 19 Jun 2008 19:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrL6NPQNx-zX for ; Thu, 19 Jun 2008 19:56:08 -0700 (PDT) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id F3D4F3A62D1 for ; Thu, 19 Jun 2008 19:56:04 -0700 (PDT) Received: from [192.168.10.2] (xdsl-177-118.nblnetworks.fi [217.30.177.118]) by dovecot.org (Postfix) with ESMTP id 7C7C81647211; Fri, 20 Jun 2008 05:55:31 +0300 (EEST) From: Timo Sirainen To: Arnt Gulbrandsen Date: Fri, 20 Jun 2008 05:55:30 +0300 Message-Id: <1213930530.3904.1577.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: morg@ietf.org Subject: [MORG] SEARCH=INTHREAD algorithm selection X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587650816==" Sender: morg-bounces@ietf.org Errors-To: morg-bounces@ietf.org --===============0587650816== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1/yzFnwLWmvWePuPiomx" --=-1/yzFnwLWmvWePuPiomx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ability to specify multiple different thread algorithms for the same search command seems quite pointless and makes its implementation unnecessarily complex. I'd like to avoid doing nested INTHREAD searches, which is possible but only as long as the same algorithm is used everywhere. How about specifying the algorithm in SEARCH RETURN options? SEARCH RETURN (THREAD (REFERENCES)) INTHREAD SUBJECT "hello" This also fixes the issue of THREADROOT and THREADLEAF not specifying the algorithm currently. --=-1/yzFnwLWmvWePuPiomx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIWxwiyUhSUUBViskRAod3AKCTE78Fjq9BC2Ids8d6iTqg37RKtACdEJfP Wdd1npWf4/bUYDYnRbxoGyg= =IE0B -----END PGP SIGNATURE----- --=-1/yzFnwLWmvWePuPiomx-- --===============0587650816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MORG mailing list MORG@ietf.org https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html --===============0587650816==--