Naming consistency of frames

[mirjak]

We should maybe review the names of the frames, e.g.:

1. Should we rename ACK_MP to MP_ACK? Or PATH_ACK?

2. Is it MP_NEW_CONNECTION_ID or maybe rather PATH_NEW_CONNECTION_ID or NEW_PATH_CONNECTION_ID or go shorter to PATH_NEW_CID or something?

3. Depending on the final definition is could be MAX_PATHS or MAX_PATH_ID

[Yanmei-Liu]

I'd support that we rename the MAX_PATHS frame to MAX_PATH_ID frame. It's easier to understand and has less ambiguity in implementation.

[mirjak]

Proposal is to rename ACK_MP to MP_ACK. @qdeconinck will propose a PR.

[huitema]

I still have a doubt about the names of frames. The new frames are:

• MAX_PATH_ID
• PATH_ABANDON, PATH_AVAILABLE, PATH_STANDBY
• MP_ACK, MP_NEW_CONNECTION_ID, MP_RETIRE_CONNECTION_ID

We could leave it at that, or we could harmonize to:

• PATH_ID_MAX
• PATH_ABANDON, PATH_AVAILABLE, PATH_STANDBY
• PATH_ACK, PATH_CONNECTION_ID, PATH_RETIRE_CONNECTION_ID

Harmonizing to "PATH_" and not using the prefix "MP" anywhere would help with the general message that "this is just an extension of QUIC, not a new protocol, we definitely don't want to call it MP_QUIC".

[MikeBishop]

I like the common prefix, and the fact that each of these frames can only talk about one of the multiple paths. However, MAX_PATH_ID better aligns with MAX_DATA, MAX_STREAMS, MAX_STREAM_DATA from RFC 9000. I'd leave that one.

[mirjak]

As discussed in the IETF-120 session, we will rename to PATH_ACK, PATH_CONNECTION_ID, PATH_RETIRE_CONNECTION_ID.

MAX_PATH_ID will not be renamed as proposed by Mike above and confirmed in the meeting.

I created PR #426

[mirjak]

#426 has been merged