[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] WGLC NOTIFY
Hi Timo:
Timo Sirainen wrote:
On Wed, 2008-06-11 at 23:22 +0100, Alexey Melnikov wrote:
[...]
The closest default IMAP behavior would be (MessageNew FlagChange).
Most servers delay sending the changes until a command is started,
but that's not required by RFC 3501 so I don't think it matters.
Perhaps MessageNew should be always enabled?
This would disallow the NOTIFY NONE behavior.
What if there was first a big switch between "NONE" vs. "something" and
then some finer switches under "something":
a) NONE - nothing sent at all.
b)
- MessageNew always sent immediately
- MessageExpunge always sent, but could be either delayed or immediate
- Flags, annotations, etc. are optionally sent, but if they are they're
always immediate
I guess the b) option could be done by specifying that unless NONE is
used, MessageNew isFrom lemonade-bounces at ietf.org Sat Jun 21 09:25:13 2008
Return-Path: <lemonade-bounces at ietf.org>
X-Original-To: lemonade-archive at optimus.ietf.org
Delivered-To: ietfarch-lemonade-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8B3D73A6980;
Sat, 21 Jun 2008 09:25:13 -0700 (PDT)
X-Original-To: lemonade at core3.amsl.com
Delivered-To: lemonade at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8C4893A6980
for <lemonade at core3.amsl.com>; Sat, 21 Jun 2008 09:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5
tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 2JSW0R7lq4Z6 for <lemonade at core3.amsl.com>;
Sat, 21 Jun 2008 09:25:11 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251])
by core3.amsl.com (Postfix) with ESMTP id 7DB7D3A6971
for <lemonade at ietf.org>; Sat, 21 Jun 2008 09:25:10 -0700 (PDT)
Received: from [192.168.0.2] ((unknown) [62.3.217.253])
by rufus.isode.com (submission channel) via TCP with ESMTPA
id <SF0raQBZBG9K at rufus.isode.com>; Sat, 21 Jun 2008 17:25:13 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <485CF694.6080407 at isode.com>
Date: Sat, 21 Jun 2008 13:39:48 +0100
From: Alexey Melnikov <alexey.melnikov at isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915
X-Accept-Language: en-us, en
To: Timo Sirainen <tss at iki.fi>
References: <C433D277.1AB18%eburger at bea.com>
<8B9B8F32-8DEF-40B9-992E-9337FB7AE344 at standardstrack.com>
<1210951366.9518.654.camel at hurina> <48312F7D.8090103 at isode.com>
<1211191304.9518.755.camel at hurina> <4835D000.4080808 at isode.com>
<1211745339.3904.166.camel at hurina> <483BAB35.2080806 at isode.com>
<1B7D968F-7A77-40FC-AFD6-ADF3C2826822 at iki.fi>
<484657A5.5070202 at isode.com> <1212595278.3904.735.camel at hurina>
<O+GZjDXJAHaQQOyh0Ev6tg.md5 at lochnagar.oryx.com>
<1212675916.3904.858.camel at hurina>
<DC758A1F-99F6-4931-A063-90B7C8E0E8A5 at iki.fi>
<4850501E.2080504 at isode.com> <1213267448.3904.1211.camel at hurina>
In-Reply-To: <1213267448.3904.1211.camel at hurina>
MIME-Version: 1.0
Cc: lemonade <lemonade at ietf.org>
Subject: Re: [lemonade] WGLC NOTIFY
X-BeenThere: lemonade at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lemonade>,
<mailto:lemonade-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/lemonade>
List-Post: <mailto:lemonade at ietf.org>
List-Help: <mailto:lemonade-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lemonade>,
<mailto:lemonade-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: lemonade-bounces at ietf.org
Errors-To: lemonade-bounces at ietf.org
Hi Timo:
Timo Sirainen wrote:
On Wed, 2008-06-11 at 23:22 +0100, Alexey Melnikov wrote:
[...]
The closest default IMAP behavior would be (MessageNew FlagChange).
Most servers delay sending the changes until a command is started,
but that's not required by RFC 3501 so I don't think it matters.
Perhaps MessageNew should be always enabled?
This would disallow the NOTIFY NONE behavior.
What if there was first a big switch between "NONE" vs. "something" and
then some finer switches under "something":
a) NONE - nothing sent at all.
b)
- MessageNew always sent immediately
- MessageExpunge always sent, but could be either delayed or immediate
- Flags, annotations, etc. are optionally sent, but if they are they're
always immediate
I guess the b) option could be done by specifying that unless NONE is
used, MessageNew is always always used regardless of whether it's explicitly
specified or not.
It probably would be cleaner if the entire syntax was changed a bit:
NOTIFY SELECTED <expunge-type> [(optionals) [(fetch attributes)]]
NOTIFY SELECTED none
- nothing sent
NOTIFY SELECTED delayed
- delayed expunges, immediate EXISTS, no flag changes
NOTIFY SELECTED delayed (FlagChange)
- delayed expunges, immediate EXISTS and flag changes
NOTIFY SELECTED immediate (FlagChange) (UID FLAGS)
- immediate expunges, EXISTS and flag changes, new messages return
FETCH (UID FLAGS)
NOTIFY SELECTED immediate () (UID FLAGS)
- no flags, immediate others
Timo Sirainen wrote:
So I wouldn't mind if NOTIFY had a big switch that
worked like:
a) Immediate: Send expunges, exists and everything else immediately to
client
b) Delayed: Server is allowed (but not required) to delay all events
until a command is executed that allows returning expunges (usually
IDLE, but also others)
I've changed the definition of "SELECTED" to "SELECT immediate" as you
defined above. I've also added SELECTED-DELAYED, which corresponds to
"SELECTED delayed" in your proposal.
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade
used regardless of whether it's explicitly
specified or not.
It probably would be cleaner if the entire syntax was changed a bit:
NOTIFY SELECTED <expunge-type> [(optionals) [(fetch attributes)]]
NOTIFY SELECTED none
- nothing sent
NOTIFY SELECTED delayed
- delayed expunges, immediate EXISTS, no flag changes
NOTIFY SELECTED delayed (FlagChange)
- delayed expunges, immediate EXISTS and flag changes
NOTIFY SELECTED immediate (FlagChange) (UID FLAGS)
- immediate expunges, EXISTS and flag changes, new messages return
FETCH (UID FLAGS)
NOTIFY SELECTED immediate () (UID FLAGS)
- no flags, immediate others
Timo Sirainen wrote:
So I wouldn't mind if NOTIFY had a big switch that
worked like:
a) Immediate: Send expunges, exists and everything else immediately to
client
b) Delayed: Server is allowed (but not required) to delay all events
until a command is executed that allows returning expunges (usually
IDLE, but also others)
I've changed the definition of "SELECTED" to "SELECT immediate" as you
defined above. I've also added SELECTED-DELAYED, which corresponds to
"SELECTED delayed" in your proposal.
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade