Re: Normative references to Workers.

[Daniel Veditz]

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​

Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

[Daniel 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 [1] to the last set of Server-Sent Events comments I
 had noted, and Bugzilla now reports Zarro Boogs [2] 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 [3] 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

 [1]
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1079.html

 [2]
 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=

 [3]
 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html


 

Re: Publishing From-Origin Proposal as FPWD

[Daniel Veditz]

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

Re: Cross-Origin Resource Embedding Restrictions

[Daniel 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