Support for format 'email'

[laurentkvb]

Will there be support for email being supported for the format field?

Like described here it is an open value: https://swagger.io/docs/specification/data-models/data-types/

Or is there a way to include custom types as a valid format values?

[jorge-ibm]

@mkistler - any thoughts on this issue? We currently throw an error if a user specified email as the format. Here's the official text from oas3 regarding using email:

However, format is an open value, so you can use any formats, even not those defined by the OpenAPI Specification, such as:
email

[mkistler]

There is a registry of "formats" to extend the OpenAPI spec here:

http://spec.openapis.org/registry/format/

But I don't see email in this list.

The intent of this warning in the validator is to flag any formats that are not "well-defined". Is there some special behavior you are expecting from format: email? If so, where is this defined? If not, then is there any value in specifying this format?

[mvasin]

Not sure what's the ultimate source of truth for the OpenAPI spec, but google takes me here: https://swagger.io/specification/#data-types

There's a table that lists the types, and that list doesn't mention email, but there's also the phrase

Formats such as "email", "uuid", and so on, MAY be used even though undefined by this specification.

[laurentkvb]

@mkistler

The intent of this warning in the validator is to flag any formats that are not "well-defined". Is there some special behavior you are expecting from format: email? If so, where is this defined? If not, then is there any value in specifying this format?

From https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md &
https://swagger.io/specification/#data-types:

However, to support documentation needs, the format property is an open string-valued property, and can have any value. Formats such as "email", "uuid", and so on, MAY be used even though undefined by this specification

Would it be possible to have open values that can be accepted in some way (via a rule or as custom value that you can add to the list)? Because in the documentation it also suggest the following: Formats such as "email", "uuid", and so on, **MAY be used even though undefined by this specification**. So it seems to suggest that this format field may include formats that are not included in the OAS - but can be accepted. A reason is to explicitly for this field indicate what format should be used, most preferably format that already known such as an email.

[jorge-ibm]

@mkistler ^^

[AgentGoldPaw]

What is the status of this issue? I also would like email to be added to the formats, as well as uuid. I have run my schema through other validators and it passes with no issues, however using this linter produces an error.

[mkistler]

Now that we have integrated Spectral, which supports custom rules, I think the appropriate path forward is to replace the hard-coded invalid_type_format_pair rule with a Spectral rule that does more or less the same thing but allows a configurable set of formats. I expect we will get to this at some point but it honestly isn't at the top of our priority list, so we would welcome a PR from the community along these lines.

[AgentGoldPaw]

That makes sense, I am sure there are definitely higher priority items than allowing formats. Just was asking. I will look into Spectral rules. Thanks for pointing me in the right direction @mkistler

[dpopp07]

This much anticipated support has been added with the latest release (0.51.3) ! email and uuid, among other formats, are now supported. Closing this issue as resolved