add a new QUIC codepoint for QUIC v1 #298
Conversation
| @@ -119,7 +119,8 @@ garlic32, multiaddr, 0x01bf, draft, I2P b | |||
| tls, multiaddr, 0x01c0, draft, | |||
| sni, multiaddr, 0x01c1, draft, Server Name Indication RFC 6066 § 3 | |||
| noise, multiaddr, 0x01c6, draft, | |||
| quic, multiaddr, 0x01cc, permanent, | |||
There was a problem hiding this comment.
Removing quic name will break all implementations that parse text multiaddrs based on libraries generated from this table.
@marten-seemann is the plan to do a hard BREAKING CHANGE across ecosystem (forcing end users or implementations to update bootstrap/peering configs and DNSAddrs manually)?
OR
do we want to have a ~1y deprecation period when both are valid, like we did when we renamed /ipfs/{peerid} to /p2p/{peerid}?
(fysa we've removed the legacy alias entry just recently in #283).
There was a problem hiding this comment.
I was planning to keep parsing quic as draft-29 for the foreseeable future, but emit quic-draft29 from now on (for the limited amount of time that we still support it).
Is there any way to encode this kind of logic into the multicodec table?
There was a problem hiding this comment.
I don't think so. We should do the rename later and for now simply add the quic-v1 codepoint. (I left a similar comment in the multiaddr PR: multiformats/multiaddr#147 (comment))
There was a problem hiding this comment.
I reverted this change.
There was a problem hiding this comment.
We could add another code-point for quic-draft29 and just deprecate the use of quic altogether. That is semantically equivalent to a rename but can be expressed in the table if we also add a "Status" called "deprecated".
There was a problem hiding this comment.
We should do the rename later and for now simply add the quic-v1 codepoint.
I would advocate for not renaming things in this table anymore, ever, and to make this table append-only. We have an increasing number of critical systems and businesses relying on these values remaining constant. There is enormous value in using the names as human-readable codes, but if we are unable to commit to not breaking names then I think we should just remove them entirely and rely on the description, which implies that it's for human and not machine consumption.
marten-seemann
changed the title
See multiformats/multiaddr#145 for a detailed explanation.
Implementations MAY choose to continue accepting
/quicmultiaddresses (and interpret them asquic-draft29orquic-v1at their discretion).cc @elenaf9 @thomaseizinger, who are apparently not part of the multiformats org yet.