On 8/4/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin (JIRA) ha scritto: > > [API Design] Reconsider MailAddress > > ----------------------------------- > > > > Key: MAILET-9 > > URL: https://issues.apache.org/jira/browse/MAILET-9 > > Project: Mailet API > > Issue Type: Task > > Reporter: Robert Burrell Donkin > > > > > > MailAddress represents an internet mail address. It is a concrete class > > including good, standards compliant code for parsing addresses. The > > strength of this design is that it enforces standards. This is also the > > weakness of the design. Occasionally, a looser algorithm capable of dealing > > with non-RFC822 mail would be preferable. > > > > Consider factoring as a logical interface (implemented as either an empty > > abstract class - my preference - or an Interface) capable of alternative > > implementations. The current class would become StandardMailAddress. > > Consider adding a marker flag for those addresses which are not RFC822 > > compliant. > > This is a delicate issue. I've not a clear opinion on the best approach. > > My doubt is: where are the lines delimiting the email address space in > the string space defined from "a random string" to a "fully valid rfc > email address"? > > Should these strings be representable by a MailAddress: > [EMAIL PROTECTED] > a > ! > a@ > @b > @@ > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > <empty string> > [EMAIL PROTECTED]
but this question is not about representation but parsing. MailAddress represents a user and host. provided that the information can be decoded then MailAddress should be able to represent them. ATM MailAddress performs parsing as well as representation. it represents a user and host but insists on parsing an input string which must be RFC822 compliant. a good example is the use of non-ASCII characters in address headers. this is not RFC822 compliant but could be reasonably parsed. - robet
