Add provider spec

[toddbaert]

Added provider spec, with minor associated changes to the existing flag-evaluation spec file.

[moredip]

Do we want to specify any semantics around how a provider should handle transient errors on their side. Like if there's a network connectivity issue, should to provider immediately fail, or have a retry/fallback mechanism.

One option is to leave this entirely unspecified and up to each provider. Another would be to give a provider implementer some guidance or suggestions - e.g. make a best effort to handle transient failure, but don't hang evaluation for "a long time" (whatever that means).

[toddbaert]

Do we want to specify any semantics around how a provider should handle transient errors on their side. Like if there's a network connectivity issue, should to provider immediately fail, or have a retry/fallback mechanism.

One option is to leave this entirely unspecified and up to each provider. Another would be to give a provider implementer some guidance or suggestions - e.g. make a best effort to handle transient failure, but don't hang evaluation for "a long time" (whatever that means).

This might be relevant to the "event" discussion. Most SDKs have readiness events, etc. We could build an events API which might cover both cases.

I think for now, I would err on the side of not defining this until we need to - but I'm not sure. If there's a pressing use-case, we can talk more about it.

[toddbaert]

@moredip any additional concerns after my updates to your comments?

I think we have 2 open questions represented here, which I may create other issues for:

• Are additional error codes allowed (see: https://github.com/open-feature/spec/pull/41#discussion_r861035906)
• handling transient errors, possibly with events

I don't think either of these are a blocker for this, but let me know if you disagree.

[moredip]

@moredip any additional concerns after my updates to your comments?

Nope, I think it's good

[toddbaert]

Squashed, added co-authors.