james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [mailet-api][proposal] MailAddress
Date Thu, 16 Aug 2007 21:30:56 GMT
On 8/16/07, Danny Angus <danny@apache.org> wrote:
> On 8/16/07, Norman Maurer <norman@apache.org> wrote:
> > Stefano Bagnara schrieb:
>
> > I fully agree with Stefano,
>
> !!
>
> What is your point? That the API should enforce RFC compliance and not
> the server?
> Why? The servlet API doesn't enforce compliance with http or html
> standards, the application server implementation might though.

there are good why it's rare for an API to actully insist on a
particular parser implementation warts and all. including the parsing
code in the API means that any fix will require a complete new version
of the API to be issued.

if it's important that the address is RFC compliant then this can and
should be stated clearly in the API. the parsing should be left to the
implementor.

> If we leave this up to implementors then it is up to users to choose
> ones which comply with appropriate standards. I don't think it is the
> job of the mailet api to constrain things beyond what is necessary to
> ensure that mailets work and are portable.
>
> James, or buni, or mailcatcher should validate addresses for compliance.

i'm not sure that it's the validation as much as the parsing that is
important. there are ways that an address header could fail to be
RFC822 compliant but still contain a parsable local part and domain.
i'd be happy to insist that the data exposed by the implementation is
valid RFC822 but feel it's important that there is implementation
freedom for the parsing phase.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message