Include message type in definitions to match QUIC notation style

[LPardue]

In other documents that use QUIC notation to define message types such as frames, we fully expand all fields. It would be nice to do the same for MoQT messages. For example,

GOAWAY Message { New Session URI (b) }

Vs. HTTP/3

GOAWAY Frame { Type (i) = 0x07, Length (i), Stream ID/Push ID (i), }

The ask is to add populate the Type field in in message definitions.

[ianswett]

Good point, that would also prevent us/me from forgetting to allocate a codepoint for new messages.

[fluffy]

I would prefer it to look more like:

GOAWAY_Frame {
Type (i) = MSG_TYPE_GOAWAY,
Length (i),
Stream_ID_Push_ID (i),
}

( I don't care about if we are camel case, snake case, or whatever, but using space as a separator is really confusing as it s the separator when want to put two labels in text. I don't care if this is how quic did it, this is not quic ) IfYouWantToUseSpaceAsTheSeperatorForPartsOfALabelNameThenWeNeedToStopUsingThemIntheText.

Then in an IANA table with all the message types, define MSG_TYPE_GOAWAY = 0x07. This make it easier to have a label to talk about the type and makes it easier to ensure 7 is not assigned to two messages.

[LPardue]

FWIW, the PR to close this issue was already merged in https://github.com/moq-wg/moq-transport/pull/550.

To address the comments though:

I don't care about if we are camel case, snake case, or whatever, but using space as a separator is really confusing as it s the separator when want to put two labels in text. I don't care if this is how quic did it, this is not quic )

I humbly disagree. There's a family of related documents that are building on each other, QUIC, HTTP/3, Capsule Protocol, other extensions, WebTransport, and then MoQT on top of those. Adding inconsistency in the documentation presentation just adds friction. Implementers are likely to be the same people.

In code, I'm going to represent this as a subtype of Message. In Rust, I can do it like

 enum Message {
   GoAway { newSessionId: Vec<u8> },
   Unsubscribe { subscribe_id: u64 },
   ...
 }

There's never anything labelled GOAWAY_Message in that model (no matter how it might be capitalized) . Sure, other programming languages are different but again, the approach we have taken so far has been widely implemented and nobody seemed to have an issue.

Then in an IANA table with all the message types, define MSG_TYPE_GOAWAY = 0x07. This make it easier to have a label to talk about the type and makes it easier to ensure 7 is not assigned to two messages.

So a few thoughts here:

1) How often are message type concrete wire values talked about in text? My very quick scan indicates zero times. In common parlance, my experience is people talk about messages "I sent you a GOAWAY Message", rather than "I sent you a MoQT message and it had the type MSG_TYPE_GOAWAY". When it comes to IANA, I expect we would register a MoQT Message registry and have entries like

| Value | Message Type | Status | Reference | Date | Change Controller | Contact | Notes | | 0x10 | GOAWAY | Permanent | RFC XXXX | YYYY-MM-DD | IETF | MoQ WG | |

and if we had that style, I don't really see where the label MSG_TYPE_GOAWAY really fits in.

I agree there's a problem using the same value twice. That's why we should already have had IANA tables :D

2) My implementation experience from QUIC etc is that its very convenient to have the pertinent information close at hand. Having the concrete value off in a different part of the document means needing to flip back and forth, which is doable but a bit annoying. Especially because of the lack of hyperlinks in our diagrams (a tooling issue). In contrast, its nice IMO to see in a single glance the objects full structure and expanded constants.

3) All that said, having a layer of indirection in concrete values has proven useful for other documents while they are in a churn phase. Especially if they need to be renumbered (which I expect will happen for MoQ). For example, in RFC 9297, in early drafts we used indirection (https://www.ietf.org/archive/id/draft-ietf-masque-h3-datagram-05.html#section-4.4.2 Type (i) = CLOSE_DATAGRAM_CONTEXT, and in the IANA text defined CLOSE_DATAGRAM_CONTEXT). Then for the RFC we removed the indirection.

On balance, I could support type indirection for I-Ds and then a removal of indirection when it comes to RFC. Would that be an acceptable compromise? If so, lets spin it out to a different issue and PR.