Please feel free to make whatever reports or references to the PHP
developers that you like. I'll be happy to assist with whatever
information is needed.
I certainly understand the frustrations that end users experience with
apparent mutual finger-pointing. The way to solve it is through
communication.
For what it's worth, here are the current semantics of type codes:
0 TEXT
1 MULTIPART
2 MESSAGE
3 APPLICATION
4 AUDIO
5 IMAGE
6 VIDEO
7 MODEL
8 X-UNKNOWN (or expansion types filed up)
9 first expansion type
...
TYPEMAX last expansion type (currently 15)
On Wed, 17 Oct 2007, Cynergi wrote:
Hi.
Thank you for your detailed reply!
That makes sense. And yes, PHP assumed too much. But it would now break much
PHP code out there to make use of body_types[], but that could be added.
Could I make a PHP bug report / feature request quoting this message from
you? Do you want me to delete you e-mail address (as these things are
publicly available) from the quoted text? Do you prefer to try and make the
PHP bug report yourself, again?
Thank you!
Pedro Freire
Cynergi
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Crispin
Sent: terça-feira, 16 de Outubro de 2007 17:35
To: Cynergi
Cc: [email protected]
Subject: Re: [Imap-uw] Apparent bug in imap-2006k.DEV.SNAP-0710121414 (and
older?)
Thank you for your report.
This is not a bug. The c-client library is designed to behave this way.
MIME types and encodings are, by definition in MIME, open-ended. From time
to time, the IETF defines new MIME types. It is desirable that c-client be
able to handle these without having to make a source code modification to
c-client.
To allow applications to support types and encodings that are unknown to
c-client, c-client will automatically add a (limited) number of unknown
types and encodings to its tables before resorting to TYPEOTHER and
ENCOTHER. The names of these added types and encodings are available in the
body_types[] and body_encodings[] arrays.
Put another way, TYPEOTHER and ENCOTHER are only used if c-client is
overflowed with unknown types and/or encodings.
If the PHP developers had asked me about this, I would have explained this
to them. Unfortunately, they have a habit of labelling unexpected behaviors
as "bugs" rather than seeking answers. I have tried to post amended
information on the PHP bugzilla in the past, but was rewarded with a "you
are not authorized to do so" so I've given up.
Hence, a more correct behavior for PHP is not to use type code values, but
instead to use the body_types[type_code] string.
I hope that this information is helpful.
On Mon, 15 Oct 2007, Cynergi wrote:
Dear Sirs,
I only want to make a bug report. I use PHP for development so I
really won't be able to keep up with messages from this list. Please
don't take offense if I unsubscribe in a few days after sending this
message.
While developing a Webmail for www.cynergi.com, we started coming upon
some
(spam) messages with bad MIME types. However PHP (via your c-client
library) reported a MIME type code of 9 instead of TYPEOTHER (8).
Looking at your library I seem to have found the bug. From a comment
in our source code:
Unknown MIME-types (such as "25-bit") are returned as int(9) due to
a
bug in c-client's rfc822.c "body_types" array that defines TYPEOTHER
as "X-UNKNOWN"; then when imap4r1.c goes to match a MIME-type and
can't match any of body_types' strings (including TYPEOTHER's), it
returns the next available integer (9).
This same bug also seems to apply to ENCOTHER.
I am unaware if the body_types array is also used to CREATE
MIME-types. If so, deleting "X-UNKNOWN" from there won't be the
solution (the solution will then have to be fixing imap4r1.c's code).
Thank you for your time, and for such a great open-source library!!
:-)
Pedro Freire
Cynergi
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
