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 -- --- t...@cs.fau.de