Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a short name for "Multipath Extension for QUIC" (possibly "Multipath QUIC") and an abbreviation (possibly "MP-QUIC") #335

Open
SpencerDawkins opened this issue May 14, 2024 · 3 comments

Comments

@SpencerDawkins
Copy link
Contributor

I'm starting to refer to this draft in multiple places, both inside and outside the IETF, and I would like to use a correct identifier, but I'm seeing this referred to as both "Multipath QUIC" and "QUIC Multipath"(*). The draft contains the string "Multipath Extension for QUIC" about 17 times, so I'm guessing you'd prefer "Multipath QUIC", but putting that in the draft would be helpful.

In addition, if there was a short abbreviation that people would be likely to include as a search term, that would also be helpful.

If you wanted to make me do the work on that, I'd be happy to submit a PR - just let me know.

(*) Yes, this is a request for better marketing. I understand why it seems silly. But I'm also seeing atrocities like "multi-path QUIC", because "Multipath Extension for QUIC" is accurate, but people are coming up with a shorter form on their own.

@mirjak
Copy link
Collaborator

mirjak commented May 14, 2024

I was actually rather trying to avoid the term "Multipath QUIC" (or "QUIC Multipath") and rather tried to talk about the multipath extension or multipath support, to explicitly indicate that this is not a new/different protocol but really just an extension and part of QUIC (similar as datagram support is also just an extension). I know the terms are still a few time in the draft but these are mainly left overs from the initial merger of the different drafts. This still needs some editorial clean-up.

@SpencerDawkins
Copy link
Contributor Author

I was actually rather trying to avoid the term "Multipath QUIC" (or "QUIC Multipath") and rather tried to talk about the multipath extension or multipath support, to explicitly indicate that this is not a new/different protocol but really just an extension and part of QUIC (similar as datagram support is also just an extension). I know the terms are still a few time in the draft but these are mainly left overs from the initial merger of the different drafts. This still needs some editorial clean-up.

Hi, @mirjak, the part in bold especially makes perfect sense to me. Would the authors be willing to consider changing the document title to

Multipath Extension for QUIC (MP-QUIC)

with no other changes requested?

@huitema
Copy link
Contributor

huitema commented May 21, 2024

@SpencerDawkins I understand that @mirjak does not want to use "MP-QUIC" or "Multipath QUIC" as some kind of brand. I think this is right: we are defining an extension to QUIC, not some kind of fork or QUIC. But by definition, adding a short name would give just that impression. The best way to avoid that would be to have no short name at all -- indeed extensions like "datagram" or "ack frequency" do not have short names. If we do pick a short term, I would specifically not use "MP-QUIC" or "QUIC-MP", because these are too damn close to being a brand. Maybe "QUIC-ME" for multipath extensions. But not saying anything is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants