Artart last call review of draft-ietf-httpbis-compression-dictionary-16

Reviewer: Darrel Miller
Review result: Almost Ready

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

Received on Sunday, 25 August 2024 19:51:48 UTC