Re: Treat as a WGLC: draft-martin-managesieve-10.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 07 July 2008 20:27 UTC

Return-Path: <owner-ietf-mta-filters@mail.imc.org>
X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5883A6B1A for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Mon, 7 Jul 2008 13:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 7ZwZZz5A-1Gb for <ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com>; Mon, 7 Jul 2008 13:27:33 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8FEB73A6AB0 for <sieve-archive-Aet6aiqu@ietf.org>; Mon, 7 Jul 2008 13:27:32 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KN7Qx055938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67KN7fa055937; Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67KN67R055928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Mon, 7 Jul 2008 13:23:07 -0700 (MST) (envelope-from jhutz@cmu.edu)
Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m67KN1bi029756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 16:23:03 -0400 (EDT)
Date: Mon, 07 Jul 2008 16:23:01 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Robert Burrell Donkin <robertburrelldonkin@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
cc: Stephan Bosch <stephan@rename-it.nl>, SIEVE <ietf-mta-filters@imc.org>, jhutz@cmu.edu
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Message-ID: <BE5281A49672F0D083DC8BB5@atlantis.pc.cs.cmu.edu>
In-Reply-To: <f470f68e0807071227w2351ebf4g7e35dc4db81d4168@mail.gmail.com>
References: <20080621210001.E1B343A698C@core3.amsl.com> <485E6169.1040202@isode.com> <48669DF3.1020006@rename-it.nl> <4867CDB6.5030700@isode.com> <4871D210.3010009@rename-it.nl> <f470f68e0807070505i124daf79s6b7209b2cc29c20b@mail.gmail.com> <487209A6.4040309@isode.com> <f470f68e0807071227w2351ebf4g7e35dc4db81d4168@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

--On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin 
<robertburrelldonkin@gmail.com> wrote:

> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

The situation here is that we are standardizing a protocol which was 
already widely deployed.  In such cases, it is usually better to avoid 
breaking interoperability with the deployed base, especially if the 
deployment experience largely shows that the existing protocol works. 
Sometimes, there is no way to avoid making a backward-incompatible change 
to correct a problem, but I don't think this is such a case.

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

That makes the assumption that sieve scripts live only in IMAP servers, 
which I don't think we want to do.

-- Jeff