Re: Further Simplifying the Response in Patch Subset

I prepared a draft PR that demonstrates the spec changes for this proposal:
https://github.com/w3c/IFT/pull/137

On Thu, Feb 16, 2023 at 1:48 PM Garret Rieger <grieger@google.com> wrote:

> I've recently become aware of a proposal by Yoav to add a generic
> compressed dictionary transport for http requests, see:
> https://github.com/yoavweiss/compression-dictionary-transport
>
> Conceptually the proposed static resources flow
> <https://github.com/yoavweiss/compression-dictionary-transport#static-resources-flow> is
> quite close to how patch subset incremental transfer works. In brief this
> proposes that:
>
>    - A http request could include a new header which includes a value
>    that identifies which version of a resource the client already has.
>    - Then the response can use a new content-encoding (eg. brotli shared
>    dictionary compression) which uses the clients existing copy of the
>    resource during decompression.
>
> This got me thinking that it may be a good idea to try and align patch
> subset incremental transfer with how this works. Fortunately, we are not
> very far off. Only two changes would be needed:
>
>    1. Eliminate the PatchResponse message and instead have server send
>    back a brotli or vcdiff compressed diff directly.
>    2. Eliminate the accept_patch_format and patch_format mechanism in
>    favour of using http "content-encoding"/"accept-encoding".
>
> Overall, this builds on the previous work to move client state into the
> font and further simplifies the protocol without sacrificing any
> functionality. Here's a more detailed look at what would change:
>
> *How to handle what's currently in patch response*
>
>    -
>
>    Protocol Version
>    -
>
>       Can be dropped, currently it's just hardcoded to “0”.
>       -
>
>    Patch Format
>    -
>
>       Use the content-encoding header instead.
>       -
>
>    Patch, Replacement
>    -
>
>       The response becomes the patch. The patch vs replacement
>       distinction isn’t actually needed as encoders can easily generate a patch
>       which ignores the existing dictionary. Alternatively it can opt to use just
>       regular brotli content encoding (or another encoding) for the replacement
>       case.
>       -
>
>    Unrecognized Ordering - there are two options:
>    - Use a http status code to signal this case.
>       - Or specify fallback behaviour where the server sends the whole
>       font if the ordering is unrecognized (if we expect this case is
>       rare).
>
>
> *Specification Changes*
>
>    1.
>
>    Drop PatchResponse message specification.
>    2.
>
>    In PatchRequest drop:
>    1.
>
>       protocol_version
>       2.
>
>       Accept_patch_format
>       3.
>
>    In “Handling Server Response” update to instead just treat the
>    response as a patch using the specified content encoding. The “IFT “ magic
>    number is no longer needed as content-encoding will signal if this is a
>    patch or just a full file.
>    1.
>
>       Presence of the client state table in the font signals whether or
>       not there are unrequested codepoints in the family.
>       2.
>
>       Add handling of the unrecognized ordering status code (if we choose
>       this route).
>       4.
>
>    Update the "load a font in a user agent with an http cache" section as
>    needed.
>    5.
>
>    "Responding to PatchRequest":
>    1.
>
>       Update to have the response just be the patch.
>       2.
>
>       Optional: for error handling server can just respond with the full
>       font if it can’t successfully decode the request.
>       6.
>
>    Patch Formats section updated to instead specify the
>    accept-encoding/content-encoding values to use for brotli and vcdiff.
>    7.
>
>    IFT Method Selection: updates may be needed here if it references the
>    four byte magic number.
>
>
>