Comments on ohttp WG and technical proposal

[Toerless Eckert <[e-mail]>]

a) WG:

I think there should be first substantial discussion about the subject matter
on the mailing list (ohttp) before proceeding on a WG request for this work.

b) Draft:

Neither the charter text, nor draft-thomson-http-oblivious provide a (to me)
good persuasive high level explanation or justification for the use-case. Something as easy as

 "A client who does not want its source-address be traceable by a target-resource
  needs a mechanism to orchestrate the following:"

  client <-> proxy-resource <-protected-leg-> request-resource <-> target-resource

and discussion of the questions arising from the model. Such as what expectations
against the proxy-resource are necessary to make this useful at all.

c) Concept:

Except for the likely (absent better text i can only guess) business cases of the
proponents of the WG, who from their perspective may not be interested in a broader
solution but want to build something constrained to just http, i for once think it
would be lot more useful for the IETF to work on such a solution with more generality.

For example, i think we could have with comparable standardization effort
such an orchestration resulting in a transparent transport (TCP) connection between
client and target-resource, allowing the scheme to be used for any protocol across
that connection, and not only for the exchange of http messages between
client and target-resource. Such work might then of course be better suited
for a TSV WG or maybe an INT WG han i guess an ART WG where ohttp might end up in
if it get chartered.

d) I am guessing that there is the assumption that a generic transport/TCP connection
connection model will have specific downsides such as more round-trips for packet exchanges,
but that comparison is really important to document, and i am no even sure
if it holds true, because if the proposed solution can deliver at e.g.: 0 additional
round-trips an HTTP get request from the client to the target resource, than so could that
AFAIK simply be a TCP message. 

Cheers
    Toerless

-- 
---
[e-mail]