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

Revert "An email is a string, not much else." #373

Merged
merged 1 commit into from
Mar 17, 2017

Conversation

erayd
Copy link
Contributor

@erayd erayd commented Mar 8, 2017

This reverts commit 73ef463.

'email' is only a valid type attribute in draft-03 (later versions of
the spec explicitly limit the value of type to the core primitive
types), and this code doesn't validate email addresses anyway. IMO we
should be validating it properly or not at all, and noting this went
away after draft-03 my opinion is on the not-at-all side of the fence.

Note that 'email' is never defined as a spec type, in any version -
it just slips in under the radar of the draft-03 language which allows
users to put arbitrary things in the type field.

This reverts commit 73ef463.

'email' is only a valid type attribute in draft-03 (later versions of
the spec explicitly limit the value of type to the core primitive
types), and this code doesn't validate email addresses anyway. IMO we
should be validating it properly or not at all, and noting this went
away after draft-03 my opinion is on the not-at-all side of the fence.

Note that 'email' is *never* defined as a spec type, in any version -
it just slips in under the radar of the draft-03 language which allows
users to put arbitrary things in the type field.
@erayd
Copy link
Contributor Author

erayd commented Mar 8, 2017

See #205 and #206 for background.

@erayd
Copy link
Contributor Author

erayd commented Mar 8, 2017

If we do want to validate email addresses, that should be done using the format attribute - this kind of thing is exactly what format is intended for. The spec does specify 'email' as a valid option for format, and says that if it is a string it should conform to RFC-5322.

Email validation of format per the above is already handled by FormatConstraint, but using the older RFC-822 standard.

@erayd erayd mentioned this pull request Mar 8, 2017
@bighappyface bighappyface merged commit 5de03d4 into jsonrainbow:6.0.0-dev Mar 17, 2017
erayd added a commit to erayd/json-schema that referenced this pull request Mar 17, 2017
This reverts commit 73ef463.

'email' is only a valid type attribute in draft-03 (later versions of
the spec explicitly limit the value of type to the core primitive
types), and this code doesn't validate email addresses anyway. IMO we
should be validating it properly or not at all, and noting this went
away after draft-03 my opinion is on the not-at-all side of the fence.

Note that 'email' is *never* defined as a spec type, in any version -
it just slips in under the radar of the draft-03 language which allows
users to put arbitrary things in the type field.
@erayd erayd mentioned this pull request Mar 17, 2017
@erayd erayd deleted the revert-invalid-type branch March 17, 2017 19:41
erayd added a commit to erayd/json-schema that referenced this pull request Mar 22, 2017
This reverts commit 73ef463.

'email' is only a valid type attribute in draft-03 (later versions of
the spec explicitly limit the value of type to the core primitive
types), and this code doesn't validate email addresses anyway. IMO we
should be validating it properly or not at all, and noting this went
away after draft-03 my opinion is on the not-at-all side of the fence.

Note that 'email' is *never* defined as a spec type, in any version -
it just slips in under the radar of the draft-03 language which allows
users to put arbitrary things in the type field.
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

Successfully merging this pull request may close these issues.

2 participants