Re: [sieve] Status of draft-freed-sieve-notary

NED+mta-filters@mauve.mrochek.com Tue, 04 May 2010 04:28 UTC

Return-Path: <NED+mta-filters@mauve.mrochek.com>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED943A6D6C for <sieve@core3.amsl.com>; Mon, 3 May 2010 21:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 cWJeX3Qacvll for <sieve@core3.amsl.com>; Mon, 3 May 2010 21:28:21 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 8BE373A6D6A for <sieve@ietf.org>; Mon, 3 May 2010 21:28:21 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMOZYSK7SG00NFXA@mauve.mrochek.com> for sieve@ietf.org; Mon, 3 May 2010 21:28:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMOWVCEMU8004042@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Mon, 03 May 2010 21:28:00 -0700 (PDT)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01NMOZYQZ0TE004042@mauve.mrochek.com>
Date: Mon, 03 May 2010 21:13:28 -0700
In-reply-to: "Your message dated Fri, 23 Apr 2010 18:25:41 +0100" <4BD1D815.3080307@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format="flowed"
References: <4BD1D815.3080307@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1272946874; i=@mrochek.com; bh=Tq4IiYjNLIhLWplzPhkvZdI1/X6EwftkT7EbCuB1sGY=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=iHk7PM5NX54IoXB+lJLLoUcjeBcjcdMadsC4AkoQvBmJdaixeOWNu1D5u3n2N8ffJ pAGqy/5IQ/xiuXVqpq3OQV/h3S3W8I4+L8bB/Oa/s0U0+2OkstwdawSf2aqa/KHRaW 4CcIVjhyDyKDCKEe2L+Ff8PDHn4my5d4IOxhCcUU=
Cc: Sieve WG <sieve@ietf.org>
Subject: Re: [sieve] Status of draft-freed-sieve-notary
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2010 04:28:22 -0000

I just posted a revised version of this draft. There are three very important
changes I've made in response to various last call comments that the WG needs
to be aware of:

(1) The draft used to be silent on what happens to the envelope from address.
    An issue was raised as to the potential to generate backscatter; I believe
    this issue to be specious but it brought up another, more reasonable
    qeustion: What does it mean to specify the generation of DSNs when the
    destination of those DSNs is implementation dependent? The only sensible
    answer I could come up with was to add text saying that when either
    the redirect-dsn or redirect-deliverby extensions are used, any
    non-empty envelope from MUST be replaced by the address of the sieve owner.

(2) The envelope-deliverby extension only provided by-time information in
    relative form. Given the lack of arithemtic operations in Sieve, this
    form isn't terribly useful and there are cases where an absolute time
    string would be better. I have changed the draft to have both a
    bytimerelative and bytimeabsolute envelope-part and an optional :zone
    arugment. The absolute time is returned in restricted ISO 8601 format.

(3) The redirect-deliverby extension only allowed a relative by-time as well.
    This supports the obvious use-case of "deliver the message in this amount
    of time", but it fails to allow for "deliver before this time" usages.
    So I've changed this to have both :bytimeabsolute and :bytimerelative.

A number of clarifications to the text have also been made; these are noted
in the revision history.

Please review these changes; if the consensus is this goes to far I can always
back them out.

There's also the question of whether or not this warrants a new last call.
I'll leave that decision to those above my pay grade ;-)

				Ned