Subject: Getting to a First Implementation Draft

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 May 2017 14:53:48 +1000

Previously, we've mentioned an intention to have a First Implementation Draft -- that is, an Internet-Draft that we feel is suitable for implementers to write code to, for the purposes of interoperability testing and gathering feedback -- shortly after the Paris interim.

Due to the size and complexity of HTTP-over-QUIC, implementing all four drafts for this purpose on a reasonable timeline isn't workable.

Instead, the editors have identified a subset of functionality that they believe will serve as a suitable starting point. See:
  https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft

They've also identified the set of issues that we believe will be necessary to have proposals for before Paris; see:
  https://github.com/quicwg/base-drafts/milestone/1

If all goes well, the plan is to have a set of drafts out (very) soon that do so; then, we can discuss them and the First Implementation Draft Candidate in the lead-up to and during the Paris interim.

After Paris, we'll make any necessary adjustments to the documents and publish another set, which will be the First Implementation Draft.

Please comment / raise concerns / make suggestions on-list. 

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 May 2017 11:54:30 -0700

A few comments on this proposed list:

> Integration with TLS 1.3 handshake - The basic 1-RTT mode must be
> supported. TLS exporters are not needed, nor are session
> tickets. Basic key exchange is sufficient and implementations can
> use any certificate. All MTI algorithms listed in TLS 1.3 are
> expected.

I note that this and the transport parameters and HRR stuff below
necessitate the generic changes to the TLS library to permit adding
extra extensions. I wonder if it might make life better to just have a
canned set of parameters for now. It's not that it's a lot of work,
it's just that it's not critical path otherwise.

> Packet protection - All post handshake packets must be sent with
> 1RTT keys and packet protection.

This is inconsistent with not requiring exporters above. As far
as I can tell, if you're not doing NST, you don't need post-handshake
packets anyway here, so you can probably skip this.

On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham <[email-masked]> wrote:

> Previously, we've mentioned an intention to have a First Implementation
> Draft -- that is, an Internet-Draft that we feel is suitable for
> implementers to write code to, for the purposes of interoperability testing
> and gathering feedback -- shortly after the Paris interim.
>
> Due to the size and complexity of HTTP-over-QUIC, implementing all four
> drafts for this purpose on a reasonable timeline isn't workable.
>
> Instead, the editors have identified a subset of functionality that they
> believe will serve as a suitable starting point. See:
> They've also identified the set of issues that we believe will be
> necessary to have proposals for before Paris; see:
> If all goes well, the plan is to have a set of drafts out (very) soon that
> do so; then, we can discuss them and the First Implementation Draft
> Candidate in the lead-up to and during the Paris interim.
>
> After Paris, we'll make any necessary adjustments to the documents and
> publish another set, which will be the First Implementation Draft.
>

---

From: Patrick McManus <[email-masked]>
Date: Sun, 14 May 2017 14:11:28 -0400

I don't really know how I feel about this wiki page.. without ratholing too
deeply on it I think that while it tries to facilitate testing and interop,
it treads pretty significantly into the land of project management which is
squarely out of bounds for the working group. I'm willing to see how it
goes but that's my concern - I would rather the WG focuses on the complete
picture while providing more of a forum for pair (or more) wise testing.

anyhow wrt specifics -  ekr points out the 2 major inconsistencies.. tbh I
would require exporters and the ability to do at least one non-0 stream. At
that point you have a hello world milestone, which is always the first
stage worthy of a toast. Its ok by me if the transport params are just
profiled.

On Sat, May 13, 2017 at 2:54 PM, Eric Rescorla <[email-masked]> wrote:

>> If all goes well, the plan is to have a set of drafts out (very) soon
>> that do so; then, we can discuss them and the First Implementation Draft

---

From: Ian Swett <[email-masked]>
Date: Sun, 14 May 2017 16:23:04 -0400

Fixing the transport parameters sounds like a good simplification to me.

I pushed for transferring some information with the 1RTT keys in a late
draft, which likely resulted in the inconsistency.  My logic is that you
haven't really shown the handshake works unless you use the output of it.

Transferring data on a non-0 stream requires an application of some sort.
Do you have any suggestions for what that would be?  Or were you thinking
something of simple like "ping" and "pong"?

On Sun, May 14, 2017 at 2:11 PM, Patrick McManus <[email-masked]>
wrote:

> I don't really know how I feel about this wiki page.. without ratholing
> too deeply on it I think that while it tries to facilitate testing and
> interop, it treads pretty significantly into the land of project management
> which is squarely out of bounds for the working group. I'm willing to see
> how it goes but that's my concern - I would rather the WG focuses on the
> complete picture while providing more of a forum for pair (or more) wise
> testing.
>

---

From: Patrick McManus <[email-masked]>
Date: Sun, 14 May 2017 16:39:32 -0400

On Sun, May 14, 2017 at 4:23 PM, Ian Swett <[email-masked]> wrote:

> Or were you thinking something of simple like "ping" and "pong"?
>

yep.

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 14 May 2017 14:43:46 -0700

Adding a PING frame + ACK seems like a good idea.

---

From: Lucas Clemente <[email-masked]>
Date: Mon, 15 May 2017 08:02:03 +0000

Another idea would be to just have a single stream and "emulate" TCP+TLS
using that. We used something similar
<https://github.com/marten-seemann/quic-conn> in the past to refine our
API, and this gave us a lot of input for that.

This would probably add flow control to the scope, unless we just manually
set the window to something huge for these initial tests.