Subject: Re: [Wpack] Mirja Kühlewind's Block on charter-ietf-wpack-00-14: (with BLOCK and COMMENT)

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Mar 2020 19:53:13 +0100

Hi Jeffrey, hi all,

The proposed changes work for me and would clarify what’s meant. However, I’m wondering if all these details need to go into the charter but that’s a different questions and nothing I would block on.

Mirja

> On 28. Feb 2020, at 22:32, Jeffrey Yasskin <[email-masked]> wrote:
> 
> On Fri, Feb 28, 2020 at 1:20 PM Jeffrey Yasskin <[email-masked]> wrote:
> On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov <[email-masked]> wrote:
> Hi Mirja,
> 
> I am only replying below to your blocking comments:
> 
> On Thu, Feb 27, 2020, at 3:07 PM, Mirja Kühlewind via Datatracker wrote:
> > Mirja Kühlewind has entered the following ballot position for
> > charter-ietf-wpack-00-14: Block
> > 
> > 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.)
> > 
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/charter-ietf-wpack/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > BLOCK:
> > ----------------------------------------------------------------------
> > 
> > Thanks for all the discussion that happen on the charter so far, unfortunately
> > there are still a few points that are not fully clear to me from a transport
> > perspective:
> > 
> > 1) It not clear to me how you plan to address low latency. I assume you don't
> > want to optimise anything in the lower layers but it does sound a bit like it.
> > Can you clarify this point?
> 
> WPACK is working on a bundle format, so there is no transport protocol here.. Can you suggest how to clarify this?
> 
> We could split this into two requirements:
> 
> >>>>>
> * When a bundle is streamed, the client must be able to start using a subresource before the entire bundle is downloaded, and for large subresources, before the entire subresource is downloaded.
> 
> * When a bundle is loaded from random-access storage, the client must be able to use a subresource without necessarily reading the entire prefix of the bundle before that subresource.
> <<<<<
> 
> I missed the "whether or not the package is authenticated" aspect. That needs something like:
> 
> * When a bundle is authenticated, the client must be able to validate the authentication without extra requests over the network.
>  
> This drives the ability to include certificate chains, SCTs (for certificate transparency), and OCSP responses (for revocation) in the bundle.
> 
> Jeffrey

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Mar 2020 20:06:31 +0100

Hi Jeffrey, hi Alexey,

See inline.

> On 28. Feb 2020, at 22:20, Jeffrey Yasskin <[email-masked]> wrote:
> 
> Those were roughly what I had in mind when I wrote "low latency”.

I replied to this in the other mail. I think this much more clear than just taking about “low latency” (but might be too detailed…?)

> 
> The current format achieves the first by putting the index of subresources at the start of the bundle (unlike ZIP) and by using https://tools.ietf.org/html/draft-thomson-http-mice-03 to protect subresource integrity.
> 
> It achieves the second by having an index (unlike multipart/*).
> 
> > 2) I think "Being extensible and crypto agile" is a requirement we have for any
> > protocol we design. Is there anything special here, or why is this listed?
> 
> Nothing special in this case, but in order to avoid any doubts.

Actually I will not block on this one. But given the charter is already collecting a bunch of very different requirement on different level, maybe take this out of the list and rather add a sentence at the end…

> 
> > 3) I also don't really understand this point
> > "Specifying constraints on how clients load the formats without describing
> > specific loading algorithm to help achieve the above goals"
> > Can you further explain? I assume there are no transport implications here but
> > as I'm not sure what is meant, I'd like to double-check!
> 
> No transport implications. By "load" this means from disk/web browser cache. Does this help?
> 
> See also the discussion on the IESG list under "WG Review: Web Packaging (wpack)" and at https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/.

Looking at that mail, maybe it would more appropriate to talk about "security constrains” instead of only “constrains". For me it would also help if the word browser would show up in the sentence e.g. “with specifying algorithm for the brewers on how to load the format”.

However, again I find the chosen format of using bullet points only instead of text (at least for the main goals) not really reader-friendly...

> 
> > 4) Again here I'm not sure what is meant and I assume you don't plan for any
> > transport protocol changes or extension but double-checking! "Optimize
> > transport of large numbers of small same-origin resources." What does this
> > mean? What's the solution you have in mind?
> 
> I might need Jeffrey's help to reply to this one. I am pretty sure there are no transport protocol implications.
> 
> This was about improving compression by letting the compression algorithm keep state across many resources. There have also been a few attempts to get the same benefits in HTTP directly, whose difficulties have led to https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00.

It would really help me if this would say anything about compression rather than just “optimising transport”…

Thanks!
Mirja

> 
> Thanks for the transport-oriented review!
> 
> Jeffrey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 04 Mar 2020 19:12:54 +0000

Hi Mirja,
Just replying to your point #4 below:

> rather than just “optimising transport”…

I've changed that to read:

 Optimize storage of large numbers of small same-origin resources (e.g. using compression)

Hopefully this is clearer.

Best Regards,
Alexey

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Mar 2020 20:14:55 +0100

Thanks!

> On 4. Mar 2020, at 20:12, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Mirja,
>>> On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov <aamelnikov@fastmail..fm> wrote:

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 04 Mar 2020 19:21:08 +0000

Hi Mirja,

I addressed your point #1 as per Jeffrey's suggestions. You agreed no changes for #2. #4 was addressed in my previous email.

Replying to your remaining point #3 below:

> Looking at that mail, maybe it would more appropriate to talk about 
> "security constrains” instead of only “constrains". 

I am not sure that only security constrains are intended here.

> For me it would 
> also help if the word browser would show up in the sentence e.g. “with 
> specifying algorithm for the brewers on how to load the format”.

We do have other HTTP clients which are not browsers, so I think saying browser above would be too restrictive...

> However, again I find the chosen format of using bullet points only 
> instead of text (at least for the main goals) not really 
> reader-friendly...

Best Regards,
Alexey

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Mar 2020 20:51:27 +0100

Hi Alexey,

I just cleared my block. Thanks for the additional edits and explanations!

I hope these latest changes do help to make thing clearer for any potential future charter-based discussions during the wg’s life time!

Mirja

> On 4. Mar 2020, at 20:21, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Mirja,
> 
>> specifying algorithm for the brewers on how to load the format”..
>