Original text:
A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over <del> HTTP. </del>  This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its

Reviewer comments:
As I understand it, the referenced CORS standard (URL) is obsolete, and has been superseded by the WHATWG fetch spec (URL). Whether this is the official W3C position, I'm not clear, but the WHATWG folks certainly seem to be running with the ball.
NAME any idea on what the right thing to do here is? or NAME ?
The fetch spec is right, and referencing URL is the appropriate thing to do. This will make the IESG unhappy because fetch doesn't meet their standards for stability of reference, but they will have to learn to deal with that (there's an open discussion about this point). The other problem is that this still doesn't help provide the necessary context. Fetch is one of the most impenetrable and obtuse specifications in existence. Its description of CORS is really quite poor as an informational resource. It's only really useful to someone who already knows what it means. I'd recommend not worrying about that though. There are plenty of resources on the web that do a better job of explaining CORS.
I would rather put a link to a readable reference than an unreadable one. Thus, I propose (in all seriousness) . If the IESG doesn't want that, they can propose something better.
For an informative reference, that's probably totally appropriate. I hope that we aren't going to start specifying the details of cross-origin requests. That wouldn't be appropriate here.
I agree that the CORS portion of the fetch spec URL clear. Even the examples in the spec (most of which I wrote) don't really help much, since the entire spec is really 'aimed' at browser manufacturers rather than end-users. However, it has basically superseded the W3C spec originally referenced, and I'm fed up with seeing references to the W3C spec... It's really no big deal, but I'd prefer the link to refer to URL
W3C/IETF Liaison hat on Early signs I'm getting from W3C is that Fetch is the best thing to reference, although they're still doing some process things on making that formal. My .02 - I think asking W3C / WebAppSec formally is going to be more productive than guessing or going on aesthetics. Setting a precedent of referencing based on our preferences rather than the responsible body's is probably not something we want to do. I'm happy to facilitate a discussion with them if the need arises.
NAME when I spoke to NAME he said that getting W3C to update their CORS spec to note that it had been superseded by fetch was... unlikely. Of course, this was a while back.
I'm more optimistic now. If you think this could be improved it would help if you filed actionable feedback as issues. (FWIW, I've had some success pointing Stack Overflow questions to the official standard.)
NAME FWIW, I don't think there was any intent by anyone to disparage the work you've done on fetch. It's just that it's a standard that was documented from the POV of browser developers rather than end-users. At least, that's my take.
The "CORS protocol" section is not really meant for "browser developers" other than the "HTTP new-header syntax" section, which is normative for the header parsing requirements. Nothing else is normative there, all normative requirements are in the "Fetching" section. (It's also not for end users, but it's certainly for web developers.)

Revised text:
A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over  <ins> HTTP in a safe way consistent with Cross Origin Resource Sharing (CORS) CORS. </ins> This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its