Subject: Re: [quicwg/base-drafts] Define INITIAL_PRIORITY frame and remove exclusive dependencies (#2075)

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 12:45:25 -0800

LPardue commented on this pull request.

> @@ -825,6 +821,70 @@ MUST be treated as a connection error of type HTTP_MALFORMED_FRAME.
 A server MUST treat a MAX_PUSH_ID frame payload that does not contain a single
 variable-length integer as a connection error of type HTTP_MALFORMED_FRAME.
 
+### INITIAL_PRIORITY {#frame-initial-priority}
+
+The INITIAL_PRIORITY (type=0x0F) frame specifies the client-advised priority of

To maintain consistency with PRIORITY frame, you could use "sender-advised priority". Language elsewhere qualifies that the only sender that is allowed is a client.

or,

change it to client-advised in PRIORITY

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180576979

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 12:51:58 -0800

+### INITIAL_PRIORITY {#frame-initial-priority}
+
+The INITIAL_PRIORITY (type=0x0F) frame specifies the client-advised priority of
+a new stream.  INITIAL_PRIORITY frames MAY be sent as the first frame of a
+request stream, and MUST NOT be sent thereafter or on other streams.  An
+INITIAL_PRIORITY frame sent on a non-request stream MUST be treated as a
+connection error of type HTTP_WRONG_STREAM.  An INITIAL_PRIORITY frame received
+after other frames or received by a client MUST be treated as a stream error of
+type HTTP_UNEXPECTED_FRAME.

Suggestion to break this out

INITIAL_PRIORITY frames MAY be sent as the first frame of a
request stream and MUST NOT be sent thereafter. An INITIAL_PRIORITY 
frame received after other frames MUST be treated as a stream error of
type HTTP_UNEXPECTED_FRAME.

INITIAL_PRIORITY frames sent on a non-request stream MUST be treated as a
connection error of type HTTP_WRONG_STREAM. 

INITIAL_PRIORITY frames received by a client MUST be treated as a stream error of
type HTTP_UNEXPECTED_FRAME.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180577222

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 13:02:33 -0800

+~~~~~~~~~~  drawing
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|DT |   Empty   |           Element Dependency ID (i)         ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   Weight (8)  |
++-+-+-+-+-+-+-+-+
+~~~~~~~~~~
+{: #fig-initial-priority title="INITIAL_PRIORITY frame payload"}
+
+The INITIAL_PRIORITY frame payload has the following fields:
+
+  Dependency Type:
+  : A two-bit field indicating the type of element being depended on.

One alternative would to have a static two-bit field that is always set to the value of `11`. There's no extra overhead since there's unused reserved bits.

However, I like @kazuho's proposal and think there is room to extend it further.

The PRIORITY frame definition says that 

> Element Dependency ID: A variable-length integer that identifies the element on which a dependency is being expressed. Depending on the value of Dependency Type, this contains the Stream ID of a request stream, the Push ID of a promised resource, the Placeholder ID of a placeholder, or is ignored.

IIUC the ignored case properly, wouldn't it be more efficient to make the EDID (chuckle, not [this one](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data)) optional too, based on the prioritisation type. I.e. if the dependency is root of the tree, don't send an ID.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r238114436

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 13:08:42 -0800

+The INITIAL_PRIORITY frame payload has the following fields:
+
+  Dependency Type:
+  : A two-bit field indicating the type of element being depended on.
+
+  Empty:
+  : A six-bit field which MUST be zero when sent and MUST be ignored
+    on receipt.
+
+  Element Dependency ID:
+  : A variable-length integer that identifies the element on which a dependency
+    is being expressed. Depending on the value of Dependency Type, this contains
+    the Stream ID of a request stream, the Push ID of a promised resource, the
+    Placeholder ID of a placeholder, or is ignored.  For details of
+    dependencies, see {{priority}} and {{!RFC7540}}, Section 5.3.

No I'm confused by this EDID. The frame is only applicable to request streams, so I think the EDID would always equal stream ID. It seems redundant to send this information twice.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180577886

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 13:10:57 -0800

+    dependencies, see {{priority}} and {{!RFC7540}}, Section 5.3.
+
+  Weight:
+  : An unsigned 8-bit integer representing a priority weight for the stream (see
+    {{!RFC7540}}, Section 5.3). Add one to the value to obtain a weight between
+    1 and 256.
+
+An INITIAL_PRIORITY frame identifies an element upon which the current request
+stream depends at creation.  The values for the Dependency Type and Element
+Dependency ID have the same interpretation as in the PRIORITY frame (see
+{{frame-priority}}).
+
+When an INITIAL_PRIORITY frame claims to reference a request, the associated ID
+MUST identify a client-initiated bidirectional stream.  A server MUST treat
+receipt of PRIORITY frame with a Stream ID of any other type as a connection

s/PRIORITY frame/INITIAL_PRIORITY frame

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180577984

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 13:21:28 -0800

No wondering if it would it be clearer to say:

INITIAL_PRIORITY frames are OPTIONAL. When used, the frame MUST be sent as the first frame of a request stream. An INITIAL_PRIORITY frame received after other frames MUST be treated as a stream error of type HTTP_UNEXPECTED_FRAME.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r238115169

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 02 Dec 2018 13:23:21 -0800

LPardue approved this pull request.

I think the general theme of the PR is good. I've made some minor suggestions. 

The big question is: new frame or rework existing PRIORITY frame. I'll see how that conversation develops.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180578447

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 12:16:56 -0800

I considered making it part of either HEADERS or simply a stream header like the Push ID, since it MUST always come first.  My reasoning was that, since it's not always going to be used, a stream header would be overkill.  The conditional presence in HEADERS in H2 was based on flags, which we don't have any more 😳, so that seemed to present its own problems, plus the restriction that it only appear on the *first* HEADERS of a stream.  It seemed simpler to restrict those semantics to their own frame type.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-443854701

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 12:21:07 -0800

MikeBishop commented on this pull request.

+~~~~~~~~~~  drawing
+ 0                   1                   2                   3

That actually could combine nicely -- rather than `11` meaning "the root of the tree," it means "the current stream," and we keep the restriction that reprioritizing the root of the tree is illegal.  So `11` means this stream when it's send on a request, but means the root when it's sent on the control stream.

I was trying not to have conditionally-present fields, but if folks are okay with that, I could try that variant.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r238422650

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 12:56:31 -0800

@MikeBishop pushed 1 commit.

ca27124  Re-merge INITIAL_PRIORITY and PRIORITY, per Kazuho and Lucas

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/1272e576646e4466bf7044318de22eb7afb7ab7f..ca2712427502676e72329b61c95643281c2cdc30

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 13:07:24 -0800

dfcbd5fe5ff10d2f030882b17d261415567e38b0  Rework error layout

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/ca2712427502676e72329b61c95643281c2cdc30..dfcbd5fe5ff10d2f030882b17d261415567e38b0

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 13:11:35 -0800

b220a6c  More error shuffling

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/dfcbd5fe5ff10d2f030882b17d261415567e38b0..b220a6c7412235b7097167a51462aa12110804f8

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Dec 2018 13:27:10 -0800

kazuho commented on this pull request.

+~~~~~~~~~~  drawing
+ 0                   1                   2                   3

Using `11` to identify the current stream (and therefore the omission of the field) makes sense.

> I was trying not to have conditionally-present fields, but if folks are okay with that, I could try that variant.

FWIW, the reason I am happy with having conditionally-present fields is that it saves bytes: omitting PEID in the INITIAL_PRIORITY frame saves one byte per request in the common, omitting EDID in the PRIORITY frame saves at least one byte in the first flight when placeholders are used.

I think omitting having bytes with no meaning is more consistent to the efforts we have spent in other parts of the transport and the h3 drafts to minimize the overhead.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r238443579

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Dec 2018 13:29:27 -0800

+1 to having PRIORITY as a separate frame on the request stream. IMO, we should refrain from wasting bytes of a HEADERS frame, because it is used for carrying the responses as well. Bandwidth from the server to the client is the most precious resource in HTTP.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-443877211

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Dec 2018 13:33:49 -0800

kazuho approved this pull request.

Looks like a nice improvement to me.

In addition to guaranteeing that the server would have the prioritization information, the proposed change saves multiple bytes (in addition to the points I clarified in https://github.com/quicwg/base-drafts/pull/2075#discussion_r238443579, we also save at least 3 bytes per packet by removing the need to emit a STREAM frame of a control stream when sending requests).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-180990275

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 03 Dec 2018 14:27:06 -0800

Lgtm

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-443894538

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 18:59:15 +0000 (UTC)

It's worth noting one of @kazuho's earlier comments raises a race condition that still appears possible here:

Request A or Control:  PRIORITY( A -> B )
Request B:  PRIORITY( B -> A )
Control:  PRIORITY( A -> C )

These two initial frames race on parallel streams.  Which is the child of the other?  When A becomes a child of C, does B come with it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444215760

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 04 Dec 2018 19:11:29 +0000 (UTC)

What if we duplicate the priority information on the control stream?  If the priority of the new stream has already been set by the control stream, ignore the priority information on the request stream.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444219901

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 11:31:12 -0800

Yes, I believe that ensures there's a complete ordering and eventual consistency.  Even if an initial PRIORITY frame on a different stream gets things off-kilter briefly, the control stream will ensure the correct order wins in the end.  With a quick exploration of the sequence above, I can't find one in which the end state is incorrect.

Should that be "MAY/SHOULD repeat the desired prioritization on the control stream if dependencies are modified in close succession," or do you think repeating it should be a hard requirement?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444227538

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 04 Dec 2018 12:33:50 -0800

I think a hard requirement is too expensive.  The only reason to duplicate the priority information from the request stream is if the priority changes, otherwise it's a waste.

Case 1: superfluous duplication

Request A: PRIORITY( A -> B )
Control: PRIORITY( A -> B )

Case 2: race possible

Request A: PRIORITY( A -> B )
Control: PRIORITY( A -> C )

Case 3: ensure eventual consistency

Request A: PRIORITY( A -> B )
Control: **PRIORITY(A - B)**; PRIORITY( A -> C )

My guess is that most clients will fall under Case 1.  If request priority changes, the client should use Case 3.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444247799

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Dec 2018 13:10:45 -0800

@MikeBishop 
> These two initial frames race on parallel streams. Which is the child of the other? When A becomes a child of C, does B come with it?

FWIW, I do not think we have a race here.

For the case of:
```
Request A: PRIORITY(A -> B)
Request B: PRIORITY(B -> A)
Control: PRIORITY(A -> C)
```
I am not sure if that would ever happen.

Having request A's initial PRIORITY specifying B as it parent and request B's initial PRIORITY specifying A means that there was a loop _when_ the _client_ created the two streams.

That's a peculiar behavior of a client and I do not think that we need to address that.

For the case of:
```
Control: PRIORITY(A -> B)
Request B: PRIORITY(B -> A)
Control: PRIORITY(A -> C)
```
Under the premise that the client adds requests to the priority tree one by one and at the same time emits a INITIAL_PRIORITY frame, and that further modifications are signaled using the control streams, a server can determine the order of this pattern; PRIORITY(B -> A) predated PRIORITY(A -> B).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444259466

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 21:29:02 +0000 (UTC)

For your second, there's no loop.  B depends on A, regardless of A's ancestry.  B might attach to A before or after it gets reparented, but that's fine.

For the first, though, there's defined behavior (in 7540) of creating a dependency on a descendant -- that descendant implicitly moves up to become a peer, then the dependency stated in the priority frame is created.  A client trying to leverage this behavior could produce that sequence.

Another option would be to instead say that declaring a dependency on a descendant is always an error, and you need to explicitly perform the elevation-to-peer step (on the control stream).  That would be consistent with removing exclusive dependencies, because it's eliminating another implicit mutation of the priority tree.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444265261

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Dec 2018 21:42:30 +0000 (UTC)

> For the first, though, there's defined behavior (in 7540) of creating a dependency on a descendant -- that descendant implicitly moves up to become a peer, then the dependency stated in the priorit…

I think I might have been unclear.

My point is that if PRIORITY(A -> B) carried on a request stream implies that stream B existed when A was created, and that PRIORITY(B -> A) implies the reverse.

Because streams are created in order, that would never happen "under the premise that the client adds requests to the priority tree one by one and at the same time emits a INITIAL_PRIORITY frame".

(copied the last subsentence from my comment above that explained the premise for the different case)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444269784

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 16:29:21 -0800

I see the argument that a well-constructed client will not emit an invalid pattern. 🙂  It's not obvious to me how to turn that into a rule the server would use for interpretation or prohibition of those patterns.  Maybe a prohibition on referencing higher stream numbers in the initial PRIORITY frame?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444311809

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 16:32:13 -0800

0141a4208a6676f33a8001286ecff9c382b3f906  Merge remote-tracking branch 'origin/master' into http/not_excusive

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/1920b13a15adc3b71915fe532e52a8f7ff7981c3..0141a4208a6676f33a8001286ecff9c382b3f906

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Dec 2018 17:13:08 -0800

> I see the argument that a well-constructed client will not emit an invalid pattern. 🙂 It's not obvious to me how to turn that into a rule the server would use for interpretation or prohibition of t…

:+1: I like the idea of banning referring to higher stream numbers in the initial PRIORITY frame.

My argument was simply that we can ignore the case (because nobody would do that), but I agree that it would be even better if we can detect and prohibit such misuse.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444320445

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 18:55:06 +0000 (UTC)

9acfcf6c6838fd93f557791419043aee47353c6f  Limit references to existing elements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/0141a4208a6676f33a8001286ecff9c382b3f906..9acfcf6c6838fd93f557791419043aee47353c6f

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 18:55:46 +0000 (UTC)

Updated -- PTAL.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#issuecomment-444600411

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Dec 2018 14:45:08 -0800

@MikeBishop Thank you for the changes. The PR looks fine modulo the concerns stated below.

> @@ -552,10 +553,11 @@ the interpretation of the associated Element ID fields.
 Note that the root of the tree cannot be referenced using a Stream ID of 0, as
 in {{!RFC7540}}; QUIC stream 0 carries a valid HTTP request.  The root of the
 tree cannot be reprioritized. A PRIORITY frame sent on a request stream that
-prioritizes any other stream MUST be treated as a stream error of type
-HTTP_MALFORMED_FRAME.  Likewise, a PRIORITY frame sent on a control stream that
-prioritizes the current stream MUST be treated as a connection error of type
-HTTP_MALFORMED_FRAME.
+prioritizes any other stream or expresses a dependency on a request with a

I am not sure if we need "prioritizes any other stream or".

Now that exclusive flag is going away, is there any case that could hit this condition?

 Note that the root of the tree cannot be referenced using a Stream ID of 0, as
 in {{!RFC7540}}; QUIC stream 0 carries a valid HTTP request.  The root of the
-tree cannot be reprioritized. A PRIORITY frame that prioritizes the root of the
-tree MUST be treated as a connection error of type HTTP_MALFORMED_FRAME.
+tree cannot be reprioritized. A PRIORITY frame sent on a request stream that
+prioritizes any other stream or expresses a dependency on a request with a
+greater Stream ID than the current stream MUST be treated as a stream error of
+type HTTP_MALFORMED_FRAME.  Likewise, a PRIORITY frame sent on a control stream
+that prioritizes the current stream MUST be treated as a connection error of
+type HTTP_MALFORMED_FRAME.

I am not sure what the intent of the last sentence is.

My understanding is that a PRIORITY frame can only refer to a "Stream ID of a request stream" (assuming that the type bits are `00` (i.e. Request stream). Therefore, I think that we do not need this sentence.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#pullrequestreview-182008151

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 14:48:51 -0800

This is a perhaps-unclear reference to a PRIORITY frame where `Prioritized Element Type` is not `11` (i.e. the thing being prioritized is anything other than "this stream").

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r239267987

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Dec 2018 14:49:32 -0800

This is the inverse of the above -- sending `11` on a control stream, indicating that the thing being prioritized is the control stream itself.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r239268187

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Dec 2018 16:00:22 -0800

Ah. Thank you for the clarification. I missed that.

My preference goes to stating that `Prioritized Element Type` MUST be `11` when the frame is sent on a request stream and that it MUST NOT be `11` when the frame is sent on a control stream.

This is because I prefer to avoid having multiple representation that means the same; under the current provision, it seems that PEID could be encoded in two ways for a PRIORITY frame sent on a request stream; either set Prioritized Element Type to `11` or set it to `00` and set Prioritized Element ID to the ID of the stream. I fear that we might see interoperability issues in the wild if _most_ of the clients use the `11` form but some used the `00` form.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r239284823

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Dec 2018 14:43:48 -0800

c66e72446a21d1c682ea6e053d78274ecbf29938  Explicitly prohibit invalid PET values

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075/files/9acfcf6c6838fd93f557791419043aee47353c6f..c66e72446a21d1c682ea6e053d78274ecbf29938

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Dec 2018 22:44:38 +0000 (UTC)

Good point.  The requirement for the values was already there (in the definition of Prioritized Element Type), but I'll scope the required-error language to the specific values as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#discussion_r239642920

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Dec 2018 14:47:22 -0800

Merged #2075 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2075#event-2011157764