[
https://issues.apache.org/jira/browse/MIME4J-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563686#action_12563686
]
Robert Burrell Donkin commented on MIME4J-34:
---------------------------------------------
I wonder whether this might have some wrinkles
There's RFC822 to consider (as well as 2045)
The header name MUST be US-ASCII. The field body may be composed of US-ASCII
characters barring CR and LF.
IIRC practically, an email client is at liberty to interpret these characters
as they please. Many choose to interpret them according to the encoding.
AIUI when the field body content contains non-US-ASCII characters, if US-ASCII
is forced then they will written out in a way that's unintelligable for any
client. If content charset is used, then some email clients may be able to
interpret them correctly. However, the body will need to be checked for bitwise
line breaks. (The output method uses a string which is inefficient.)
But I'm not an expert - hopefully someone who is will jump in...
At the least, it seems unreasonable not to give the user the option to use
US-ASCII or content-type encoding
If you have a particular example in mind where content-encoding produces a bad
result, it would be useful if you could explain it.
> o.a.j.m.message.Header#writeTo violates RFC 822
> -----------------------------------------------
>
> Key: MIME4J-34
> URL: https://issues.apache.org/jira/browse/MIME4J-34
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Oleg Kalnichevski
> Attachments: mimeheader.patch
>
>
> The Header#writeTo method uses the content charset instead of US-ASCII
> required by the RFC 822. Same problem exists in the Multipart#writeTo.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
