On Thu, 30 Oct 2003 09:43:57 -0000 "Richard Bang" <[EMAIL PROTECTED]> wrote:
Could this not be resolved cleanly and made a little more general purpose in the next revision of imap.
The SELECT could have a TYPE response
TYPE = MAILSTORE | ICARD | ICAL | DOCUMENT
Thus SELECT addressbooks/fred Could reply with * [TYPE ICARD] * [EXISTS 10] ......
That would not suit the needs we have, as a client needs to show the type of each mailbox w/o selecting it. Thus we have implemented the CLASS attribute for mailboxes (supported with the LISTEXT):
[EMAIL PROTECTED] admin]$ telnet mail.stalker.com 143 Trying 206.253.23.169... Connected to mail.stalker.com. Escape character is '^]'. * OK CommuniGate Pro IMAP Server 4.1.6 at mail.stalker.com ready s login xxxx xxx s OK completed s LIST "" "%" * LIST (\UnMarked) "/" Calendar * LIST (\Marked) "/" Connections * LIST (\UnMarked) "/" Contacts * LIST (\Noselect) "/" Customers * LIST (\Marked) "/" "Deleted Items" * LIST (\UnMarked) "/" INBOX * LIST (\Marked) "/" Large * LIST (\UnMarked) "/" Lists * LIST (\Marked) "/" MAPI * LIST (\Marked) "/" Notes * LIST (\Marked) "/" Office * LIST (\Marked) "/" Sent * LIST (\UnMarked) "/" SharedContacts * LIST (\Marked) "/" Suggestions * LIST (\UnMarked) "/" Tasks s OK completed
s list (CLASS) "" "%"
* LIST (\Class("IPF.Appointment") \UnMarked) "/" Calendar
* LIST (\Class("Default") \Marked) "/" Connections
* LIST (\Class("IPF.Contact") \UnMarked) "/" Contacts
* LIST (\Noselect) "/" Customers
* LIST (\Class("Default") \Marked) "/" "Deleted Items"
* LIST (\Class("Default") \Marked) "/" Discussions
* LIST (\Class("Default") \Marked) "/" Drafts
* LIST (\Class("Default") \Marked) "/" FAQ
* LIST (\Class("Default") \Marked) "/" GmbH
* LIST (\Class("Default") \UnMarked) "/" INBOX
* LIST (\Class("Default") \Marked) "/" Large
* LIST (\Class("Default") \UnMarked) "/" Lists
* LIST (\Class("Default") \Marked) "/" MAPI
* LIST (\Class("IPF.stickyNote") \Marked) "/" Notes
* LIST (\Class("Default") \Marked) "/" Office
* LIST (\Noselect) "/" POSTMASTER
* LIST (\Class("Default") \Marked) "/" Sent
* LIST (\Class("IPF.Contact") \UnMarked) "/" SharedContacts
* LIST (\Class("Default") \Marked) "/" Suggestions
* LIST (\Class("IPF.Task") \UnMarked) "/" Tasks
s OK completedYou also need a special SETCLASS <mailboxname> <class> command to set a mailbox class (alternatively, the CREATEMAILBOX syntax can be extended to provide class information, something like this:
CREATEMAILBOX (CLASS "IPF.Contact") "Contacts"
As you see, we used Microsoft names for growpware "mailboxes" - not the best choice, for sure, but as there is no standard in any case, and the initial target was to support the MAPI Connector - not the worst case either. If/when a standard on these names would emerge, we would quickly map these names to standard names.
Each item in the store has an additional header field MODIFIEDDATE which is similar to INTERNALDATE but return the date modified. A plain old mailstore would return the INTERNALDATE as the file is not modifiable. This is also searchable so you can simply find the messages modified since the last check.
You then need a modify command
MODIFY id {size} data And UID MODIFY uid {size} data
This replaces the message with a new message.
We thought about this, and rejected it for the reasons already mentioned on this list. It's not a problem for a groupware client to be aware of "changing" messages and somehow sync its cache with the server when a message changes, but the point is to maintain compatibility with existing IMAP mail-only clients. While the IMAP specs do not say it explicitly (to the best of my knowledge), all IMAP clients ASSUME that messages do not change, and thats' how they maintain their caches.
A minimal header for none message (MAILSTORE) types should be included in the RFC as something like FROM, TO, Subject, Date, content-type
Yes, that's how all these systems work.
Finally the document type should allow access to a OS folder store where any old document can be stored
You can always create a mailbox manager that will use certain file storage folders as its mailstore, adding the necessary headers "on the fly" and base64-encoding the files when retreiving them. The only problems there are:
a) you need to design some method to calculate the size of the "message image" for each file (i.e. you need to be able to calculate the size of headers and the size of the message body from the file name and file size).
b) you need to maintain the UIDs for all files there. Unless you keep some index file, it's not a trivial task.
The document would be presented as a mime message. E.g.
MIME-Version: 1.0 Content-Type: image/jpeg ; name="logo.jpg" Content-disposition: attachment; filename="logo.jpg"
What is the general feeling of the community for adding these extra features which would make IMAP into a groupware protocol. I think that it is pointless us all trying our own flavours of IMAP to try to get the clients to work. A specification would solve this, or, should we start a new protocol specifically designed for groupware.
a) the Mailbox "class" is definitely needed, and it should be availably from non-select state, and should be available quickly.
b) message modification - IMHO, it's not possible to implement the modify (we call it REPLACE) command w/o breaking the existing IMAP clients.
c) providing access to file store via mailbox store is not a very big problem, but this has nothing to do with IMAP.
-------------------- chapter 2 :-) --------------
Mark has mentioned that many IMAP client designers fight with the protocol, w/o fully understanding it, rather than using all the features it offers.
I spoke to quite a few of those designers and I completely agree with Mark here. And I'd say that one of the reasons is the size of the IMAP standard, and one other reason is the fact that the IMAP standard speaks about the things that are not directly IMAP related - such as mailstore semantics.
So, I'd repeat it again - it would be much better if the IMAP standard doc is splitted into two - one the "Message store concept and semantics", and one - the IMAP protocol per se, i.e. the protocol-only description.
While a lot of message store semantics was invented/clarified/discovered during the course of the IMAP "infrastructure" development, it has nothing to do with the protocol itself. The same semantics is used by other mail server components dealing with the mail store - POP3 servers, WebMail servers, local delivery agents, etc.
Still a lot of semantics is assumed in the IMAP protocol, but is not formulated anywhere (like the "const" nature of messages).
Separating these two issues would provide much more clear picture of the technology to all new developers, will make the IMAP protocol much more "readable", and it will allow Mark to put much more samples into the IMAP protocol specs, they DO help.
Regards
Richard Bang Floosietek Ltd [EMAIL PROTECTED] http://www.floosietek.com
Sincerely, Vladimir
