Draft: draft-ietf-ohai-ohttp

Commentary: I Found A Few Instances Where Oblivious Was n't Capitalized Consistently , Which Would Be Bad . There Were Also A Few Occurrences of " oblivious request resource " , Which Is Worse .
Each oblivious request requires at least two regular HTTP
requests, which adds latency.
Each request requires at least two regular HTTP requests, which
adds latency.
In particular, the Expect header field with 100-continue (see
Section 10.1.1 of HTTP) cannot be used.  Clients MUST NOT construct a
request that includes a 100-continue expectation; the oblivious
request resource MUST generate an error if a 100-continue expectation
is received.
In particular, the Expect header field with 100-continue (see HTTP)
cannot be used.  Clients MUST NOT construct a request that includes a
100-continue expectation; the Oblivious Gateway Resource MUST
generate an error if a 100-continue expectation is received.
The relay that serves the Oblivious Relay Resource has a very simple
function to perform.  For each request it receives, it makes a
request of the oblivious request resource that includes the same
content.  When it receives a response, it sends a response to the
client that includes the content of the response from the Oblivious
Gateway Resource.
The relay that serves the Oblivious Relay Resource has a very simple
function to perform.  For each request it receives, it makes a
request of the Oblivious Gateway Resource that includes the same
content.  When it receives a response, it sends a response to the
client that includes the content of the response from the Oblivious
Gateway Resource.
Firstly, a generic implementation will forward unknown fields.  For
oblivious HTTP, a relay SHOULD NOT forward unknown fields.  Though
clients are not expected to include fields that might contain
identifying information, removing unknown fields removes this privacy
risk.
Firstly, a generic implementation will forward unknown fields.  For
Oblivious HTTP, a Oblivious Relay Resource SHOULD NOT forward unknown
fields.  Though clients are not expected to include fields that might
contain identifying information, removing unknown fields removes this
privacy risk.
As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see ta), servers that operate the
Oblivious Gateway resource might need an arrangement with proxies.
This arrangement might be necessary to prevent having the large
volume of requests being classified as an attack by the server.
As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see ta), servers that operate the
Oblivious Gateway Resource might need an arrangement with Oblivious
Relay Resources.  This arrangement might be necessary to prevent
having the large volume of requests being classified as an attack by
the server.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
request resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Oblivious Target Resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier.  An Oblivious Relay can link requests using
the public key corresponding to KeyConfig.key_id.
One goal of this design is that independent client requests are only
linkable by the chosen key configuration.  The Oblivious Relay and
Gateway resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the Oblivious Target Resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier.  An Oblivious Relay Resource can link
requests using the public key corresponding to KeyConfig.key_id.