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

List:       imap
Subject:    UIDs for mailbox formats that can't support UIDs
From:       Rob Austein <sra () epilogue ! com>
Date:       1994-09-30 5:07:40
[Download RAW message or body]

Sorry for the delay responding to Chris's request, I'm on vacation and
only checking mail occasionally.

I take it that we are all agreed that UIDs are not optional.  I can't
picture attempting to write a disconnected client that didn't use
them, and I would almost certainly not bother to use anything but UIDs
even in an interactive client.

If we're going to set a length limit on UIDs, it should be high.  255
digits is probably tolerable.  I think we'd want to phrase this the
same way as the DNS specs did: it's a restriction to allow easier
implementation, and may be lifted at some point in the future if we
decide we were wrong.  In practice I suspect the vast majority of uses
will be under six digits.  For reference, the current top UID on my
primary DMSP mailbox is just under 11000, representing about .3 of my
received email traffic in the last 14 months.

As I see it, the real question at the core of this discussion is what
is the least harmful thing to do with a mailbox format that can't
support "real" (immutable for all time) UIDs.  Ok, the first thing to
note is that efficiency just went west.  Forget about efficiency.  In
the long run, this is the real answer, because in the long run, it
means that anybody who has any control at all over their environment
will stop using this mailbox format for any folder that needs to be
available for disconnected access.  Think of it as evolution in action.

So the question remaining is what's the least awful thing to do to the
user during the time it takes the user to figure out that this is a
silly configuration.  Here's my take on the options, in decreasing
order of badness:

1) The worst thing would be "fake" UIDs that were not really unique,
   such that a disconnected client could delete and expunge the wrong
   message by accident.

2) The next worst thing would be denial of access to the mailbox, eg,
   not being able to get UIDs for the mailbox.

3) The next worst thing would be fake UIDs that were unique but not
   persistent across sessions, so that a simpleminded disconnected
   client would re-fetch everything (a smarter disconnected client
   might be checking Message-IDs anyway, to avoid extra fetches on
   "move" operations).

4) The next worst thing would be "fake" UIDs that were unique but not
   always persistent across sessions.

5) The least bad thing would be (4) with a special token on SELECT
   like [UIDSAREBROKEN] so that a smart client could warn the user
   that this is a really dumb way to do things.

(1) is clearly unacceptable.  (2) I could live with, but by the
robustness principle it seems like a bad thing for the server to be
doing if there's any way around it.  (3) and (4) allow the
disconnected client to hobble along, less efficiently, and with some
risk of message duplication.  (5) allows the client to warn the user
and/or decide to punt, without a lot of work (for the client).

To summarize: this problem only occurs when (a) a user insists on
using a mailbox format that (b) an implementor can or will only
partially support as a real IMAP4 mailbox.  Anything that allows
graceful failure without data loss seems adaquate for such a case.

--Rob Austein <sra@epilogue.com>

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