If you don't know whether it is structured or unstructured then you are,
officially, stuck.
but it only matters for the purpose of display. if you're using an
encoded-word
for anything other than purely human-readable text, you're not using them
properly.
Actually, it does matter for purposes other than display, because people
want to construct whitelists, blacklists, killfiles, etc so as to filter
or compartmentalise their mail and news, and they are certainly not going
to construct those lists using raw encoded-words.
correct. nor would it work if they did.
so if an implementation doesn't recognize a field and treats it as
unstructured,
the worst that will happen is that it won't decode some encoded words before
display (because it won't recognize them next to some 'special' characters,
or it won't recognize that parentheses are comment delimeters).
Yes, but that is going beyond a strict reading of RFC 2047.
funny, that's what I got from a strict reading of RFC 2047.
And some
implementations may treat them as structured by default, or use other
heuristics.
perhaps, but it's pretty useless to assume that a field is structured
if you don't know the syntax. even then, the effect is only that you
will treat some encoded-words as literals rather than as human-readable
text to be decoded.
As I have said, the real problems are in generating RFC 2047.
You have to second guess what a plausible encoding of some unknown header
might be, and then you have to second guess what receiving agents might do
if you guessed wrongly.
I'm very much opposed to having intermediaries trying to guess what
encoding was used at the source. Tag it as "unknown", encode it,
and move on.
Keith