Wire protocol naming

[thomaspoignant]

Hello 👋

During all the discussions in Slack around the wire protocol, we have seen some confusion around what is the scope of the wire protocol. The naming does not help to understand the scope of this initiative, this is why I am opening this poll to propose alternatives and to find the best naming for it.

You can read this document to get the full context of the initial discussions.
But a small TL;DR:

The wire protocol or remote flag evaluation, is a mechanism that allows the use of generic providers to connect to any feature flag service that supports the protocol.
Currently feature flag vendors are expected to write OpenFeature providers for every language they support. With the wire protocol, they would only be required to implement a single set of endpoints (technology needs to be defined), that could be consumed directly by all of the OpenFeature SDKs.
In the event that the wire protocol does not provide the required capabilities for the vendor, they could write language-specific providers if they wished.

I've put in this poll some propositions shared by the community, but feel free to answer in the discussion if you have other ideas.

[ivarconr]

@thomaspoignant
What confuses me is the use of word 'protocol'. Usually a protocol is on a lower layer (HTTP, gRPC) and defines how bits and bytes are transmitted between two parties.

From my understanding this iniative is trying to define an API or a specification on how two applications can work together to solve something. The solution would select one (or multiple) protocol(s), eg. HTTP, gRPC, etc, and define a standard API to be implemented.

I would prefer a name such as "OpenFeature Remote Evaluation API". This would be less confusing to me at least.

[toddbaert]

I'm not sure I agree. Let's take OTLP for example: https://opentelemetry.io/docs/specs/otlp/. As usual, OTel is a good analogy to our goals. They called their equivalent a protocol, and it's based on top of gRPC and HTTP 1.1, just like ours might be:

This specification defines how OTLP is implemented over gRPC and HTTP 1.1 transports and specifies Protocol Buffers schema that is used for the payloads.

Another example is SCIM, which has a REST-based "protocol" (their term) for identify exchange: https://datatracker.ietf.org/doc/html/rfc7644:

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol

Personally I think "API" is a bit overused to describe web or other RPC services. APIs are something a programmer codes against, I somewhat dislike how "API" and "REST API" have become practically synonymous. Put another way, we already have the API, this would be the communication layer that powers it.

I'm happy to be overruled on this though.

cc @ivarconr

[thomaspoignant]

I agree, with Todd on this.
I like the word protocol it is more generic and it follows the same strategy as OpenTelemetry.

[kinyoklion]

I agree that we already have an API, and the API would be the same doing local or remote evaluations.

Protocol is also a bit overloaded, but is closer to what this is. Using the same API, but being able to switch protocols, is the primary boon.

[kinyoklion]

Protocols are also often layered, one protocol operating over another protocol. So ultimately you may have "OREP over http" or "OREP over gRPC". The flow and composition of messages is a protocol, which is then independent of the transport protocol. We use HTTP, but HTTP is using TCP, both protocols handling different domains.

[ivarconr]

I appreciate your feedback and the examples you provided @toddbaert . You raise valid points about the potential ambiguity of using the term "API" in this context. I also think "API" and "protocol" too often are used interchangeability.

My initial response was formed from the document describing the initiative where it states:

Wire protocol: A special REST (or similar) API that a vendor/rules engine might implement, at which point they'd have a baked-in client for all the major open-feature clients.

Upon closer examination, I realize that my understanding of the initiative's goal and scope might have been incomplete due to my limited involvement. In light of your suggestion, I believe that "protocol" might be a more appropriate term.

[justinabrahms]

Todd referenced "OFREP" when referring to this protocol. This seems too audibly similar to "OFEP", so I'd recommend we choose something more distinct.

[toddbaert]

Ya I dislike how close they are. I'd be interested in a name that could be abbreviated nicely. 🤷

[thomaspoignant]

I understand Justin's point, but I am sad to discard a name just because the acronym is too close to something already existing.

If we look at the different proposals we have:

• OREP - OpenFeature Remote Evaluation Protocol
• RFEP - Remote Flag Evaluation Protocol or ORFEP (if we add OpenFeature before)
• OSP - OpenFeature Standard protocol
• OOPEP - Out of process evaluation protocol
• FEP - Flag Eval Protocol or OFEP (clearly bad to call it OFEP 😉)

[toddbaert]

I like OREP

[kinyoklion]

What about prefixing out the OF with a dash? OF-REP. Thinking about other situations, like MPEG-DASH?

[toddbaert]

Also not a bad candidate. Either way, I think if we don't choose an abbreviation, one will be chosen for us.

[thomaspoignant]

Based on the result of the poll, we will use OpenFeature Remote Evaluation Protocol as the namming for the wire protocol 🎉