Thanks for the review. I'll work up a draft with the suggested edits but there were a few points that probably need more discussion:
> 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.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.
There was a LOT of bikeshedding on the match pattern. It was originally a custom algorithm that only allowed for wildcard but between the w3c and HTTP working groups we came to a consensus that standardizing on URL Pattern was a better solution, even for non-browser clients. There are already rust and js-based libraries and the expectation is that we are going to converge on using it for pattern matching in a lot more cases and that there will be libraries available for most platforms to make integration easier.
As far as taking a snapshot, this was discussed during the IESG telechat but the standard practice for referencing the living standards is to not reference a snapshot and that the standard maintainers are responsible for maintaining backward compatibility. The same goes for the references into the fetch spec.
> ### 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?
>
> 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?
At some level the set of destinations needs to be maintained in such a way that even an IANA list would not contradict the list in the Fetch standard as the Fetch standard evolves. That would involve keeping them in sync in such a way that additions to either list don't collide with the other. Fundamentally that would mean that either an IANA registry would need to reference Fetch and maintain additional destinations or that Fetch would need to defer to an IANA registry. At some level it is not that different from the registry of link relation types. I'd be ok with requesting a new IANA registry if everyone thinks that's the right path but I'm also a bit worried if the w3c side would agree that deferring registration of fetch destinations to IANA was appropriate.
To some extent, the CORS processing also requires a fetch-like client (or for the client to not be sensitive to CORS).
Would it be better if I make the match-dest matching optional on the client even if it is specified in the response? The intent is for it to be compatible in that the client will advertise dictionaries but it is up to the server to decide to use it or not so if the additional filtering provided by match-dest isn't applied and the client advertises an inappropriate dictionary, it would just be ignored.
> ### 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?
>
> 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?
"type" is there for future-looking backward compatibility. For example, Brotli and ZStandard both have encoding-specific dictionary formats that provide some more capabilities. If, at some point in the future, a spec decides to use the same dictionary negotiation for one of those types, using an unknown "type" would allow existing clients to ignore the formats that they do not understand. Otherwise, any future specs would have to use a new set of headers entirely (which is an option but would be duplicating a lot). Since the same response would never be two different types of dictionary, having an optional value that allows for forward/backward compatibility felt like a low bar.
> #### 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.
>
> 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.
The PATTERN in the algorithm is explicitly an instance of the URLPattern class which has the "test" method and operation defined: https://urlpattern.spec.whatwg.org/#dom-urlpattern-test
Should I be referencing it in another way to be clear that that is the IDL that it is referencing and that the method steps are in the URLPattern spec (or for clarity of reading, just a bit more text to "run the 'test' method which executes the URL matching algorithm"?
Should I be referencing it in another way to be clear that that is the IDL that it is referencing and that the method steps are in the URLPattern spec (or for clarity of reading, just a bit more text to "run the 'test' method which executes the URL matching algorithm"?
Thanks,
-Pat
On Sun, Aug 25, 2024 at 3:51 PM Darrel Miller via Datatracker <noreply@xxxxxxxx> wrote:
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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
