On Wed, Aug 7, 2013 at 8:54 AM, Glenn Adams <gl...@skynav.com> wrote:
> > On Mon, Aug 5, 2013 at 5:48 PM, Brad Hill <hillb...@gmail.com> wrote: > >> I'd like to issue this as a formal Call for Consensus at this point. If >> you have any objections to CORS advancing to Proposed Recommendation, >> please reply to public-webapp...@w3.org. Affirmative response are also >> encouraged, and silence will be taken as assent. >> > > >> >> The proposed draft is available at: >> >> http://webappsec-test.info/~bhill2/pub/CORS/index.html >> >> This CfC will end and be ratified by the WebAppSec WG on Tuesday, August >> 13, 2013. >> >> Thank you, >> >> Brad Hill >> >> >> On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill <hillb...@gmail.com> wrote: >> >>> WebAppSec and WebApps WGs, >>> >>> CORS advanced to Candidate Recommendation this January, and I believe >>> it is time we consider advancing it to Proposed Recommendation. In the >>> absence of an editor, I have been collecting bug reports sent to the >>> public-webappsec list, and now have a proposed draft incorporating these >>> fixes I would like to run by both WGs. >>> >>> The proposed draft can be found at: >>> >>> http://webappsec-test.info/~bhill2/pub/CORS/index.html >>> >>> A diff-marked version is available at: >>> >>> >>> http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html >>> >>> (pardon some spurious diffs indicated in pre-formatted text that has not >>> actually changed) >>> >>> A list of changes is as follows: >>> >>> 1. Changed "Fetch" references. The CR document referenced the WHATWG >>> Fetch spec in a number of places. This was problematic due to the maturity >>> / stability requirements of the W3C for document advancement, and I feel >>> also inappropriate, as the current Fetch spec positions itself as a >>> successor to CORS, not a reference in terms of which CORS is defined. The >>> proposal is to substitute these references for the "Fetching Resources" >>> section of the HTML5 spec at: >>> >>> http://www.w3.org/TR/html5/infrastructure.html#fetching-resources >>> >>> I do not believe this produces substantive changes in the reading of >>> CORS> >>> >>> 2. In the "Terminology" section, added a comma after "Concept" in >>> response to: >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html >>> >>> 3. Per discussion to clarify the interaction of HTTP Authorization >>> headers with the user credentials flag, >>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 and >>> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0366.html, >>> I have inserted the following clarification: >>> >>> "user credentials for the purposes of this specification means cookies, >>> HTTP authentication, and client-side SSL certificates >>> <!-- begin change --> that would be sent based on the user agent's >>> previous interactions with the origin. <!-- end change --> >>> >>> 4. In the defintion of the Access-Control-Allow-Methods header, in >>> response to >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0046.html, >>> clarified that "The Allow header is not relevant for the purposes of the >>> CORS protocol. >>> >>> 5. >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.htmland >>> >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0096.htmlpoint >>> out >>> that header and method are not defined correctly in the response >>> headers for preflight requests. >>> It appears that the intent was to respond with the list provided as >>> part of the preflight request, >>> rather than the potentially unbounded list the resource may >>> actually support >>> >>> The following clarifications were made: >>> >>> (for methods) "Since the list of methods can be unbounded, simply >>> returning the method indicated by >>> Access-Control-Request-Method (if supported) can be enough. >>> >>> (for headers) "Since the list of headers can be unbounded, simply >>> returning the headers from >>> Access-Control-Allow-Headers (if supported) can be enough. >>> >> > I would suggest using "is sufficient" or "is adequate" rather than "can be > enough". "Can be" implies that it may be or may not be. Need to be more > definite. > > >> >>> 6. In response to: >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html, >>> removed spurious 'than' >>> >>> 7. In response to: >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0055.html, >>> added comma after "Concept" >>> >>> 8. In response to thread beginning at: >>> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0078.html, >>> added 204 as a valid code equivalent to 200 for the CORS algorithm. >>> >> > Would this be considered a substantive technical change? Or correction to > an editorial oversight? I see below that 204 (and 308) tests need to be > added, which makes it sound a little like a technical change. > > >> >>> If these changes are acceptable to the WGs, I believe the only remaining >>> steps are to prepare an implementation report and update the test suite to >>> cover the 204 and 308 status codes. I'll let us discuss these for a bit >>> here before beginning a formal call for consensus. >>> >> > What is the status on resolving the open bugs at [1]? > > [1] > https://www.w3.org/Bugs/Public/buglist.cgi?list_id=22771&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=CORS&product=WebAppsSec > > >> >>> Please send comments to public-webapp...@w3.org >>> >>> Thank you, >>> >>> Brad Hill >>> >>> >>> >> >
