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

[Mirja Kuehlewind <[e-mail]>]

Hi Jeffrey, hi Alexey,

See inline.

> On 28. Feb 2020, at 22:20, Jeffrey Yasskin <[e-mail]> wrote:
> 
> On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov <[e-mail]> 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.
> <<<<<
> 
> 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