Re: [Ohai] Terminology updates

[Martin Thomson <[e-mail]>]

Speaking of a similar shade, I want to point out that the Oblivious Relay, Oblivious Gateway, and Target are all Resources in the sense that they are each identified by a URI with the "https" scheme.  We'll write them out in full in the spec, but I expect that an acceptable in-context shorthand will just be client, relay, gateway, and target. 

On Thu, Jun 30, 2022, at 00:35, Lucas Pardue wrote:
> +1 to this name change, or a very very similar shade
>
> I think the present terminology makes the protocol sound harder than it 
> actually is. Thanks for working on trying to clarify and simplify the 
> language.
>
> On Wed, Jun 29, 2022 at 3:13 PM Tommy Pauly 
> <tpauly=[e-mail]> wrote:
>> These proposed names seem reasonable. I like that they have “Oblivious” in the name, so it will be clear when used in other contexts that they refer to OHTTP. It’s also probably for the best that we avoid “proxy” since that has many meanings, and “relay” works fine here.
>> 
>> This is an acceptable shade to paint the bike shed =)
>> 
>> Thanks,
>> Tommy
>> 
>> > On Jun 29, 2022, at 7:04 AM, Christopher Wood <[e-mail]> wrote:
>> > 
>> > Hi folks,
>> > 
>> > Issue #121 [1] discusses the terminology used in the draft. Currently, we have the following four entities:
>> > 
>> >   Client <> Oblivious Proxy <> Oblivious Request <> Target
>> > 
>> > And we have the following three distinguished types of requests:
>> > 
>> > - Client -> Proxy
>> > - Proxy -> Request
>> > - Request -> Target
>> > 
>> > The Client->Proxy and Proxy->Request requests carry an encrypted (or encapsulated) request in their body, and the Request->Target request is this decapsulated/decrypted request.
>> > 
>> > In discussing OHTTP with folks, it’s become clear that the names used here are somewhat confusing. To help make the concepts more clear, I think it’d be useful to establish better names for the entities and requests used in the document. Obviously, this is a bike shed, but it’s a shed worth painting now rather than later.
>> > 
>> > After discussing with several people, Martin and I settled on the following proposal. First, let’s rename the four entities to the following:
>> > 
>> >   Client <> Oblivious Relay <> Oblivious Gateway <> Target
>> > 
>> > We use gateway here because the entity does a couple of different things to transform ingress requests to requests for the target, including decapsulation and replay prevention. And we use the term relay here to distinguish this entity from a traditional proxy. 
>> > 
>> > With these names, we then use the following terms for the three distinguished requests:
>> > 
>> > - Client -> Oblivious Relay: Oblivious Relay Request (carrying an Encrypted Request)
>> > - Oblivious Relay -> Oblivious Gateway: Oblivious Gateway Request (carrying the same Encrypted Request)
>> > - Oblivious Gateway -> Target: Request
>> > 
>> > What do folks think of this proposal?
>> > 
>> > Best,
>> > Chris
>> > 
>> > [1] https://github.com/ietf-wg-ohai/oblivious-http/issues/121
>> > -- 
>> > Ohai mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ohai
>> 
>> -- 
>> Ohai mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ohai
> -- 
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai