[Dovecot] Fwd: [MORG] IMAP5 List
If anyone's interested, especially client developers. It's been a bit
quiet there after the initial rush.
Begin forwarded message:
From: Randall Gellens <randy@qualcomm.com> Date: August 1, 2008 5:08:39 AM EDT To: ietf-imapext@imc.org, morg@ietf.org Subject: [MORG] IMAP5 List
At the MORG BOF, a discussion as to if the proposed IMAP extensions
would merely further add to the existing problem with IMAP being too
hard to get right, for both clients and servers, let to a revival of
the "IMAP5" discussion (previous held during the IMAP EAI
discussions). Here, "IMAP5" refers to a Big Switch (new port and
version) to distinguish this revision from current IMAP. The goal
is to delete as much as possible from IMAP.A new mailing list now exists for this discussion on drastically
slimming-down IMAP to make it easier to implement clients and servers.================================================================== To subscribe, click here: <mailto:imap5-request@ietf.org?body=subscribe
.
It's been observed that "most IMAP clients suck" and that it's hard
for both clients and servers to implement.One reason IMAP is hard to implement is that it has a lot of
options. Often there are several alternative ways to accomplish
something. It also has considerable functionality.Is it possible and desirable to start with the current set of (IMAP
- all extensions) and consider subtracting as much as possible? The
resulting protocol would still be IMAP, but not backwards-compatible
with today's IMAP, since some currently-mandated items are likely to
be deleted.General information about the IMAP5 mailing list is at: <https://www.ietf.org/mailman/listinfo/imap5
.
You can subscribe and manage your subscription at <https://www.ietf.org/mailman/listinfo/imap5
.
-- Randall Gellens Opinions are personal; facts are suspect; I speak for myself
only -------------- Randomly-selected tag: --------------- If Murphy's Law can go wrong, it will.
MORG mailing list MORG@ietf.org https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html
--On Tuesday, August 12, 2008 3:17 AM -0400 Timo Sirainen <tss@iki.fi> wrote:
If anyone's interested, especially client developers. It's been a bit quiet there after the initial rush.
Very interesting. Thanks for the forward. I'll send this on to the Mulberry developer list.
One thing I'd like to see is the ability of the server to notify the client of updates on any folder, not just subscribed or open ones. From what I understand, the client must poll all unsubscribed folders, which can be expensive. If one has a lot of folders (mine count well over 100, due to the large number of mailing lists to which I subscribe, and that I filter to them on the server side), the time to find new mail can be large and costly on the server.
And I wish to &deity. that the IMAP protocol had feedback elements to inform the user of appropriate usage of IT resources, such as green/yellow/red indicators denoting info on the size of messages about to be sent, quotas, etc. Oh, yes, and that the imap alert, part of UWIMAP be made part of the core standard
--
Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
On Aug 12, 2008, at 6:04 AM, Kenneth Porter wrote:
One thing I'd like to see is the ability of the server to notify the
client of updates on any folder, not just subscribed or open ones.
From what I understand, the client must poll all unsubscribed
folders, which can be expensive. If one has a lot of folders (mine
count well over 100, due to the large number of mailing lists to
which I subscribe, and that I filter to them on the server side),
the time to find new mail can be large and costly on the server.
Lemonade group is working on NOTIFY extension for that. But that's
only the protocol part, server would still have to be able to optimize
it somehow internally. For Dovecot that would mean I should finish/fix
mailbox list indexes.
Timo,
Thanks for bringing it up.
I dealt with i18n MUA. I would love to see i18n from IMAPEXT (http://www.ietf.org/rfc/rfc5255.txt) be part of IMAP5, the mechanism, not all language translations, of course :)
And I guess no MUA needs to 'ENABLE' anything in IMAP5.
Joseph
PS. I had subscribed to the mailing list :)
Timo Sirainen wrote:
If anyone's interested, especially client developers. It's been a bit quiet there after the initial rush.
Begin forwarded message:
From: Randall Gellens <randy@qualcomm.com> Date: August 1, 2008 5:08:39 AM EDT To: ietf-imapext@imc.org, morg@ietf.org Subject: [MORG] IMAP5 List
At the MORG BOF, a discussion as to if the proposed IMAP extensions would merely further add to the existing problem with IMAP being too hard to get right, for both clients and servers, let to a revival of the "IMAP5" discussion (previous held during the IMAP EAI discussions). Here, "IMAP5" refers to a Big Switch (new port and version) to distinguish this revision from current IMAP. The goal is to delete as much as possible from IMAP.
A new mailing list now exists for this discussion on drastically slimming-down IMAP to make it easier to implement clients and servers.
================================================================== To subscribe, click here: <mailto:imap5-request@ietf.org?body=subscribe>.
It's been observed that "most IMAP clients suck" and that it's hard for both clients and servers to implement.
One reason IMAP is hard to implement is that it has a lot of options. Often there are several alternative ways to accomplish something. It also has considerable functionality.
Is it possible and desirable to start with the current set of (IMAP + all extensions) and consider subtracting as much as possible? The resulting protocol would still be IMAP, but not backwards-compatible with today's IMAP, since some currently-mandated items are likely to be deleted.
General information about the IMAP5 mailing list is at: <https://www.ietf.org/mailman/listinfo/imap5>.
You can subscribe and manage your subscription at <https://www.ietf.org/mailman/listinfo/imap5>.
-- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If Murphy's Law can go wrong, it will.
MORG mailing list MORG@ietf.org https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html
On Aug 12, 2008, at 9:52 PM, Joseph Yee wrote:
Timo,
Thanks for bringing it up.
I dealt with i18n MUA. I would love to see i18n from IMAPEXT (http://www.ietf.org/rfc/rfc5255.txt ) be part of IMAP5, the mechanism, not all language translations, of
course :)
Dovecot v1.1+ currently supports I18LEVEL=1. Maybe more in future. :)
Are you interested more in the comparator selection or the language
translations? I don't see the LANGUAGE extension all that useful since
most clients won't show the server-given error messages to users
anyway..
And I guess no MUA needs to 'ENABLE' anything in IMAP5.
I guess we'll see.
participants (4)
-
Joseph Yee
-
Kenneth Porter
-
Stewart Dean
-
Timo Sirainen