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

List:       majordomo-workers
Subject:    Re: MIME-munging (was Re: Current 2.0 TASKS list)
From:       Bill Houle <Bill.Houle () SanDiegoCA ! NCR ! COM>
Date:       1997-07-10 2:49:31
[Download RAW message or body]

At 10:06 PM 7/9/97 -0400, "Merrill Cook" <mcook@pcusa01.ecunet.org> wrote:
>I'll send this just to you.  Pass it along if it's not been
>covered already.

Responses to me have been negligible. I recommend everyone post to the list
to get some dialogue going out there from other than just myself. These are
good ideas...

>Your option for multipart/mixed appeared to be "bounce". Would
>there be an option for multipart/mixed to pass along any parts
>that are in a "text" format, and leave the rest for the GET
>command?

[Remember: the "bounce" action was just an example. How each type was acted
upon would ultimately be up to each list admin.]

I think Jason or someone more versed in the MIME:: Perl module could answer
this one, but I can take a stab. If the MIME module splits out multipart
messages into their included types, then yes, you could just use the
attachment_rules to specify what you wanted to do with the parts. However,
there would be no way to say "do this if application/msword, but do this if
application/msword is an included part within a multipart message" -- the
MIME type is the MIME type.

However, if the MIME module does not split the multipart but instead treats
it as a single entity, then no, because there would be no way to parse out
the individual parts to act upon them.


>That is, if a
>message comes in encoded to "quoted-printable", run a routine to
>turn it back to text/plain, wrap it to 75 columns per line, and
>send it on its way -- or, I suppose, the opposite, take text/plain
>and reformat it to quoted-printable.

That's basically what the "pass=8bit" and "pass=qp" is supposed to do.

>It might be that some folks
>would benefit from being able to turn on a function to "wrap"
>lines that exceed, say, 80 columns.

That gets a little more tricky. Now you are talking about something like
"pass=8bit,wrap". Certainly possible, but a little more work would have to
go into the parser. Plus you'd have to be able to catch non-sensical things
like "pass=8bit,qp".

Bottom line: if we can come up with a good framework for the syntax that is
easily extensible, then we can add these features as we think them up. I'm
less concerned with "how are we going to code this up" than I am with "how
can we develop a flexible syntax that can evolve". The code can fall into
place over time as long as we have a spec to work against.


--bill

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