Nathaniel -
I don't know whether your software generated the header
I showed, but MetaMail has been implicated in other cases of
non-quoted dots.
Although (obviously) my vote is to remove dot from
tspecials, the first thing we need to do is agree that the
specification is broken. That is, I claim that including
dots in tspecials while having examples which show unquoted
parameter values which contain dots is a syntax violation.
Hopefully we all agree on this. Do we?
If we agree on that, we then need to decide what to do.
I strictly implement the BNF. I quote any parameter values
which contain a tspecial. I break a token parse at any
tspecial, and end up rejecting the rest of the line as a
syntax error. So, something like:
Content-Type: MULTIPART/MIXED;boundary=foo.bar
leaves me to search for a boundary named `foo' (which I will
never find) along with reporting a syntax error of a funny
`.bar'. This has caused me interoperability problems, and
my users are not sympathetic to my claims of compliance.
I suspect that I'll end up having to have two types of
tspecials, one for what I generate and one for what I parse;
the latter distinguished by the absence of dot from the
list. Even if the spec gets fixed, I may end up having to
do this to ensure interoperability with old software that
strictly follows the current spec.
Sheesh. Will we have to do this as the fix to the spec
too? 1/2 ;-)
-- Mark --