RFC 3986 Quiz

**Explanation:** In RFC 3986 Section 3, `//` selects the grammar branch that contains an authority. The authority continues until the next `/`, `?`, or `#` and can contain userinfo, host, and port. By contrast, `?` begins the query and `#` begins the fragment. An authority is optional: `mailto:user@example.com`, for example, uses a path-rootless form without `//`. Parsers, proxies, routers, and security filters therefore need to agree on the grammar branch before they make routing or policy decisions.

**Explanation:** RFC 3986 Section 3.2 defines authority as `[userinfo@]host[:port]`. Here it begins after `//` and ends before `/a`, so it is `user:pass@example.com:8443`: userinfo is `user:pass`, the host is `example.com`, and the port is `8443`. `example.com:8443/a?x=1` crosses into the path and query. `https://user:pass@example.com` includes the scheme and omits the port. Those boundary errors can change proxy routing, origin comparison, logging, and authorization behavior. RFC 3986 deprecates cleartext passwords in userinfo. The password-like text in this example illustrates the grammar; applications should not expose or persist such credentials as URI text.

**Explanation:** RFC 3986 Sections 2.2 and 2.3 divide URI characters into reserved and unreserved sets. `?` and `#` are generic delimiters, while `&` is a sub-delimiter; `~` is unreserved. “Reserved” does not mean forbidden or inherently unsafe. It means that a character can have a delimiter role, depending on the component or scheme. Query construction, signature processing, and redirect validation must preserve whether the character is syntax or data; a reserved character used as data may need percent-encoding.

**Explanation:** RFC 3986 Sections 2.1, 2.4, and 7.3 distinguish reserved delimiters from encoded data. Applications must split a URI into components and subcomponents before decoding octets; otherwise decoded data can be mistaken for syntax. RFC 3986 does not define the application's task-ID model, so the profile must state that the ID occupies one segment. A: Encoding the structural separators destroys the generic path structure. B: The raw slash creates another path segment and leaves identity to parser-specific guessing. C: Correct. It preserves syntax/data roles and gives both sides one decoding boundary. D: Decoding before parsing can turn encoded data into a delimiter and change component boundaries.

**Explanation:** RFC 3986 Sections 6.1 and 6.2.2.1 make scheme and host case-insensitive under the generic syntax. Other generic components are assumed case-sensitive unless the scheme says otherwise. URI comparison is purpose-dependent and must avoid false-positive equivalence. A: The generic rule does not extend host semantics to the path. B: Correct. After allowed normalization, /tasks/A and /tasks/a remain different identifiers for this profile. C: Lowercasing the path invents an equivalence that neither the RFC nor the profile defines. D: Equal content at one moment does not establish authorization-identifier equivalence.

**Explanation:** RFC 3986 Section 3.5 calls the component after `#` the fragment. It identifies a secondary resource in relation to the primary resource; its interpretation depends on the media type and client context. The fragment is separated before dereferencing, so a user agent normally does not include it in an HTTP request. This differs from a query, which begins with `?` and is part of the resource request. Confusing the two changes both parsing and policy behavior.

**Explanation:** RFC 3986 Sections 6.1 and 6.2 do not define one universal URI comparison rule. The relevant trade-offs depend on the comparison purpose and can require scheme-specific or application-specific rules. A security decision must especially avoid a false positive that treats different identifiers as equivalent. Returning the same representation at one moment does not prove authorization-identity equivalence. Redirects, virtual hosting, shared content, and temporary routing can make results coincide. RFC 3986 recommends consistently producing URI references in an already-normalized form to reduce unnecessary aliases. A security profile can pin that canonical form and comparison rule at a trusted boundary, avoiding verifier-specific guesses. Scheme and host case normalization follow generic rules, but paths and other components can be scheme dependent. Receiver-added alias or display-name repair creates new equivalence from attacker-controlled input. The draft narrows the rule further for decision-sensitive values: canonicalize before issuance or trusted policy comparison, then do not repair peer aliases, case variants, URI variants, or natural-language interpretations in the final acceptance path. “Canonicalize on input” means **apply one deterministic, profile-defined transform at a trusted boundary**, not let the verifier infer convenient meaning.

**Explanation:** RFC 3986 Sections 2.4 and 7.3 require component separation before decoding and say security checks should apply after decoding. Section 5.2.4 defines dot-segment removal for complete path segments. The RFC does not define an A2A storage authorization policy; the profile must bind every enforcement point to one resulting identity. A: A raw-value decision and a decoded backend decision can authorize different resources. B: Repeated decoding can transform literal percent data again and also parses after the dangerous transformation. C: Correct. It preserves URI boundaries, checks the security-relevant value, and prevents backend reinterpretation. D: Encoded octets can become security-significant characters during dereferencing, so a literal-only check is incomplete.

**Explanation:** RFC 3986 Section 7.4 says alternate decimal, octal, and hexadecimal IPv4 forms are outside its URI syntax and warns that platform routines may still accept them. If address filtering is performed, literals should be converted to numeric form and filtered by numeric value, not string prefix or suffix. A: The mismatch between text and resolver semantics is exactly the bypass. B: Successful resolution says nothing about whether the destination is permitted. C: Correct. It aligns accepted syntax and policy with the actual numeric destination. Redirect and name-resolution rechecks are additional application-policy concerns, not rules supplied by RFC 3986. D: A suffix comparison is another representation-dependent string test.

**Explanation:** RFC 3986 Sections 3.2.1, 7.5, and 7.6 place userinfo before the host, deprecate password-like secrets in userinfo, warn that URIs are displayed and logged, and describe misleading userinfo as a semantic attack. The exact rejection and no-secret-URI rules here come from the stated profile threat model; RFC 3986 does not impose a universal userinfo ban. A: Not selected. The host follows @; the earlier text is userinfo. B: Selected. Generic parsing sends the request to attacker.example. C: Selected. It addresses both the display deception and the profile-defined disclosure attack before logging. D: Not selected. Authenticating one host does not establish authority over the userinfo string. E: Not selected. The RFC permits userinfo syntax while warning about its risks and deprecating cleartext passwords.