Subject: IMAP section specifiers illogical?

From: Edmund GRIMLEY EVANS <[email-masked]>
Date: Wed, 21 Jul 1999 15:12:29 +0200

They are, aren't they?

Here's the example from section 6.4.5 of RFC 2060:

                        1          TEXT/PLAIN
                        2          APPLICATION/OCTET-STREAM
                        3          MESSAGE/RFC822
                        3.1        TEXT/PLAIN
                        3.2        APPLICATION/OCTET-STREAM
                        4          MULTIPART/MIXED
                        4.1        IMAGE/GIF
                        4.2        MESSAGE/RFC822
                        4.2.1      TEXT/PLAIN
                        4.2.2      MULTIPART/ALTERNATIVE
                        4.2.2.1    TEXT/PLAIN
                        4.2.2.2    TEXT/RICHTEXT

It seems that, in order to make the specifiers a little more concise,
at the cost of making them a lot harder to understand, an entity (which
corresponds to the data type "BODY" in c-client) that is of type
"multipart" and whose parent entity is of type "message/rfc822" does
not receive its own specifier.

Using a less concise but more logical scheme, here is a complete list
of the entities (instances of BODY) that are present in the message:

        1               -          MULTIPART/MIXED
        1.1             1          TEXT/PLAIN
        1.2             2          APPLICATION/OCTET-STREAM
        1.3             3          MESSAGE/RFC822
        1.3.1           -          MULTIPART/???
        1.3.1.1         3.1        TEXT/PLAIN
        1.3.1.2         3.2        APPLICATION/OCTET-STREAM
        1.4             4          MULTIPART/MIXED
        1.4.1           4.1        IMAGE/GIF
        1.4.2           4.2        MESSAGE/RFC822
        1.4.2.1         -          MULTIPART/???
        1.4.2.1.1       4.2.1      TEXT/PLAIN
        1.4.2.1.2       4.2.2      MULTIPART/ALTERNATIVE
        1.4.2.1.2.1     4.2.2.1    TEXT/PLAIN
        1.4.2.1.2.2     4.2.2.2    TEXT/RICHTEXT

The entities that have no IMAP section specifiers are the multipart
bodies of the message/rfc822 entities. I've written MULTIPART/MIXED for
the first one but MULTIPART/??? for the other two because the complete
table in section 6.4.5 somewhat inconsistently contains also the
following lines:

                        TEXT       MULTIPART/MIXED
                        3.TEXT     ([RFC-822] text body of the message)
                        4.2.TEXT   ([RFC-822] text body of the message)

Are IMAP section specifiers an unfortunate mistake that we now have to
live with, or are they in some way defendable?

Note that the special case really is specific to multipart bodies of
message/rfc822 entities; a multipart part of a multipart entity and a
message/rfc822 whose body is a message/rfc822 are both treated as you
would expect. The bit of code in mtest.c that handles the special case
is this:

    if ((body->type == TYPEMESSAGE) && !strcmp (body->subtype,"RFC822") &&
	(body = body->nested.msg->body)) {
      if (body->type == TYPEMULTIPART) display_body (body,pfx,i-1);
      else {			/* build encapsulation prefix */
	sprintf (tmp,"%s%ld.",pfx,i);
	display_body (body,tmp,(long) 0);
      }

In line 3 of this excerpt the prefix pfx is not extended in the special
case of a TYPEMESSAGE whose body is TYPEMULTIPART; the other recursive
calls to display_body extend the prefix.

I noticed that Netscape's MUA uses a numbering scheme like the one I
used above rather than the IMAP one so I'm presumably not the first
person who thinks they could do better ...

The only reason I've noticed this, by the way, is because the c-client
API apparently forces me to generate IMAP section specifiers. Am I
right that there is no way of fetching a body other than by computing
an IMAP section specifier and using it as a character string argument
to mail_fetch_body? It certainly would be easier if I could just give
the pointer to the BODY and let c-client take care of the numbers ...

Edmund

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Jul 1999 10:02:02 -0700 (PDT)

Thank you very much for your complimentary remarks about how I designed IMAP
section specifiers.  It is always a great pleasure to deal with people who use
works such as "illogical", "inconsistant", and "unfortunate mistake" when they
really mean "I don't understand".

Your claim that "an entity (which corresponds to the data type "BODY" in
c-client) that is of type "multipart" and whose parent entity is of type
"message/rfc822" does not receive its own specifier" is false.  The clue is in
that text that you labelled as "inconsistant".

Since you found the table in RFC 2060, section 6.4.5, please take a look at
the previous page.  Read it carefully, particularly that last paragraph.  Is
"part specifier" just random text that the author haphazardly threw in, or
perhaps is it a term that is formally defined?  If something is a "part
specifier", what does that mean?  What is the proper interpretation of that
table entry that you called "inconsistant"?

Most people do not find it to be a particularly egregious burden to generate
IMAP section specifiers, especially after being shown the right way to do it
(e.g. from the mtest example).  Even if section specifiers were stored in body
structures for the convenience of lazy programmers, it wouldn't eliminate the
need to generate them because not all section specifiers relate to a body
structure.

PS: I seriously doubt that Netscape sticks in spurious "1." in front of
attachment numbers.

---

From: "Alex Shvedov" <[email-masked]>
Date: Wed, 21 Jul 1999 18:11:36 -0400

> Am I right that there is no way of fetching a body other than
by computing
> to mail_fetch_body?
In my opinion, you are.
At least, I found no other (simple) way as to port a parsing
subroutine from mtest.

The only thing that I didn't like in it: it doesn't provide
anything for a special MULTIPART/ALTERNATIVE case, so I must deal
with both variants of a part instead of making a choice.