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

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:

> ### 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?

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?

"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 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"?

Thanks,

-Pat

On Sun, Aug 25, 2024 at 3:51 PM Darrel Miller via Datatracker <
noreply@ietf.org> 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
>
>
>