Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major version changes (v3) #22

Open
12 of 24 tasks
Porges opened this issue Jun 29, 2017 · 4 comments
Open
12 of 24 tasks

Major version changes (v3) #22

Porges opened this issue Jun 29, 2017 · 4 comments
Milestone

Comments

@Porges
Copy link
Owner

Porges commented Jun 29, 2017

Ideas for v3:

  • Input type should be Text, not ByteString (see Use Text instead of ByteString, since emails can be unicode #9)
  • Test suite will be inherited from Dominic Sayer's isemail, and won't be inlined in the code.
  • The basic EmailAddress should not provide individual access to localPart/domainPart, but instead be a newtype around Text. This will facilitate loading/storing from unvalidated stores in a simpler fashion than is currently possible (e.g. at the moment you can use unsafeEmailAddress but it takes the two parts separately, not a single email address string).
  • Lift ParseOptions to type level, per this comment.
  • The default parsing mode will change to something saner that excludes "obsolete" syntaxes (these can be accessed using the "Detailed" module).
  • Support internationalized emails.
    • In local parts
      • Add tests for each bit (atext, ctext, etc – ignore dtext since we'll do proper handling)
    • In domains (this probably requires an IDNA2008 implementation)
  • For those who want full analysis, there will be a separate "Detailed" module which can break apart an email address. (Or, just provide functions to break down the EmailAddress type...)
  • Error messages should be improved, and this checked by tests.
  • Consider exposing an FFI interface for other languages to use.
  • Consider improved equality (see Use case-insensitive ByteString in EmailAddress #36)
    this should fall out of better domain parsing
  • Consider switching to Megaparsec, for better error messages?
  • Consider which instances to upstream from https://github.com/cdepillabout/emailaddress (as pointed out by @bitemyapp)
@Porges Porges added this to the v3.0 milestone Jun 29, 2017
@Porges
Copy link
Owner Author

Porges commented Jun 30, 2017

8c6e0c7 adds the isemail test-suite.

Another thing to think about: I should be testing the canonicalized versions of email addresses to ensure the normal form is as expected. (The isemail suite does not do this.)

@Porges Porges mentioned this issue Jun 30, 2017
Closed
@Porges
Copy link
Owner Author

Porges commented Jul 5, 2017

Idea: use DataKinds for the options type that controls what to allow in the email address.

This way we have type EmailAddress = EmailAddress' SaneParseOptions and you can't accidentally mix email addresses parsed with different levels of flexibility.

Also: add a RestrictedEmailAddress for "Emails as they supported by most major providers".

Edit: didn't use DataKinds because that forces it onto the consumer. Instead we have a typeclass ParseOptions which supplies the configuration. This provides the extra safety without any extra burden on consumers.

@MichelBoucey
Copy link

@Porges Don't you know my IPv6Addr package? It should give all you need about IPv6 addresses. If not, feel free to contact me.

@Porges
Copy link
Owner Author

Porges commented Jul 13, 2017

@MichelBoucey I didn't come across it when I was looking. It looks like it could be useful. I'll stick with ip for now until I get everything working and then have a better look.

One thing that might be required is: in order to pass the test-suite, in some situations I have to be able to parse IPv4-only addresses and not accept IPv6 ones. I'm not sure if this is possible with your current API (except if I parse and then check the result to see if it is IPv4-compatible).

@Porges Porges pinned this issue May 1, 2019
@Porges Porges unpinned this issue Jul 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants