On February 6, 2002 at 23:18, Mike Acar wrote:
> > > Is there a way to get MHonArc to prefer text/plain versions of messages
> > > over text/html in multipart/alternative?
> >
> > Not without code changes.
> >
> > Currently, if you specify that text/html should be excluded, then the
> > text/plain will be used, but the exclusion applies to all text/html
> > data, even for non-multipart/alternative messages.
>
> Which would be ok with me; I can't really see that there's any reason to
> send HTML to this list.
Then you can use the MIMEEXCS resource.
> > Some thought needs to be applied on what would be the best way to
> > support such a feature. One part is that actual implementation, the
> > other is how the user would tell MHonArc about multipart/alternative
> > preference ordering.
>
> Well, by far the most common is text/plain and text/html sent by such
> clients as Outhouse (which you love so well ;), so the obvious thing
> would be simply adding a prefer-multipart-plain-over-html config option.
This is too specific. There can be other cases where you may
want to set a preference list of types for multipart/alternative
data.
> More generally I guess you could have a config section that specified
> a a multipart type and a list of MIME types in order of preference... A
> truly generic solution might be difficult to describe elegantly in a
> config file.
Exactly. Maybe something like:
<MIMEAlternativePrefs>
text/enriched
text/plain
application/pdf
text/html
</MIMEAlternativePrefs>
The list goes from most prefered to least prefered.
A problem is how mhonarc should order things for a multipart/alternative
message that includes some parts that are in the list and some that
are not. What to do about the ones not in the list.
An alternative approach is to specify paired preferences settings.
For example:
<MIMEAlternativePrefs>
text/enriched; text/plain
text/plain; text/html
</MIMEAlternativePrefs>
This states that text/enriched is prefered over text/plain and
text/plain is prefered over text/html. I.e. If a message
contained a text/plain part and a text/html part, the text/html
part will automatically be discarded since the prefered text/plain
part exists.
Of course, mhonarc should be smart enough to resolve the case
where a message contained a text/plain, a text/enriched, and a
text/html part: text/enriched should be the winner. You also
have other types of complexities:
<MIMEAlternativePrefs>
text/plain; text/html
text/enriched; text/html
</MIMEAlternativePrefs>
The winner would then be determined by the part ordering in the
message. If text/enriched occur later than text/plain, text/enriched
wins. Otherwise, text/plain wins.
Now, the issue with unspecified types is handled pretty easily (and
come to thing about it, the approach I am going to mention could apply
to the first usage of MIMEAlternativePrefs). MIMEAlternativePrefs
basically defines a exclusion list that only applies with
mulitpart/alternative data. For example, a text/html part is
automatically excluded if a text/plain part exists. Once all parts are
excluded, the part ordering sematics of mulitpart/alternative come in
to determine which part wins out.
With this model, the first MIMEAlternativePrefs usage (specifying
a preferences list) can be used and should be less confusing than the
second usage.
A subtle problem that could show up is the case of nested
multipart/alternatives. For example:
--XXX
Content-Type: text/plain
asdfasd
--XXX
Content-Type: multipart/alternative; boundary="YYY"
--YYY
Content-Type: text/html
<html>...</html>
--YYY--
--XXX--
In this case, the text/html would sneak through. Now, if the
MIMEAlternativePrefs is implemented a certain way, the above
could be addressed with the following setting:
<MIMEAlternativePrefs>
text/plain
text/html
multipart/alternative
</MIMEAlternativePrefs>
This states that a text/plain or a text/html has precedence
over a nested multipart/alternative part.
It would be cool if multipart/alternative nesting was "flattened" out,
but I think this would take too much work, and since it is probably
extremely rare to have multipart/alternative parts within
multipart/alternative parts, why bother.
The final thing to deterime if base types should be supported.
Example:
<MIMEAlternativePrefs>
text/*
image/*
</MIMEAlternativePrefs>
--ewh
