On 8/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > IMHO it is not true that we can leave the checks to the container: > sometimes Mailets do write new addresses. In this case we would have > mailet author to write their own implementation
No. > or depend on some > specific container (using the container implementaion) ? Yes, that. Because it is the container which will ultimately need to use the address for transport. and James would use this exact same class, it won't go away, it will just become James specific. > Btw I've not strong positions on this, this is just my idea: I won't > veto a similar change. Good, but I'd still like us to agree if possible. > I still anyway think that the basic discussion belongs to mailet-api > list: at least the change to introduce an interface instead of a class > should be discussed/decided in the mailet-api list. I've posted on that subject this morning. I'm asking server-dev if we want MailAddress in James. the API list can decide if we want it in the API, if it isn;t in the API and server-dev don;t want it it could still go into a RI. > Why using > MailAddress instead of InternetAddress, then? Is this a move to remove > javamail dependencies? Also this topic belongs first to the mailet api > list, IMHO. That topic certainly does. > Conclusion: if you think that the API should only publish an interface > then I would like to know what you propose as javadocs for that > interface. The current MailAddress methods. > Javadocs will be the only place where we can "suggest" > contracts to the implementors. E.g: should an implementation be allowed > to create MailAddresses returning NULLs in one or both of the string > properties? Thats for the api list to determine. In my opinion implementations should comply with one of the address spec standards, but I don't think there is any need for the api to say *which* one. If that standard permits local-part with no domain as a valid address then domain returning null is valid. If it forbids domain without local-part then local-part should be not-null for that implementation. If this causes problems for addresses which comply with a different specification then the server authors can choose whether to change their implementation to validate against more/other specifications or to remain strictly compliant with the original specification. RFC compliance is a topic I've talked about often on this list and elsewhere, I cannot understate the importance of strict compliance if we want the standards to retain their value. The difference in this case is that I have come to the conclusion that there is no need for the mailet api to police this compliance in order for the api to achieve its objectives. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
