Michelle Konzack writes:
Hello Sam,Am 2010-07-16 19:06:30, hacktest Du folgendes herunter:Michelle Konzack writes: >And this is the question: WHY is Outlook not able to create it? Because Outlook is written by a convicted monopolist who is not interested in making it work with commodity servers based on Internet standards, rather the preference is for its companion server product.Can it be, that there is a diffence beween imaps://mail.example.com/INBOX and imaps://mail.example.com/INBOX/ where it result in something like: imaps://mail.example.com/INBOX.Trash and imaps://mail.example.com/INBOX/.Trash because "mutt" show the first version, but older Outlook the second one.
Yes, there most certainly is a difference. This is an endless source of confusion.
First of all, there is a generic specifications for URIs (or URLs), RFC 2396, which takes a rather circuitious route to define the format as:
<scheme>://<authority><path>?<query> path = [ abs_path | opaque_part ] abs_path = "/" path_segments path_segments = segment *( "/" segment )The capsule summary is that the path component of a URL is defined to be a hierarchical object that specifies the path component as a hierarchical list, with the "/" character as a hierarchy delimiter.
Then, there is the specification of the IMAP URL scheme, RFC 5092, which defines an IMAP URL format as:
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]IMAP, as you know, lets the server select a hierarchy delimiter character. It does not have to be "/", it can be anything. Courier-IMAP uses ".".
It's a source of ambiguity whether the IMAP server's hierarchy should be mapped into the generic hierarchy in the URI path string.
The seemingly intuitive approach, that it should be, is wrong. If you take this approach, then you end up with the following situation. If the IMAP server uses "/" for a hierarchy delimiter, then a folder on that server called "public/archive" would be referenced as "imap://server/public/archive". That's fine a dandy, but if the IMAP server uses "." for a hierarchy delimiter, if you use URI's hierarchical path, then the "public.archive" folder on that server would also be referenced as "imap://server/public/archive".
Now, you end up with the application taking something like "imap://server/public/archive", and needing to open that folder. To open that folder, the application needs to send the folder's name to the IMAP server. If you take the approach of mapping the URI hierarchy into an IMAP hierarchy, in order to do this you need to know what the IMAP server uses for a hierarchy delimiter, in order to construct the actual folder name.
In the IMAP protocol, if you have an arbitrary folder name, the IMAP server will tell you which characters in the folder's name are hierarchy delimiters. But you already have to have the IMAP server's folder name as a starting point, so you have a chicken-vs-egg situation: you need the IMAP server's hierarchy delimiter character in order to create the actual folder name from an imap: URL, but in order to get the server's hierarchy delimiter character you already need to have an actual folder name on the IMAP server.
Faced with this quandary, forging ahead with the strategy of trying to map the IMAP hierarchy into the URI path hiearchy always ends up with the application using some crazy scheme to come up with the folder's name from the URI. What you're probably seeing is something along these lines, from Outlook getting it wrong.
The IMAP URL scheme, RFC 5092, gives you a clue as to how to do it right: imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]The IMAP folder name, in the context of URIs (or URLs) is a single flat name. If the folder's name contains any character that has a special meaning in URIs, it should be %-encoded, as described elsewhere. A folder named "public/archive", on an IMAP server that uses "/" as a hierarchy separator, should be referenced as:
imap://server/public%2Farchive Courier-IMAP's Trash folder should be referenced simply as: imap://server/INBOX.Trash Because the "." character carries no special meaning in URIs.
pgpwpDUFBUtvQ.pgp
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
