Original text:
A client cannot push.  Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a ConnectionErrorHandler of type <del> PROTOCOL_ERROR.  Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a ConnectionErrorHandler of type PROTOCOL_ERROR. </del>  8.2.1.

Reviewer comments:
The previous text implied that a value of 1 was a problem, which was somewhat in tension with the default being 1 and servers mostly not sending the setting. So clearly what was being checked by client was the frame, not the value. This changes to checking the setting as it arrives, changes where that text lives. Also, this changes from "endpoint" to "client" or "server" as appropriate to match actual practice.
The definition of ENABLEPUSH implies that it can be set to 0 by a server, but the effect of that is meaningless as it results in treating PUSHPROMISE as an error. PUSH_PROMISE can't be sent by a client. Should we update the definition?
I don't think it's a good idea to start forbidding ENABLEPUSH = 0 from servers. It's clearly acceptable from the perspective of the RFC, and while it's a silly waste of bytes it doesn't introduce any protocol ambiguity. I do think we should clean up the text in § 6.5.2, which currently reads: However, Section 8.2 implies the default value for servers is 0: Arguably these two sections should be reconciled. In principle we could simply say that the value of ENABLEPUSH has no effect for servers, as the protocol forbids servers from pushing anyway, and remove the requirement that clients error.
I think that you mean clients are forbidden from pushing, but otherwise I would agree. The initial value for ENABLE_PUSH is defined as 1, which muddies things further. I think that we can change the definition to say that the setting has no effect when sent by a server and drop the connection error requirement.
Would we leave the connection error as an option?
I'm inclined to remove it as being inconsistent with reality. Though we might have to note that some implementations might do that (because they haven't updated) and so advise strongly against servers sending any value for this setting.
Is it inconsistent with reality? Presumably some implementations actually do police the MUST here.
Two things are in tension: policing probably happens in the sense that if a server sends ENABLEPUSH with any value (especially 1) a client might choke on it the initial value is 1, so those clients should probably choke on a connection preface from the server as well Removing the requirement that ENABLEPUSH result in an error avoids the second, but you need to keep a recommendation not to send it or you hit the first.
I suspect most implementations treat initial values somewhat specially, and while they enforce that they cannot receive a value of 1 from a server, they don’t prevent the server’s setting value having the value of 1.
This might be one worth circulating with the WG tbh, if only to get a sense of what existing clients actually do. We can also investigate putting together a test suite.
One minor language nit, otherwise seems great.

Revised text:
A client cannot push.  Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a ConnectionErrorHandler of type  <ins> PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). </ins> 8.2.1.