Draft: draft-ietf-doh-dns-over-https-latest

Commentary: As I understand it , the referenced CORS standard ( ) is obsolete , and has been superseded by the WHATWG fetch spec ( ) . Whether this is the official W3C position , I 'm not clear , but the WHATWG folks certainly seem to be running with the ball . 
 any idea on what the right thing to do here is ? or ? 
 The fetch spec is right , and referencing is the appropriate thing to do . This will make the IESG unhappy because fetch does n'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 does n'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 does n't want that , they can propose something better . 
 For an informative reference , that 's probably totally appropriate . I hope that we are n't going to start specifying the details of cross - origin requests . That would n't be appropriate here . 
 I agree that the CORS portion of the fetch spec clear . Even the examples in the spec ( most of which I wrote ) do n'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 
 W3C / IETF  hat on Early signs I 'm getting from W3C is that  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 . 
 when I spoke to 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 . ) 
 FWIW , I do n'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 . )
Paragraph (version A):
A secondary use case is allowing web applications to access DNS
information, by using existing APIs in browsers to access it over
HTTP.
Paragraph (version B):
A secondary use case is allowing web applications to access DNS
information, by using existing APIs in browsers to access it over
HTTP in a safe way consistent with Cross Origin Resource Sharing
(CORS) CORS.