Re: [Ohai] Reviving work on streaming OHTTP

Definitely agreed that we wouldn’t want too many variants floating around.

Practically, I would expect that for any given gateway, it would make sense to use one variant or the other (streamed or non-streamed), across all clients. If your gateway is serving DNS queries, then you don’t need streamed. If it is sending much larger or slower responses, it might.

For proprietary methods of sharing gateway configurations, they can certainly indicate whether or not streaming should be used for all clients. The consistency problem then needs to be solved for this entire bundle. I agree that this becomes the easy case.

Dynamic discovery is trickier to make consistent, and I’ll need to think about that case more.

Tommy

> On Jul 4, 2023, at 5:51 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> Certainly, there will be cases where the new format is known to be supported, such that a client can just use it, with the server responding in kind.  It is also possible for this to be asymmetric, where a server supports both and chooses a response format based on the request of the client.  But those are the easy cases.
> 
> For something like the SVCB config, things get interesting.  The obvious approach here is to have the gateway indicate what it accepts alongside the key configuration.  The format we've defined has no direct means to do that, but the method overloading suggests that maybe Accept on a key configuration fetch would work, even if that might be a bit of a misuse of the field (it doesn't appear to be so based on a strict reading, but...).
> 
> There is also the possibility that the gateway could indicate what it accepts, such that clients could try one format and be told which formats are acceptable.  That uses an unauthenticated medium (the outer envelope, which is visible to the relay) and comes with delays in the case that a client guesses incorrectly.  It also separates clients into multiple groups based on what format they choose, which leads to the next point...
> 
> The choice of formats is subject to all of the same considerations regarding consistency as other aspects of configuration.  Clients opting to use format A will be distinguished from clients that choose format B.  For that reason, we probably shouldn't have too many options floating around.
> 
> On Wed, Jul 5, 2023, at 10:09, Mark Nottingham wrote:
>> It might be worth thinking about how this should be invoked/portrayed; e.g.,
>> 
>> - is it something that the sender just decides to use?
>> - or, something negotiated/hinted?
>> - or, do we give the whole thing a different name, and people bake in 
>> OHTTP or [new thing]?
>> 
>> Cheers,
>> 
>> 
>>> On 4 Jul 2023, at 6:05 am, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>> 
>>> Hi, OHAI!
>>> 
>>> A little over a year ago, Martin had proposed adding streaming support for OHTTP, written up in this PR (https://github.com/ietf-wg-ohai/oblivious-http/pull/108).
>>> 
>>> We had decided not to add this into the base spec, since it requires a slightly different wire format (with chunk lengths), but instead have a new media type for that.
>>> 
>>> As the core OHTTP spec is almost an RFC, and we’re getting more experience with deployment, it seemed like a good time to revive the work and pull together a document to define that new media type, and the delta it has from the base OHTTP format based on Martin’s PR.
>>> 
>>> I don’t think I’ll be able to get a full draft out before the deadline, but I’d like to hear:
>>> - If people are interested
>>> - If there’s any objections to doing this work now
>>> - If people would like to volunteer to co-author
>>> 
>>> Best,
>>> Tommy
>>> -- 
>>> Ohai mailing list
>>> Ohai@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ohai
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> -- 
>> Ohai mailing list
>> Ohai@ietf.org
>> https://www.ietf.org/mailman/listinfo/ohai