Draft: draft-ietf-ohai-ohttp

Commentary: This is a lot more disruptive , but I think it is a clearer description of how you might repurpose this design . I 'm still a little unsure about using application / dns - message , but I can live with it . 
 If this is acceptable , I might cherry - pick some of the other changes from rather than take it wholesale . 
 OK , I think that I understand what you are looking for and I agree , we can say more about that . But we probably do n't need to say heaps more . Is the latest commit what you are looking for ? 
 I think it 's closer , but I genuinely do n't see why noting precisely where things need to change in the spec is harmful . I prefer Tommy 's original change here . 
 Yeah , this still does n't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types . Another way to look at this is , for another spec to define how to use another media type , it should be easy to simply say " the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots " . We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE , etc , and just have one subtle difference . 
 I 'm not seeing that . I realize that I missed the padding piece ( though I do n't consider that particularly important , it 's worth mentioning ) . For a generic format , the only adaptation required is replacing the constant strings . This describes how that might work . That we do n't burden the reader of the algorithm piece with this detail at the time is a feature , not a bug , as far as I 'm concerned . 
 I do n't consider it a burden . I think it 's an important piece for someone who 's implementing OHTTP since it has API implications . For example , one could implement the main encap and decap algorithms using the fixed " message / bhttp " content type and then find they have to either duplicate code later on adjust their encap and decap APIs ( or something else ) to accommodate another type of application encoding . The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they do n't run into this situation down the road , and they 're minimally invasive hints at that . 
 I 've the pointers , as requested . ( I only skipped one on the decapsulation process as that seemed redundant . ) 
 Thanks , latest changes look good to me
An encapsulated HTTP request contains a binary-encoded HTTP message
BINARY and no other fields; see fig-req-pt.
This document defines how a binary-encoded HTTP request BINARY is
encapsulated.  This Encapsulated Request format is identified by the
iana-req.  Alternative encapsulations or message formats are
indicated using the media type.
The content of ""message/ohttp-req"" request encapsulation contains
only a binary HTTP message; see fig-req-pt.
This document defines how a binary-encoded HTTP request BINARY is
encapsulated.  This Encapsulated Response format is identified by the
iana-res.  Alternative encapsulations or message formats are
indicated using the media type.
The content of ""message/ohttp-res"" response encapsulation contains
only a binary HTTP message; see fig-res-pt.
Build "info" by concatenating the ASCII-encoded string "message/
bhttp request", a zero byte, and the header.  Note: repurposing
discusses how alternative message formats might use a different
"info" value.
Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified
by new media types.
Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified
by new media types.  New media types might be defined to use similar
encapsulation with a different HTTP message format than in BINARY;
see repurposing for guidance on reusing this encapsulation.
Alternatively, a new encapsulation method might be defined.
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  The Client and Oblivious Gateway Resource agree
on this encrypted payload type by specifying the media type "message/
bhttp" in the HPKE info string and HPKE export context string for
request and response encryption, respectively.
Future specifications may repurpose the encapsulation mechanism
described in this document.  This requires that the specification
define a new media type.  The encapsulation process for that content
type can follow the same process, using new constant strings for the
HPKE info and exporter context inputs.
For example, a future specification might encapsulate DNS messages,
which use the "application/dns-message" media type RFC8484.  In
creating a new, encrypted media types, specifications might define
the use of string "application/dns-message request" (plus a zero byte
and the header for the full value) for request encryption and the
string "application/dns-message response" for response encryption.
Clients can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.  If the encapsulation method described in this document
is used to protect a different message type (see repurposing), that
message format might need to include padding support.
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "message/bhttp request" label.
Designers of protocols that reuse this encryption format, especially
new versions of this protocol, can ensure key diversity by choosing a
different label in their use of HPKE.  The "message/bhttp response"
label was chosen for symmetry only as it provides key diversity only
within the HPKE context created using the "message/bhttp request"
label; see repurposing.