Reference RTCP subsections from tables

[mengelbart]

The tables in sections 6.5 - 6.8 contain a lot of information which is also explained in more detail in section 6.3. I think we can reference the relevant subsections from the tables instead.

[SpencerDawkins]

@mengelbart - I agree that putting all of the material relating to a specific feedback mechanism in one place, and referring to it rather than adding text elsewhere makes sense. Here's what I was thinking about while working on PR #71.

• some material is duplicated (in text and in tables),
• some material is split (between text in tables),

That's roughly this issue. But, in addition,

• It makes sense to me that we would have a list of what can be mapped between approved QUIC (RFC 9000 + RFC 9221) and RTCP, and a separate list of what could be mapped if we had one of the timestamps drafts (to help people understand why we need one of those drafts). Does that make sense to you?
• I made the (not necessarily correct) decision to list everything that we looked at, whether it can be mapped between QUIC and RTCP or not, so we have a lot of table entries that say "no", even if some entries in the same table say "yes", and that's begging for us to also document why we think the answer is "no" (again, should we be adding that?)

It might make sense to move this second group of possible changes into its own, but (especially if we decide that spending a lot of effort on "no" entries isn't worth doing), we might be making to changes to text/tables/rows that we'll end up deleting from the document.

Do you have thoughts about that? Should we have a short Slackathon to discuss?

[mengelbart]

It makes sense to me that we would have a list of what can be mapped between approved QUIC (RFC 9000 + RFC 9221) and RTCP, and a separate list of what could be mapped if we had one of the timestamps drafts (to help people understand why we need one of those drafts). Does that make sense to you?

I agree that having a list of what could be mapped with or without a timestamp extension would be helpful. I am not sure if that should be a separate table or if it would be enough to have an extra column for that.

I made the (not necessarily correct) decision to list everything that we looked at, whether it can be mapped between QUIC and RTCP or not, so we have a lot of table entries that say "no", even if some entries in the same table say "yes", and that's begging for us to also document why we think the answer is "no" (again, should we be adding that?)

That sounds good, too. I assume that the explanation would be the same for many of the fields so maybe we can do something similar to what you did in the topologies section, so we can reference the explanation/notes/subsection from all rows in the table to which it applies?

[SpencerDawkins]

We may want to move some of these sections into an appendix ("we looked at these and don't think they're useful, so other people don't have to wonder if we looked at them").