Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (athena.apache.org: domain of markus.wiederkehr@gmail.com
 designates 209.85.217.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Tqtt2C0JTFDgGeaDU06kUr0pUq2VPczCHcDHepMfsgi3KkJNqN6BJGI4e9MXPnD3us
         4n+q+044sfL9yKAj15Mrfd+P0VaKj2/qMEmsUzWqMqNjZg5Asv/i+eu4FL/oARWKp1J8
         HFOWYEIuV36Qg/lilk3QjlxYIFav8uyeFDLfY=
MIME-Version: 1.0
In-Reply-To: <1622001685.1234787220159.JavaMail.jira@brutus>
References: <794310291.1234787219951.JavaMail.jira@brutus>
	 <1622001685.1234787220159.JavaMail.jira@brutus>
Date: Mon, 16 Feb 2009 14:42:29 +0100
Message-ID: <a92573960902160542k641860d8t1836f69f4f548074@mail.gmail.com>
Subject: Re: [jira] Assigned: (MIME4J-118) MIME stream parser handles
	non-ASCII fields incorrectly
From: Markus Wiederkehr <markus.wiederkehr@gmail.com>
To: mime4j-dev@james.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In my opinion this issue is closely related to MIME4J-112 and MIME4J-116.

I think that in the course of MIME4J-116 we should (maybe) create
Field instances in AbstractEntity instead of later on in
MessageBuilder. A Field object could store the raw data in a byte[]
instead of a String which would greatly help with MIME4J-112.

The only problem is that the charset for a lenient parsing mode is not
known at this early point. But considering your clarification about
the lenient writing mode I wonder if anybody really needs a lenient
parsing mode. (I wonder if anyone really needs a lenient writing mode
for that matter.)

So maybe AbstractEntity should simply use US-ASCII to decode the
header fields without direct support for a lenient parsing mode that
nobody needs. Then AbstractEntity can build Field instances and a
ContentHandler receives those Field instances without having to parse
them again.

All in all I'm not sure if #118 should be addressed independently of
112 and 116 and whether 118 should be targeted for 0.6..

But those are just my 2 cents,

Markus


On Mon, Feb 16, 2009 at 1:27 PM, Oleg Kalnichevski (JIRA)
<mime4j-dev@james.apache.org> wrote:
>
>     [ https://issues.apache.org/jira/browse/MIME4J-118?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Oleg Kalnichevski reassigned MIME4J-118:
> ----------------------------------------
>
>    Assignee: oleg.kalnichevski
>
> Working on a patch
>
> Oleg
>
>> MIME stream parser handles non-ASCII fields incorrectly
>> -------------------------------------------------------
>>
>>                 Key: MIME4J-118
>>                 URL: https://issues.apache.org/jira/browse/MIME4J-118
>>             Project: JAMES Mime4j
>>          Issue Type: Bug
>>            Reporter: Oleg Kalnichevski
>>            Assignee: oleg.kalnichevski
>>             Fix For: 0.6
>>
>>
>> Presently MIME stream parser handles non-ASCII fields incorrectly. Binar=
y field content gets converted to its textual representation too early in t=
he parsing process using simple byte to char cast. The decision about appro=
priate char encoding should be left up to individual ContentHandler impleme=
ntations.
>> Oleg
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>