I am the assigned Art-ART reviewer for this draft. The General Area
Review Team (Art-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

In general this document is well written and its value is clear from the use cases provided. I think capability has the potential to have a significant impact on the HTTP API ecosystems as well as browser user agents.

I do not see any major issues with the document as written, but there are some areas that I think could be improved to address a broader audience.

## 1.  Introduction

It states that the document registers media types for content encoding Brotli and Zstandard, however there are no media type registrations in the document.  There are however registrations for content encoding values.

### 1.1.2 Common Content

The example suggests that the first request returns app.v1.js which is from the previous example.

### 2.1.1 match

It is concerning that a feature such as this requires taking a dependency on the URL Pattern specification which is a living standard. In the HTTP API space, there are many user agents that are not browsers, that will need to implement URL Pattern and that specification could change at any time.  It would be much preferable if this specification could take a snapshot of the current URL Pattern behavior and define that in this specification.

### 2.1.2 match-dest

It is unclear why match-dest would not be a IANA registry of values that are seeded with the values from the Fetch specification. This would allow for values to be added to the registry in order to support the same concept in different user agents that do not use the Fetch specification.  It seems strange to only allow this feature to be used if the Fetch specification is being used to make requests. Is the destination feature not useful to a broader audience?

### 2.1.4 type

It is not obvious what the value of this property is.  It has only one value "raw", which is the default value which is described as an "unformatted blob of bytes". It is stated that if a client receives a dictionary of a type that it does not understand, it must not use the dictionary. But type has only one value. How can any other value be returned and be compliant with this specification? There is no described mechanism of how other values for type could be introduced.

Said another way, what is lost if we drop this section 2.1.4 completely?

#### 2.1.5.2 versioned directories

The use of the term directory here seems to be making some assumptions about the implementation. Would the more generic term "segment" be more appropriate?


### 2.2.2 Dictionary URL matching

The first paragraph infers that both "match" and "match-dest" strings are stored with the dictionary. However, "match-dest" is indicated as optional in the Use-As-Dictionary header.  Is it required that the client maintain the match-dest as an empty array of strings if not provided by the server?

Is the provided algorithm normative?  The reason I ask is because the paragraph

> Dictionaries MUST have been served from the same Origin (Section 4.3.1 of [HTTP]) as the outgoing request to match.

and the following steps seem duplicative. 

> Let BASEURL be the URL of the dictionary request.
> Let URL represent the URL of the outbound request being checked.
> If the Origin of BASEURL and the Origin of URL are not the same, return FALSE.

Is it sufficient to read the prose to understand all the constraints, or is it necessary to read the algorithm as well?

#### 2.2.2 step 7

The instructions suggest to run the "test" method.  Looking at the URL Pattern specification it is not immediately clear what the behaviour of the "test" method is. There is a test method defined in some IDL, but it does not reference any defined behaviour.  Looking at the section "High Level Operations" it might be reasonable to assume that the "test" method implements the "match" operation.  It would be helpful to clarify this in the specification. 

## 6

> When a compression dictionary is available for use for a given request,

The wording here suggests that a compression dictionary may be usable for compressing a request payload. It is my understanding that is not the case.  Perhaps the wording could be changed to "When a compression dictionary is available for use compressing the response to a given request,"?


Thanks,

Darrel