ORIGIN frame feedback

Hi,

Dusting off my ORIGIN frame implementation, I'm unsure in a few areas. Below are some questions/suggestions, I'm happy to prepare some PRs if there is agreement:

Repetition of fields
I naively assumed the ORIGIN frame was very similar to the ALTSVC frame, I missed out on the repetition element. I think it would help to improve upon diagram in section 2.1, first coin a term for the Origin-Len:ASCII-Origin pair (it is loosely referred to as set, which is easily confused with Origin Set), for this email I'll use the term Origin-Entry. Section 2.1 would be changed to contain two clearly labelled diagrams: one shall show the fields comprising an Origin-Entry, the other shall show the ORIGIN frame payload as an OPTIONAL sequence of Origin-Entries, with cardinality of 0-*. 0 indicates an empty ORIGIN frame, which is implied by the text in Appendix B - "inform the client that the connection is only to be used for the SNI-based origin, by sending an empty ORIGIN frame.".

Expectations for Origin Set size
If my interpretation of the specification is correct, the Origin Set is currently unbounded. While the size of an individual H2 frame is bounded and negotiated, the Origin set can seemingly be added to ad nauseam. Even in the default size case, for a short ASCII-Origin<http://www.dirk-loss.de/short-domains.htm> such as http://dk, if might be possible to create an Origin set with ~1500 entries. I like the fact that ORIGIN frame extension doesn't need any negotiation, so perhaps some guidance for client-side implementations would help e.g. be aware of the Origin Set size and be prepared to close the connection if you're getting unhappy.

Non-normative processing algorithm
Is this reflective of current ORIGIN frame fields? The terminology seems slightly askew as each Origin is comprised of two fields and I'm wondering if it got outdated. Using the term Origin-Entry could help here.

Regards
Lucas