You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be appropriate to use the case-insensitive package to represent the internal ByteStrings domain in EmailAddress. This would also seem to "fix" the Eq instance.
Has this been considered before? I've generally implemented the entire email address in a web app as newtype Email = Email CaseInsensitive.ByteString but after a little research, it appears the part before the @ can technically be interpreted as case-sensitive.
The text was updated successfully, but these errors were encountered:
Yes, at the moment there's no normalization performed except for stripping non-significant whitespace and comments. Really the domain part should be handled by a package specifically for handling domains, we could also argue that punycode/Unicode encodings of the same name should be equivalent and that an IPv4-in-IPv6 address should be considered the same as the equivalent address in IPv4. I've started handling the domains more correctly in the work for v3, I'll add this as something to ensure for that work.
You're correct that for the local-part we can't really do anything because the meaning is entirely up to the receiving system.
I think it would be appropriate to use the
case-insensitive
package to represent the internalByteString
s domain inEmailAddress
. This would also seem to "fix" theEq
instance.Has this been considered before? I've generally implemented the entire email address in a web app as
newtype Email = Email CaseInsensitive.ByteString
but after a little research, it appears the part before the@
can technically be interpreted as case-sensitive.The text was updated successfully, but these errors were encountered: