Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis

From: Randall Gellens <[email-masked]>
Date: Sun, 2 Dec 2007 16:03:21 -0800

At 10:53 AM -0800 11/27/07, Mark Crispin wrote:

>  Any measures that reduce complexity and increase demand are good things IMHO.

Sure, reducing complexity while at the same time increasing demand 
for lemonade is great.  Which proposals do so?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The whole dream of democracy is to raise the proletarian to the level
of stupidity attained by the bourgeois.            --Gustave Flaubert

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

ived: from lemonade by megatron.ietf.org with local (Exim 4.43)
	id 1Iyz0I-0003Bp-VV for [email-masked];
	Sun, 02 Dec 2007 19:17:42 -0500
Date: Sun, 2 Dec 2007 16:03:21 -0800
To: Mark Crispin <[email-masked]>,
	Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [lemonade] Proposal for addition and deletion of
	extensions to 	the Lemonade Profile Bis
Cc: Lemonade WG <[email-masked]>

At 10:53 AM -0800 11/27/07, Mark Crispin wrote:

>  Any measures that reduce complexity and increase demand are good things IMHO.

Sure, reducing complexity while at the same time increasing demand 
for lemonade is great.  Which proposals do so?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The whole dream of democracy is to raise the proletarian to the level
of stupidity attained by the bourgeois.            --Gustave Flaubert

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 07:10:09 -0800

<contributor hat on>
I noted in the discussion on error reporting that absolute times,
particularly for a mobile device, often just do not work.  In fact, the
solution offered for URLAUTH is to use relative times.

The main purpose of WITHIN is to store a search pattern, e.g., "get me mail
that is less than a day old" without having to calculate, upload, re-parse,
and re-optimize search indices before doing the search.  However, it also
has what might be the desirable property of using relative times.

Is that not of value?

More importantly, will we run afoul of OMA requirements if we drop WITHIN?

What is the complex interaction?  I missed it on the list.  If we refine
CONTEXT, would it provide the functionality required that drove us to write
WITHIN in the first place?

<chair hat on>
Believe me, I am all for the philosophy of dumping stuff to get this work
done!  I just want to make sure we do not cut to the point our constituency
says our work is irrelevant.  One of the work group's customers, and
probably our largest market, is the OMA.

If we can meet their requirements easily without WITHIN, then I would +1
dumping it.  If we cannot, then I would do a big -1.

On 11/27/07 10:07 AM, "Alexey Melnikov" <[email-masked]> wrote:

> Based on various discussions during the Lemonade interop in Munich, I
> would like to propose the following changes to the Lemonade Profile Bis
> document:
> 
> After reviewing existing server and client implementations, there was
> support for removing  RFC 5032 (WITHIN) from the Lemonade Profile Bis.
> The reason for this is because server implementors found interaction
> between WITHIN and CONTEXT to be too complex to implement, while client
> implementors didn't find the extension  to be useful. If somebody would
> like to argue that RFC 3052 should be in Lemonade Profile Bis, please
> speak up now.
[snip]

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Dec 2007 16:05:00 +0000

> has what might be the desirable property of using relative times.
It depends... As things stand, no, since the client has to re-send  
the CONTEXT anyway. But it does mean that messages won't "drop out"  
of the context when they have aged sufficiently.

> More importantly, will we run afoul of OMA requirements if we drop  
Not as far as I can see.

> WITHIN in the first place?
Even with all the hand-waving that we added to WITHIN to avoid the  
issue, it still changes CONTEXT from being event-driven to being  
time-driven as well.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 11 Dec 2007 14:55:08 +0100

Dave Cridland writes:
>> What is the complex interaction?  I missed it on the list.  If we  
>> refine CONTEXT, would it provide the functionality required that 
>> drove us  to write WITHIN in the first place?
>

For the server. For the client it's the other way. Without WITHIN, the 
client has to use BEFORE/SINCE, change the argument every so often and 
resend the context.

And how often is "every so"? (Cue to repeat that long, long discussion ;)

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Dec 2007 14:07:22 +0000

On Tue Dec 11 13:55:08 2007, Arnt Gulbrandsen wrote:
> For the server. For the client it's the other way. Without WITHIN,  
> the client has to use BEFORE/SINCE, change the argument every so  
> often and resend the context.

 From a client's perspective, this is quite true - somewhere, if what  
you want to do is show messages within a certain timeframe (and  
typically you want YOUNGER), then filters need re-evaluating.

However, I have yet to use WITHIN. My client does support it, as well  
as CONTEXT=SEARCH, but the only times I've used it are for testing.

The actual purpose of WITHIN, it seems, is not to restrict the  
summary listing by time, but by volume, and PARTIAL manages this  
considerably more effectively - just grab the last X messages  
matching the filter, and if the user wants more, grab more, again  
with PARTIAL.

Dave.