Re: New Second Implementation Draft

Martin Duke <martin.h.duke@gmail.com> Tue, 25 July 2017 22:39 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75810131FB9 for <quic@ietfa.amsl.com>; Tue, 25 Jul 2017 15:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIybSniHMKCx for <quic@ietfa.amsl.com>; Tue, 25 Jul 2017 15:39:11 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F31131F36 for <quic@ietf.org>; Tue, 25 Jul 2017 15:39:09 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id t201so57644423wmt.1 for <quic@ietf.org>; Tue, 25 Jul 2017 15:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ELSGvpixSZbcr2foZFyUu6yIRQGdsW8xswfBOVJ6stc=; b=d1xVrVxbCBcHGBwHI7bMEunXnwwjm6pPgE3rhQp1nrR6HFc2OKW8JN6l3ft4tyhuvz Ywsw12tXpbmS6d6ZSg6N7cWAb2BsEJxmJcd5EQvVNzRiwiXRBgu7R20Y2RtQAuLd1d8L HoQ6GFQy2EStRZjM0Z5Z3v1o2Tm2KOCxJa/mHuXhPmjo7sxbDf2ZJ51KFF9nX/elNiAJ CiAQFPXPK1R1yrNZCP7yrgSGEDvEV4wugxBnuG4FScVlSyY5d9K+wApfcwbVwm0VFe27 97BKRpFNqBxVvqippZ3ztUqO2YLUtQRjtze/MU3tpk2dYalBQ3BhzB4PzQRN+rAZLBH8 2E+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ELSGvpixSZbcr2foZFyUu6yIRQGdsW8xswfBOVJ6stc=; b=XdwPrCu67AtpXefSfWGqYw+/s9g9564vFvCuZqHQAMOanFs6EVohTiB9NKSTQUAIeI G9Sp2VimT70/8U+JeX8nl7pN1VvyJafNkXH46LhVNyWC5i/kA8BZm5G971IaKi6K7V8L Q7GKMKb6UqV0yZLkHFWliYVBURfjwe58essrnvcvnmR1/oRaA4V7dNQW/RcJuuD021CY EmwfB+fZS0aDg8aInT6zBUIzzZslp6FTYCxRtRHAKk2lTDQWr2mvMBDl29QJNqmwFfTN 7LhBFCBUcY2EEZb8RuXs1uNWFkFo+1ZMXZHaEc8ifklAFgwN8FSeXayDe+hi5B0foyDw cPig==
X-Gm-Message-State: AIVw110SBC9aHe1oXqXUibv/ISWcQJSGu4jyMua7tcDY9F6PkSghM5FA Xj1xIQ9PqdMRo429HtSRQ1E1b2XVGFtC
X-Received: by 10.28.11.212 with SMTP id 203mr9840381wml.105.1501022348400; Tue, 25 Jul 2017 15:39:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.119 with HTTP; Tue, 25 Jul 2017 15:39:07 -0700 (PDT)
In-Reply-To: <CABcZeBNB5RFXYWOXa8-_nO5LYoTmXzprzAHNh1XqdESOo_b-ng@mail.gmail.com>
References: <CAM4esxSYekUaQ_vr6RnmeS2ZePzPyaAwUjy201qBTZHHrpuwtA@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A37748A01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A37748A51@bgb01xud1012> <CABkgnnWYwd9Kc4XSB=uf2uvxRWcJEpEZfw9A7PVgmDnmXpFa9g@mail.gmail.com> <CABcZeBNc3vWnY7Bn=KeERMHOptX16=aievVmvj61MxqwOOf61w@mail.gmail.com> <CAOdDvNph_dd1MGSAJFoA+T8KTj6=ms2T78PXjqUz_9htymqEtg@mail.gmail.com> <MWHPR21MB0141E6CD40B97385610701E887BB0@MWHPR21MB0141.namprd21.prod.outlook.com> <MWHPR21MB01412439AD2FA29B1E9F648C87B80@MWHPR21MB0141.namprd21.prod.outlook.com> <CABcZeBNB5RFXYWOXa8-_nO5LYoTmXzprzAHNh1XqdESOo_b-ng@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 25 Jul 2017 15:39:07 -0700
Message-ID: <CAM4esxT3n9tKWekdHWrcfi5B+ESzw5+niHe9V0zKHVjseehJBg@mail.gmail.com>
Subject: Re: New Second Implementation Draft
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, Lucas Pardue <Lucas.Pardue@bbc.co.uk>, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114450cee061eb05552bffd5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7oGtofs-A93hMtTn_51QvZfrBgk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2017 22:39:13 -0000

