Re: [sieve] AD review of draft-ietf-sieve-notify-presence-02.txt

Barry Leiba <barryleiba@computer.org> Mon, 25 October 2010 22:41 UTC

Return-Path: <barryleiba@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 F3D303A6B7D for <sieve@core3.amsl.com>; Mon, 25 Oct 2010 15:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.127
X-Spam-Level:
X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, 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 3JnnUJCJVl9Y for <sieve@core3.amsl.com>; Mon, 25 Oct 2010 15:41:54 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 073693A6ABB for <sieve@ietf.org>; Mon, 25 Oct 2010 15:41:52 -0700 (PDT)
Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9PMhc9D026971 for <ietf-mta-filters@imc.org>; Mon, 25 Oct 2010 15:43:38 -0700 (MST) (envelope-from barryleiba@gmail.com)
Received: by iwn35 with SMTP id 35so141989iwn.16 for <ietf-mta-filters@imc.org>; Mon, 25 Oct 2010 15:43:37 -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:content-transfer-encoding; bh=qAahsMrskrZTMEAX2PN2Db8bEdeG7vN9gRK1scyGeFc=; b=jCu65d043l0bEra7asCpuBODdQYo1qyFiNUQJRefHdZkXZYZVJm0vxLKGSx1WYIt8H tqxdw71FUCM5T8RugSNji0mlrvYTKt6oveUtxnpMWG/u72l7D/FbqQYyM7Gmyp39Gz+l yPGj7/zniwgFvknJKL1JG1gEVcdn4zr0WBuyo=
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 :content-transfer-encoding; b=BqZnjruLoKVDzPuf9riT1sxa+jIQZ9WaWECuXwqWHzfJWDYcN0ORwJ7Tj4U09roChQ WY/8MvgGbwWl/SELOJ8cjIU0ASN28E61A0qW+U3QrWlzBQ3YkseKXO3JBDEKjij6uqou aK8DJxgS7MQaRcp4Njqpr1kXgVA9geI/7jjdo=
MIME-Version: 1.0
Received: by 10.231.59.13 with SMTP id j13mr6543932ibh.77.1288046617607; Mon, 25 Oct 2010 15:43:37 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.231.33.10 with HTTP; Mon, 25 Oct 2010 15:43:37 -0700 (PDT)
In-Reply-To: <4CC5E59A.9060408@isode.com>
References: <4D3598DBCECC3A3B4CABFEF6@socrates.local> <4CC5E59A.9060408@isode.com>
Date: Mon, 25 Oct 2010 18:43:37 -0400
X-Google-Sender-Auth: GVvP9KAy1ArriGaS5rLzwkNtTS8
Message-ID: <AANLkTi=yVuQq5i9qa=hsAag9NMZpobSM1n-qcePTOQj0@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ietf-mta-filters@imc.org
Subject: Re: [sieve] AD review of draft-ietf-sieve-notify-presence-02.txt
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: Mon, 25 Oct 2010 22:41:55 -0000

> I've just noticed that "status" is not registered in the IANA Considerations
> section.

Geez, how'd I miss that?
I've added it to my working copy.  We can put it in as an RFC-ed note,
or I can submit a new version at the appropriate time.

> The "online" notification capability used the value "maybe" instead of
> "unknown". I know that this is awkward, but should we be using the same
> value for consistency?

I think not.  It could make sense to use "maybe" for "busy", but
definitely not for "show".  Too bad about "online".  :-)

>>   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; Note that in addition to the presence values, any
>>   item may have the value "unknown" if it is not possible to determine
>>   the correct presence value of the item.
>
> Does this mean that the "status" notification item can also have a value
> "unknown" if it is not possible to determine it?

As I replied to Tony:
>> After status definition, add
>>
>> unknown - The correct availability status could not be determined.
>
> I thought about that, but I don't think I like it.  This is a
> human-readable field, and it's made clear that it's not for automated
> processing.  It's plain text, most likely set by the user, and it
> could be anything, including "unknown".  I don't want to try to
> *reserve* the value "unknown" in any way -- we can't, anyway; we have
> no control of it.

I'd prefer to leave things as they are, and if an implementation wants
to infer that it can stick in "unknown", that's fine.  The reality is
that we're clear that this is for human consumption, and *any* value
that's put in there could also be put there by the human.

If you think that's confusing, and want me to put explicit text saying
that there's no way to indicate that the value of this is not known, I
can do so.  I don't think it'll be an issue, in practice.  I'm also
not averse to changing the text.  Either way.

Barry