[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Syntax for choosing content transfer encoding
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] Syntax for choosing content transfer encoding |
Date: |
Thu, 07 Mar 2013 15:02:33 -0500 |
>> > `*8bit' wouldn't look to the future. How about `field:value' as I
>> > don't think it can be mistaken for any of the existing syntax? It
>> > could also occur more than once if future needs arise. `cte:8bit'.
>>
>> I'm not sure I follow that it wouldn't look to the future. I was
>> really thinking of "*" as being the start character to indicate the
>> CTE. So you could have *8bit, *q-p, *base64, whatever. I don't see
>> many (any) new CTE's being defined, but note that it's not a case of
>> just copying it into the MIME draft, like every other header; it needs
>> to be interpreted by mhbuild to perform the necessary encoding.
>
>I was thinking of the next time we want to tweak the syntax having
>already used () {} <> [] and now *. We could even add fields for
>existing ones, e.g. disposition, rather than have to remember it's {}
>versus [] for description.
Well, I'm sympathetic to that view. The problem is, again, one of parsing.
Specifically, let's look at what we have now:
() An RFC-822 style comment. Ignored by everything.
<> A Content-ID header (basically, a message-id token)
[] A Content-Description header. Basically free-form text
{} A Content-Disposition header. One token, followed by
additional MIME-parameters.
The problem here is that with the exception of Content-ID, it's hard to tell
when any of those end; that's why they have closing punctuation. So we can't
really do something like *dispo:attachment because there's no way of adding
the additional MIME parameters you might want to put in there.
Depending on what a future MIME header looks like, perhaps we _could_
extend it with *foo:whatever. I'm willing to punt on that for now.
>> - We'd switch to a default of 8bit for text/* parts.
>
>Presumably 8bit isn't suitable, e.g. for a long line, whereas
>quoted-printable is. That's what I mean by having nmh pick what's best;
>it uses the first that can legally cover the content.
I follow you. I was thinking that if the "default" of 8bit isn't suitable,
then mhbuild would fall back to q-p, which should always work (for text,
at least). But if you explicitly specify an encoding in a mhbuild directive
that isn't suitable, that should fail.
--Ken