Subject: Consensus Call on issues closed by the -03 drafts

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 May 2017 17:56:22 +1000

Everyone,

The -02 drafts incorporate the proposed resolutions to another group of issues, as listed below. 

Please have a look through them. If there are any resolutions that you feel need more discussion, please bring it up, either here on the mailing list or by commenting on the issue itself. In either case, please explicitly ask for the issue to be re-opened if you want it to be reconsidered.

If folks do this before the Paris interim, we can hopefully have any necessary discussions before or during the meeting, allowing us to publish the First Implementation Draft afterwards, incorporating any changes needed.

See <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving-issues> for a reminder about the process we're using here. Even when we have consensus, we can reopen an issue if new information emerges (and that can take a variety of forms).

This list is also available at <https://github.com/quicwg/base-drafts/issues?page=2&q=is%3Aissue+is%3Aclosed+-label%3Aduplicate+-label%3Aeditorial+-label%3Ahas-consensus&utf8=✓>.

* #543: Reduce the number of different offset sizes for STREAM   (transport)
* #542: Don't include timestamps until after the handshake completes   (transport)
* #513: Create more certainty about 0-RTT transport parameters   (transport)
* #481: FNV-1a 64   (transport)
* #451: No rules limit the sending of BLOCKED   (transport)
* #443: Split WINDOW_UPDATE   (transport)
* #442: Invert the connection ID logic during the handshake   (transport)
* #439: Unclear stream close semantics   (transport)
* #434: PADDING Frame performance   (transport)
* #432: Specify what concurrent stream limit protects   (transport)
* #425: Do not require clients to reset initial streams   (transport)
* #419: Get rid of the concurrent stream limit by advertising a maximum stream ID   (transport)
* #405: Transport parameter that limits 0-RTT data   (transport tls)
* #388: Timestamps in acknowledgment of PING?   (transport)
* #370: Out-of-order Flow Control   (transport)
* #344: Justify retransmitting handshake packets so slowly   (recovery)
* #294: Ignore version negotiation if the client version is present   (transport)
* #284: Ignore Version Negotiation if it was already done   (transport)
* #267: Server enforcement of 1280 octet packet size   (transport)
* #265: Define source address validation in the transport   (transport)
* #264: Define how source address validation interactions with TLS work   (transport tls)
* #263: Counting closed streams against the concurrent stream limit   (transport)
* #248: Exemption from congestion control   (transport recovery)
* #241: What do we do if special packets are lost   (transport)
* #237: Create a firm recommendation on when to send WINDOW_UPDATE   (transport)
* #232: New connection ID message   (transport)
* #227: Encrypt the initial cleartext packets with a deterministic key   (transport)
* #217: Packet reordering / loss distorts open stream limits   (transport)
* #200: Race condition between stream creation and MSPC   (transport)
* #199: Why are reason phrases potentially 65k long?   (transport)
* #194: Frames should have a length field   (transport)
* #181: Remove SETTINGS[_ACK]   (transport http)
* #167: Hash for unencrypted packets   (transport tls)
* #158: Padding between frames   (transport)
* #143: Repeating Version Negotiation   (transport)
* #134: Certificate compression   (transport tls)
* #123: ACK frame timestamp format   (transport)
* #89: Version negotiation gaps   (transport)
* #60: Stateless Reject mechanism needs description   (transport tls)
* #55: What can change in a different version   (transport)
* #45: Handshake protocol selection   (transport)

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 May 2017 09:56:26 +1000

> On 22 May 2017, at 5:56 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
> 

That's -03, of course.