On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr.
wrote: > there's nothing wrong with reffing WHATWG specs. It will not delay > or hamper > > publication or Rec-track advancement, despite the > occasional misinformed > > complaint from someone not aware of the > > policies. > When the complaint comes from the office of the Director we have to assume it's going to hamper us whether or not they are misinformed. -Dan Veditz
FWIW I'm going to push for the Mozilla implementation to dispatch only when an event is clearly terminated with a blank line (I filed the bug). If EOF is encountered w/out a blank line it should be considered an incomplete/corrupted event. The fix for the spec would be to drop the line Once the end of the file is reached, the user agent must dispatch the event one final time, as defined below. For clarity something explicit could be added If the end of the file is reached while collecting data and before encountering a blank line the incomplete event must not be dispatched. -Dan Veditz On 7/5/11 5:49 AM, Arthur Barstow wrote: Since this thread was started, bug 13071 was filed against this spec (the only open bug): http://www.w3.org/Bugs/Public/show_bug.cgi?id=13071 Any comments re the priority of this bug, in particular if it must be addressed before publishing a new LCWD? Hixie - would you please provide a rough estimate re when you can address this bug? All - if anyone is willing to submit a fix for this bug, please send the fix to the list or add the fix to the bug. -AB On 6/24/11 7:33 AM, ext Arthur Barstow wrote: Hixie, All, Ian responded  to the last set of Server-Sent Events comments I had noted, and Bugzilla now reports Zarro Boogs  for this spec (11835/Fixed, 11836/WontFix, 12411/Fixed, 12883/WontFix). As such, this raises the question if the spec is ready for Last Call Working Draft publication (see  for information about what it means for the spec to be LC ready). If you have any feedback on this question, please send it by July 1. The latest Editor's Draft is: http://dev.w3.org/html5/eventsource/ -AB  http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1079.html  http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=Server-Sent+Events+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyexactbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=  http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html
On 6/30/11 9:31 AM, Maciej Stachowiak wrote: On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote: (Added public-web-security because of the potential for doing this in CSP instead. Though that would require a slight change of scope for CSP, which I'm not sure is actually desirable.) I approve of publishing this as FWPD. I also don't think it makes sense to tie this to CSP. Conceptually it's similar to the CSP frame-ancestors directive--which we've decided doesn't fit in CSP either. Most of CSP is can load while frame-ancestors was can be loaded by. We've proposed that the frame-ancestors functionality be moved into an expanded/standardized X-Frame-Options mechanism, but a standardized From-Origin would work just as well (better?). It may still make sense to put From-Origin in the WebSecurity (not-quite) WG along with CORS rather than free floating in WebApps. But I don't have strong feelings about that. Mozilla would be interested in implementing this feature regardless. -Dan Veditz
On 3/1/11 12:26 AM, Adam Barth wrote: From-Origin is closely related to one of the proposed CSP features, namely frame-ancestors, which also controls how the given resource can be embedded in other documents: Also similar to X-Frame-Options; I'd hate to end up with all three mechanisms. I'd be happy(ish) to jettison frame-ancestors from CSP if there's another competent header that can take up that use-case. Mainly we wanted to fix X-Frame-Options (without introducing the incompatibilities of embrace and extend) but didn't want to invent yet another header to do it. Depending on how it's eventually spec'd the Origin header could satisfy the same use-case with server-side enforcement. For that to happen it'd have to be sent with every request; not sure it's specified that way currently. Personally I'm more optimistic about client-enforced mechanisms because you only need five or so correct browser implementations, not tens or hundreds of app framework implementations. Either way the site authors have to correctly specify their policy, of course, and that's a big concern. -Dan Veditz