Re: Orie Steele's No Objection on draft-ietf-httpbis-compression-dictionary-12: (with COMMENT)

Thank you. It was a great question because I actually had to do some
research to see how much canonicalization and normalization URLPattern
itself would do to percent-encoded strings. It ended up not mattering too
much because it mostly worked as expected except for a few cases where both
encoded and non-encoded were valid (%20 and an actual space both work
fine). I figured it was best not to call out those few cases and instead
focus on the fact that it is always operating on the percent-encoded
version of URLs (and the match patterns must also be percent-encoded).

Since they are HTTP headers anyway, there's not really any way someone
would have been able to send a raw unicode match string but I added a bit
to the "match" definition to make it clear that the matching and patterns
are all done on the percent-encoded version of the strings and used
the düsseldorf string as an example. I didn't think it would help to add
more richer unicode examples because they wouldn't be able to be
represented in HTTP headers directly anyway but let me know if you think it
still needs a little more clarity.

Draft 13 has the changes:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/13/

On Mon, Aug 19, 2024 at 6:54 PM Orie Steele via Datatracker <
noreply@ietf.org> wrote:

> Orie Steele has entered the following ballot position for
> draft-ietf-httpbis-compression-dictionary-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # 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.
>
>
>
>