I think the ID1 group has to reach consensus they are at the point of
diminishing returns, whenever that may be. If anyone wants to get ahead,
this is the stuff to tackle.

On Tue, Jul 25, 2017 at 1:34 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
> On Tue, Jul 25, 2017 at 1:03 PM, Mike Bishop <Michael.Bishop@microsoft.com
> > wrote:
>
>> Just so we’re on the same page – this set of “Second Implementation
>> Draft” targets is for Seattle?  Or some future date?
>>
>
> I had previously understood ID2 to be for Singapore. Given the somewhat
> rickety state of the implementations I saw in PRG, I think it might be
> better to get them solid in SEA rather than rickety but more full
> featured...
>
> -Ekr
>
>
>>
>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mike Bishop
>> *Sent:* Sunday, July 23, 2017 10:21 PM
>> *To:* Patrick McManus <pmcmanus@mozilla.com>; Eric Rescorla <ekr@rtfm.com
>> >
>> *Cc:* Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>;
>> Martin Thomson <martin.thomson@gmail.com>; Martin Duke <
>> martin.h.duke@gmail.com>
>> *Subject:* RE: New Second Implementation Draft
>>
>>
>>
>> I’d follow precedent – http/1.1 is already defined, so why not http/0.9?
>>
>>
>>
>> I’d also like to mention that my wife is particularly fond of the paint
>> color “Rhino” for the associated bikeshed.  😉
>>
>>
>>
>> *From:* QUIC [mailto:quic-bounces@ietf.org <quic-bounces@ietf.org>] *On
>> Behalf Of *Patrick McManus
>> *Sent:* Friday, July 21, 2017 3:53 AM
>> *To:* Eric Rescorla <ekr@rtfm.com>
>> *Cc:* Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>;
>> Martin Thomson <martin.thomson@gmail.com>; Martin Duke <
>> martin.h.duke@gmail.com>
>> *Subject:* Re: New Second Implementation Draft
>>
>>
>>
>> its a good idea that needs a bikeshed. hq-nop would be my preference
>> (stay in the hq namespace)..
>>
>>
>>
>> On Fri, Jul 21, 2017 at 12:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> h09q-05? :)
>>
>>
>>
>> On Fri, Jul 21, 2017 at 2:27 AM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>> Do we need a permanent ALPN token for this?  It seems like a useful
>> facility to build into stacks that are transport-only.  Maybe "h09q".
>>
>>
>> On 21 July 2017 at 10:00, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
>> > I appreciate the flexibility but have difficulty in seeing how this
>> would
>> > flow through to interop testing, how do we measure success? One possible
>> > outcome is interop limited to self-test of “bespoke-simple-app” over
>> QUIC,
>> > is that good enough? My preference is to pick a minimal baseline (“echo
>> and
>> > amplify” or whatever else) and then additionals are a bonus that is up
>> to
>> > external coordination. I think this common baseline could also help
>> towards
>> > ongoing consideration for performance or benchmarking, over disparate
>> > implementations, as aspects of the protocol evolve or change.
>> >
>> >
>> >
>> > The proposal to do HTTP 0.9 GET, discussed in Prague, addresses my
>> concerns.
>> >
>> >
>> >
>> > Lucas
>> >
>> >
>>
>>
>>
>>
>>
>
>