Hi,
If I've read this correctly, this issue...
In particular, the boundary delimiter is often seen following
immediately in the body part of a message, with no leading CRLF:
8---
...
...
headers
Content-Type: multipart/mixed; boundary=magic
Subject: Hello
If I send:
x LIST foo/%
and foo is a selectable mailbox with children, should the reply
contain \NoSelect flag for foo/ entry? ie. are the flags for foo
mailbox, or (invalid) foo/ mailbox?
--
-
For information about this
Timo Sirainen writes:
If I send:
x LIST foo/%
and foo is a selectable mailbox with children, should the reply
contain \NoSelect flag for foo/ entry? ie. are the flags for foo
mailbox, or (invalid) foo/ mailbox?
That client is asking information about mailboxes whose names start with
foo/ and
On Monday, Sep 15, 2003, at 19:14 Europe/Helsinki, Arnt Gulbrandsen
wrote:
Timo Sirainen writes:
If I send:
x LIST foo/%
and foo is a selectable mailbox with children, should the reply
contain \NoSelect flag for foo/ entry? ie. are the flags for foo
mailbox, or (invalid) foo/ mailbox?
That
On Mon, 15 Sep 2003, Arnt Gulbrandsen wrote:
That client is asking information about mailboxes whose names start with
foo/ and contain exactly one /, right?
foo does not match that, so why should the server mention foo at all?
foo/ is just one of the umpteen million possible names that don't
On Monday, Sep 15, 2003, at 19:49 Europe/Helsinki, Mark Crispin wrote:
On Mon, 15 Sep 2003, Timo Sirainen wrote:
Actually another question about that: Should foo/ be listed if foo
doesn't actually exist, but it has children?
What do you mean? How does this differ from foo being \NoSelect?
I was
On Monday, Sep 15, 2003, at 19:48 Europe/Helsinki, Mark Crispin wrote:
In the case where foo has children (which was Timo's question), that
makes
sense. But what if foo does not have children?
If the server doesn't list foo/ in that case, then it's saying that
the
hierarchical name foo
On Mon, 15 Sep 2003, Timo Sirainen wrote:
Hmm. So is it necessary to send foo/ at all if at least one of it's
children is listed?
IMHO, yes. Otherwise the behavior is inconsistent
1 create dir/
2 list dir/%
Is it required to show the dir/ entry?
Yes, it is. The only difference between
On Monday, Sep 15, 2003, at 20:12 Europe/Helsinki, Mark Crispin wrote:
Or if mailbox can contain children but currently doesn't, should list
mailbox/% show anything?
Yes, it should show the mailbox.
What about:
x list */%
Should it list all \NoInferiors mailboxes twice, once as mailbox and
Lyndon Nerenberg wrote:
--On Monday, August 11, 2003 1:33 PM -0400 Pete Maclean
[EMAIL PROTECTED] wrote:
Suppose that
the server works through the messages, decoding each appropriate MIME
part and sending it. Then suppose it hits one message that has the
part encoded using a method that
What is the meaning of BINARY[]? Is this the same as BODY[] (e.g.,
nothing gets decoded)?
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
--
On Monday, Sep 15, 2003, at 20:12 Europe/Helsinki, Mark Crispin wrote:
IMHO, foo and foo/ should be treated as equivalent in all cases
except for CREATE.
I've just returned NO to all such requests.
I don't think that your server should do that.
Looks like that's what your server does too. Or did
Mark Crispin wrote:
On Mon, 15 Sep 2003, Ken Murchison wrote:
What is the meaning of BINARY[]?
I think that it should be a syntax error, but unfortunately the
section-binary rule in RFC 3516 is:
section-binary = [ [section-part] ]
instead of:
section-binary = [ section-part ]
I
On Mon, 15 Sep 2003, Ken Murchison wrote:
What is the meaning of BINARY[]?
I think that it should be a syntax error, but unfortunately the
section-binary rule in RFC 3516 is:
section-binary = [ [section-part] ]
instead of:
section-binary = [ section-part ]
I consider this to be a bug
On Mon, 15 Sep 2003, Mark Crispin wrote:
On Mon, 15 Sep 2003, Rob Siemborski wrote:
If I do a LIST INBOX/%, and I have no sub-mailboxes in my INBOX,
INBOX does not match the pattern -- it is missing the trailing hierarchy
separator.
However, INBOX/ does; and if INBOX is not \NoInferiors
On Mon, 2003-09-15 at 22:37, Mark Crispin wrote:
On Mon, 15 Sep 2003, Ken Murchison wrote:
What is the meaning of BINARY[]?
I think that it should be a syntax error, but unfortunately the
section-binary rule in RFC 3516 is:
section-binary = [ [section-part] ]
instead of:
On Tue, 16 Sep 2003, Timo Sirainen wrote:
Maildir itself doesn't have any standard where other than INBOX should
be placed. Courier's Maildir++ places everything into ~/Maildir/
directory with '.' separating hierarchies. So it's possible to create
.1.2 directory without having .1.
OK, I
On Mon, 15 Sep 2003, Timo Sirainen wrote:
What is the meaning of BINARY[]?
I think that it should be a syntax error, but unfortunately the
section-binary rule in RFC 3516 is:
section-binary = [ [section-part] ]
instead of:
section-binary = [ section-part ]
I consider this
Mark Crispin wrote:
On Mon, 15 Sep 2003, Timo Sirainen wrote:
What is the meaning of BINARY[]?
I think that it should be a syntax error, but unfortunately the
section-binary rule in RFC 3516 is:
section-binary = [ [section-part] ]
instead of:
section-binary = [ section-part ]
I consider
On Mon, 15 Sep 2003, Ken Murchison wrote:
I guess we didn't do a very good job during last call of this doc ;)
I've only stumbled into these issues while implementing it. Maybe (as
Rob suggested offline) that independent interoperable implementations
should be a prereq (or at least strongly
Timo Sirainen wrote:
On Tue, 2003-09-16 at 00:21, Mark Crispin wrote:
OK, I understand now. And without some registry of names, there's no good
way to create foo.1. without creating foo.1, and you'd have to have a
placeholder if there is no foo.1.2 (or other child). That may be hard to
do.
Timo Sirainen wrote:
On Tue, 2003-09-16 at 00:59, Ken Murchison wrote:
Looks like Cyrus just creates a normal selectable mailbox with CREATE
mailbox.. I guess there haven't been much complains about that, so I'll
do that as well.
I don't believe that is correct. You can create foo.1.2 without
Mark Crispin wrote:
On Mon, 15 Sep 2003, Rob Siemborski wrote:
If I do a LIST INBOX/%, and I have no sub-mailboxes in my INBOX,
INBOX does not match the pattern -- it is missing the trailing hierarchy
separator.
However, INBOX/ does; and if INBOX is not \NoInferiors then that name
should be
Date: Mon, 15 Sep 2003 14:13:30 -0700 (Pacific Daylight Time)
From: Mark Crispin [EMAIL PROTECTED]
[...]
Where in RFC3501 does it say that the server needs to maintain
this trailing-hierarchy-separator convention?
The semantics of hierarchy vis a vis % were discussed in great
On Mon, 15 Sep 2003, Lawrence Greenfield wrote:
Cyrus has
never had this behavior.
Cyrus does not have such a thing as a \NoSelect mailbox with no children.
On a server which has such a thing as a \NoSelect mailbox with no
children, it becomes very important to respond to foo/% with foo/ since
On Mon, 15 Sep 2003, Ken Murchison wrote:
However, INBOX/ does; and if INBOX is not \NoInferiors then that name
should be shown.
Are you saying that a client depends on this in order to determine that
the mailbox can contain submailboxes?
Yes.
If a server returns INBOX and not
On Mon, 15 Sep 2003, Mark Crispin wrote:
On a server which has such a thing as a \NoSelect mailbox with no
children, it becomes very important to respond to foo/% with foo/ since
otherwise there is no distinction from the error case of foo no existing.
Ok, now I atleast partly understand. It
On Mon, 15 Sep 2003, Rob Siemborski wrote:
While I think its somewhat bizarre to report a leaf mailbox that is
\NoSelect and doesn't have any children, I can atleast appreciate why this
is necessary in some environments. However, as you say, such a case does
not apply to all servers (and
On Mon, 15 Sep 2003, Mark Crispin wrote:
On Mon, 15 Sep 2003, Rob Siemborski wrote:
While I think its somewhat bizarre to report a leaf mailbox that is
\NoSelect and doesn't have any children, I can atleast appreciate why this
is necessary in some environments. However, as you say, such a
29 matches
Mail list logo
