RFC 8999 Quiz

**Explanation:** RFC 8999が固定するのは,QUICを認識しversionを交渉するための性質だけです. A: v1全体を固定すると有意な進化を妨げます. B: 変更できない部分を限定し,将来versionの配備可能性を守ります. C: congestion control algorithmはここで定める不変条件ではありません.

**Explanation:** 原則は進化の自由です. A: v1で観測できる動作が自動的に不変条件になるわけではありません. B: 不変条件に含まれないことは予約を意味しません. C: RFC 8999が明示的に禁止しない限り,別versionは異なる意味を定義できます.

**Explanation:** A: connection-orientedなendpoint communicationはabstract modelに含まれます. B: UDP datagramはQUIC endpointが交換するcontainerです. C: HTTP/3はQUIC上のapplication protocolの一つであり,HTTP semanticsはQUIC自体のversion-independent propertyではありません. D: connectionは二つのendpoint間で確立するshared protocol stateです.

**Explanation:** A: 先頭byteの最上位bitはlong headerとshort headerを分ける不変のdiscriminatorです. B: short headerの先頭byte直後にDestination Connection IDがありますが,その長さはpacket内に符号化されません. C: long-header layoutではVersionの後に両connection IDの長さと値を読めます. D: invariantなshort-header layoutにはVersionとSource Connection IDがありません.

**Explanation:** A: RFC 8999はconnection IDをopaque fieldと定義します. B: endpointはversion-specificな方法で値を選び,同じconnectionでも値が変わり得ます. C: これはpacketの配送先を識別する値であり,userやauthorization subjectではありません.

**Explanation:** A: 0はVersion Negotiation用に予約され,そのlong-header packetを識別します. B: 暗号化なしのv1ではありません. C: short headerにはVersion fieldがありません.

**Explanation:** A: unsupported versionを持つlong-header packetだけがVersion Negotiationを返す契機になり得ます. B: fieldの意味が異なり,short headerにVersion fieldはありません. C: RFC 8999が明示しています.

**Explanation:** Version Negotiation packetはintegrity protectionもconfidentiality protectionも持ちません. A: 形式の認識は認証ではありません. B: その結果としてversionを変更するなら,選んだversionの仕組みでsemantic contentを認証する必要があります. C: RFC 8999は「先頭を選ぶ」と定めていません.

**Explanation:** A: Appendix Aは,別versionでは成立しない可能性のあるv1の観測可能な性質を列挙しています.これを強制するとossificationが起きます. B: connection IDは変わり得ます. C: Version Negotiationは意図的にlong-header形式で認識できるようにしています.

**Explanation:** A: 最初のprofile全体を固定すると進化できません. B: 偶然見える特徴を契約にするとossificationを招きます. C: 小さな明示的coreなら,architecture上の類推として交渉可能性と配備自由度を両立できます.具体的なA2A coreはapplication仕様が決めるもので,RFC 8999の要件ではありません.