Skip to main content

Compression Dictionary Transport
draft-ietf-httpbis-compression-dictionary-19

Yes

Francesca Palombini

No Objection

Deb Cooley
Erik Kline
Jim Guichard
Mahesh Jethanandani
Murray Kucherawy

Note: This ballot was opened for revision 09 and is now closed.

Francesca Palombini
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment (2024-08-20 for -12) Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-httpbis-compression-dictionary-12

## Many thanks for writing this document. I found the text not easy to process, mostly because i am not  overly familiar with http compression technologies, and a significant number of abbreviations and acronyms sounded exotic to me. However I do suspect that is normal and that these all of these are understood by the HTTP experts.

## I only got one small suggestion about making the abstract. Feel fre to use or ignore:

11	Abstract
12
13	   This specification defines a mechanism for using designated HTTP
14	   responses as an external dictionary for future HTTP responses for
15	   compression schemes that support using external dictionaries (e.g.,
16	   Brotli (RFC 7932) and Zstandard (RFC 8878)).

[minor]
Making the abstract slightly higher level to explain the benefits of the document. 

"
This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). The proposed method enables the use of pre-shared dictionaries to improve compression efficiency for HTTP responses. By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the negotiation and use of compression dictionaries within the HTTP protocol.
"
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-08-21 for -14) Not sent
I support Roman's DISCUSS.
Mahesh Jethanandani
No Objection
Murray Kucherawy
No Objection
Orie Steele
No Objection
Comment (2024-08-19 for -12) Sent
# Orie Steele, ART AD, comments for draft-ietf-httpbis-compression-dictionary-12 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-12.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comment

### String

```
220	   This document uses the following terminology from Section 3 of
221	   [STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary,
222	   String, Inner List, Token, and Byte Sequence.
```

Consider the following examples: https://url.spec.whatwg.org/#example-5434421b

Am I correct to assume that the matcher would be written against the percent encoded pathname?

For example:

```
var url = new URL("♞", new URL("https://chess.example/"))
```

```
...
Use-As-Dictionary: match="/%E2%99%9E"
```

I think query or "search" as it is referred to in URL Pattern would be handled the same way, for example:

```
new URL("http://www.example.com/düsseldorf?neighbourhood=Lörick")
```

```
...
Use-As-Dictionary: match="/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick"
```

String, is defined in https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-sfbis-06#section-3.3.3 

But given that URL Pattern matches against https://url.spec.whatwg.org/#concept-url 

A few complete examples covering interesting unicode cases would improve the document.
Paul Wouters
No Objection
Comment (2024-08-21 for -14) Not sent
I support Roman's DISCUSS.
Roman Danyliw
(was Discuss) No Objection
Comment (2024-08-23 for -15) Sent
Thank you to Reese Enghardt for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.
Warren Kumari
No Objection
Comment (2024-08-15 for -11) Sent
Thank you for writing this (and helping me understand it :-))

I have two comments:

1: I found:
"4.  If PATTERN has regexp groups then return FALSE."
confusing -- I initially understood this to be regex capturing groups (e.g "I like cheese" -> /.*(c.*se)/ captures 'cheese'). After discussions with Patrick I see that this is actually https://urlpattern.spec.whatwg.org/#dom-urlpattern-hasregexpgroups ...

2: I also found the number of 'dictionary's in "The "match" value is required and MUST be included in the Use-As-Dictionary Dictionary for the dictionary to be considered valid." hard to parse, and I couldn't figure out if the second "Dictionary" should actually have been "dictionary" (is it a [STRUCTURED-FIELDS] term or just a word :-))
Zaheduzzaman Sarker
No Objection
Comment (2024-08-21 for -13) Not sent
Thanks for working on this specification. No objection but supporting Roman's discuss.
Éric Vyncke
No Objection
Comment (2024-08-12 for -09) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-httpbis-compression-dictionary-09

Thank you for the work put into this document. Please note that I am outside my area of expertise when reading this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Mark Nottingham for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Introduction

Suggest adding some (graphical?) explanations on how the technique works. It took me a while (admitting that I am not familiar with the domain) to understand how the headers are used. In other words, it would be nice to present the forest before describing the trees.

## Section 1

Is it "file" or "page/resource" in `Using a previous version of a file as a dictionary for a newer version ` ?

## Section 2.1.3

It is unclear to me how `when the dictionary is advertised as being available` can be verified by the client.

## Section 2.3

I have hard time to fit the example with `The "Dictionary-ID" request header ... MUST be identical to the server-provided "id".` as there is a prefix: `/v1/main.js`. This is of course due to structured field, but it would be nice to explain the structure of this field.

## Section 4

As draft-vandevenne-shared-brotli-format has expired for more than a year (and not even WG adopted), I wonder whether this section is still useful ? I.e., just keep section 5 and remove section 4.

Is there a reason why the lengths of the magic number are different for the two supported compressions ?

## Section 7.1

Suggest referring to the IANA registry by their URI (i.e., https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding) rather than by the RFC that has created them.

## Section 8

Should `middle-boxes` be more descriptive (e.g., web proxies, ...) ?

# NITS (non-blocking / cosmetic)

## Section 2.1.4

Suggest to use double quotes around raw in `and defaults to raw`.

## Section 4

s/fixed 4 byte sequence and a 32 byte hash/fixed 4-byte sequence and a 32-byte hash/ ?

s/Bytes/bytes/ ?