[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Bug#28498: IMAP account shows two inboxes
From:       Sven Carstens <s.carstens () gmx ! de>
Date:       2001-07-10 9:51:02
[Download RAW message or body]

Am Sun, 10 Jul 2001 schrieben Sie:
> On Tuesday, 10. July 2001 01:04, Alan Chandler wrote:
> >
> > Here is potentially the problem!
> >
> > . list "" INBOX
> > * LIST (\NoInferiors) NIL INBOX
> > * LIST (\NoInferiors) NIL INBOX
> > . OK LIST completed
> 
> I think so, yes.
> KMail always uses an empty refenence parameter, therefore the other cases 
> should not appear.


Quoting RFC 2060 (Imap 4 rev 1) pages 29 and 30

   Arguments:  reference name
               mailbox name with possible wildcards

      .....

      An empty ("" string) reference name argument indicates that the
      mailbox name is interpreted as by SELECT. The returned mailbox
      names MUST match the supplied mailbox name pattern.  A non-empty
      reference name argument is the name of a mailbox or a level of
      mailbox hierarchy, and indicates a context in which the mailbox
      name is interpreted in an implementation-defined manner.

      .....

      The reference and mailbox name arguments are interpreted, in an
      implementation-dependent fashion, into a canonical form that
      represents an unambiguous left-to-right hierarchy.  The returned
      mailbox names will be in the interpreted form.
 
      Any part of the reference argument that is included in the
      interpreted form SHOULD prefix the interpreted form.  It SHOULD
      also be in the same form as the reference name argument.  This
      rule permits the client to determine if the returned mailbox name
      is in the context of the reference argument, or if something about
      the mailbox argument overrode the reference argument.  Without
      this rule, the client would have to have knowledge of the server's
      naming semantics including what characters are "breakouts" that
      override a naming context.

The problem here is a lot of 'SHOULD' and 'implementation-dependend'.
Thats why we don't use the references parameter so far.
A good reading is also RFC 2683 (implementation recommendaions).

CU Sven

_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]