Consider making requests and responses more generic

[martinthomson]

The current design allows just a single message in each direction. This is fine for a range of use cases, but it falls short of achieving the full range of things that HTTP normally allows. We might consider making the encapsulation of messages more generic to support this. This requires a length delineation so that individual pieces can be managed, a means of updating nonces (primarily for responses, we can just continue to use the same HPKE context for requests), plus some means of marking messages as incomplete (or complete) in order to prevent truncation attacks.

A streaming design would allow for messages to be incrementally processed. It would also allow 1xx status codes to be generated and sent independent of final status codes.

The cost of this is overhead (the length delimiter) and complexity (nonces, truncation).

[chris-wood]

For what it's worth, I don't think we should generalize this design, for three reasons:

1. I'm not aware of any known use case that requires generic HTTP support.
2. If an application does require generic HTTP support, then it might be better served by using CONNECT or similar.
3. This could probably be added in a future draft by extending the encapsulation mechanism in a backwards compatible way, maybe by introducing a label to denote the "type" of encapsulation applied?

I'm curious to hear what others think!

[tfpauly]

I agree I'd prefer to leave this complexity out. The single request-response setup also has a good privacy property of not including any metadata that can be linked across messages. For example, a server cannot measure the client RTT timings to try to locate clients if the server only ever sees one message and sends a reply. Once you change that property, you change a lot more assumptions.

Having a way to do this in the future is fine, but I don't know if we need a type field in the existing struct to do that. It could use a different media type.

[chris-wood]

Having a way to do this in the future is fine, but I don't know if we need a type field in the existing struct to do that. It could use a different media type.

Yeah, in hindsight, a type wouldn't make any sense unless it expressed something like "I support these different formats, server please pick the one that you want to use!" It would be simpler to just use a different media type here.

[martinthomson]

So Tommy is right that if we have to do something in future, then it will be best as a new media type. We could build something now into the one media type, but we'd need to be comfortable with the cost.

Is there a particular concern about complexity/overhead/etc... that might be assuaged by having more details of the design? FWIW, this same concern was raised when we did web push and the resolution there was to cabin the complexity and then profile it away. I'm happy to do a write-up of a design that I think would be very simple to produce or process if that would help.

[tfpauly]

The main thing concerning me is that the use cases I'm currently tracking and using this for are very specifically single-request/single-response models, and that assumption is baked into the analysis of what can be done with the protocol. For these use cases, having one peer try to send more messages for a single context would be something that I'd want to prohibit. At that point, I'd rather not have the code even support doing this for this media type, so that it's very easy and minimal to have a valid implementation of the protocol and ensure that it won't do something unexpected.

Are we aware of any use case and adopter that currently wants more than the single request-response?

[martinthomson]

How would you get from streaming requests or responses to having multiple messages? Those are very different things.

Maybe we got ourselves confused, but the "generic" aspect here is really about being able to incrementally send the same message (though HTTP has this weird idea that 1xx responses are discrete messages, I'm ignoring that; those are just streamed). Let me see if I can sketch something out...

[tfpauly]

Ah if this is just about streaming messages, that’s more understandable. I think I was thrown off by the original comment starting with “The current design allows just a single message in each direction.”, and assuming it was trying to more requests and responses. I’d be curious to see what the design would be.

[mnot]

My .02 -- If the cost is reasonable it's probably best to pay it now. If not, that's fine, but I'd ask that we be very careful with the messaging that this is some form of HTTP -- perhaps including the name.

[martinthomson]

Discussion at IETF 113 tended toward a less general form, which would be informed by seeing a more worked design for streaming of requests and responses. Some desired to keep things simple, as you will see on #108.

One idea, which @tfpauly suggested, was that we look at splitting the general thing out into a different media type, which could be negotiated.

[martinthomson]

Closing out; I will open an issue to discuss how we might convey information about what media types are acceptable to an oblivious request resource.