Re: Email type

For reference, I just found:

    http://isemail.info/

The "About" page is worth reading:

    http://isemail.info/about

The implementation is in PHP:

    https://github.com/dominicsayers/isemail

Somebody created a JavaScript version of this:

    https://github.com/hapijs/isemail

It seems like this uses its own parser rather than a regexp:

    https://github.com/hapijs/isemail/blob/master/lib/index.js

In any case, it seems like serious work, but I don't know how that compares
with the simpler validator from Apache Commons.

-Erik


On Sun, Jun 25, 2017 at 3:08 AM, Alain Couthures <
alain.couthures@agencexml.com> wrote:

> For RFCs support, there might be a dedicated namespace for corresponding
> types. That is what I have recently implemented in my own XQuery engine for
> types such as "ietf:email", "ietf:ipv4", "ietf:mac", "ietf:port",...
>
> Specifically for email addresses, it is, at least, programmatically
> possible to check if the domain part is an effective mail server (a DNS
> request for an MX record). More likely, we want an existing email address
> than a one to be created for a domain to be created too!
>
> It is, of course, a good idea to define our own "xf:email" type for a more
> commonly-used regular expression.
>
> --Alain
>
>
>
> Le 24/06/2017 à 00:57, Erik Bruchez a écrit :
>
> Validation schemes coming from specifications such as RFCs might be
> correct, but they are not very useful to end users.
>
> It is true that some web sites/web apps reject email address which are
> definitely valid in practice (I remember the rejection of the "+" character
> in emails such as `erik+test@example.org` by some sites).
>
> But, witness Steven's example: it is technically true that `steven@cwi`
> is correct, yet there are virtually zero users in practice for whom that
> kind of email address will not be an actual error.
>
> So there is some tension here which is hard to solve: you don't want to
> block users, but you also want validation to catch likely errors.
>
> A possible way around this could be to have two kinds of email validations:
>
> 1. per RFC, which would catch a wide net and accept `steven@cwi` and
> other rare-in-practice addresses
> 2. practical, which would reject `steven@cwi` and other funny cases
>
> This would work better if XForms had a concept of "warning" validation
> (which our implementation supports): you could have a hard validation
> catching certainly incorrect addresses and soft/warning validation for the
> narrower validation. This would allow a determined user to enter a likely
> incorrect email address if she is sure that it is correct, after accepting
> the warning. A form author could choose how to deal with the various
> options of email validation.
>
> -Erik
>
> On Fri, Jun 23, 2017 at 12:51 PM, Liam R. E. Quin <liam@w3.org> wrote:
>
>> On Fri, 2017-06-23 at 13:28 +0200, Steven Pemberton wrote:
>> > Our definition of email accepts the following as a valid email
>> > address:
>> >
>> >       steven@cwi
>> >
>> > Are we OK with that? I'd expect at least one "." after the @.
>>
>> https://tools.ietf.org/html/rfc5321#section-2.3.11
>> has:
>> [[
>> A domain name (or often just a "domain") consists of one or more
>>    components, separated by dots if more than one appears.
>> ]]
>>
>> so steven@cwi should be allowed.
>>
>> Liam
>>
>>
>> --
>> Liam R. E. Quin <liam@w3.org>
>> The World Wide Web Consortium (W3C)
>>
>> Web slave for www.fromoldbooks.org
>>
>>
>
>