Danny Angus ha scritto: > On 8/16/07, Norman Maurer <[EMAIL PROTECTED]> 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. > > 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. > > d.
My point is the question I made to Robert: what is a Mail Address? Is every string in the world a mail address? Or just a subset of strings? IMHO the RFC tell us what is a mail address, anything more relaxed is probably only a string and may have no sense to some server out there. I don't understand why the API should tell us that a MailAddress is a strings tuple and nothing more. Why don't we say that a MailAddress is simply a *single* string? I don't get the choice behind this step. Why don't we use a byte array then (like Robert said few weeks ago this is what we receive on the wire, a bytearray ensure that we can represent what we received)? I understand the need of flexibility in the API, but I'm not convinced that we should relax *that* way. 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 or depend on some specific container (using the container implementaion) ? Btw I've not strong positions on this, this is just my idea: I won't veto a similar change. 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. 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. 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. 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? Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
