Subject: [lemonade] Profile-bis and IMAP Notifications

From: Eric Burger <[email-masked]>
Date: Sat, 15 Dec 2007 10:15:24 -0500

WITH CHAIR HAT OFF, just a member of the work group...

Right now we say Lemonade Message Stores MUST support IDLE and is silent on
NOTIFY.

I would offer Lemonade Message Stores MUST support NOTIFY and MAY support
IDLE.

Mandating support for IDLE means IDLE lives forever, even if no one uses it
in the future.

If there are other reasons for servers to support IDLE, like no extant
client today supports NOTIFY, then market forces will ensure Lemonade
Message Stores will support IDLE for the time being.

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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 16 Dec 2007 21:37:57 +0000

>I would offer Lemonade Message Stores MUST support NOTIFY and MAY support
Personally, this would be fine with me. However this would violate the 
implicit assumption that Profile Bis is a superset of Profile.
Maybe you should poll the WG if people want to do that.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 17 Dec 2007 10:21:13 +0100

Eric Burger writes:
> Right now we say Lemonade Message Stores MUST support IDLE and is 
> silent on NOTIFY.
>
> I would offer Lemonade Message Stores MUST support NOTIFY and MAY 
> support IDLE.
>
> Mandating support for IDLE means IDLE lives forever, even if no one 
> uses it in the future.
>

I submit that a) IDLE is easy for servers to implement, b) most extant 
servers have it already and c) we should have at least two good reasons 
before we make profile-bis anything other than strict superset of 
profile.

So my vote is to keep IDLE. I may or may not change my vote if other 
things are taken out of profile-bis.

Arnt

---

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

On Sat Dec 15 15:15:24 2007, Eric Burger wrote:
> silent on
Indeed, and that's sane - a client which wants to use MSNs - a quite  
sensible option for various tasks - won't want to be notified about  
expunges except when it's ready for them, and IDLE provides an  
excellent method for telling the server when it can handle them, by  
dint of it being a long running command when expunge events may be  
sent.

Perhaps in the future all clients will be written such that they use  
only UIDs, and use no MSNs at all, but this isn't how IMAP works now,  
and I'd be much happier to know that we really knew what we were  
talking about before we abandoned IDLE.

> support
And I'd deeply uncomfortable about having optional parts of the  
specification at this stage - up until now, we have had a very clear  
policy on this - servers have a list of mandatory features, clients  
have a set of SHOULDs above the base specifications.

Before introducing optional portions of the profile for servers, I'd  
want a clear consensus to be reached that this, in itself, is a good  
idea.

I also agree with the backwards compatibility arguments, so that's  
three nails in the coffin for this proposal, from where I'm sitting.

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: Dave Cridland <[email-masked]>
Date: Mon, 17 Dec 2007 16:49:53 +0000

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 17 Dec 2007 09:08:09 -0800 (PST)

On Mon, 17 Dec 2007, Dave Cridland wrote:
> Perhaps in the future all clients will be written such that they use only 
> UIDs, and use no MSNs at all, but this isn't how IMAP works now, and I'd be 
> much happier to know that we really knew what we were talking about before we 
> abandoned IDLE.

I hope that such a thing never happens.  Appropriate use of MSNs is key to 
using IMAP effectively.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Dec 2007 10:53:11 -0800

At 9:37 PM +0000 12/16/07, Alexey Melnikov wrote:
>>
>Personally, this would be fine with me. However this would violate the implicit assumption that Profile Bis is a superset of Profile.

Is this just an implicit assumption?  I thought that the working group's discussions
with OMA had pretty much said that the profile-bis would be a superset of profile.
I just checked my email copies of some of the liaison statements, and it doesn't seem
to be said quite as clearly as that in those, so I may be confused.  But it might
be worth informally confirming that this assumption change won't cause
heartburn there.
			regards,
				Ted

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 17 Dec 2007 21:34:25 +0100

Mark Crispin writes:
>> only UIDs, and use no MSNs at all, but this isn't how IMAP works 
>> now, and I'd be much happier to know that we really knew what we 
>> were talking about before we abandoned IDLE.
>
> I hope that such a thing never happens.  Appropriate use of MSNs is 
> key to using IMAP effectively.

I used to think so too, but then I rewrote my hobby client to never go 
out of its way to obtain an MSN (although it remembers them when it 
receives some), and found that it was an improvement in terms of round 
trips and bytes sent/received.

The main problem is that if I get an EXPUNGE and don't know the UID, I 
may noeed to mark many messages in the client's cache as "possibly 
gone, verify with UID FETCH UID before using". That turns out to happen 
very seldom. The similar problem with flag updates is also small in 
practice.

Arnt