Nice MS Quote: =?UTF-8?Q?=22IMAP?= is just not a very rich =?UTF-8?Q?protocol=22?=

Nice MS Quote: =?UTF-8?Q?=22IMAP?= is just not a very rich =?UTF-8?Q?protocol=22?=

Post by Sam » Tue, 19 Aug 2003 02:33:41

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

Timo Sirainen writes:

That depends on the definition of "simplified". I believe that a much
simpler procedure can be defined which is still functionally equivalent to
IMAP, yet does not require the implementor to reverse-engineer IMAP by
looking at the protocol stream of an existing implementation. You can be
looking at nothing other than RFC 2821, and have a reasonable chance of
believing that your end result has a fairly good chance of sending or
receiving a message from someone else. You cannot make the same statement
about IMAP.

I estimate that only 25-33% of all functionality available in IMAP (which I
define as the base specification+common extensions) are actually implemented
by all clients in existence, and each client might use another 10%-20% of
the protocol for its own, client-specific reasons. Although every IMAP
functionality is used by some client out there, I estimate that most IMAP
clients use no more than half the available IMAP functionality, and no
client uses more than 80%-85% of it.

Even Cone, my IMAP client, which I consider to be quite versatile (partial
MIME access, IDLE, MIME/PGP, client-side mail filtering, etc...) doesn't
need half of what's available in IMAP.

Nobody says that you should. But first you had BODY, then BODYSTRUCTURE,
and now you have a son-of-BODYSTRUCTURE.

Each time you try to approach the same basic problem -- MIME access -- you
end up going back to the drawing board a few years later down the road.
Hello? To me, that sounds like there's something wrong with the approach.

Neither does the IMAP base. You have to have IDLE for that.

Same as IMAP.

Well, you're looking at it purely from a perspective of migrating from IMAP.
But, if you're starting from scratch then, with all other factors being
the same, would you rather:

A) Spend a month implementing the full IMAP syntax, or

B) Spend two weeks implementing an alternative syntax that's mostly a
functional superset of A).


Version: GnuPG v1.2.1 (GNU/Linux)


Nice MS Quote: =?UTF-8?Q?=22IMAP?= is just not a very rich =?UTF-8?Q?protocol=22?=

Post by Sam » Tue, 19 Aug 2003 07:21:24

his is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

Timo Sirainen writes:

There are two fundamental problems with BODYSTRUCTURE.

The reasons why you first had BODY, then BODYSTRUCTURE, then
son-of-BODYSTRUCTURE, is that because as clients evolved over time, and
gained new functionality, they acquired a need to obtain a header summary
that includes new headers not included in BODY (and BODYSTRUCTURE, now).

So the first problem is that BODY/BODYSTRUCTURE is limited to a fixed set of
predefined headers. Which either limits the current client functionality,
or will limit it at some point in the future.

The second problem with BODYSTRUCTURE is that it imposes a fixed
numbering/naming scheme for individual MIME sections.

All that really a client cares about is the parent/child MIME hierarchy
relationship: which MIME section is a component of which multipart MIME
section; and the order of siblings in the same multipart section.

To an IMAP client, it doesn't really matter whether the message has MIME
sections 1, 1.1, and 1.2; or A, B and C. All the IMAP client needs to know
is that MIME section A contains sections B and C.

The client is not likely to derive any valued functionality from the current
MIME numbering scheme. Clients typically model the message as hierarchical
tree of MIME sections. When the client wants to retrieve a given section,
the client is not likely to traverse the entire tree, and figure out what
the client's MIME hierarchical number is. It's far more likely that the
client will save the MIME section's identifier, when it builds the tree,
which then becomes nothing more than an opaque identifier for the MIME
section, as far as the client is concerned.

On the other hand, an IMAP server might find it more convenient to use an
internal database identifier or a handle for each attachment. But it can't.
It must then implement a mapping between MIME section numbers, and the
attachment's information.

Or the server would also use MIME section numbers as the index into the
internal mail store database. So the server will also not derive anything
value added from the current MIME section numbering scheme.

Instead of BODYSTRUCTURE, a better approach would've been a request for a
client-specified set of headers from all MIME sections in the message. As
IMAP client functionality evolves over time the clients can include any
additional headers in the request which they need. IMAP clients that don't
need certain headers (I don't think that many clients these days will find
anything useful to do with Content-MD5:, yet every BODYSTRUCTURE has one)
won't waste both the client's and the server's resources on them. The
server would then return the requested headers from all MIME sections, using
either prefix or infix hierarchy traversal, whichever it's more convenient
for the server. The server would also supply any convenient identifier for
each MIME section, which the client treats as an opaque item (as well as the
identifier of its parent MIME section).

