Re: PRIORITY extension

This thread seems to have resolved itself, so I'll just add that in the past we've split things off into extensions when they're both optional *and* doing so is relatively uncontroversial. This clearly isn't the case here.

Generally, I consider issues like this to be editorial -- i.e., it's about how the spec is structured, and therefore under the purview of the editor; the protocol itself doesn't care which document what is defined in. As such, editorial feedback is always appreciated by Martin, but we shouldn't get too bogged down on the list about this sort of thing -- never mind trying to justify one's position on this sort of thing based upon charter-lawyering.


On 13 Jul 2014, at 6:46 am, wrote:

> As far as I can tell, everything in h2-13 related to PRIORITY is completely optional (please correct me if I'm wrong).
> I've repeatedly seen arguments against adding anything optional to the spec. So why does PRIORITY get a pass? If it's truly optional, it could easily be moved to a separate RFC as an extension.
> So, why not move PRIORITY to an extension? It would make the main spec smaller and cleaner.
> This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Mark Nottingham

Received on Tuesday, 15 July 2014 04:20:22 UTC