Dain Sundstrom wrote:
On Jan 12, 2006, at 3:24 PM, Rick McGuire wrote:
Dain Sundstrom wrote:
On Jan 11, 2006, at 1:17 PM, Bruce Snyder wrote:
Is it possible to look at the Sun implementation's source code to
distinguish enforced vs. ignored rules?
That would make the code not clean room.
I propose we ask Sun for a formal definition of the parser for this
class, and in a parallel track make an effort to try to match their
bugs. The code from the second track doesn't have to be perfect,
but just good enough. We simply let our users know that our goal
with the "implement.sun.javamail.bugs=true" code is to emulate the
sun bugs, and if they find something that produces different results
for the same text, we consider it a bug.
I'm becoming less and less convinced this is a good idea. So far,
I've found many, many sun bugs in this code where they produce
results that are in conflict with with RFC822. The API documentation
refers relaxed parsing rules, which says to me there are addresses
that would not be valid under RFC822, but javamail will accept them
based on the type of parsing requested. I can accept that.
However, the great majority of the problems I've found have been
involved with internet addresses that RFC822 says ARE valid, but the
javamail code does not handle them properly. And there are a few
situations where it appears the authors just chose to punt and say
"yeah, whatever".
It appears that the solution is to write hacked code that mostly,
sorta, kinda does what it claims to do, or write a good parser, then
triple the size of the code trying to get all of the Sun bugs to work
properly.
Working strictly from the RFC822 spec, I had a fairly nice parser
written that gave very good RFC822 compliance, but things turned
nightmarish when I discovered the sorts of Sun behaviors I had to
insert back in. I think I've completely rewritten this code about 5
times now, and am getting pretty close to the Sun "relaxed rules".
Inserting some of the real bugs back in to the parsing might pose
similar problems.
It really appears that this code somewhat "lost it's way somewhere".
It's serving two purposes that are really at odds with each other.
The first purpose, is to parse any internet address that might appear
in a received message. For that purpose, the code needs to accept
any valid internet address as defined by RFC822. The Sun code does
not currently do that, and making the new version "bug compatible"
would also not achieve that.
The other purpose of the InternetAddress parser is to process email
addresses entered into applications and perform some validation on
the addresses. This is where the "relaxed rules" come in to play,
and basically allows internet addresses that are not strictly RFC822
compatible to pass. Now for those, I'm relatively comfortable that
this can be made compatible. It is very difficult though, when the
requirement becomes one of being both more and less restrictive at
the same time, with no good definition of the what rules are being used.
Ok, how about we say, in "sun bug mode" we will parse all addresses
that are valid RFC822 address or are sucessfull parsed by sun's
javamail implementation? This means that valid RFC822 addresses that
sun's implementation rejects will be accepted by ours. We would
further would consider it a bug to reject addresses accepted by sun's
implementation when in "sun bug mode".
That sounds like a more reasonable goal.
-dain
