Re: Expected Client Response to SERVER_BUSY

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> effectively the overall context of the discussions in the mailing list
(as a
> whole) and within this thread (in particular) doesn't imply generic
> applicability, focusing strictly on the HTTP/X use case instead.

I would strongly oppose that. While there are more general purpose features
schedule for v2 and the main driver for v1 is HTTP, a lot of design
decisions and discussion consider other uses cases, for example tunnelling,
extension frames, peer to peer networking, separation of stream id
semantics and the general layer segregation as is evident in error codes.

On 21 February 2019 at 11.43.10, Töma Gavrichenkov ([e-mail])
wrote:

> Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP
> is unique in sense that it can use either TCP or QUIC as a transport.
> We cannot expect every application protocol to have that kind of
> property.

— Well, I personally agree as long as two conditions are met:
1) The considerations discussed above are reflected in the HTTP/3 spec
— and that one certainly might be outside of this WG's area of
responsibility;
2) The QUIC spec is tailored for consistency with the charter,
specifically in the Section 1 "Introduction" where it states that, to
quote, "QUIC is a multiplexed and secure general-purpose transport
protocol".

As far as my myopic eyes can read, there's no requirement in the
charter for the protocol to be general purpose, and also effectively
the overall context of the discussions in the mailing list (as a
whole) and within this thread (in particular) doesn't imply generic
applicability, focusing strictly on the HTTP/X use case instead.

A "general purpose" goal IMO implies sort of more attention to the
variety of use cases, featuring probably some suggestions on how
[nearly] all the important applications active within the Internet
should be able to switch from the previous general purpose protocols
No. 6 and 17 towards the new 17+, or if some of them couldn't, then
why. If the new protocol only fits some certain use cases (e.g. HTTP),
then it's fine to release it under the existing charter, however, the
promise in the Section 1 in this case needs to be further reviewed.

1)
> And even in case of H3, our conclusion might depend on how the H3
> endpoint was discovered. We might argue that it makes sense to permit
> the fallback when the H3 endpoint was discovered due to an upgrade
> from TCP (e.g. alt-svc). But the situation would be different if the
> H3 endpoint was discovered through other means
2)
> Why not deal with this at the DNS layer
> and work with the designs that are floating?

— This is totally correct as long as the required changes in the DNS
protocol — whatever they are — are implemented and deployed across the
DNS infrastructure before HTTP/3 sees the light of day.

-- 
Töma