On Fri, 10 Jan 2003, Lawrence Greenfield wrote:
> If this is what people want (and I think I've heard it enough that it is)
I disagree with this claim.
> Is there anyone who wants to speak up in favor of using Subject in
> threading?
Yes, everybody for whom threading will break if this is remove
On Fri, 10 Jan 2003 13:12:32 -0500, Ken Murchison wrote:
> Well, I don't think we can change the current name, because there is
> already some deployment.
We can not change the name.
> We _could_ add a THREAD=REFERENCES-ONLY or
> THREAD=REFERENCES-NOSUBJ or ...
Fine. The THREAD specification ex
On Thu, 10 Jan 2003, Timo Sirainen wrote:
> Another thing I saw with UW, it
> didn't group these messages together:
> Subject: =?iso-8859-1?Q?foo?=
> Subject: =?iso-8859-1?Q?RE=3A_foo?=
Question for the list: should it?
It turns out that UW imapd does something different from the base subject
ext
This note is to announce the availability of the University of Washington
IMAP toolkit version 2002b. This release does not introduce major new
functionality. Instead, it addresses bugs found in earlier versions.
Source code for the latest IMAP toolkit release is available at:
ftp://ftp.
On Thu, 10 Jan 2003, Timo Sirainen wrote:
> The draft says "If two or more messages have the same Message ID, assign
> a unique Message ID to each of the duplicates". Doesn't that mean that
> those messages should behave exactly as if they didn't have Message-ID
> header at all?
No, although I can
On Thu, 9 Jan 2003 23:12:18 +0100 (CET), Andreas Aardal Hanssen wrote:
> qmail saves messages using bare LFs. Should an IMAP server convert the
> mime data to CRLF?
Yes.
> Should a client assume CRLF / bare LF mime content when fetching data
> from the server?
CRLF.
Your issue is not with UW imapd, but rather with SSL certificates. For more
detailed help, you should check on a mailing list or newsgroup dedicated to
OpenSSL and/or certificate issues.
The procedure that you gave:
openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 3650
is the
On 02 Jan 2003 11:15:12 +0200, Timo Sirainen wrote:
> The latest IMAP4rev1 draft
It's already gone to the RFC editor, after numerous last calls.
> specifies that UNSEEN reply is required after
> SELECT and EXAMINE, but it doesn't say what to do when there are no
> unseen messages.
What to do is
The only actions that can take place before the initial banner that may
consume time are:
1) DNS lookup of the local host name.
2) ident lookup by [x]inetd
I suspect an ident lookup. Check your TCP wrappers configuration.
On Mon, 23 Dec 2002 16:46:37 +0530, venkat Devarajan wrote:
> Why dont the fetch and store commands not warrant unsolicited EXPUNGE
> replies ?
You can pipeline FETCH or STORE commands; that is, you can send multiple
commands at a time.
If untagged EXPUNGE responses were allowed, then the sequenc
The specification is quite explicit: flags SHOULD be copied from the original
message to the copy at the time the copy is made.
I don't think that subsequent changes to the flags in either the original or
the copy should in any way effect the other. The specification doesn't forbid
such behavior,
The explanation is that the user is running an inferior POP3 client that
spawns multiple simultaneous POP3 connections. The POP3 protocol permits only
one POP3 connection at a time. Also, the traditional UNIX mailbox format only
can have one read/write access at a time. POP3 is always read/write
On Thu, 19 Dec 2002, nick elprin wrote:
> Does anyone know how well abstracted the storage mechanism in the UW
> code is?
All access to a mail store (whether it be a network protocol, a local
filesystem object, or a database) in UW imapd is done via a driver, which
is a set of routines that implem
On Wed, 18 Dec 2002 09:34:03 -0500 (EST), Mark Hennessy wrote:
> I have just recently installed imap-2002.RC10 and am wondering if there is
> any documented way to block users that may be unauthorized on a temporary
> basis by flat file?
There isn't anything specific to imapd.
The easiest way to
This note is to announce the availability of the University of Washington
IMAP toolkit version 2002a. This release does not introduce major new
functionality. Instead, it addresses bugs found in earlier versions.
Source code for the latest IMAP toolkit release is available at:
ftp://ftp.
draft-ietf-imapext-sort-11.txt has been submitted, and is also available
on:
ftp://ftp.cac.washington.edu/mail/draft-ietf-imapext-sort-11.txt
This document merges the SORT and THREAD drafts, and makes some tenative
steps towards addressing some long-standing nits; e.g. there is now a
valid
On Sun, 8 Dec 2002, Jorge Minassian wrote:
> * BYE Service not available localhost.localdomain IMAP4rev1 2001.315rh at
> Sun, 8 Dec 2002 15:25:40 +0300 (GMT-3)
You have an /etc/nologin file, which indicates that new logins should not
be permitted.
-- Mark --
http://staff.washington.edu/mrc
Scien
On Fri, 06 Dec 2002 11:15:07 -0500, Pete Maclean wrote:
> If my analysis is correct, the non-obvious reason is that the client gets
> unhappy if it fails to obtain certain tagged responses in single read/recv
> chunks. Which effectively means that it expects said responses to be
> delivered in sin
What you describe is not a "security whole" (or a security hole). I have told
you that multiple times. I also told you how you can configure imapd if you
want to apply extraordinary access control; this is even documented.
I object to your attempt to pressure me.
On Thu, 5 Dec 2002, Tomki wrote:
> On the ftp site, I see that the archive imap-2002 is no longer in place,
> but the development archive is.
> Does this indicate such a problem with imap-2002 that the dev version
> should be used instead?
Yes. A problem has been discovered such that the "recomme
Some mailbox formats do not copy keyword flags (flags that do not begin with a
"\" character) well. This is a known deficiency of those formats.
On Wed, 4 Dec 2002 17:50:22 +0100 (CET), Andreas Aardal Hanssen wrote:
> >* STATUS "new" (messages 3 uidnext 0 uidvalidity 0)
> So even if it isn't too clear _why_ a client would want to do this, it's
> obviously a "case" that is not handled in the rfc in any way.
Huh? The RFC is very specific ab
On Wed, 04 Dec 2002 10:12:19 -0500, Pete Maclean wrote:
> * STATUS "new" (messages 3 uidnext 0 uidvalidity 0)
I hope that everybody understands that this is a non-compliant response, and
therefore represents a server bug which must be fixed.
On Tue, 3 Dec 2002, Andreas Aardal Hanssen wrote:
> If someone does a STATUS on a mailbox that the IMAP server has not seen
> before - what is expected output for UIDNEXT and UIDVALIDITY?
I don't understand this question.
The UIDVALIDITY is always the uidvalidity value assigned to the mailbox,
an
A 30MB mailbox, while large, is not ridiculously large. If the mailbox is in
traditional UNIX mailbox format, it will have to read the entire file; but
that should take no more than a few seconds unless I/O is very slow on your
system. Using mbx format will speed this up greatly.
100 seconds is
On Thu, 28 Nov 2002, Simon Josefsson wrote:
> What guarantees that traffic from 127.17.23.42 did not go through
> non-local systems?
Isn't 127/24 defined as being the local interface?
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate
On Wed, 27 Nov 2002 19:45:32 +0200, Matti Aarnio wrote:
> You might even consider "local" not only loopback, but any connection
> where getpeername() and getsockname() returned addresses are
> same (port-numbers will vary, of course.)
I'd be worried about doing this, because of the possi
On Wed, 27 Nov 2002 13:14:54 -0500, Lawrence Greenfield wrote:
>Note: a server implementation MUST implement a
>configuration
Although that weasel-wording helps previous source distributions (if you
remember, I lobbied hard for it), it does not help binary distributions if
On Wed, 27 Nov 2002 10:26:12 -0600, Don Moore wrote:
> In my opinion, it's not a software author's job to tell users what level
> of security they _must_ comply with. If the author wishes to suggest
> security, cleartext logins could be disabled by default if the connection is
> unsecure. However
I recently received a request to allow plaintext passwords in unencrypted
connections if the connection is localhost, even if plaintext passwords are
otherwise forbidden in unencrypted connections.
I see no reason not to do this in UW imapd (and make a user very happy), but
before I do it I'd like
On Fri, 22 Nov 2002, Newsgroup posting address wrote:
> root@jwilde-solaris# /usr/local/sbin/ipop3d
> +OK POP3 jwilde-solaris.glocalnet.com v2001.80 server ready
> USER james
> -ERR Unknown AUTHORIZATION state command
This happens when the software is built to disable plaintext password
authentica
On Wed, 20 Nov 2002, Jay Klesitz wrote:
> Hi, I am running the imapd linux binary.
> - Is there any specific startup parameters? or config files it must read?
> - It isn't listening on any ports, thus I am unable to connect to it.
Did you read the installation instructions for imapd? imapd does n
On Fri, 15 Nov 2002, Grant Baillie wrote:
> 1) For "/", use a Unicode character like U+2215, which will display
> approximately the way the user expects. I think there's a similar
> unichar for "." and maybe even "\".
As Larry Osterman says, this *is* a valid solution, but is problematic
with clie
David -
I think that the Mercury server, which allows duplicate subscriptions, is fine
as-is, and does not need to be changed.
If you choose to change your server's behavior, I recommend that it issue a
"NO" in response to an attempt to subscribe a mailbox that is already
subscribed.
The problem
On Thu, 14 Nov 2002 10:38:39 +1300, David Harris wrote:
> What is the proper action to take when a client issues a SUBSCRIBE
> command with a parameter that already appears in the subscription list?
> Should a duplicate be created, or should the existing entry be removed
> from the subscription lis
In general, since a server has the untagged EXPUNGE mechanism to indicate what
messages it has expunged, there is little/no need to send a NO for an EXPUNGE
command.
Many clients do an automatic EXPUNGE before LOGOUT when they quit, so you
should consider whether you really want to send a NO, thus
On Thu, 7 Nov 2002 05:45:49 -0800 , SIDWALL,GRANT (HP-Canada,ex1) wrote:
> The customer states that they are using IMAP4.4, and c-client 4.7c2.
This sounds like VERY OLD versions of UW imapd, with known security issues.
It should be upgraded immediately, and that old version not installed on any
n
On Tue, 5 Nov 2002 07:45:45 -0800 (PST), Mark Crispin wrote:
> All IMAP tokens (as opposed to strings such as user name, password, mailbox
> name, etc.) are case-insensitive.
However, with that in mind, I don't think that a server should change the case
of tags.
c-client (used by P
All IMAP tokens (as opposed to strings such as user name, password, mailbox
name, etc.) are case-insensitive.
On Tue, 5 Nov 2002 11:43:01 +0100 (CET), =?ISO-8859-1?Q?Peter_L=F6fkvist?=
wrote:
> Question: Does, the on the home page linked, imap-2002.RC10 support ipv6?
> I saw that Peter Derr made a patch to 2002.RC1, but I didn't see any signs
> of IPv6 in the 2002.RC10. If not, is there a patch one could g
That "/" is a typo.
I will try to get it fixed before the RFC comes out.
These are certainly *not* known UW imapd issues. We have people who move
messages in and out of INBOX all the time; and if you are using mbx (as
opposed to mbox) format it shouldn't matter if there is still an old imapd
server process since mbx is a shared access format.
Have you tried using othe
Hello Vladimir -
Once again, I would like to thank you for your thoughful analysis and
comments.
I've read your message, and I don't think that there is anything that
justifies recalling the document from the IESG; so it will not go into the new
RFC. However, I certainly will keep your message,
On Wed, 23 Oct 2002 23:25:31 -0700, Auteria Wally Winzer Jr. wrote:
> I've read the doc on md5.txt which states the file to be created is
> /etc/cram-md5.pwd.
> How is this mechanism created?
/etc/cram-md5.pwd is an ASCII text file, created with an editor such as emacs
or vi.
> Is it done via sas
On Mon, 21 Oct 2002, Don Buchholz wrote:
> $ gcc -lc-client -o simap simap.c
What happens if you give the command
gcc -o simap simap.c /usr/lib/libc-client.a
If that works, then you need to take your question to the gcc people to
find out the correct way to do linking.
By the way, yo
It is an error to set up a black-box-directory without a directory for each
user under it. The software will NOT run under such circumstances. In
versions prior to imap-2002, it will segfault due to a null pointer. In imap-
2002, it will issue an error message and crash.
There is an additional,
On Sun, 20 Oct 2002, [windows-1252] Atle Magnus $BOW(Brebust wrote:
(B> But when trying to compile php4 with imap support, I get the following errors:
(B> /usr/bin/ld: cannot find -lc-client
(B
(BYou need to look at the PHP4 build script to find where it is looking for
(Bc-client.a, and th
Return-Path: is written by your mail delivery agent when it writes to your
mail file. Some broken MDAs don't do this.
On Wed, 9 Oct 2002 09:42:54 -0700, Larry Osterman wrote:
> If the IMAP for some mail stores defers committing operations until a
> logout command, how does the server report the result back to the
> client? The client at this point has no way of recovering from the
> error, since it's tearing d
On Wed, 9 Oct 2002 11:03:28 -0400, Murat Bicer wrote:
> I want the server not to time out, once imap connection is established
> between the client and the server.
Your client must send a command at least every 29 minutes. There is a NOOP
command which is suitable for this purpose.
On Wed, 09 Oct 2002 11:42:52 -0400, Pete Maclean wrote:
> Mark, thank you for setting us straight on this. For me, another question
> arises: when a server detects a connection break, should it process any
> IMAP commands that it has pending for the session, or should it discard
> them? Seems t
If you do not send a LOGOUT and just close the connection:
Depending upon how the operating system fields the event to the server, the
server will see it as a "Hangup" (SIGINT), "Terminated" (SIGTERM), or as "End
of file on stdin". In my experience, the last is the most common.
If the server lo
On Tue, 8 Oct 2002 09:39:46 -0300, Domingo Antoniowrote:
> I'm using uw-imapd for about 70 users.
> All users haves yours mailbox more then 100m ( it is store in mailbox
format.. unix default )
> When i have 20 simultanious connection my server work very slow!!!
100MB is much
On Thu, 03 Oct 2002 11:46:53 -0700 (PDT), [EMAIL PROTECTED] wrote:
> FWIW, I raised the point that a revised draft will be received with the
> IESG today and said that I wasn't planning an additional last call unless
> there are substantive changes. Everyone seemed happy with that.
Thank you. Do
Everybody, please take a final look at
http://www.ietf.org/internet-drafts/draft-crispin-imapv-20.txt
This addresses all of the nits that Vladimir pointed out. I hope that this is
the version we can ask the IESG to consider.
Thank you to everybody who has taken the time from their busy
Hi Brenden -
I think that the document is correct and non-conflicting as it stands.
The text in 6.1.1 requires that STARTTLS be implemented. The text in 6.2.2
and 11.2 requires that STARTTLS or "some other mechanism" be used.
In other words, you can use other protection mechanisms instead of S
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> Please search on the "\Recent" - the phrases themselves are different, but
> they have the same meaning.
I did. I only found one place in the entire document where it said that
you could not STORE \Recent, and I changed that place to mention APPE
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> In serveral places the following phrase is being used:
>\Recent can not be used as an argument in a
>STORE command, and thus can not be changed at all
I only found one place?
> Actually, "flag"s can be used as an argument of the APPEND com
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> The state of a connection is only changed by successful commands
> which are documented as changing state. In particular, a failed (NO
> response) or rejected (BAD response) command does not change the
> state of the connection.
> A
On Tue, 1 Oct 2002, Chris Newman wrote:
> Does this imply that concurrent sessions see flag change notifications in
> response to the next command they issue (as Outlook assumes)? Or are lazy
> notifications permissible (where concurrent sessions may get delayed
> notification of flag changes)?
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> , when acceptable authentication credentials have been
> provided, after the CLOSE command, or after an error in selecting
> a mailbox.
Thank you. I have adopted this suggestion.
> -- note about the protocol (IMAP 5 suggestion?)---
>
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> Since a mailbox can be opened by several sessions at the same time, this
> should be changed to:
>; that is, subsequent and concurrent sessions will see any
> change in permanent flags.
I make it be "concurrent and subsequent", but otherwis
On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> a client can only assume that a new
> message will have a UID that is greater than or equal to
> the next unique identifier value.
Based upon your comments, I have changed the above text to:
A client can only assume, at
On Tue, 1 Oct 2002 [EMAIL PROTECTED] wrote:
> Wonder if anyone could tell me if there's an easy way to change the log file
> location for imapd (preferably without recompiling!)?
Since there is no reserved syslog facility for imapd, it uses the mail
facility. There are 8 "local" facilities which
On Tue, 1 Oct 2002, Keith Robinson wrote:
> One other thing, is this scenario OK?
>
> C: tag EXPUNGE
> S: * 2 EXISTS
> S: tag OK EXPUNGE completed
Yes. This means "nothing was expunged. Message 2 exists."
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party po
On Tue, 1 Oct 2002, Keith Robinson wrote:
> So I fully understand what you are saying. EXPUNGE can only remove messages
> the client knows to have the \Deleted flag set?
NO!!!
If I said anything that implies that, I'm sorry, because that is certainly
not the case.
If it were, it would be imposs
> [client issues an EXPUNGE when a new message 2, not yet seen by the client,
> has \Deleted set due to the action of another client.]
The behavior is implementation-dependent, as long as it complies with the
requirements of IMAP.
I think that the scenario SHOULD be:
S: * 1 EXISTS
If group concensus is that no last call is needed, don't let me be the
cause of there being one. I would be happy to do without a last call if
such is permissible.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Draft 19 of the base specificationis now available at:
http://www.ietf.org/internet-drafts/draft-crispin-imapv-19.txt
I would like to go to Last Call on this as soon as possible. Before doing
that, I would like to ask Vladimir to see if it satisfactory addresses the
issues that he raised, or if
On Thu, 26 Sep 2002 12:21:37 -0700, Larry Osterman wrote:
> I feel obliged to toss out that when you select a mailbox when you are
> unauthenticated, the Exchange IMAP server does:
> [snip]
> I don't have access to a UW IMAP server to see what it does
If you don't need to be logged in, try .d
On Thu, 26 Sep 2002 11:17:14 -0700, Vladimir A. Butenko wrote:
> I'm not talking about "fixing" anything here. I'm talking about making the
> standard a definitive document.
That's what I'm talking about as well; if the standard fails in some
substantive way to be a definitive document, it needs
On Thu, 26 Sep 2002 10:09:29 -0700, Vladimir A. Butenko wrote:
> Do you suggest that there should be NO strict and explicit definition for
> the cases when BAD should be returned instead of NO?
My opinion (subject to change with a convincing argument):
It is desirable to distinguish between BAD
On Thu, 26 Sep 2002 09:15:34 -0700, Larry Osterman wrote:
> On the other hand, it is NOT a protocol
> error for the following to occur:
> S: * 2 EXISTS
> S: tag OK
> C: tag FETCH 2
> S: * 2 EXPUNGE
> S: * FETCH 2 (NIL)
> S: tag OK Fetch completed but message del
Thank you for your comments. Even if I don't always agree, they are very
valuable since they indicate issues which need to be addressed.
For most of your issues regarding sequences, watch for draft 19. The text has
been completely rewritten, and should be a lot better. I should be posting it
i
On Wed, 25 Sep 2002 14:58:39 -0700 (PDT), [EMAIL PROTECTED] wrote:
> > I discovered that the MULTIAPPEND draft had expired while waiting for IESG
> > action. I've resubmitted it.
> Grr. This is not supposed to happen. Documents which are "in the system",
> and this one most certainly is, are not
On Wed, 25 Sep 2002 22:18:02 +0200, Simon Josefsson wrote:
> Except possibly this new UIDNEXT thing. Cyrus IMAP for one doesn't do
> this.
Cyrus in your example is fine. It returned an error when using * to access a
message sequence number in an empty message:
> . FETCH * UID
> . NO No matchin
There is no simple answer.
If you EXAMINE the mailbox, leave it open, and there is a shared lock, it is
possible that the owner of the mailbox may discover the monitoring if an
EXPUNGE returns a "can't do it because someone else has a shared lock" error.
On the other hand, EXAMINE may also fail
On 25 Sep 2002 20:36:43 +0100, Jinn Koriech wrote:
> From what I understand this should pipe all mail to jinn to
> /var/spool/mail/jinn - but instead in the logs dmail reports that it
> can't run as root or daemon.
This means either that dmail was invoked incorrectly by procmail, or that the
dmai
If a server does not normally announce new mail messages with EXAMINE it
probably not do so just because you use the IDLE command.
The entire reason why a server might not announce new mail messages with
EXAMINE is if the underlying mail store requires an exclusive lock in order to
read. If the
On Wed, 25 Sep 2002 10:20:56 -0700, Larry Osterman wrote:
> Nit: Should it be "should" or "SHOULD" in "The server should respond
> with a tagged BAD" below?
In general, I've avoided placing requirements on server handling of errors.
In my opinion, a compliant server could treat "FETCH *" of an em
I'm afraid that we are reaching (or have already reached) the point where we
will have to do another Last Call.
If that is the case, would there be any objection to folding the MULTIAPPEND
draft into the base specification? Unlike other extensions, MULTIAPPEND is
not a new command; it is an obvi
On Wed, 25 Sep 2002 14:58:15 +0200, Simon Josefsson wrote:
> Would it improve the standard to make this more obvious? The text
> that the argument is based on is located inside parentheses in a
> comment inside the ABNF without saying how to handle the error or why
> it is an error.
Well, sectio
On Wed, 25 Sep 2002 07:39:40 -0700, Vladimir A. Butenko wrote:
> If FETCH 2:2 is legal for a mailbox that contains one message, I do not
> understand why Fetch 1:1 is illegal in an empty mailbox, or why FETCH 1:* is
> illegal in an empty mailbox.
FETCH 2:2 is *NOT* legal for a mailbox that conta
I discovered that the MULTIAPPEND draft had expired while waiting for IESG
action. I've resubmitted it.
-- Mark --
--
-
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.htm
The statement in RFC 2246 is certainly applicable to special SSL ports. For
example:
[...] application protocols which are secured by
TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
connection port: for example, the https protocol (HTTP secured by SSL
or TLS) uses port 443
On Wed, 25 Sep 2002 10:43:41 +0200, Arnt Gulbrandsen wrote:
> Hm. Is the server even allowed to give different responses to two FETCH
> commands for the same item?
>
> C: a FETCH 1 RFC822.SIZE
> S: * 1 FETCH (RFC822.SIZE 12345)
> S: a OK
> C: b IDLE
> S: +
> S:
On Tue, 24 Sep 2002, Simon Josefsson wrote:
> > That is also impossible in IMAP. Review sections 5.5 and 7.4.1.
> The sections seem to only discuss multiple commands from one client.
> I was thinking of server initiated emptying of mailboxes, or multiple
> concurrent clients where one of them emp
On Tue, 24 Sep 2002, Larry Osterman wrote:
> But what about this scenario:
> C: 1 NOOP
> S: * 5 EXISTS
> S: 1 OK NOOP Completed
> Client 2 now deletes all the messages in the mailbox. At this point,
> the client thinks that there are 5 items in the mailbox while the server
> knows that there are
On Tue, 24 Sep 2002, Marion Hakanson wrote:
> In particular, I'm wondering if the Eudora SSL failures described in
> the UW IMAP FAQ item 7.41 could be related to this issue:
>
> 7.41 Why can't I connect via SSL to Eudora? It says the connection has
> been broken, and in the server syslogs I s
On Tue, 24 Sep 2002 17:27:24 +0200, Simon Josefsson wrote:
> I meant that the mailbox can become empty during the time it takes to
> send the EXISTS to the client, and during that time window the client
> can issue a command with the * message number. Not a likely scenario,
That is also impossib
On Tue, 24 Sep 2002 17:06:23 +0200, Simon Josefsson wrote:
> > By the way, even a UID only client could avoid the problem if it paid
> > attention to the EXISTS value.
> No, the mailbox can become empty before the client received the EXISTS
> value. Returning BAD in this case seems unwarranted.
On Tue, 24 Sep 2002 14:16:49 +0200, Simon Josefsson wrote:
> I also recall from a comp.mail.imap discussion that it was the word
> "sequence" that caused confusion, some people (me included) regard
> "sequences" to be ordered. It was suggested to use the word "set"
> throughout the specification
On Tue, 24 Sep 2002 14:00:38 +0200, Simon Josefsson wrote:
> I feel "an error" is a bit loose. Exactly what will happen?
The server would return either BAD or NO. I prefer BAD.
> It is
> not impossible for a client to send e.g. a UID SEARCH UID 1:* to a
> mailbox before it discover that the ma
To address Pete's nits, I've done the following. While I was at it, I saw
something else that needed a clarification: a message sequence number of * in
an empty mailbox is an error, but a UID-only client might do * in an empty
mailbox if it doesn't look at EXISTS and thus * needs a definition for
Draft 18 is already at the Internet-drafts editor, although it doesn't
seem to be on the FTP server yet. I've been beating my head over the
alleged ambiguities and contradictions in the definition of sequence
sets all day with considerable frustration.
Here's what I've come up with, which I prop
Here's my own commentary on the current wording:
[...] For message
; sequence numbers, these are consecutive
; numbers from 1 to the number of messages in
; the mailbox
This does not belong in the defini
The following was recently sent to me regarding message set:
> More careful wording is a must
> there, as now it specifies that comma can separate individual numbers, so
> the form:
> 1,2:3
> is illegal, as comma here separates an individual number and a range, and
> this is not allowed by the IM
That's fine; I just needed the feedback. I wasn't sure if this was going in
the right direction, and if you thought that it would meet with IESG approval.
On Fri, 20 Sep 2002 14:37:13 -0700 (PDT), [EMAIL PROTECTED] wrote:
> I think the new wording is fine and even an improvement. I should have s
On Fri, 20 Sep 2002 14:20:58 -0700 (PDT), [EMAIL PROTECTED] wrote:
> > Other than that nit, I personally like the wording.
> Good.
Do *you* like the wording? I hate to assume that "silence == yes" and would
prefer a definite "yes".
OK, here is what I have for draft 18, based upon all the comments which I have
read. Please try to give me feedback on whether or not this is will be
acceptable to the IESG as soon as possible. I'd like to send draft 18 by the
end of the day today and hopefully not need a draft 19.
In AUTHENTIC
501 - 600 of 722 matches
Mail list logo
