EmailFormatSpecifier not validating in 0.5.0beta4 about json-schema-validator

[fge]

Good catch!

Just to be sure, can you give an example of a mail address which passes validation and should not pass it? Just for tests, and adding an appropriate comment in the code? I'd appreciate a lot!

[dsjellz]

Sure. while using 'new InternetAddress(instance.textValue())' the address 'testaddress123' passes as a valid address.
However, if we change this to 'new InternetAddress(instance.textValue(), true)', validation will fail as expected.

[fge]

Hmmwait, RFC 822 does not specify anywhere that an email should have a domain part! As such, this "true" parameter does not really enforce RFC 822, just a "canonical" form for an email address.

As such, I do not see it as a bug. I know that 90+% people now think that "testaddress123" is not a valid email address -- in which they are mistaken.

The "workaround" is to:

{
    "format": "email",
    "pattern": "@"
}

since @ is not a valid character in a username part.

That is how I read the RFC. If an authoritative source on that tells otherwise, I'd like a link to it.

[fge]

OK, since then I have reconsidered the matter at hand.

The problem you raise not only applies to the "email" format specifier, but also the "hostname" format specifier. In a similar vein, strictly speaking, "foo" is a valid hostname -- and email address.

However, I can only admit that most, if not all, use cases of JSON Schema will instinctively expect fully qualified hostnames and/or email addresses. I will therefore switch the default behaviour accordingly.

Expect a commit soon. And sorry for my bluntness ;)

[fge]

Could you review the aforementioned commit? Tests have been adapted accordingly.

While this makes me uneasy wrt strict RFC conformance, you have me convinced that this will turn out to be the better choice.

[fge]

Done.