The server cannot send an EXPUNGE anytime it feels like it.

It's still a client-initiated process. With IDLE, the client immediately
receives all changes to the folder's status, in realtime.

Well, I don't think I really want to know the specific IMAP server

Nice MS Quote: =?UTF-8?Q?=22IMAP?= is just not a very rich =?UTF-8?Q?protocol=22?=

Post by Sam » Tue, 19 Aug 2003 14:03:56

his is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

Timo Sirainen writes:

I don't see how CONDSTORE will help the client to resynchronize. The client
will know if someone else messed with the message, but it won't know that
until it tries to mess with it itself.

And what if the client doesn't want to mess with any message in the folder?
How exactly would it know which messages' flags were changed?

I reopened a folder. I know what the folder used to have. Now, how exactly
will CONDSTORE tell me which messages' flags have changed, and which
messages have been expunged?

It saves a round trip back to the server, the first time the message is
read. 99% of the time this is the desired behavior, and now you have a
trivial option that saves a frequent round trip.

What I'm not sure, exactly, is what's to be gained by imposing what
essentially is a specific implementation of a transaction identifier.

Your old transaction id was 50. You reopened the folder. What conclusion
can you make if you now see that the new transaction id is 70, or if it's
100? What does it get you?

In either case, your next step is to ask for a list of changes between
either 50 and 70, or 50-100. Then you set the current transaction id to
either 70 or 100, and you're done.

So, what exactly was the difference between receiving 70, or 100?

This is exactly the same thing as MIME identifier structure. The only
argument for a counter-based transaction id is because it's consistent with
the rest of IMAP. Counters for MIME sections. Counters for UID. Counters
for UIDVALIDITY. Other than overall consistency, there's not much to be
gained from that.

I expect to be around 2038, and I expect to still have most of my mental
faculties intact. I'm looking forward to seeing what happens to IMAP UIDs
and UIDVALIDITY's that either. That is, if IMAP's still around.

Anyway, the client really doesn't care about the counter aspect of a
transaction identifier. From the client's perspective, the only thing that
matters is whether the id has changed, or not. From the server's
perspective, you've now hung a particular implementation requirement around
its neck, which may or may not be optimum for the server to do.

I'm not convinced that the semantics of Recent are well defined and
uniformly implemented. That whole discussion has arisen precisely because
it's a mess.

Furthermore, the semantics of Recent do not work well with snapshots.

Cone does everything it needs to do -- checking for new mail, etc... --
without needing Recent. I'm not sure whether Pine does anything with Recent
too. Recent is another thing that IMAP servers are tortured with, with not
a lot to show for it.

Which client actually does something functionally significant with the
Recent flag?

Correct. It's unlikely for a MIME text/plain to sport a Subject: header.
There's a little detail that can be easily overlooked: headers received from
the server are folded. The client does need to parse the headers, but with
the headers being folded, the parsing is trivial. Discarding unwanted
headers for a given MIME section is nothing more than background noise.

The server has an option to individually reject a requested address as
invalid, or as unacceptable, for some reason.

Same as SMTP.


Nice MS Quote: =?UTF-8?Q?=22IMAP?= is just not a very rich =?UTF-8?Q?protocol=22?=

Post by Sam » Wed, 20 Aug 2003 11:57:47

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

Timo Sirainen writes:

A multiline parameter to ADD is already used to specify the message's
contents, and to commit it to a folder, or to send it.

Defining another multiline parameter is going to make things go even further
out of line. As it is, the only existing oddity is that the RCPTTO
attribute may occur multiple times.

The next step is -- I think -- is to define a process for uploading
individual MIME sections, in binary form, to the server (together with any
non-MIME headers), have the server choose the best encoding, and assemble
all MIME sections into a multipart MIME message. The existing IMAP (and
SMAP) model is not in balance: the server fully implements the facilities
for processing the message into its individual MIME components (and in case
of SMAP, or IMAP+BINARY, to decode each component); but the client is still
responsible for assembling a MIME message from its components.

That always seemed a bit skewed to me. If the server decodes MIME messages,
then it should also encode them too.

Version: GnuPG v1.2.1 (GNU/Linux)