What (encrypted) media types are acceptable

[martinthomson]

We are defining a media type here that has some limitations (mostly lack of streaming, #75). If we want to define a more capable media type, what would the system need to do to allow that to happen?

At face value, this seems simple: the oblivious request resource consumes the media type. It already needs to make its key known to clients, so adding a set of acceptable media types to that information seems entirely reasonable.

Questions:

• Should we enrich the key configuration with other meta-information? Or is this supplementary information?
• Is there any value in an in-band signaling mechanism? We've already seen that feedback about time is ...challenging.
• Supported media types convey information that might be used to distinguish clients in the same way that key selection could. What do we need to do about ensuring consistency?

[chris-wood]

Since OHTTP is meant for specific applications, this seems like something the client and server ought to know a priori, unlike the specific key configuration. I don't think we need to make any changes here.

[tfpauly]

So far, the models I've seen would know the media type a priori. So, I'd agree with Chris for this.

[martinthomson]

OK, let's put this to bed then. I've work to do on something more sophisticated for a streaming design, but this isn't critical for that.