On 8/15/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Why do you bounce back to server-dev? Isn't this a mailet api issue, > first?
Thinking about it I believe not, heres why, the Mailet API tells you how to process mail which conforms to the interoperability specs (RFC's), not how mail should be constructed to comply with those RFC's. It is the responsibility of anyone who implements the api to ensure that they comply with the RFC's as much or as little as they choose to. James implements the API therefore James should be responsible for complying with the RFC's. Be that by wrapping InternetAddress or by creating stricter validation. QED. >IMHO similar issues should be discussed also with other > implementors (e.g: MailCatcher author) and other interested parties (A. > Oliver @ Buni). I thought we created a mailet api project mainly to > separate this decisions from Apache specific implementation. Agreed, but in this case I think that MailAddress is an apache specific implementation of a class that should be an interface. > I would like to know exactly what kind of invalid email address we think > should be represented and what scenario does this cover. Thats an issue for James, which needs to interoperate with other mail agents, not for the API which does not. > In the mean time, generally speaking, I don't think this is a good idea. > We produce an API based on a given specification, IMHO we should follow > that specification and make very clear when we give tools to break the > specification. The API can require implementors to comply with RFC281 or 2821 without needing to supply a load of compliant implementations. Of course we could choose to supply a reference implementation which would contain a compliant implementation. > To mailet users this would be a major changes: previously any time I > reveived a MailAddress in a method I knew it was a syntatically valid > address. With the proposed change I won't know this anymore. But compliant with what, if james chose to comply with 2821 and mailet only complied with 281 James' felxibility is constrained by the API, and the API doesn;t *need* to constrain it. I can see your point though! d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
