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,
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 s
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.
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/ sinc
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, Mark Crispin wrote:
> > 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 deal in the
> IMAP WG. You might want to review some of the old messages
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 withou
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 foo or
Mark Crispin wrote:
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
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.
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 strong
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 c
On Tue, 16 Sep 2003, 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 chil
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.
I think you meant
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 "]
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,
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, 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
> > sh
On Mon, 2003-09-15 at 22:53, Mark Crispin wrote:
> > > IMHO, a Maildir type structure should never use \NoSelect except in
> > > LSUB.
> > And if a mailbox with children is deleted.
>
> Is there such a concept in Maildir? Doesn't the fact that the directory
> exists mean that it's valid? Or do y
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:
>
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
sh
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
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 shown.
> T
On Mon, 15 Sep 2003, Mark Crispin wrote:
> > Or if mailbox can contain children but currently doesn't, should list
> > "" mailbox/% show anything?
>
> Yes, it should show the mailbox.
Why? RFC3501 states:
The character "*" is a wildcard, and matches zero or more
characters at this p
On Mon, 15 Sep 2003, Timo Sirainen 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.
I was talk
On Mon, 15 Sep 2003, Timo Sirainen wrote:
> What about:
> x list "" */%
> Should it list all \NoInferiors mailboxes twice, once as "mailbox" and
> again as "mailbox/"?
That's a bizarre case, but it sounds like that's the right thing to do.
> > IMHO, a Maildir type structure should never use \NoSe
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 b
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 "]
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 d
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
--
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 t
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" a
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
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 doesn
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 w
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?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge f
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
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/" mailb
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
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 th
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<---
> ...
> ...
>
> Content-Type: multipart/mixed; boundary="magic"
> Subject: Hello
>
>
41 matches
Mail list logo
