Q1: RFC 8999が主に守ろうとしているものはどれか
Multiple Choice**Explanation:**
RFC 8999が固定するのは,QUICを認識しversionを交渉するための性質だけです.
A: v1全体を固定すると有意な進化を妨げます.
B: 変更できない部分を限定し,将来versionの配備可能性を守ります.
C: congestion control algorithmはここで定める不変条件ではありません.
References (URLs)
Q2: あるfieldの動作がRFC 8999で固定も禁止もされていない.そこから言えることはどれか
Multiple Choice**Explanation:**
原則は進化の自由です.
A: v1で観測できる動作が自動的に不変条件になるわけではありません.
B: 不変条件に含まれないことは予約を意味しません.
C: RFC 8999が明示的に禁止しない限り,別versionは異なる意味を定義できます.
Q3: RFC 8999の抽象的なQUIC説明に含まれるものはどれか.複数選択
Multi-Select**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です.
Q4: QUIC version間で不変なheaderの記述はどれか.複数選択
Multi-Select**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がありません.
Q5: QUIC connection IDについて安全に置ける前提はどれか
Multiple Choice**Explanation:**
A: RFC 8999はconnection IDをopaque fieldと定義します.
B: endpointはversion-specificな方法で値を選び,同じconnectionでも値が変わり得ます.
C: これはpacketの配送先を識別する値であり,userやauthorization subjectではありません.
Q6: Version 0x00000000が表すものはどれか
Multiple Choice**Explanation:**
A: 0はVersion Negotiation用に予約され,そのlong-header packetを識別します.
B: 暗号化なしのv1ではありません.
C: short headerにはVersion fieldがありません.
Q7: endpointが解釈できないshort-header QUIC packetを受信した.RFC 8999に合うresponseはどれか
Multiple Choice**Explanation:**
A: unsupported versionを持つlong-header packetだけがVersion Negotiationを返す契機になり得ます.
B: fieldの意味が異なり,short headerにVersion fieldはありません.
C: RFC 8999が明示しています.
Q8: clientが妥当に見えるVersion Negotiation packetを受信し,versionを切り替えようとしている.追加で必要な条件はどれか
Multiple Choice**Explanation:**
Version Negotiation packetはintegrity protectionもconfidentiality protectionも持ちません.
A: 形式の認識は認証ではありません.
B: その結果としてversionを変更するなら,選んだversionの仕組みでsemantic contentを認証する必要があります.
C: RFC 8999は「先頭を選ぶ」と定めていません.
Q9: 設計レビューとして最も正確な指摘はどれ？
単一選択network gatewayは、QUIC v1のfixed bitと、v1 trafficから学習したTLS関連の特徴が見えるpacketだけをQUICとして通す。将来versionはRFC 8999の全invariantを守るが、この二つの観測値を変更したためgatewayに遮断される。
**解説:**
RFC 8999 Section 7とAppendix Aは、middleboxがinvariantではない観測値へv1の意味を結び付ける危険を説明する。文書のfixed propertyを満たすversionは、それらの特徴を変えただけでは無効にならない。Cがgatewayによるossificationを指摘する。Bは観測によってprotocol contractを暗黙に書き換え、Dはopaqueなrouting値を恒久定数と誤解している。
Q10: 全要件を満たすversioningとverificationの分担はどれ？
単一選択A2A profile 1ではtask type、grant format、routing fieldが見える。Profile 2ではそれらを暗号化または再構成できなければならない。gatewayはdispatch用の安定したprofile identifierとnegotiation exchangeを必要とし、backendはoperationをauthorizeする前にversion固有の署名付きgrantを検証する必要がある。
**Explanation:**
RFC 8999 Section 2は、QUICの認識とversion negotiationに必要な最小propertyだけを固定し、他のsemanticsをversion固有にする。Section 7は、versionを変更するendpointが、選択したversionの仕組みでnegotiationのsemantic contentを認証することも求める。Cはこの分離を類推として適用し、署名付きgrantを理解するbackendにauthorizationを残す。RFC 8999自体はA2A fieldやgrant検証を定義しないため、それらはA2A profile側の責務である。