Address HTTPDIR review feedback and add structured partition keys

[darrelmiller]

This PR addresses feedback from Lucas Pardue's HTTPDIR early review and introduces structured partition keys.

Key Changes

New Features

• RateLimit-Partition header field - declares partition dimensions as parameters on policy identifiers, with fixed-value filtering support
• Partition key construction rule - dimensions sorted alphabetically, UTF-8 values concatenated with 0x1F (Unit Separator)
• Cost parameter (c) on RateLimit field - reports quota units consumed by the request
• Wire parameter rename: r to a (available quota), t to w (effective window)

IANA Registries (5 new)

• RateLimit-Policy Parameters (q, qu, w, pk)
• RateLimit Parameters (a, w, pk, c)
• RateLimit-Partition Parameters
• RateLimit Partition Key Dimensions (user_id, client_id, method)
• RateLimit Quota Units (pre-existing, formalized)

Structural

• Merge Notational Conventions + Terminology into single section
• Move Problem Types after Client Behavior
• Rewrite Quota Partitions section with motivation-first prose

Editorial (29 of 37 HTTPDIR comments addressed)

• Remove dead Origin import, fix SF reference style, add missing SF terms
• Pluralize intro summaries, replace resource server with server
• Upgrade should be careful to SHOULD avoid for redirects
• Relax intermediary text, replace unenforceable MUST NOT
• Replace vendor-prefix guidance with parameter registries

Remaining items for follow-up

• Client guidance for fields in trailers (Describe RateLimit-Remaining using structured-field-values #22)
• Consider trimming Appendix A ("[RFCxxxx] section yyy" notation #4/Improve the description of Missing Remaining information. #37)
• Clarify SHOULD consistency applies to servers (Reference gh-pages #17)
• Define glob matching for future path dimension

Resolves #161, #162. Incorporates #163, #164.

[ioggstream]

Suggested change

	These fields enable servers to communicate complex rate limiting policies, including using multiple and variable time windows and dynamic quotas, and implementing concurrency limits. This information helps improve the resiliency of HTTP infrastructure by providing clients with the information needed to throttle their requests and avoid 4xx or 5xx responses.
	These fields enable servers to communicate complex rate limiting policies, including using multiple and variable time windows and dynamic quotas, and implementing concurrency limits. This information helps improve the resiliency of HTTP infrastructures by providing clients with the information needed to throttle their requests and avoid 4xx or 5xx responses.

[ioggstream]

Suggested change

	: A quota unit is the unit of measurement used to measure the activity of a client.
	: A quota unit is the unit of measurement for the activity of a client.

[ioggstream]

1. explain the reason for consistency :)

Suggested change

The "RateLimit-Policy" field enables clients to pace their requests based on policy information provided by the server. The field value SHOULD remain consistent over a sequence of HTTP responses, as policy information is not expected to change frequently. Situations where throttling constraints are highly dynamic are better served using the RateLimit field ({{ratelimit-field}}) that communicates the latest service information a client can react to. Both fields can be communicated by the server when appropriate.

The "RateLimit-Policy" field enables clients to pace their requests based on policy information provided by the server. The field value SHOULD remain consistent over a sequence of HTTP responses, changes would prevent clients from correctly following the communicated policy. Situations where throttling constraints are highly dynamic are better served using the RateLimit field ({{ratelimit-field}}) that communicates the latest service information a client can react to. Both fields can be communicated by the server when appropriate.

[ioggstream]

Maybe going full normative.

Suggested change

Servers SHOULD avoid returning RateLimit header fields in redirection responses (i.e., responses with 3xx status codes) because a low available quota could prevent the client from following the redirect. For example, given the RateLimit header fields below, a client could decide to wait 10 seconds before following the "Location" header field (see {{Section 10.2.2 of HTTP}}), because the available quota is 0.

Servers SHOULD NOT return RateLimit header fields in redirection responses (i.e., responses with 3xx status codes) because a low available quota could prevent the client from following the redirect. For example, given the RateLimit header fields below, a client could decide to wait 10 seconds before following the "Location" header field (see {{Section 10.2.2 of HTTP}}), because the available quota is 0.