nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] Syntax for choosing content transfer encoding


From: Ken Hornstein
Subject: [Nmh-workers] Syntax for choosing content transfer encoding
Date: Tue, 26 Feb 2013 11:22:23 -0500

Greetings all,

I believe that we've had general agreement in the past to move to a default
Content-Transfer-Encoding of 8bit, at least for text parts.  To that end,
I've been thinking about a minor but important problem: exactly what
should the syntax be for specifying a Content-Transfer-Encoding?

I ask because while not everyone uses mhbuild rules directly, a lot of
the backend tools generate mhbuild rules in the draft.  Also, it's always
bugged me that you can't specify a CTE directly; nmh is actually nice that
if you want exact control over your MIME content you can do it, but
the CTE is the one thing you can't specify.

So the mhbuild syntax is a bit weird.  The way it looks like now is:

#type/subtype \
        ;mime-attribute1=foo;mime-attribute2=bar \
        (Comment which is essentially ignored) \
        <Content-ID header> \
        [Content-Description header] \
        {Content-Disposition header} \
        filename

There are a few other variations, but that's the basics.

So the one thing that leaps right out at me is that the normal ASCII set
of matching left-right punctuation characters are already in use.  And
the MIME attributes are actually copied directly into the MIME attributes
when the final message is constructed, so overloading a MIME parameter
with an encoding would make the parser more complicated (it's the same
parser which parses mhbuild directives and MIME messages).  Also, it seems
to break the mold because every other instance of something that goes
into it's own header has special syntax to designate it.

But it occurs to me that those other headers are (for the most part)
free-form and don't have an easy way to indicate the end, so they need
closing punctuation.  Since the C-T-E has only one token, we could get away
with something simpler.  Like a "*" preceeding the C-T-E, like "*8bit",
or "*q-p".  Or maybe a "^".  Or something else entirely.  I'd like avoid
"#" since it indicates the start of a mhbuild directive, and "|" as it
indicates the start of a command to read MIME content from.  Also anything
that looks like MIME parameters, since they come before the other
header content in the mhbuild directive.

So I am totally open to ideas here; my suggestion is just my first thoughts
on the subject.  What do others think?

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]