Thanks for the concrete suggestions for text Mark, this is really helpful. I've taken those here: https://github.com/ietf-wg-ohai/oblivious-http/pull/223 Responses to questions/issues inline. On Wed, Nov 30, 2022, at 14:38, Mark Nottingham wrote: > * The term 'Obvivious Relay Resource' is a bit odd. Section 6.2 admits > that it can be a normal HTTP intermediary (i.e. a proxy) as long as a > few constraints are observed. So, it doesn't need to be a resource. > I know that's the fashion with the MASQUE folks, but I'd suggest that > this just be called an 'Oblivious Relay' -- or, indeed, 'Oblivious Proxy'. Yes, it doesn't need to be a resource, but I think - in the spirit of the MASQUE work, which I happen to think is taking a positive direction - a resource is appropriate here. That is, there is a resource that the relay operates with an identity of its own. I realize that the classic HTTP proxy scenario has the proxy receive something like: POST https://gateway.example/some/resource HTTP/1.1 Header: fields go: here This doesn't give the proxy any control over how resource identity affects its functioning as a proxy. For a proxy that operates exclusively as a proxy, that's probably not a big deal, but we're seeing MASQUE functions being added to servers that do other things. > HTTP has no concept of a 'Target Resource'; it's just a 'resource' (see > 9110 3.1). An easy fix would just be to use lowercase 'target'. I'd > also consider lowercasing 'resource' throughout. Hmm, fair call. I started on this then realized that maybe we were Making Names Stand Out a little too much and followed that to its logical conclusion here: https://github.com/ietf-wg-ohai/oblivious-http/pull/224 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
