Re: [sieve] Working Group Last Call: draft-ietf-sieve... autoreply, notify-presence, vacation-seconds

Barry Leiba <barryleiba@computer.org> Wed, 13 October 2010 13:54 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 70FE23A6951 for <sieve@core3.amsl.com>; Wed, 13 Oct 2010 06:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.972
X-Spam-Level:
X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 BqHvdpOKtP39 for <sieve@core3.amsl.com>; Wed, 13 Oct 2010 06:54:02 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1B1803A67FD for <sieve@ietf.org>; Wed, 13 Oct 2010 06:54:02 -0700 (PDT)
Received: by iwn10 with SMTP id 10so7883952iwn.31 for <sieve@ietf.org>; Wed, 13 Oct 2010 06:55:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/1qkxiimiJ1Wvqy8BJn7UO/meLzlTwXoEn2BWUX5d8U=; b=j0ctM/SNiV1JNJJAZpTyle9QMVCP18ZPDtHC56WqPQBj67aQfyw9pewrNavzIZtrQU dEHGpucAfn0Ft3B1mOPn5HruivbSbAoSrz0Rq76bH9escucpt4i57GJVxykvLKWi/8tP hReNdmOI/mpeyvNbg8PwWpRJs/+bjVuSXF71I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=d2AHUtDLZ0JdFCcK3qCvfZTot/cfoD9crIji8OGbpA8voukfPWDEER5JjcT2h2nfbN D9Y5aJZanmwnGc6XoqS/9i6N5ErwBZ5e2nadaoeuvwZwVXlqcAi0KoGRAJkzedrLe24s 2XLz0fvlvCxUQz34qOh/qCnbfwvjLN1crXpLs=
MIME-Version: 1.0
Received: by 10.42.209.143 with SMTP id gg15mr3644744icb.467.1286978118349; Wed, 13 Oct 2010 06:55:18 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.42.6.65 with HTTP; Wed, 13 Oct 2010 06:55:18 -0700 (PDT)
In-Reply-To: <01NSZ2PTFXCI000CVY@mauve.mrochek.com>
References: <AANLkTik994DjP7T7tj-VzJQ4J1nAgtq4hTdj5ZFQ-h=u@mail.gmail.com> <4CB4F39A.8040806@att.com> <01NSZ2PTFXCI000CVY@mauve.mrochek.com>
Date: Wed, 13 Oct 2010 09:55:18 -0400
X-Google-Sender-Auth: hhT135VFZUMRt-01dSSAz7-hokg
Message-ID: <AANLkTi=4K21-vdL3B2jQ95QvF2JjZPKLqBS93HRU8R3X@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: NED+mta-filters@mauve.mrochek.com
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Sieve mailing list <sieve@ietf.org>
Subject: Re: [sieve] Working Group Last Call: draft-ietf-sieve... autoreply, notify-presence, vacation-seconds
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: Wed, 13 Oct 2010 13:54:10 -0000

> =======
> notify-presence
>
> The value of "unknown" should be explicity listed in section 2 for each
> item that can return that value, rather than being mentioned in passing
> at the end of section 2.

I don't agree; "unknown" isn't a value of the presence, but an
artifact of retrieving it; I think it's worth keeping that separate.
Would you be happier (I think I would) if I moved it up?  My working
copy now has this as the second paragraph, just before the list:

   This document defines a set of items of notification presence, which
   may be specified in the notification-capability parameter.  The
   script tests the values of notification presence items in the key-
   list parameter.  The values that each item may have are specified in
   the list below; in addition, any item may have the value "unknown",
   if it is not possible to determine the correct value of the item.

>> I think it would be worth putting a note in somewhere that an
>> implementation may wish to cache the results of a call to
>> notify_method_capability so that if it is used in a series of if/else
>> tests, it only needs to be retrieved once.
>
> Now that you bring this up, I'm tempted to go even further, and say that any
> result should be consistent throughout the script. If statuses change and
> notify_method_capability returns inconsistent results at different times in
> the same script, I could see that causing some unpleasant results.

I like Ned's suggestion, and I will add that.  My working copy now has
this as the third paragraph, just before the list:

   If a particular presence item is tested multiple times within the
   same script execution context, implementations MUST present the same
   value each time (for example, by caching the value on first use).
   This provides consistency within a single execution.

Please let me know if you guys are happy with these changes, and I'll
post a revision.

Barry