CfC: publish Last Call Working Draft of Web IDL; deadline July 7

[Arthur Barstow]

As Cameron indicated in [1], all non-enhancements bugs for Web IDL are 
now resolved and as such, this is a Call for Consensus to publish a Last 
Call Working Draft of Web IDL:


  http://dev.w3.org/2006/webapi/WebIDL/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreement with the proposal. The deadline for 
comments is July 7. Please send all comments to:


public-script-co...@w3.org

-Art Barstow

[webstorage] Plan to move the spec to Last Call Working Draft

[Arthur Barstow]

Given the lack of support for stopping work on Web Storage [1], I'd let 
to get consensus on the plan to move it to Last Call Working Draft.


Currently there are two open bugs:

1. Bug 12111: "spec for Storage object getItem(key) method does not 
match implementation behavior". PLH created a version of the spec that 
addresses this bug [12111-fix].


2. Bug 13020: "No user agent will implement the storage mutex so this 
passage does not reflect reality".


There are different opinions on the priority of Web Storage ...

* Web Storage is a low priority and the Editor will get to it when he 
gets to it


* Web Storage is a high priority because the lack of a LCWD will block 
at least the Widget Interface spec from progressing on the Rec track


There are various options on what to do next, including:

1. Fix 12111 and 13020 and move Web Storage to LCWD

2. Leave Web Storage as is and eventually implementations will match the 
spec


3. Do #1 in one version of the spec and keep #2 as a separate version of 
the spec (e.g. L1 and L2).


Comments on these options are welcome.

If you prefer #1, please indicate if you are willing to create a 
fix/patch for bug 13020.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html
[12111] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
[12111-fix] http://www.w3.org/2011/06/Web%20Storage.html
[13020] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020

CfC: publish Proposed Recommendation for Widget Packaging and XML Configuration; deadline July 7

[Arthur Barstow]

The comment period for the 7-June-2011 LCWD of the Widget Packaging and 
XML Configuration spec ended with no comments and as documented in the 
spec's Implementation Report [ImplRept], there are 4 implementations 
that pass 100% of the test suite. As such, this is Call for Consensus to 
publish a Proposed Recommendation (PR) as indicated on May 26 [PR-plan]:


 http://dev.w3.org/2006/waf/widgets/

Note the Process Document includes the following regarding the entrance 
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented. 
Preferably, the Working Group SHOULD be able to demonstrate two 
interoperable implementations of each feature.

]]

If you have any comments about this proposal, please send them to 
public-webapps@w3.org by July 7 at the latest.


-Art Barstow

[ImplRept] http://dev.w3.org/2006/waf/widgets/imp-report/
[PR-Plan] 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0712.html

CfC: publish Proposed Recommendation for Widget Digital Signature; deadline July 7

[Arthur Barstow]

The comment period for the 7-June-2011 LCWD of the Widget Digital 
Signature spec ended with no comments and as documented in the spec's 
Implementation Report [ImplRept], there are 2 implementations that pass 
100% of the test suite's Mandatory feature tests. As such, this is Call 
for Consensus to publish a Proposed Recommendation (PR) as indicated on 
May 26 [PR-plan]:


 http://dev.w3.org/2006/waf/widgets-digsig/

Note the Process Document includes the following regarding the entrance 
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented. 
Preferably, the Working Group SHOULD be able to demonstrate two 
interoperable implementations of each feature.

]]

If you have any comments about this proposal, please send them to 
public-webapps@w3.org by July 7 at the latest.


-Art Barstow

[ImplRept] http://dev.w3.org/2006/waf/widgets-digsig/imp-report/
[PR-Plan] 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0712.html

TPAC2011 Meeting Registration Open; 31Oct - 4 Nov @ Santa Clara, CA

[Arthur Barstow]

Below is some information about the W3C's 2011 Technical Plenary and all 
Working Group meeting week which is October 31 - November 4 in Santa 
Clara California:


  http://www.w3.org/2011/11/TPAC/#Finalized

The current plan is for WebApps to only meet on Monday October 31. I 
created an agenda outline for our meeting:


  http://www.w3.org/2008/webapps/wiki/TPAC2011

Specific agenda requests including time slots are welcome and 
encouraged. As was done during last year's TPAC f2f meeting, the start 
of the meeting is agenda tweaking à la an unconference style meeting. We 
can use this time to discuss topics such as cross-spec issues, 
coordination with other groups, spec status, plans, etc.


Registration is now open (through October 15) and there will be a 
per-day fee. Non-WG members ("Observers") are welcome to attend WebApps' 
meeting but they must register and pay the fee.


  http://www.w3.org/2002/09/wbs/35125/TPAC2011/

I hope to see many of you at this meeting!

-AB

P.S. If any of you with an "artsy" inclination want to work on a 
WebApps'y type t-shirt design, I can look for some funding to create 
some shirts for us.



On 6/30/11 9:23 AM, ext TPAC Organizer wrote:
Registration [1] for TPAC2011 is now open. The Meeting Overview [2] 
page is packed with new information to include important deadlines for 
meeting registration and the hotel discount rate.


Schedule for the week: M-F;  31 October - 4 November 2011, Santa 
Clara, CA

Group Meetings: Monday, Tuesday, Thursday, Friday [3]
Plenary Day: Wednesday
AC Sessions: Tuesday afternoon, Wednesday Plenary and Thursday 
morning


As with past meetings, there will be a small registration fee of 50 
USD per day to defray a portion of the meeting costs. Registration 
will increase to 150 USD per day after 14 October 2011 [4]


Deadlines: (see overview page [2] for all deadlines)
14 October 2011 - Register and pay for the meeting
10 October by 17:00 pacific time - Book your hotel
W3C has contracted for a significant portion of the Hotel's meeting 
space. Please do your best to stay at the Meeting Hotel. We have done 
our best to offer a competitive guest room rate. In order to meet 
guest room quotas, avoid steep charges for meeting rooms, and maintain 
all the meeting space we require for a successful meeting, we ask that 
you book your room at the Santa Clara Marriott.


Please register, pay for the meeting, and make hotel arrangements as 
soon as possible. Hotel reservations can easily be canceled if plans 
change. We would like to know as early as possible if we need to 
adjust the meeting guest room block.


1. http://www.w3.org/2002/09/wbs/35125/TPAC2011/ - WBS Registration
2. http://www.w3.org/2011/11/TPAC/ - Overview Page
3. http://www.w3.org/2011/11/TPAC/#Finalized - Groups Schedule
4. http://www.w3.org/2011/11/TPAC/#Registrati - Registration Fees
5. http://www.w3.org/2011/11/TPAC/#Hotel - Hotel rates and deadlines
6.http://lists.w3.org/Archives/Member/chairs/2011AprJun/0069.html - 
TPAC schedule announcement

Re: Publishing From-Origin Proposal as FPWD

[Arthur Barstow]

On 6/30/11 10:31 PM, ext Daniel Veditz wrote:

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.


I don't feel strongly about the charter issue either. (As I understand 
it, CORS will be a joint deliverable between WebApps WG and WebAppSec WG 
and as such, my expectation is that both WGs will participate in 
decisions such as "does the spec meet Last Call Working Draft 
requirements?".)



Mozilla would be
interested in implementing this feature regardless.


This is good to read. Based on the feeback so far, I will start a CfC to 
publish a First Public Working Draft of Anne's spec.


-Art Barstow

[1] http://lists.w3.org/Archives/Public/www-tag/2011Jun/0192.html

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

[Arthur Barstow]

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=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Server-Sent+Events+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
[3] 
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html

Re: Publishing From-Origin Proposal as FPWD

[Arthur Barstow]

Hi Brad, Anne,

As I mentioned in [1], I think there is sufficient support for WebApps 
to publish this spec as a FPWD and I will start a Call for Consensus to 
more formally determine WebApps' level of support.


A WG may publish a FPWD without consensus on the _contents_ of the spec. 
The Status of the Document section may be explicit on this point. We try 
to employ a "publish early, publish often" to encourage early and 
frequent comments and I think a FPWD will help stimulate comments.


Anne - please add some text re the consensus of the contents point and 
then I'll start the CfC.


-Art Barstow

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

On 7/1/11 1:52 PM, ext Hill, Brad wrote:

The new WebAppSec WG charter draft does include a deliverable for secure 
mashups built with cross-domain framing, with the specific intent to put 
forward a proposal for anti-clickjacking in this space.

However, I have concerns with nearly every aspect of this draft.

First, I am concerned about mixed goals in the problem statement.  It's definitely not in 
the proposed charter scope for the WebAppSec WG to address issues like bandwidth 
"theft" and license enforcement.   Even for the WebApps WG, it is arguable that 
some of these goals go against core Web Architecture principles. 
(http://www.w3.org/TR/webarch/)

Secondly, several of the goals, even if couched in terms of security, aren't in 
the interest of the user.  If I go to a page, I want to see images, fonts and 
videos on it.  Policies that prevent that from working are actually adversarial 
to the user.From a basic security principles perspective, the client-side 
UA is not the place for such restrictions to be enforced, as they can be easily 
disabled.Further, conflating mechanisms to protect the user 
(anti-clickjacking) with mechanisms adversarial to the user (font licensing) 
encourages the user to disable even the protections that they should want.

Finally, don't think the proposed mechanism here for user-protection is adequate for many/most use cases at 
risk of clickjacking that web application owners would like to deploy.  A binary frame/no-frame policy based 
on a whitelist of origins is both very limiting and not terribly secure.   Consider a "like", 
"+1" or "pay" button.  These may be framed on tens of thousands of origins, making a 
whitelist unmanageable.  Or they may be framed-by-permission on an origin with tens of thousands of 
resources/pages/applications (forum, auction site, etc.)  where an XSS or similar in any one of which would 
expose the framed content to clickjacking again.

I think it's preferable to work towards a mechanism where resources can declare 
they can be framed, but only subject to some policy or set of capabilities 
which guarantee clickjacking protection, visibility, etc.

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van Kesteren
Sent: Thursday, June 30, 2011 7:23 AM
To: WebApps WG
Cc: public-web-secur...@w3.org
Subject: Publishing From-Origin Proposal as FPWD

Hi hi,

Is there anyone who has objections against publishing 
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
The idea is mainly to gather more feedback to see if there is any interest in 
taking this forward.

(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.)

Cheers,


--
Anne van Kesteren
http://annevankesteren.nl/

CfC: publish FPWD of Cross-Origin Resource Embedding Exclusion; deadline July 12

[Arthur Barstow]

As discussed in [1], Anne would like to publish a First Public Working 
Draft (FPWD) of Cross-Origin Resource Embedding Exclusion (From-Origin) 
and this a Call for Consensus (CfC) to do so:


  http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

This CfC satisfies the group's requirement to "record the group's  
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to  
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreement with the proposal. The deadline for 
comments is July 12. Please send all comments to:


public-webapps@w3.org

-Art Barstow

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

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

[Arthur Barstow]

Thanks Anne and Dan. I added your comments to bug 13071.

All - in addition to 13071, on July 6, Anne submitted 13155 and 13156 
against this spec. Unless I hear otherwise, I assume the group wants to 
block LC until all of these bugs are addressed.


As always, patches/fixes for open bugs are welcome (preferably as 
comments in the bugs).


-AB

On 7/6/11 4:52 AM, ext Anne van Kesteren wrote:
On Tue, 05 Jul 2011 21:16:55 +0200, Daniel Veditz 
 wrote:

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.


The ABNF in 
http://dev.w3.org/html5/eventsource/#parsing-an-event-stream would 
also need updating.

Re: Publishing From-Origin Proposal as FPWD

[Arthur Barstow]

Thanks Björn and Brad for your comments.

I agree early comments from a broad set of stakeholders is important and 
I encourage everyone to please send all technical feedback on this spec to:


  public-webapps@w3.org

-Art Barstow

On 7/5/11 11:14 PM, ext Hill, Brad wrote:

To the procedural points:

I am not a member of the Web Applications WG.  I do not have standing to block 
or make a formal objection to this moving forward as a FPWD.  Responsibility to 
measure consensus and the decision to move forward within that WG rests with 
Art.

The opinion of the proposed Web Applications Security WG (currently in the 
process of being chartered and of which I am a proposed co-chair)  was 
solicited as to whether the work should move to that forum or be a joint 
deliverable with the Content Security Policy.  Additionally, one of the goals 
of the draft was to address concerns around clickjacking, an item under the 
proposed charter scope of the WebAppSec WG.  Wearing that (still phantom) hat, 
I can say is that there isn't consensus to move this proposed mechanism as a 
cross-domain framing security solution to FPWD, alone or as part of the CSP, in 
the WebAppSec WG, at this time.  Until AC approval, we can't move anything to 
FPWD at this time.  :)

My other concerns with the proposal are put forward only as an interested 
member of the community.  I expect there will be ample opportunity to discuss 
them.  If Art feels that moving forward to FPWD is the best next step to foster 
that and other discussions, I'm more than happy to participate there to the 
extent the WG welcomes my feedback and finds it useful.

Thanks,

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann
Sent: Tuesday, July 05, 2011 4:38 PM
To: Marcos Caceres
Cc: WebApps WG; public-web-secur...@w3.org
Subject: Re: Publishing From-Origin Proposal as FPWD

* Marcos Caceres wrote:

On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad  wrote:

I feel that the goals of this draft are either inconsistent with the
basic architecture of the web, cannot be meaningfully accomplished by
the proposed mechanism, or both, and I haven't seen any discussion of
these concerns yet.

I note that the Web Applications Working Group's Charter, if Brad Hill is a 
member, does require the rest of the Working Group to duly consider his points 
before moving on without consensus. If not, then the group is not required to 
wait with publication, but not discussing the points in a timely manner, 
without an argument how publication is urgent in some way, does not inspire 
confidence that the arguments will be heard and duly handled.


Publication will enable wider discussion - particularly wrt the issues
you have raised. Not publishing it is tantamount to saying "I OBJECT TO
PROGRESS!". If you are correct, more people will see it and the
proposal will be shot down. Otherwise, other opinions will flourish
that may sway your position (or a new perspective will emerge all
together). In any case, calling for a spec not to be published, no
matter how bad it is, is not the right way to do this. Publishing a
spec is just a formality which can lead to discussion.

The more invested people are into something, the less likely they are to cut 
their losses; by doing things, you frame the discussion in favour of doing 
more. You get people to think more about how something can be fixed rather than 
thinking about whether to abandon the work, or use a very different approach. 
If you just propose an idea to me, we can talk about it more freely than if you 
had already invested a lot of effort on implementing the idea and asked me to 
review the idea after the fact.

(~ "Die normative Kraft des Faktischen")

Realizing something is a bad idea early is therefore very important and not 
objecting to progress. Not wasting time on bad ideas is certainly progress, 
even if only indirectly as you'd work on other things instead.
As such it is quite important to react timely to design critique with care and 
detail. Psychologically, if you press ahead, you communicate that you care more 
about moving on than discussing details, which is likely to turn away the 
people more interested in details and quality; and the same is of course true 
for draft of genuinely bad quality.

Which is just to say this is actually an important matter; sometimes it is best 
to go ahead and put your ideas into practise whatever others may be saying, 
other times it turns out that you should have listened more.
That is why we allow people to block actions, not necessarily progress, but 
only up to the point where arguments have been duly considered. And here we 
have yet to do that. Until that happens, short of someone making the case for 
urgency, I would agree the group should not publish and talk about this instead.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am 
Badedeich 7 · Telefon: +

Re: [webstorage] Plan to move the spec to Last Call Working Draft

[Arthur Barstow]

Thanks Scott for volunteering to create a fix for 13020.

Ideally, the Editor would address all of the open bugs and WebApps' 
version of Web Storage would be as close as possible to the WHATWG's 
version. However, given the conflicting constraints of moving this spec 
to LC now and the low priority of this spec for Ian, it appears we need 
to proceed otherwise.


Scott - please create a fix we can review and base it on the latest ED 
[ED]. It may be helpful if your fix included PLH's fix for 12111 
[1211-fix] and to put your version of the spec in the "publish" 
directory [PUB] e.g. create LC-webstorage-2011July.html.


-Thanks, ArtB

[ED] http://dev.w3.org/cvsweb/html5/webstorage/
[PUB] http://dev.w3.org/cvsweb/html5/webstorage/publish/
[1211-fix] http://www.w3.org/2011/06/Web%20Storage.html


On 6/30/11 3:20 PM, ext Scott Wilson wrote:

On 30 Jun 2011, at 14:55, Arthur Barstow wrote:


Given the lack of support for stopping work on Web Storage [1], I'd let to get 
consensus on the plan to move it to Last Call Working Draft.

Currently there are two open bugs:

1. Bug 12111: "spec for Storage object getItem(key) method does not match 
implementation behavior". PLH created a version of the spec that addresses this bug 
[12111-fix].
2. Bug 13020: "No user agent will implement the storage mutex so this passage does 
not reflect reality".

There are different opinions on the priority of Web Storage ...

* Web Storage is a low priority and the Editor will get to it when he gets to it

* Web Storage is a high priority because the lack of a LCWD will block at least 
the Widget Interface spec from progressing on the Rec track

There are various options on what to do next, including:

1. Fix 12111 and 13020 and move Web Storage to LCWD

+1


2. Leave Web Storage as is and eventually implementations will match the spec

3. Do #1 in one version of the spec and keep #2 as a separate version of the 
spec (e.g. L1 and L2).

Comments on these options are welcome.

If you prefer #1, please indicate if you are willing to create a fix/patch for 
bug 13020.

Yes.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html
[12111] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
[12111-fix] http://www.w3.org/2011/06/Web%20Storage.html
[13020] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020

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

[Arthur Barstow]

On 7/6/11 1:55 PM, ext Ian Hickson wrote:

On Tue, 5 Jul 2011, Arthur Barstow wrote:

Any comments re the priority of this bug, in particular if it must be
addressed before publishing a new LCWD?

Can we please stop letting the LCWD/CR/PR process nonsense drive the
prioritisation of the bug fixing process? This is getting ridiculous.


(I will respond to the TR publication process issue separately with a 
different Subject:)


Regarding the SSE spec, at least one WG member said moving the SSE spec 
to LC is important. As such, it seems appropriate (and not "nonsense" 
nor "ridiculous") to then effectively ask the group (the To: on my 
e-mail included public-webapps too) "is moving this spec to LC important 
enough for you to submit fixes for the open bugs?".


I think we have other capable people in WebApps that can fix bugs and 
thus lighten your load.


Do you oppose others submitting fixes to your spec bugs?

-AB

Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

[Arthur Barstow]

Hi Hixie,

On 7/6/11 1:55 PM, ext Ian Hickson wrote:

On Tue, 5 Jul 2011, Arthur Barstow wrote:

Any comments re the priority of this bug, in particular if it must be
addressed before publishing a new LCWD?

Can we please stop letting the LCWD/CR/PR process nonsense drive the
prioritisation of the bug fixing process? This is getting ridiculous.


I think we all realize you have issues with the W3C's TR process. I 
actually agree with some of your view points [at least as I understand 
them ;-)] and I think they should be discussed with a different set of 
people then WebApps.  For instance, the so-called Advisory Board 
[AdvBrd] "manages the evolution of the W3C Process Document", yet I 
suspect very few of them are subscribed to public-webapps.


So, rather than continuing to complain about this process on 
public-webapps, I would appreciate it if you would please move TR 
process type discussions to another Public list.


IJ, PLH - what Public list is appropriate for discussions about the TR 
process?


-AB

[AdvBrd] http://www.w3.org/2002/ab/

Re: [websockets] Getting WebSockets API to Last Call

[Arthur Barstow]

On 7/7/11 6:00 PM, ext Adrian Bateman wrote:

We're keen to resolve the remaining issues with the WebSockets API and have a 
timetable
to get to Candidate Recommendation. From informal conversations we've had, we 
believe
other browser vendors share this goal. I think the current WebSocket API is 
feature
complete and meets the requirements for publishing a Last Call working draft to
encourage wider review and feedback. There are no tracker issues for 
WebSockets. Here
is my analysis of the outstanding bugs (not closed, where resolution not Fixed).
I believe the outstanding issues could be resolved as Last Call comments and 
would like
to see a CfC to publish a LCWD shortly.


I think the spirit of the publication process is that all bugs that 
affect an implementation should be resolved before going to LC. As such, 
it would be helpful if others would do as Jonas did and provide feedback 
on the bugs and/or Adrian's general proposal to move to LC "as is". If 
there is consensus within the group to go to LC with these bugs open, we 
can do so, but it may be preferable to do some extra work now if it can 
prevent the overhead of additional LCs.



12917 - "deflate-stream" should be an optional extension when establishing a 
connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the 
protocol spec
on what is optional in the protocol. The API spec should not normatively 
mention specific
extensions. References to "deflate-stream" should be informative and only 
provided as examples.


The bug only includes comments from IanH and Adrian. It does seem like a 
mismatch in requirements for deflate-stream to be optional in the 
protocol and mandatory in the API. What do others think about this bug?


-AB

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

[Arthur Barstow]

On 7/6/11 5:49 PM, ext Ian Hickson wrote:

On Wed, 6 Jul 2011, Arthur Barstow wrote:

Do you oppose others submitting fixes to your spec bugs?

If someone is interested in submitting fixes, they are welcome to contact
me, so that I can work with them to work out how we can get something set
up. There are a number of people who have done this (e.g. Aryeh's
atob()/btoa() spec text, Ian Fette's adoption of the WebSockets protocol,
Adam Barth's work on file type identification). Exactly how it should be
done, and whether it's worth it to do it at all, depends on what kinds of
edits we're talking about.


Ian - OK; thanks for the clarifications.

All - if you do work on any fixes with Ian, I think it would be good if 
there was a public record of the exchanges e.g. cc'ing public-webapps or 
www-archive.


-AB

Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7

[Arthur Barstow]

Although there are ongoing discussions regarding exceptions, there were 
no objections to this CfC. As such, I will request publication of a LC 
specification to encourage broader review and comments.


-AB

On 6/30/11 6:46 AM, ext Arthur Barstow wrote:
As Cameron indicated in [1], all non-enhancements bugs for Web IDL are 
now resolved and as such, this is a Call for Consensus to publish a 
Last Call Working Draft of Web IDL:


  http://dev.w3.org/2006/webapi/WebIDL/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreement with the proposal. The deadline for 
comments is July 7. Please send all comments to:


public-script-co...@w3.org

-Art Barstow

[widgets] Re: Call for Prior Art Related to US Patent 7,743,336 and US Patent Application 20070101146

[Arthur Barstow]

FYI, this announcement was forwarded to public-widgets-pag and there is 
at least one response to that CfPA:


  http://lists.w3.org/Archives/Public/public-widgets-pag/
  
http://lists.w3.org/Archives/Public/public-widgets-pag/2011JulSep/0001.html


On 7/8/11 4:22 PM, ext Philippe Le Hegaret wrote:

This is a public call for prior art. The W3C seeks information about
access control systems available before October 2005 and content
distribution systems before April 2006 that offer a viable solution that
may apply to the use of access requests policy in Widgets.

On 13 November 2009,  pursuant to its rights under W3C's Patent Policy,
Apple, Inc. disclosed US Published Patent Application No. 11/432,295 and
US Published Patent Application 11/409,276 and claimed that it applies
to the Web Application WG's Widget Access Request Policy specification.
Apple excluded all claims from the W3C Royalty-Free License commitment
of the W3C Patent Policy given by Participants of the Web Applications
Working Group.

In accordance with the exception procedures of the Patent Policy, W3C
launched a Patent Advisory Group (PAG) to determine possible solutions.
The PAG has advised W3C to issue this call for prior art.

People who wish to provide feedback should refer to the call for prior
art for more information:
   http://www.w3.org/2010/12/cfpa

Please, don't hesitate to forward this message to other public fora,

Regards,

Philippe

Re: [websockets] IETF HyBi current status and next steps

[Arthur Barstow]

Is there a deadline for protocol comments?

Based on the e-mail below, it appears the deadline is July 25. Please 
clarify.


Also, for those of us not familiar with IETF process, what is the 
relationship between the IETF's LC review and v10's "Expires: January 
12, 2012"?


-Thanks, Art Barstow

On 7/8/11 4:05 PM, ext Brian Raymor wrote:

The HyBi WG is publishing Version 10 of the WebSockets protocol on 7/11 and 
then requesting IETF Last Call. If there are remaining issues related to the 
protocol, these should be immediately raised with the HyBi WG.


http://www.ietf.org/mail-archive/web/hybi/current/msg07713.html

From: Salvatore Loreto
To: "hybi at ietf.org"
Date: Fri, 8 Jul 2011 11:33:41 +0300


(as chairs)

status:
--
Gabriel and I started the WG last call process for version -07 on April 25th, 
2011 (until May 9th),
since then two new version -08 and -09 have been produced
to address all the comments/discussion received during the WG LC time and after
the IESG process requires that once the WG LC is over and the document is ready
it has to be submitted to IESG for publication...
so we have asked the IESG to publish it,
I will be the Document Shepherd for it.


(if you are not familiar with the IETF process see: 
http://tools.ietf.org/html/rfc4858#section-3 )

Now we are on the AD evaluation phase:
Peter Saint-Andre is the Application AD responsible for HyBi wg;
(you can check all the information from the tracker:
https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ )

In order to address the last, mostly editorials comments/fix we have asked the 
editors to produce
a new version -10 for July 11th

as soon the version -10 is produced we will ask
to start the two weeks broader IESG/IETF last call that involve all the IETF 
community (not only the HyBi wg):
the discussion will happen on the IETF discussion list (ietf at ietf.org):
http://www.ietf.org/list/discussion.html


The idea is to take advantage of the IETF81 meeting in Quebec to discuss all 
the comments received
on version -10



what next:
-
now that the WebSocket Protocol is stable, it is time to discuss the extension 
that we have put on hold for a while
and decide on what we want to work.
among the others I have in my notes:
 - Multiplexing
 - per Frame deflate extension 
(draft-tyoshino-hybi-websocket-perframe-deflate)
 - Timeout (draft-thomson-hybi-http-timeout)
 - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv)


forgive me and let me know if I forgot something... or there is other stuff you 
think is important to discuss


cheers
/Sal

RfC: Last Call Working Draft of Web IDL; deadline August 23

[Arthur Barstow]

On July 12 a Last Call Working Draft of Web IDL was published:

  http://www.w3.org/TR/2011/WD-WebIDL-20110712/

The deadline for comments is August 23 and all comments should be sent to:

   public-script-co...@w3.org

Cameron, Philippe - if you think it is necessary, please fwd this e-mail 
to ECMA TC39.


-AB

RfC: Last Call Working Draft of the API for Media Resources 1.0; deadline August 7

[Arthur Barstow]

WebApps has been asked to submit comments for the LCWD of the API for 
Media Resources 1.0 spec:


  http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/

Individual WG members are encouraged to provide individual feedback 
directly to the Media Annotations WG. If you have comments, please send 
them to the following list by August 7:


  public-media-annotat...@w3.org
  http://lists.w3.org/Archives/Public/public-media-annotation/

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the WebApps WG can discuss it.


-AB

 Original Message 
Subject: 	Last Call Working Drafts transition announcement of the API 
for Media Resources 1.0

Date:   Tue, 12 Jul 2011 20:00:54 +0200
From:   ext Thierry MICHEL 
Reply-To:   
To: 	cha...@w3.org , , 
, Ivan Herman , , 
, Doug Schepers , Charles 
McCathieNevile , 'Chris Lilley' , 
, , , 
, , , Thomas 
Roessler , , , 
, Michael Cooper , Ralph R. Swick 
, , , 
, , , 
, , PF group 
, 




Chairs and Team Contact,


(1) This is a 2nd Last Call Working Draft Transition Announcement for
the following Recommendation Track specification:

(2) Document Title and URI

* API for Media Resources 1.0
http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/


(3) Instructions for providing feedback

If you wish to make comments regarding this specification please send
them to  which is an email list publicly
archived at http://lists.w3.org/Archives/Public/public-media-annotation/
Please use "[2ndLC Comment API]"  in the subject line of your email.

(4) Review end date

The Last Call period  ends on 07 August 2011.

(5) A reference to the group's decision to make this Transition

The Media Annotations Working Group made the decision for this
Transition at its teleconference on July 5th 2011:
"Resolution: the wg agrees to move the api doc to 2nd LC"
http://www.w3.org/2011/07/05-mediaann-minutes.html


(6) Evidence that the document satisfies group's requirements. Include a
link to requirements

The Media Annotations Working Group believes that these specifications
satisfy the requirements of the working group's charter at
http://www.w3.org/2008/01/media-annotations-wg.html

and the "Use Cases and Requirements for Ontology and API for Media
Resource 1.0" at
http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/

(7) The names of groups with dependencies, explicitly inviting review
from them.

The following groups are known or suspected to have dependencies on this
specification:

* Semantic Web Deployment Working Group
* Semantic Web Coordination Group
* Scalable Vector Graphics Working Group (SVG)
* Web Applications (WebApps) Working Group
* HyperText Markup Language (HTML) Working Group
* The Device API and Policy (DAP) Working Group

also the following groups have liaisons on one or more of these
specifications:
* Protocol for Web Description Resources (POWDER) Working Group
* Protocols and Formats Working Group

The Media Annotations Working Group requests review from each of these
working groups.  The chairs of the working group listed have been copied
on the distribution list of this transition announcement as well as
other individuals known to have expressed prior interest.


(8) Report of any Formal Objections

The Working Group received no Formal Objection during the preparation of
this specification.


(9) Patent Disclosure Page Link can be found at
http://www.w3.org/2004/01/pp-impl/42786/status

This Transition Announcement has been prepared according to the
guidelines concerning such announcements at
http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr#trans-annc

Regards,

Thierry Michel (on behalf of the Media Annotations Working Group chairs)
Team Contact for the Media Annotations WG.

CORS/UMP to become joint WebApps and WebAppSec joint deliverable

[Arthur Barstow]

As indicated a year ago [1] and again at the end of last month [2], the 
proposal to create a new Web Application Security WG has moved forward 
with a formal AC review now underway and ending August 19.


The proposed charter includes making CORS and UMP a joint deliverable 
between the WebApps and WebAppSec WGs:


[[
http://www.w3.org/2011/07/appsecwg-charter.html

Secure Cross-Domain Resource Sharing - Advance existing recommendations 
specifying mechanisms necessary for secure mashup applications, 
including the Cross-Origin Request Sharing (CORS) and Uniform Messaging 
Policy (UMP) Such recommendations will be harmonized and published as 
joint work with the W3C Web Applications Working Group.

]]

-Art Barstow

[1] 
http://lists.w3.org/Archives/Public/public-web-security/2010Jul/0002.html
[2] 
http://lists.w3.org/Archives/Public/public-web-security/2011Jun/0162.html

[websockets] Reminder: review Web Socket Protocol v10; deadline July 25

[Arthur Barstow]

A reminder to review the Web Socket Protocol v10 spec by July 25:

  https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/
  http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-10.txt

Individual WG members are encouraged to provide individual feedback 
directly to the Hybi WG:


  h...@ietf.org

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the WebApps WG can discuss it.


-AB

 Original Message 
Subject:[websockets] IETF HyBi current status and next steps
Resent-Date:Mon, 11 Jul 2011 08:25:19 +
Resent-From:
Date:   Fri, 8 Jul 2011 20:05:14 +
From:   ext Brian Raymor 
To: 	Web Applications Working Group WG (public-webapps@w3.org) 


CC: ife...@google.com 



The HyBi WG is publishing Version 10 of the WebSockets protocol on 7/11 and 
then requesting IETF Last Call. If there are remaining issues related to the 
protocol, these should be immediately raised with the HyBi WG.


http://www.ietf.org/mail-archive/web/hybi/current/msg07713.html

From: Salvatore Loreto
To: "hybi at ietf.org"
Date: Fri, 8 Jul 2011 11:33:41 +0300


(as chairs)

status:
--
Gabriel and I started the WG last call process for version -07 on April 25th, 
2011 (until May 9th),
since then two new version -08 and -09 have been produced
to address all the comments/discussion received during the WG LC time and after
the IESG process requires that once the WG LC is over and the document is ready
it has to be submitted to IESG for publication...
so we have asked the IESG to publish it,
I will be the Document Shepherd for it.


(if you are not familiar with the IETF process see: 
http://tools.ietf.org/html/rfc4858#section-3 )

Now we are on the AD evaluation phase:
Peter Saint-Andre is the Application AD responsible for HyBi wg;
(you can check all the information from the tracker:
https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ )

In order to address the last, mostly editorials comments/fix we have asked the 
editors to produce
a new version -10 for July 11th

as soon the version -10 is produced we will ask
to start the two weeks broader IESG/IETF last call that involve all the IETF 
community (not only the HyBi wg):
the discussion will happen on the IETF discussion list (ietf at ietf.org):
http://www.ietf.org/list/discussion.html


The idea is to take advantage of the IETF81 meeting in Quebec to discuss all 
the comments received
on version -10



what next:
-
now that the WebSocket Protocol is stable, it is time to discuss the extension 
that we have put on hold for a while
and decide on what we want to work.
among the others I have in my notes:
- Multiplexing
- per Frame deflate extension 
(draft-tyoshino-hybi-websocket-perframe-deflate)
- Timeout (draft-thomson-hybi-http-timeout)
- DNS SRV for WebSocket (draft-ibc-websocket-dns-srv)


forgive me and let me know if I forgot something... or there is other stuff you 
think is important to discuss


cheers
/Sal
--
Salvatore Loreto
www.sloreto.com

Seeking view-mode Media Feature implementation data

[Arthur Barstow]

[ Bcc www-style ]

Marcos is gathering and organizing implementation data for the view-mode 
Media Feature Candidate Recommendation [VMMF-CR] with a goal of moving 
this spec to Proposed Recommendation:


  http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/

If you have any implementation data for this spec, especially for the 
'fullscreen' view mode, please send it to:


  public-webapps@w3.org

-Regards, Art Barstow

[VMMF-CR] http://www.w3.org/TR/2010/CR-view-mode-20100624/

Re: Seeking view-mode Media Feature implementation data

[Arthur Barstow]

FYI, Marcos now has sufficient data to meet the CR's exit criteria and 
to move this spec to Proposed Recommendation:


http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/

On 7/19/11 9:46 AM, ext Arthur Barstow wrote:

[ Bcc www-style ]

Marcos is gathering and organizing implementation data for the 
view-mode Media Feature Candidate Recommendation [VMMF-CR] with a goal 
of moving this spec to Proposed Recommendation:


  http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/

If you have any implementation data for this spec, especially for the 
'fullscreen' view mode, please send it to:


  public-webapps@w3.org

-Regards, Art Barstow

[VMMF-CR] http://www.w3.org/TR/2010/CR-view-mode-20100624/

CfC: publish Proposed Recommendation of view-mode Media Feature; deadline July 27

[Arthur Barstow]

As mentioned in [1], the exit criteria of the view-mode Media Feature 
Candidate Recommendation [2] has been met (at least two implementations 
pass every test):


  http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/

As such, this is Call for Consensus to publish a Proposed Recommendation 
(PR) of this spec.


Note the Process Document includes the following regarding the entrance 
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented. 
Preferably, the Working Group SHOULD be able to demonstrate two 
interoperable implementations of each feature.

]]

If you have any comments about this proposal, please send them to 
public-webapps@w3.org by July 27 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreeing with 
the proposal.


-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0383.html
[2] http://www.w3.org/TR/2010/CR-view-mode-20100624/

Re: [websockets] Getting WebSockets API to Last Call

[Arthur Barstow]

Regarding the bugs Adrian identified in the e-mail below, here is my 
take on the status:


* Resolved: NeedsInfo: 9973, 12180, 13104; WontFix: 12816, 13178
* Moved to another component: 10213
* Open and considered Editorial (thus will not block LC): 12510, 13162, 
13180 and 13172 (not in Adrian's original list)


Since Adrian's email, Brian submitted two additional bugs that are Open:

13294 "The send() method should fail the WebSocket connection when data 
cannot be sent "

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13294

13295 "The "make disappear a WebSocket object" case should not fail the 
WebSocket connection"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295

Based on the various comments on 12917 (currently Resolved as WontFix), 
there is no consensus on this bug:


.

I will follow up separately on 12917 via the [1] thread.

Comments, corrections, etc. on the above status are welcome.

-Art Barstow

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

On 7/7/11 6:00 PM, ext Adrian Bateman wrote:

We're keen to resolve the remaining issues with the WebSockets API and have a 
timetable
to get to Candidate Recommendation. From informal conversations we've had, we 
believe
other browser vendors share this goal. I think the current WebSocket API is 
feature
complete and meets the requirements for publishing a Last Call working draft to
encourage wider review and feedback. There are no tracker issues for 
WebSockets. Here
is my analysis of the outstanding bugs (not closed, where resolution not Fixed).
I believe the outstanding issues could be resolved as Last Call comments and 
would like
to see a CfC to publish a LCWD shortly.

9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put 
normative
requirements in parenthesis
Resolved, NeedsInfo
MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date 
now, and
from an anonymous contributor

10213 - The definition of "absolute url" makeshttps:foo  not an absolute url
Open, Assigned to Adam Barth
MICROSOFT PROPOSAL: Section 3 of the protocol spec
(http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) 
shows the
valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the 
address
supplied does not match this format.

12180 - give the name of url to download the Jetty server
Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months 
ago
MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server 
implementations

12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, 
otherwise
they're ambiguous
Reopened, Assigned to Ian Hickson
MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call

12816 - Make second argument in constructor an object for future extensibility
Resolved, WontFix
MICROSOFT PROPOSAL: We think the second argument should be an object, not only 
for future
extensibility but to allow binaryType to be set now.

12917 - "deflate-stream" should be an optional extension when establishing a 
connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the 
protocol spec
on what is optional in the protocol. The API spec should not normatively 
mention specific
extensions. References to "deflate-stream" should be informative and only 
provided as examples.

13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 
2) onpong();
//allow client to receive response of ping
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We don't think this is necessary.

13162 - The notes really do need to be cleaned up to be made explicit.
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call

13178 - binaryType should be immutable after connection is established
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.

13180 - [Editorial] Causes that lead to failing the WebSocket connection, which 
results
in an error event, should be more clearly specified
Open, Assigned to Ian Hickson
MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Arthur Barstow]

Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail 
including this thread started by Adrian (Hixie's follow-up is [2]) and 
Adrian's general Web Sockets LC thread [3].


This bug is currently resolved as WontFix and this resolution is 
supported by at least Hixie and Jonas. Adrian, Takeshi and Greg have 
argued against this resolution (i.e. they do not support deflate-stream 
being a mandatory extension in the API).


What do others (Anne?, Maciej?, ...) think about this issue?

Given the Protocol is now in LC review, it seems relatively important to 
align the API and Protocol.


-Art Barstow

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0242.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0193.html

On 7/8/11 5:44 PM, ext Adrian Bateman wrote:

On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote:

12917 - "deflate-stream" should be an optional extension when

establishing a connection

Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling

the protocol spec

on what is optional in the protocol. The API spec should not

normatively mention specific

extensions. References to "deflate-stream" should be informative and

only provided as examples.

I strongly disagree. We must have interoperability amongst browser user
agents. Having some support compression and others not would lead to
authoring mistakes and will force us into either having or not having
compression based on how big sites first get this wrong.

It's fine to disagree, but you should disagree in the IETF working group where
this is made optional and not in the Web API. There will be other users of
WebSockets outside the browser and by implementing the protocol they won't be
required to implement this extension. In addition, there are still discussions
about whether this is an appropriate mechanism for compression since it requires
intermediaries to decompress the whole stream if they want to review messages.
There are still proposals to remove deflate-stream from the spec.

We think there are legitimate cases for implementing the protocol without
compression. That aside, however, we strongly disagree with one consumer of a
protocol, the Web API, making decisions to override the requirements of the
protocol spec.

Adrian.

Re: From-Origin FPWD

[Arthur Barstow]

On 7/22/11 11:08 AM, ext Anne van Kesteren wrote:

The WebApps WG published the From-Origin header proposal as FPWD:

  http://www.w3.org/TR/from-origin/

The main open issue is whether X-Frame-Options should be replaced by 
this header or should absorb its functionality somehow.


Anne - what list is X-Frame-Options being discussed?

RfC: Last Call of Page Visibility API; deadline August 18

[Arthur Barstow]

On July 21, the Web Performance WG published a Last Call Working Draft 
of the Page Visibility spec and WebApps has been asked to review it, 
especially its usage of Web IDL:


http://www.w3.org/TR/2011/WD-page-visibility-20110721/

Individual WG members are encouraged to provide individual feedback 
directly to the Web Performance WG. If you have comments, please send 
them to the following list by August 18:


public-web-p...@w3.org@w3.org
http://lists.w3.org/Archives/Public/public-web-perf/

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the WebApps WG can discuss it.


-AB

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Arthur Barstow]

On 7/25/11 5:05 PM, ext Aryeh Gregor wrote:

 From the discussion here, it sounds like there are problems with
WebSockets compression as currently defined.


Yes, this is what I have concluded too (and if we are wrong, I would 
appreciate it if someone on the hybi list would please clarify).



If that's the case, it
might be better for the IETF to just drop it from the protocol for now
and leave it for a future version, but that's up to them.


When hybi agrees on this issue, I would appreciate it if someone would 
update 12917  
and/or ping public-webapps.


-AB

CfC: publish Last Call WD of Progress Events; deadline August 2

[Arthur Barstow]

The pre-LC comment period for Progress Events resulted in no comments 
[1]. As such, Anne proposes a new LC be published and this is a CfC to 
do so:


http://dev.w3.org/2006/webapi/progress/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 2. Please send all comments to:


public-webapps@w3.org

Assuming there is consensus to publish this LCWD, the tentative  plan is 
to publish the LC on August 4 with a 3-week LC comment period (ending 
August 25).


-Art Barstow

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

Re: CORS/UMP to become joint WebApps and WebAppSec joint deliverable

[Arthur Barstow]

On 8/2/11 8:20 AM, ext Anne van Kesteren wrote:
On Tue, 02 Aug 2011 13:10:25 +0200, Anne van Kesteren 
 wrote:
Can we at least make it so that public-webapps@w3.org stays the list 
for technical discussion on CORS? We already switched mailing lists 
once (twice if you count going from the initial proposal on 
public-web...@w3.org to public-appform...@w3.org) and I would like to 
avoid doing it again. Getting feedback is hard enough as it is, 
requiring all relevant people to subscribe to yet another list would 
be bad.


If that is not possible I think I would prefer CORS and From-Origin 
to stay in the WebApps WG.


The From-Origin spec is WebApps'; it is _not_ a joint deliverable with 
the proposed WebAppSec WG.


I discussed this with Thomas on IRC (not logged) and he hopes that 
doing this work in a new group will open up new resources to get it 
moving along (e.g. to get a test suite). I am fairly skeptical, but we 
agreed that trying it out for half a year should be okay given the low 
activity of this work here in WebApps. If nothing much has changed the 
work moves back to WebApps, which should work per charters of both 
groups.


Did you guys agree on the "which list will CORS use going forward?" 
question?


I agree it can be a bit painful to subscribe to YA list but I think it 
has the advantage of getting some "new eyes" on the spec as well as the 
advantages mentioned above.


-AB

Re: [XHR]

[Arthur Barstow]

On 8/2/11 12:08 PM, ext gk...@gurpreetkaur.org wrote:

My Suggestions for XMLHttpRequest Document Page...

1) W3C Editor's Draft (red vertical bar on the left)-> Draft is 
something when you are putting things together. It's not a final 
product. It should be renamed or removed.


You are correct the "Editor's Draft" is not a "final product". That's 
what is meant by the use of "Draft" in this context.


2) This page is so long. I have to do so much scrolling. Don't need to 
display links for Previous Versions on multiple lines. Just have one 
link - open up a new page with previous versions links displayed.


3) As a developer, I don't care what the "Status of this Document" is. 
All I care about is what this object do. This section should be moved 
somewhere else.


4) Candidate Recommendation Exit Criteria: I really don't understand 
this section. Why do I need to know so much about the working group 
and their work. This should be given to them not the public.


The introductory part of the document (version data through the Table of 
Contents) is informative and useful to some people. Skip/Get over it if 
this information is not of interest to you.


-Art Barstow

Re: [XHR]

[Arthur Barstow]

On 8/2/11 1:09 PM, ext gk...@gurpreetkaur.org wrote:

XMLHttpRequest Document:

ECMAScriptHTTPAPI- ECMASCRIPT takes you to the following..
http://www.ecma-international.org/publications/standards/Ecma-262.htm

This is a specification for ECMA script. 


Yes, that's correct.


Where is the actual script?


I don't understand your question.

Since this list has ~550 subscribers, if you want to follow-up, please 
do so just to me (and do not include public-webapps).


-AB

Re: UAs shipping unprefixed websocket API implementations?

[Arthur Barstow]

Hi Boris, All,

On 8/2/11 9:48 AM, ext Boris Zbarsky wrote:
http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html indicates 
that the Chrome dev channel now has an unprefixed implementation of 
the WebSocket API, as far as I can tell.  Also as far as I can tell, 
the API is not really stabilized yet (e.g. there's the big open 
question about whether the compression stuff is required or forbidden).


Am I missing something?  Should UAs actually be shipping unprefixed 
websockets at this point?


[I think Anne's replies to this thread (the head is [1]) addressed the 
status of the compression issue in the API.]


Regarding the spec stability question, there is a bit of chicken-and-egg 
issue here with the protocol and API. IIRC, HyBi WG met last week and I 
think it would be useful if one of the HyBi participants would provide a 
short status/plan of the protocol spec.


The open bug list for the Web Socket API is at [2]. Additionally, Thomas 
started a thread about redirects [3].


-Art Barstow

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

[2] 
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=WebSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=


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



-Boris

CfC: publish new WD of DOM Core; deadline August 10

[Arthur Barstow]

Anne would like to publish a new WD of DOM Core and this is a Call for 
Consensus (CfC) to do so:


  http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Agreeing with this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support for the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps@w3.org by August 10 at the latest.


Positive response is preferred and encouraged and silence will be 
considered as agreement with the proposal.


-Art Barstow

CfC: publish new WD of XMLHttpRequest Level 2; deadline August 10

[Arthur Barstow]

Anne would like to publish a new WD of XMLHttpRequest Level 2 and this 
is a Call for Consensus (CfC) to do so:


  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

Agreeing with this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support for the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps@w3.org by August 10 at the latest.


Positive response is preferred and encouraged and silence will be 
considered as agreement with the proposal.


-Art Barstow

Re: [widgets] Re: Call for Prior Art Related to US Patent 7,743,336 and US Patent Application 20070101146

[Arthur Barstow]

Philippe - is there a deadline for responses? -Regards, Art Barstow

On 7/11/11 7:27 AM, ext Arthur Barstow wrote:
FYI, this announcement was forwarded to public-widgets-pag and there 
is at least one response to that CfPA:


  http://lists.w3.org/Archives/Public/public-widgets-pag/
  
http://lists.w3.org/Archives/Public/public-widgets-pag/2011JulSep/0001.html


On 7/8/11 4:22 PM, ext Philippe Le Hegaret wrote:

This is a public call for prior art. The W3C seeks information about
access control systems available before October 2005 and content
distribution systems before April 2006 that offer a viable solution that
may apply to the use of access requests policy in Widgets.

On 13 November 2009,  pursuant to its rights under W3C's Patent Policy,
Apple, Inc. disclosed US Published Patent Application No. 11/432,295 and
US Published Patent Application 11/409,276 and claimed that it applies
to the Web Application WG's Widget Access Request Policy specification.
Apple excluded all claims from the W3C Royalty-Free License commitment
of the W3C Patent Policy given by Participants of the Web Applications
Working Group.

In accordance with the exception procedures of the Patent Policy, W3C
launched a Patent Advisory Group (PAG) to determine possible solutions.
The PAG has advised W3C to issue this call for prior art.

People who wish to provide feedback should refer to the call for prior
art for more information:
   http://www.w3.org/2010/12/cfpa

Please, don't hesitate to forward this message to other public fora,

Regards,

Philippe

FYI: new IETF mail list re IANA Registration

[Arthur Barstow]

If you are interested in IANA's registration process, IETF created a new 
mail list to discuss "the evolution of registration 
policies/infrastructure for Web-related registries":


  https://www.ietf.org/mailman/listinfo/happiana

 Original Message 
Subject: 	Fwd: [happiana] New Non-WG Mailing List: happiana -- 
IETF/W3C/IANA Registry Happiness

Resent-Date:Wed, 3 Aug 2011 21:19:49 +
Resent-From:
Date:   Wed, 3 Aug 2011 14:19:13 -0700
From:   ext Mark Nottingham 
To: public-ietf-w3c 



For those interested, this is for discussion of the evolution of registration 
policies/infrastructure for Web-related registries. Please forward as you see 
fit.

Cheers,

Begin forwarded message:


 From: IETF Secretariat
 Date: 3 August 2011 11:54:36 AM PDT
 To: IETF Announcement list
 Cc: presn...@qualcomm.com, happi...@ietf.org
 Subject: [happiana] New Non-WG Mailing List: happiana -- IETF/W3C/IANA 
Registry Happiness



 A new IETF non-working group email list has been created.

 List address: happi...@ietf.org
 Archive: http://www.ietf.org/mail-archive/web/happiana/
 To subscribe: https://www.ietf.org/mailman/listinfo/happiana

 Purpose: This list is for discussion of IANA Registry issues to
 result in Happy IETF, Happy W3C, and Happy IANA.

 For additional information, please contact the list administrators.
 ___
 happiana mailing list
 happi...@ietf.org
 https://www.ietf.org/mailman/listinfo/happiana


--
Mark Nottingham   http://www.mnot.net/

Re: Reference to the HTML specification

[Arthur Barstow]

On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:

Several documents in the WebApps Working Group are linking to HTML, more
specifically to the WHATWG HTML specification. An example of those is
Progress Events. This is done for no reason than political as far as I
can tell. This undermines and is disrespectful the work of the HTML
Working Group. Unless the WebApps comes up with a set of good reasons of
why this is done and convince the HTML Working Group, those references
must be changed in order to publish the documents properly and respect
the work of the HTML Working Group,


Philippe,

Re the specific case of the Progress Events spec - when it was last 
published it included non-normative references to both version of HTML:


  http://www.w3.org/TR/progress-events/#references

May we do that again? (I interpret that to mean the W3C has a fixed 
version of HTML and the WHATWG has a tip-of-the-tree version of HTML and 
as such, I don't think it  'disses the HTMLWG nor the W3C.)


-AB

Re: Reference to the HTML specification

[Arthur Barstow]

On 8/5/11 8:50 AM, ext Philippe Le Hegaret wrote:

On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:

On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:

Several documents in the WebApps Working Group are linking to HTML, more
specifically to the WHATWG HTML specification. An example of those is
Progress Events. This is done for no reason than political as far as I
can tell. This undermines and is disrespectful the work of the HTML
Working Group. Unless the WebApps comes up with a set of good reasons of
why this is done and convince the HTML Working Group, those references
must be changed in order to publish the documents properly and respect
the work of the HTML Working Group,

Philippe,

Re the specific case of the Progress Events spec - when it was last
published it included non-normative references to both version of HTML:

http://www.w3.org/TR/progress-events/#references

May we do that again? (I interpret that to mean the W3C has a fixed
version of HTML and the WHATWG has a tip-of-the-tree version of HTML and
as such, I don't think it  'disses the HTMLWG nor the W3C.)

Again, what are the reasons to link to the WHATWG HTML version? What
does it mean for the work of the HTML Working Group? There are features
in the WHATWG version that got rejected in the HTML Working Group.


I agree with the requirement for a single normative reference for HTML 
and that it should be the HTMLWG's version.


However, I don't see any particular harm with including *non-normative* 
references to both given the reality is there are two versions of HTML 
serving two different organizations.


It seems somewhat myopic for the "HTMLWG" to pretend there is no other  
version of HTML (at least within the context of the informational 
reference in the PE spec) so I respectfully disagree including both 
references is "ditching" the W3C's version.


-AB


See

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?

This list keeps growing.

I don't think it's appropriate for one Working Group to ditch the work
of an other.

Philippe

RfC: LCWD of Progress Events; deadline September 1

[Arthur Barstow]

On August 9, WebApps published LCWD #2 of the Progress Events spec:

  http://www.w3.org/TR/2011/WD-progress-events-20110809/

The comment deadline is September 1. Please send all comments to:

   public-webapps@w3.org

-AB

CfC: publish LCWD of Web Storage; deadline August 17

[Arthur Barstow]

Given Hixie's recent set of bug fixes, the Web Storage spec now has zero 
bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/webstorage/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

CfC: publish LCWD of Web Workers; deadline August 17

[Arthur Barstow]

Given Hixie's recent set of bug fixes, the Web Workers spec now has zero 
bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


  http://dev.w3.org/html5/workers/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Re: HTTP, websockets, and redirects

[Arthur Barstow]

Hi All,

Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I 
would characterize them both as editorial [Bugs]. As such, the redirect 
issue Thomas originally reported in this thread (see [Head]) appears to 
be the only substantive issue blocking WSAPI Last Call.


If anyone wants to continue discussing this redirect issue for WSAPI, I 
recommend using e-mail (additionally, it may be useful to also create a 
new bug in Bugzilla).


As I understand it, the HyBi WG plans to freeze the Web Socket Protocol 
spec "real soon now" (~August 19?).


-Art Barstow

[WSAPI] http://dev.w3.org/html5/websockets/
[Head] 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.html
[Bugs] 
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=WebSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=



On 7/27/11 8:12 PM, ext Adam Barth wrote:

On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
  wrote:

Thanks Adam,

By discussed on some  mailing list, do you mean a *W3C* mailing list?

A quick search turned up this message:

"But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now."

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.html

I started that thread at Greg Wilkins' recommendation:

"This is essentially an API issue for the browser websocket object."

http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html


Also, allowing the users to handle these explicitly implies that the API does 
not mandate dropping the connection. Currently, the API does not have this 
flexibility, nor does it allow other uses of non-101 codes, like for 
authentication. I understand the potential risks with redirects in browsers, 
and I thought at one moment we were going to augment the security 
considerations with your help for additional guidance. If websec has already 
worked on similar language in some draft that we could reuse that would be 
great, or, similarly, if we could work with you on that text.

We can always add support for explicitly following redirects in the
future.  If we were to automatically follow them today, we'd never be
able to remove that behavior by default.

Adam



-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Sunday, July 24, 2011 13:35
To: Thomas Roessler
Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel
Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald Alvestrand;
Tobias Gondrom
Subject: Re: HTTP, websockets, and redirects

This issue was discussed on some mailing list a while back (I forget which).  
The
consensus seemed to be that redirects are the source of a large number of
security vulnerabilities in HTTP and we'd like users of the WebSocket API to
handle them explicitly.

I'm not sure I understand your question regarding WebRTC, but the general
answer to that class of questions is that WebRTC relies, in large part, on ICE 
to
be secure against cross-protocol and voicehammer attacks.

Adam


On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roessler  wrote:

The hybi WG is concerned about the following clause in the websocket API

spec:

When the user agent validates the server's response during the "establish a

WebSocket connection" algorithm, if the status code received from the server is
not 101 (e.g. it is a redirect), the user agent must fail the websocket 
connection.

http://dev.w3.org/html5/websockets/

Discussion with the WG chairs:

- this looks like a conservative attempt to lock down redirects in the
face of ill-understood cross-protocol interactions
- critical path for addressing includes analysis of interaction with
XHR, XHR2, CORS
- following redirects in HTTP is optional for the client, therefore in
principle a decision that a client-side spec can profile
- concern about ability to use HTTP fully before 101 succeeds, and
future extensibility

Salvatore and Gabriel will bring this up later in the week with websec, and 
we'll

probably want to make it a discussion with Webappsec, too.

Side note: Does WebRTC have related issues concerning multiple protocols in a

single-origin context?  Are there lessons to learn from them, or is the case
sufficiently different that we need a specific analysis here?

Thanks,

Re: Permission Systems across APIs

[Arthur Barstow]

Hi Philippe,

Thanks for notifying us of ENISA's work.

I generally agree W3C specs should be as consistent as possible and 
practical. If there is a need for WebApps WG to coordinate with some 
other group, please be more specific about the issue.


FYI, the Geolocation API is specified by the Geolocation WG [GeoWG]. The 
System Information API is specified by the DAPI WG and they are also 
doing the only explicit permissions-related work at the W3C that I know 
about [DAPIWG]. As such, if you have not already contacted those WGs, 
you may want to do so.


WebApps' specs are enumerated in [PubStatus]. If you have identified any 
specific spec issues, please submit them to the 
 mail list (or file a bug via [Bugzilla]). 
If ENISA's work resulted in test cases for any of WebApps' specs, please 
send the details to .


-Regards, Art Barstow

[GeoWG] http://www.w3.org/2008/geolocation/
[DAPIWG] http://www.w3.org/2009/dap/#roadmap
[PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
[Bugzilla] 
http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG


On 8/3/11 1:48 PM, ext Philippe De Ryck wrote:

The following comment contains information about a general observation,
identified during a recent security analysis of 13 W3C standards,
organized by ENISA (European Network and Information Security Agency),
and performed by the DistriNet Research Group (K.U. Leuven, Belgium).

The complete report is available at http://www.enisa.europa.eu/html5
(*), and contains information about the process, the discovered
vulnerabilities and recommendations towards improving overall security
in the studied specifications.



The security analysis of multiple specs shows that permission systems
are very inconsistent or incomplete across the specifications. The
specifications suffer from a number of problems, which will be addressed
below.

* Permission System Design

Several specifications include a permission system, without any
consistency between these systems. This is troublesome, since some
systems are fairly weak compared to other systems. One good example is
the Geo-location API versus the System Information API, where the latter
is much more extended (e.g. it requires permission for a pair of origins
for a framed document and distinguishes between one-host vs. monitoring
permissions).

Our recommendation is to co-ordinate these permission systems across
specifications. This would enable a strong permissions system for all
involved APIs and makes it less complicated for browser vendors.
Optionally, a separate permission specification, which describes how
permission systems should work across all the specifications, can be
created. The specification should describe the necessary types of
permissions (e.g. persistent vs one-time, one-shot permission vs a
watching process, ...) and what they are based on. The specifications
describing the APIs can then reference the permission specification with
a certain type of permission, and require the implementation of that
permission system. This brings consistency across all permission systems
and decouples improvements to permission systems from functionality
developments. Recent work on Feature Permissions
[http://dev.w3.org/2009/dap/perms/FeaturePermissions.html] already
points in this direction, but does not yet cover all aspects raised in
this analysis.

Additionally, it might be useful to investigate potential conflicts of
the permission systems with underlying security controls (e.g. on a
smartphone device). Integration of API permissions systems and
underlying security controls not only avoids potential conflicts between
systems, but can also be useful in delivering an integrated and
consistent experience to the end user.

* User Interfaces

The specifications do not include much detail about the user interfaces
for giving permissions and managing permissions. Typically, they require
that the origin of the document is displayed. One major missing item is
the nature of the permission (one-shot vs watching process) as well as
the actual document requesting it (e.g. is it sandboxed or framed? is it
visible?). For managing permissions, the specifications typically state
that it should be clear and easily usable. This is very vague and is not
even a strong requirement (should instead of must). Evidence of this are
the current permission management interfaces, which are not always
intuitive or clear.

Our recommendation is to extend the specifications to include more UI
requirements. At least all the aspects of the requested permission
should be present. For managing the permissions, the specifications
should describe how it should happen (not what it should look like). For
example, they could state that "A user must be able to get an overview
of all assigned permissions, grouped per origin".

Optionally, these UI requirements can be included into the
abovementioned separate permission specific

Re: Restricted Contexts (private browsing / sandbox)

[Arthur Barstow]

Philippe - if there any specific issues for WebApps' specs [PubStatus], 
please start a new thread on public-webapps with an appropriate subject.


-ArtB

[PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus

On 8/3/11 1:49 PM, ext Philippe De Ryck wrote:

The following comment contains information about a general observation,
identified during a recent security analysis of 13 W3C standards,
organized by ENISA (European Network and Information Security Agency),
and performed by the DistriNet Research Group (K.U. Leuven, Belgium).


...




(*) HTML version of the report is available as well:
https://distrinet.cs.kuleuven.be/projects/HTML5-security/

CfC: publish LCWD of Server-sent Events spec; deadline August 17

[Arthur Barstow]

Given Hixie's recent set of bug fixes, the Server-sent Events spec now 
has zero bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/eventsource/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Rescinding the DOM 2 View Recommendation?

[Arthur Barstow]

Anne, Ms2ger, All,

Anne and others proposed in [Proposal] the DOM 2 View Recommendation 
[D2V] be "rescinded". The rescinding process is defined in the Process 
Document [Rescind]. However,  Ian Jacobs just indicated in IRC 
[#webapps] it has never actually been used.


One process requirement for rescinding a Recommendation is a "separate 
rationale for the proposal to rescind". Would you Anne and/or someone 
please create the rationale document (using WebApps' wiki)? I think it 
should include a clear problem statement i.e. identify the interop 
issues this Recommendation is causing as well as the alternative (new) 
solution.


If anyone has comments about this proposal, please speak up.

-ArtB

[Proposal] 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0454.html

[D2V] http://www.w3.org/TR/DOM-Level-2-Views/
[#webapps] http://krijnhoetmer.nl/irc-logs/webapps/20110810

RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Arthur Barstow]

[ Topic changed to how to organize the group's DOM specs ... ]

Hi Adrian, Anne, Doug, Jacob, All,

The WG is chartered to do maintenance on the DOM specs so a question for 
us is how to organize the DOM specs, in particular, whether Anne's DOM 
spec should be constrained (or not) to some set of features e.g. the 
feature set in the DOM L3 Core spec.


There are advantages to the monolithic/kitchen-sink approach and, as we 
have seen with other large specification efforts, there aredisadvantages 
too. In general, I prefer smaller specs with a tight{er,ish} scope and I 
think there should be compelling reasons to take the monolithic 
approach, especially if there is a single editor. Regardless of the 
approach, the minimal editor(s) requirements are: previous credible 
experience, technical competence in the area, demonstrated ability to 
seek consensus with all of the participants and willingness to comply 
with the W3C's procedures for publishing documents.


In the case of AvK's DOM spec, there has been some progressive feature 
creep. For instance, the 31-May-2011 WD included a new chapter on Events 
(with some overlap with D3 Events). The 2-Aug-2011 ED proposed for 
publication includes a new chapter on Traversal. Additionally, the ED 
still includes a stub section for mutation events which is listed as a 
separate deliverable in group's charter ("Asynchronous DOM Mutation 
Notification (ADMN)").


Before we publish a new WD of Anne's DOM spec, I would like comments on 
how the DOM specs should be organized. In particular: a) whether you 
prefer the status quo (currently that is DOM Core plus D3E) or if you 
want various additional features of DOM e.g. Traversal, Mutation Events, 
etc. to be specified in separate specs; and b) why. Additionally, if you 
prefer features be spec'ed separately, please indicate your willingness 
and availability to contribute as an editor vis-à-vis the editor 
requirements above.


-ArtB

On 8/4/11 2:24 PM, ext Adrian Bateman wrote:

On Wednesday, August 03, 2011 7:12 AM, Arthur Barstow wrote:

Anne would like to publish a new WD of DOM Core and this is a Call for
Consensus (CfC) to do so:

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Agreeing with this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support for the contents of the WD.

If you have any comments or concerns about this proposal, please send
them topublic-weba...@w3.org  by August 10 at the latest.

Positive response is preferred and encouraged and silence will be
considered as agreement with the proposal.

Microsoft has some concerns about this document:

1. We have received feedback from both customers and teams at Microsoft that
the name DOM Core is causing confusion with the previous versions of DOM Core.
We request that the specification be named DOM Level 4 Core. The original Web
DOM Core name would also be acceptable.

2. The scope of the document is unclear. Microsoft believes that the document
should focus on core DOM interfaces to improve interoperability for DOM Core
in the web platform and to incorporate errata. If there are problems with
other specification such as Traversal, those documents should be amended.
This functionality shouldn't be pulled into DOM Core. We believe improvements
for mutation events should be kept a separate deliverable for this working
group (ADMN).

We would prefer to see these issues addressed before moving ahead with
publication.

Thanks,

Adrian.

Reminder: RfC: Last Call Working Draft of Web IDL; deadline August 23

[Arthur Barstow]

Reminder: August 23 is the comment deadline for the 12-July-2011 Last 
Call Working Draft of Web IDL:


http://www.w3.org/TR/2011/WD-WebIDL-20110712/

 Original Message 
Subject:RfC: Last Call Working Draft of Web IDL; deadline August 23
Resent-Date:Tue, 12 Jul 2011 16:14:30 +
Resent-From:
Date:   Tue, 12 Jul 2011 12:14:00 -0400
From:   ext Arthur Barstow 
Reply-To:   public-script-coord 
To: 	public-webapps , public-script-coord 





On July 12 a Last Call Working Draft of Web IDL was published:

  http://www.w3.org/TR/2011/WD-WebIDL-20110712/

The deadline for comments is August 23 and all comments should be sent to:

   public-script-co...@w3.org

Cameron, Philippe - if you think it is necessary, please fwd this e-mail
to ECMA TC39.

-AB

Re: Rescinding the DOM 2 View Recommendation?

[Arthur Barstow]

On 8/10/11 6:02 PM, ext Doug Schepers wrote:
After discussion with PLH and Ian Jacobs, and I don't think it's 
necessary for us to go through the additional overhead of rescinding 
the DOM 2 View specification.


Instead, PLH and I support Anne's original proposal to simply update 
the status section of the spec to point people to the HTML5 spec.  We 
could add wording like:


[[
Updated definitions of the 'document' and 'defaultView' attributes are 
now defined by the HTML5 specification.  Other concepts in this 
specification may not be necessary for implementation in general user 
agents such as Web browsers.

]]

I don't object to rescinding it, I simply prefer the option with the 
least process necessary.


Anne, Ms2ger, All - can you live with adding a note to D2V rather than 
going down the rescind path?


-AB

Re: [WebIDL] remove modules

[Arthur Barstow]

Hi Paddy,

If modules are removed from the Web IDL spec, what running code e.g. 
browsers, web/widget runtimes, IDEs, test cases, etc. will no longer 
comply with the spec (looking for real breakages here)?


If WAC needs that type of functionality, could they define their own IDL 
extension?


-ArtB

On 8/12/11 2:27 AM, ext Paddy Byers wrote:
(Previously send to public-script-coord but I was asked to forward to 
webapps.)


Hi,

Two things to be aware of if we drop the feature:

One, BONDI folks were using IDL modules, IIRC. Although I think their
spec stabilised well before now, so presumably they’re dependent on an
earlier WD of Web IDL, and thus it’s probably not a big deal to
drop the
feature, aside from the fact that we should focus on the Web and not
other concerns.


The BONDI spec has been superseded by the WAC spec [1] and this still 
uses modules. The WAC spec is frozen and there is already a growing 
list of incompatibilities between the WAC WebIDL and the latest WebIDL 
spec - so in any event there would need to be changes if WAC creates a 
new revision of its spec and wishes to migrate to the latest WebIDL.


However, the motivation for using modules I think still stands, in 
that a module is the unit by which support for a given feature is enabled.


That is, we associate a WebIDL module with one or more features (in 
the sense of [2]). If one or more of the features associated with a 
module is successfully requested, then all of the interfaces belonging 
to that module are available, and all of the objects (eg interface 
objects) entailed by those interfaces are instantiated.


If modules are dropped from WebIDL, then there would still be a desire 
I think to have a logical grouping of interfaces, but we would have to 
specify that in prose instead of in WebIDL.


Thanks - Paddy

[1]:http://specs.wacapps.net/2.0/jun2011/deviceapis/webidl.html
[2]: http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes

Re: CfC: publish LCWD of Web Storage; deadline August 17

[Arthur Barstow]

Given no objections to this CfC and no subsequent bug activity, I will 
work towards a LC publication on September 1 with a 3-week review period.


On 8/10/11 7:33 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Web Storage spec now has 
zero bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/webstorage/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Re: CfC: publish LCWD of Web Workers; deadline August 17

[Arthur Barstow]

Bug 13772 was filed after the CfC started and since it appears to be an 
editorial bug, I will work towards a LC publication on September 1 with 
a 3-week review period.


Bug 13373 had some discussion after the CfC ended. However, it is 
currently resolved as WONTFIX and as such will not block the LC publication.


On 8/10/11 7:35 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Web Workers spec now has 
zero bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


  http://dev.w3.org/html5/workers/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Re: CfC: publish LCWD of Server-sent Events spec; deadline August 17

[Arthur Barstow]

Since this CfC was started, 6 new bugs have been filed against this spec 
[1]. As such, an LC will not be published until these bugs are addressed.


[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Server-Sent%20Events%20%28editor%3A%20Ian%20Hickson%29&resolution=---


On 8/10/11 10:24 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Server-sent Events spec now 
has zero bugs. As such, it appears this spec is ready to proceed on 
the Recommendation track and this is a Call for Consensus to publish a 
new LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/eventsource/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Reminder: RfC: LCWD of Progress Events; deadline September 1

[Arthur Barstow]

On 8/9/11 1:34 PM, ext Arthur Barstow wrote:

On August 9, WebApps published LCWD #2 of the Progress Events spec:

  http://www.w3.org/TR/2011/WD-progress-events-20110809/

The comment deadline is September 1. Please send all comments to:

   public-webapps@w3.org

-AB

Re: HTTP, websockets, and redirects

[Arthur Barstow]

Hi Brian, All - I just checked Bugzilla and besides the two editorial 
type bugs (12510 and 13700), bug 13777 was filed against the Web Sockets 
API on August 15:


  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777

Currently, there have been no followup comments on 13777 and I think it 
should be addressed before the LC is published.


-Art Barstow


On 8/25/11 2:31 PM, ext Brian Raymor wrote:

On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow<  art.bars...@nokia.com>   
wrote:

Hi All,

Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I
would characterize them both as editorial [Bugs]. As such, the
redirect issue Thomas originally reported in this thread (see [Head])
appears to be the only substantive issue blocking WSAPI Last Call.

As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be 
characterized as editorial bugs.

Microsoft has no objections to the requirement to fail non-101 responses such 
as redirects. If there are no further concerns in the working group related to 
this issue, then the current WebSocket API looks feature complete. I recommend 
that we publish a Last Call working draft and define a timetable to reach 
Candidate Recommendation.


If anyone wants to continue discussing this redirect issue for WSAPI,
I recommend using e-mail (additionally, it may be useful to also
create a new bug in Bugzilla).

As I understand it, the HyBi WG plans to freeze the Web Socket
Protocol spec "real soon now" (~August 19?).

-Art Barstow

[WSAPI] http://dev.w3.org/html5/websockets/
[Head]
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.ht
ml
[Bugs]
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short
_de sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=We
bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&
longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_white
boar
d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywo
r ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailt
ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyex
act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=d
oit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-
0=noop&value0-0-0=


On 7/27/11 8:12 PM, ext Adam Barth wrote:

On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
wrote:

Thanks Adam,

By discussed on some  mailing list, do you mean a *W3C* mailing list?

A quick search turned up this message:

"But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now."

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.
html

I started that thread at Greg Wilkins' recommendation:

"This is essentially an API issue for the browser websocket object."

http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html


Also, allowing the users to handle these explicitly implies that
the API does

not mandate dropping the connection. Currently, the API does not have
this flexibility, nor does it allow other uses of non-101 codes, like
for authentication. I understand the potential risks with redirects
in browsers, and I thought at one moment we were going to augment the
security considerations with your help for additional guidance. If
websec has already worked on similar language in some draft that we
could reuse that would be great, or, similarly, if we could work with you on 
that text.

We can always add support for explicitly following redirects in the
future.  If we were to automatically follow them today, we'd never
be able to remove that behavior by default.

Adam



-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Sunday, July 24, 2011 13:35
To: Thomas Roessler
Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel
Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald
Alvestrand; Tobias Gondrom
Subject: Re: HTTP, websockets, and redirects

This issue was discussed on some mailing list a while back (I
forget which).  The consensus seemed to be that redirects are the
source of a large number of security vulnerabilities in HTTP and
we'd like users of the WebSocket API to handle them explicitly.

I'm not sure I understand your question regarding WebRTC, but the
general answer to that class of questions is that WebRTC relies,
in large part, on ICE to be secure against cross-protocol and
voicehammer

attacks.

Adam


On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roesslerwrote:

The hybi WG is concerned about the following clause in the
websocket API

spec:

When the user agent validates the server's response during the
"establish a

WebSocket connection" algorithm, if the status code received from
the server is not 101 (e.g. it is a 

Re: Request for participation in W3C widgets standard

[Arthur Barstow]

Hi Ronny - to formally participate in the Web Applications WG, your 
company must first join the W3C and information about that process can 
be found in [1].


Re W3C widgets, I consider the v1 specs functionally complete with the 
exception of the Widget Update specs. See [2] for the status of the 
group's widget specs.


The WG does have a "Widgets Embedding" spec in its charter. There hasn't 
been any formal  work done on that spec although there is a wiki to 
gather links to related resources [3].


-Art Barstow

[1] http://www.w3.org/Consortium/membership
[2] http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications
[3] http://www.w3.org/2008/webapps/wiki/WidgetEmbedding

On 8/25/11 4:37 PM, ext Ronny A Pena wrote:

Hello W3C,

My company is looking to become an active participant in the W3C 
widgets standard. We are a portal software company and we have a 
widget standard that is similar to this standard and OpenSocial 
Gadgets. We would like to participate as allowed by W3C in the 
requirements definition and standard definition. Also, We would love 
to be listed a user agent that is looking to support this standard in 
our 5.0 release. Please let me know what the process is for active 
participation.


Regards,
--
*Ronny A Pena
*/Senior Solution Architect

/Backbase / Customer Experience Solutions
T / 917-566-5222
E / ro...@backbase.com 
W / www.backbase.com 
349 5th Ave, New York, NY 10016

Click here to register for our Webinar Series 

Re: Rescinding the DOM 2 View Recommendation?

[Arthur Barstow]

On 8/13/11 6:19 AM, ext Anne van Kesteren wrote:
On Thu, 11 Aug 2011 00:02:56 +0200, Doug Schepers  
wrote:
After discussion with PLH and Ian Jacobs, and I don't think it's 
necessary for us to go through the additional overhead of rescinding 
the DOM 2 View specification.


Instead, PLH and I support Anne's original proposal to simply update 
the status section of the spec to point people to the HTML5 spec.  We 
could add wording like:


[[
Updated definitions of the 'document' and 'defaultView' attributes 
are now defined by the HTML5 specification.  Other concepts in this 
specification may not be necessary for implementation in general user 
agents such as Web browsers.

]]

I don't object to rescinding it, I simply prefer the option with the 
least process necessary.


This works for me and is actually what we decided back in 2009 as 
Working Group and back then Ian Jacobs said it was okay


http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0454.html

so I am glad this is acceptable again. Lets do it.


Doug - do you know of any RECs that contain such text (that we can review)?

Anne, Ms2ger - would you please propose some text we can review?

-Thanks, AB

CfC: obsolescence text for DOM 2 View Recommendation; deadline September 7

[Arthur Barstow]

In [1], Anne proposed some text be added to the top of the DOM 2 View 
REC [2] to signal the 'document' and 'defaultView' attributes are now 
defined in HTML5 and this Recommendation is now effectively obsolete. We 
discussed some updates to the proposed text in IRC [3] and we now 
propose the following text be added to this REC:


[[
Note: This paragraph is informative. This document is currently not 
maintained. The concepts this document defines are obsolete. The 
'document' and 'defaultView' attributes are defined in the HTML5 
specification with simplified semantics. The Web Applications WG 
encourages implementation of these concepts as defined by HTML5.

]]

If you have any comments, please send them by September 7.

-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0454.html
[2] http://www.w3.org/TR/DOM-Level-2-Views/
[3] http://krijnhoetmer.nl/irc-logs/webapps/20110831

Re: Last Call: Performance Timeline, User Timing, and Resource Timing

[Arthur Barstow]

Individuals are encouraged to provide individual feedback directly to 
the Web Performance WG.


If anyone in WebApps WG wants to propose an official WG response, please 
do so ASAP, in reply to this email so the WebApps WG can discuss it.


On 9/1/11 3:54 PM, ext Philippe Le Hegaret wrote:

This is a Last Call Working Draft transition announcement for the
following 3 documents:

Performance Timeline
  http://www.w3.org/TR/2011/WD-performance-timeline-20110901/
User Timing:
  http://www.w3.org/TR/2011/WD-user-timing-20110901/
Resource Timing:
  http://www.w3.org/TR/2011/WD-resource-timing-20110811/

Deadline of comments on the first two documents is September 22.
Resource Timing is September 15, but due to this late announcement,
please let us know if you're planning to send comments after the
deadline.

Please send comments to public-web-p...@w3.org (archived) with ,
[UserTiming], or [ResourceTiming] at the start of the subject line.

Thank you,

Philippe

Re: RfC: LCWD of Progress Events; deadline September 1

[Arthur Barstow]

Cyril - unless we hear otherwise from you, we will assume you are 
satisfied with the way your comments have been addressed:


  http://dev.w3.org/2006/webapi/progress/

Anne - assuming Cyril is agreeable with the way his comments were 
addressed, please update the ED to reflect a CR publication (e.g. add CR 
exit criteria you used in rev 1.25) and notify me when you are done so I 
can start a CfC to publish a CR.


-Thanks, AB

On 8/16/11 7:54 AM, ext Anne van Kesteren wrote:
On Tue, 16 Aug 2011 10:06:25 +0200, Cyril Concolato 
 wrote:
The sentence is so unreadable that it's hard to suggest something. It 
starts with a general statement but ends with an example. I think it 
should be split in two: general statement with a full sentence (now 
it seems to end at "letter" ?) and then add the example. Also add 
"to" before "prefix" and "start".


Fair enough, I dropped it. Progress Events is so small anyway and the 
specification it depends upon (DOM Core) already has clearer text on 
extensibility.




There are no requirements.


When reading that: "The editor is encouraged to define it in a way 
consistent with this", it did not seem so.


Well there are no specific requirements. If other editors do it wrong 
that will be pointed out, but since use can vary wildly I doubt that 
will happen much.




Because it very much depends on the context.


Example ?


Cross-origin XMLHttpRequest versus same-origin XMLHttpRequest versus 
the HTML application cache feature.

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Arthur Barstow]

Hi All,

Thanks for the comments and discussion! I finally reviewed all of the 
responses and here are my thoughts on moving forward ...


Some members of the group consider the D3E spec as the highest priority 
of our DOM-related specs and they have put considerable resources into 
that spec. Doug and Jacob will continue to lead that spec effort, and as 
I understand it, a CR for D3E is imminent. I expect the group to help 
progress that spec.


At the same time, others members have put substantial resources into DOM 
Core (and closely related functionality such as DOM Range). Naturally, 
they want to preserve that investment and I support that work 
continuing. Although Aryeh's DOM Range spec was recently added to DOM 
Core, the totality is still relatively small, at least when compared to 
some other specs such as HTML5, SVG1, CSS2.


To help address "feature creep" for DOM Core, the Editors will notify 
the list before adding any significant features to the spec.


Aryeh will become an Editor of DOM Core. Others that make substantial 
contributions will also be considered as additional Editors (provided 
they meet the type of requirements listed below). Adrian mentioned 
Microsoft may be willing to provide editor resources for DOM and their 
participation in DOM Core would of course be welcome.


Re the scope of DOM Core, I agree the spec lacks clear text regarding 
its scope. Inputs for scope, as well as the spec's requirements, should 
be submitted to the list.


Re the degree of "done-ness" of the various parts of DOM Core, I agree 
this can create various issues. To help address this issue, it may be 
useful for specific sections to include descriptive text about that 
section's implementation and deployment status.


The CfC to publish a new WD of DOM Core was blocked by this RfC. I will 
proceed with a  request to publish a new WD of DOM Core in TR/. The name 
DOM Core will be used for the upcoming WD. If anyone wants to propose a 
name change, please start a *new* thread.


-Regards, ArtB

On 8/11/11 6:28 AM, ext Arthur Barstow wrote:

[ Topic changed to how to organize the group's DOM specs ... ]

Hi Adrian, Anne, Doug, Jacob, All,

The WG is chartered to do maintenance on the DOM specs so a question 
for us is how to organize the DOM specs, in particular, whether Anne's 
DOM spec should be constrained (or not) to some set of features e.g. 
the feature set in the DOM L3 Core spec.


There are advantages to the monolithic/kitchen-sink approach and, as 
we have seen with other large specification efforts, there 
aredisadvantages too. In general, I prefer smaller specs with a 
tight{er,ish} scope and I think there should be compelling reasons to 
take the monolithic approach, especially if there is a single editor. 
Regardless of the approach, the minimal editor(s) requirements are: 
previous credible experience, technical competence in the area, 
demonstrated ability to seek consensus with all of the participants 
and willingness to comply with the W3C's procedures for publishing 
documents.


In the case of AvK's DOM spec, there has been some progressive feature 
creep. For instance, the 31-May-2011 WD included a new chapter on 
Events (with some overlap with D3 Events). The 2-Aug-2011 ED proposed 
for publication includes a new chapter on Traversal. Additionally, the 
ED still includes a stub section for mutation events which is listed 
as a separate deliverable in group's charter ("Asynchronous DOM 
Mutation Notification (ADMN)").


Before we publish a new WD of Anne's DOM spec, I would like comments 
on how the DOM specs should be organized. In particular: a) whether 
you prefer the status quo (currently that is DOM Core plus D3E) or if 
you want various additional features of DOM e.g. Traversal, Mutation 
Events, etc. to be specified in separate specs; and b) why. 
Additionally, if you prefer features be spec'ed separately, please 
indicate your willingness and availability to contribute as an editor 
vis-à-vis the editor requirements above.


-ArtB

On 8/4/11 2:24 PM, ext Adrian Bateman wrote:

On Wednesday, August 03, 2011 7:12 AM, Arthur Barstow wrote:

Anne would like to publish a new WD of DOM Core and this is a Call for
Consensus (CfC) to do so:

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Agreeing with this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support for the contents of 
the WD.


If you have any comments or concerns about this proposal, please send
them topublic-weba...@w3.org  by August 10 at the latest.

Positive response is preferred and encouraged and silence will be
considered as agreement with the proposal.

Microsoft has some concerns about this document:

1. We have received feedback from both customers and teams at 
Microsoft that
the name DOM Core is causing confusion with the previous versions of 
DOM Core.
We reque

CfC: publish Candidate Recommendation of Progress Events; deadline Sept 11

[Arthur Barstow]

The August 9 Progress Events Last Call comment period ended with 1 
comment and that comment appears to have been adequately addressed [1]. 
As such, Anne proposes the spec be published as a Candidate 
Recommendation and this is a Call for Consensus (CfC) to do so:


  http://dev.w3.org/2006/webapi/progress/

This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process 
Document:


  http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

The exit criteria is included in the ED:

http://dev.w3.org/2006/webapi/progress/#crec

As with all of our CfCs, positive response is preferred and encouraged 
and silence will be considered as agreeing with the proposal. The 
deadline for comments is September 11.


(Anne - please add the August 9 LCWD to the list of "Previous Versions").

-Art Barstow

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

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Arthur Barstow]

On 9/5/11 3:34 PM, ext Tab Atkins Jr. wrote:

We should make these kinds of
decisions *solely* on technical grounds.


Well surely making decisions on technical grounds is important. However, 
it seems a bit simplistic to consider it the only factor. (I seem to 
recall some previous decisions were based, for example, on existing 
implementations and deployments.)


-AB

RfC: LCWD of Web Storage; deadline September 27

[Arthur Barstow]

A new LCWD of Web Storage was published:

  http://www.w3.org/TR/2011/WD-webstorage-20110901/

Please send all comments to public-webapps@w3.org by September 27.

RfC: LCWD of Web Workers; deadline September 27

[Arthur Barstow]

A new LCWD of Web Workers was published:

  http://www.w3.org/TR/2011/WD-workers-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Re: [widgets] CFC to republish Widget URI spec

[Arthur Barstow]

All - we had a brief chat about this request in IRC [1].

Marcos wants to publish a new WD (last publication was a LCWD) and the 
tentative publication date for that WD is Sept 13.


After there is "working code" for this spec, Marcos will resume/restart 
the scheme registration discussion.


-AB

[1] http://krijnhoetmer.nl/irc-logs/webapps/20110906

On 8/24/11 10:09 AM, ext Marcos Caceres wrote:

  Hi,
I would like to republish the Widget URI scheme spec as a Working Draft.

http://dev.w3.org/2006/waf/widget-uris/

Please consider this a 1 Week CFC - if you object, please let the group know.

What's new:
  0 . Added a bunch of examples.
  1. Resolving URIs is now left to the host Document (i.e., HTML5's resolve URL 
algorithms).
  2. Added straw-man for behaving like HTTP (inspired by FileAPI's blob://)
  3. Generalized the dereferencing algorithm so non P&C compliant runtimes can 
use it.

I will continue doing a minor cleanup over the next week.

Kind regards,
Marcos

RfC: rename DOM Core to DOM4; deadline Sept 9

[Arthur Barstow]

It appears the majority of the people that voiced an opinion on this 
thread prefer "DOM4".


If anyone objects to DOM4, please speak up by September 9 at the latest 
and include the rationale for your objection as well as an alternate 
proposal.


On 9/4/11 9:39 AM, ext Anne van Kesteren wrote:
On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow 
 wrote:
The CfC to publish a new WD of DOM Core was blocked by this RfC. I 
will proceed with a  request to publish a new WD of DOM Core in TR/. 
The name DOM Core will be used for the upcoming WD. If anyone wants 
to propose a name change, please start a *new* thread.


Given that the specification replaces most of DOM2 and DOM3 I suggest 
we name it DOM4, including for the upcoming WD (or alternatively a WD 
we publish a couple of weeks later).

Re: [DOM] Scope

[Arthur Barstow]

On 9/4/11 9:38 AM, ext Anne van Kesteren wrote:
On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow 
 wrote:
Re the scope of DOM Core, I agree the spec lacks clear text regarding 
its scope. Inputs for scope, as well as the spec's requirements, 
should be submitted to the list.


Please say what is unclear about this:

  http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#goals


I think the changes you made in mid-August plus later refinements are 
much better.


(I can't quite parse the later part of point #1 starting with ", and do 
the following [REF][REF]..." but that's an editorial nit we can take 
offline).


-AB

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Arthur Barstow]

On 9/9/11 6:27 AM, ext Olli Pettay wrote:

On 09/07/2011 05:09 PM, Aryeh Gregor wrote:
On Sun, Sep 4, 2011 at 9:12 AM, Arthur 
Barstow  wrote:
Some members of the group consider the D3E spec as the highest 
priority of
our DOM-related specs and they have put considerable resources into 
that

spec. Doug and Jacob will continue to lead that spec effort, and as I
understand it, a CR for D3E is imminent. I expect the group to help 
progress

that spec.

At the same time, others members have put substantial resources into 
DOM
Core (and closely related functionality such as DOM Range). 
Naturally, they

want to preserve that investment and I support that work continuing.


The real question is not who's invested what, it's what browsers will
implement.  If we're moving toward a situation where IE will implement
D3E and everyone else will implement DOM Core's idea of events,

What is the real difference in D3E and DOM4's "idea of events"?
Just some different syntax for initialization (new Event() ), which I
see as an additional feature on top of D3E.

Features in D3E are actively being implemented also in non-IE browsers.

 and

both groups will claim to be implementing "the standard", that's an
absolutely terrible idea and we need to put a stop to it right now.
If the only real reason for it is because different editors or
employers have made investments in different bodies of spec text,
instead of because browser implementers actually disagree on what they
should implement, that's even worse.  I would object in the strongest
terms to progressing any standard to CR if it contains features that
are specified differently in a different standard, if it looks
plausible that different implementers will follow different versions.

(I have not looked at the content of D3E or DOM Core, though, so I
can't say specifically how bad the situation would be if this
happened, nor which should be retired in favor of the other.)


Atm the situation isn't bad, IMHO. DOM4 just adds something on top
of D3E.


The D3E and DOM Core (nka DOM4) compatibility question has been asked 
before. I believe some alignments on both sides were made last May 
(before DOM Core was last published in /TR/).


If additional changes need to be made to make these specs compatible, 
the www-dom list should be used for related discussions, issues, etc.


-ArtB

CfC: publish LC#2 of Web IDL; deadline September 16

[Arthur Barstow]

Hi All - based on the changes made to address the comments received [1] 
for Web IDL LC #1, Cameron recommends WebApps publish LC#2 and this is a 
Call for Consensus (CfC) to do so:


  http://dev.w3.org/2006/webapi/WebIDL/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreement with the proposal. The deadline for 
comments is September 16. Please send all comments to:


  public-script-co...@w3.org

-Art Barstow

[1] http://dev.w3.org/2006/webapi/WebIDL/lc1.txt

 Original Message 
Subject:publishing Web IDL with a second LCWD
Resent-Date:Fri, 9 Sep 2011 13:29:28 +
Resent-From:
Date:   Fri, 9 Sep 2011 23:28:43 +1000
From:   ext Cameron McCormack 
To: public-script-co...@w3.org 



Hello everyone.

I've just finished resolving the LC comments on Web IDL.  The only
sticking point is the one about modules -- I decided to defer their
removal just because I don't have the time right now, but it seems like
that is the right thing to do.  I think it should be OK to drop them
from the spec after the publication, and not have that be an impediment
to going to CR afterwards.  Similarly, there was some editorial work
(making more obvious which features are for legacy APIs only) that I did
not get to.  I will do that once I am back, too.

There were a couple of questions in Allen Wirfs-Brock's feedback that
weren't direct requests for changes, but my response questions to him
might result in some further changes at some point.  Nothing drastic,
though.

The lc1.txt file is up to date, I believe.  We probably don't need to
wait for commenter satisfaction indication in all cases, since we are
not going to CR straight away.

I'm away for the next four week, so it would be good if we could get the
spec published again.  Art, if you think we are good to go, could you do
a CfC for LCWD#2 (and assume my +1 to publishing) and handle the
publication?

Thanks,

Cameron

Fwd: W3C Workshop on the Future of Offline Web Applications (Call for Participation)

[Arthur Barstow]

Speaking of application caches and widgets, below is an announcement 
about a "Future of Offline Web Applications" workshop on Saturday 
November 5 in Redwood City CA US:


  http://www.w3.org/2011/web-apps-ws/

Position Papers are due September 30.

 Original Message 
Subject: 	Join the W3C Workshop on the Future of Offline Web 
Applications (Call for Participation)

Date:   Fri, 9 Sep 2011 20:16:07 +
From:   Ian Jacobs 









Dear Advisory Committee Representative,

W3C is pleased to announce an upcoming Workshop:

The Future of Offline Web Applications
5 November 2011
Redwood City, CA, USA
Hosted by Vodafone
http://www.w3.org/2011/web-apps-ws/

The Web has rapidly evolved into a platform suitable for applications that 
exhibit a level of richness and interaction that could barely be envisioned 20 
years ago. Word processors, email clients, navigation systems, and games are 
just a small sample of applications that are now a regular part of the Web 
experience, but there are many types of applications that are difficult to 
produce using Web technologies. In order to facilitate these complex 
applications move into the Web, additional functionality is required from the 
Open Web Platform.

Off-line use of Web applications is one of the key missing elements from the 
Web platform that application developers require. The current fragmentation in 
this solution space is creating confusion among would-be WebApp developers and 
organizations who would otherwise invest in the Open Web Platform.

The goal of this workshop is to identify a clear path forward for innovation in 
the Open Web Platform related to offline Web application invocation and use.

More background information for this Workshop is available:
 http://www.w3.org/2011/web-apps-ws/#cfp_background

If you have any questions, please contact the chairs: Daniel 
Appelquist  and Matt Womer.

This announcement follows section 9 of the Process Document:
   http://www.w3.org/2005/10/Process-20051014/events#GAEvents

Ian Jacobs, Head of W3C Communications

--
Important Dates

  9 September: Call for Participation
30 September: Deadline for position papers
15 October: Program released
28 October: Deadline for Registration
  5 November: Workshop

--
Requirements for Participation

Participation will be governed by the following:

 - To ensure maximum interaction among participants, the number of participants 
will be limited to two from one company.
 - W3C membership is not required to participate in this workshop.
 - Attendees are required to submit a Position Paper by email 
to  by 30 September

For details on Position Paper and Statement of Interest, see:
 http://www.w3.org/2011/web-apps-ws/#cfp_participationRequirements

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

Fwd: W3C Workshop on the Future of Offline Web Applications (Call for Participation)

[Arthur Barstow]

Speaking of application caches and widgets, below is an announcement 
about a "Future of Offline Web Applications" workshop on Saturday 
November 5 in Redwood City CA US:


  http://www.w3.org/2011/web-apps-ws/

Position Papers are due September 30.

 Original Message 
Subject: 	Join the W3C Workshop on the Future of Offline Web 
Applications (Call for Participation)

Date:   Fri, 9 Sep 2011 20:16:07 +
From:   Ian Jacobs 









Dear Advisory Committee Representative,

W3C is pleased to announce an upcoming Workshop:

The Future of Offline Web Applications
5 November 2011
Redwood City, CA, USA
Hosted by Vodafone
http://www.w3.org/2011/web-apps-ws/

The Web has rapidly evolved into a platform suitable for applications that 
exhibit a level of richness and interaction that could barely be envisioned 20 
years ago. Word processors, email clients, navigation systems, and games are 
just a small sample of applications that are now a regular part of the Web 
experience, but there are many types of applications that are difficult to 
produce using Web technologies. In order to facilitate these complex 
applications move into the Web, additional functionality is required from the 
Open Web Platform.

Off-line use of Web applications is one of the key missing elements from the 
Web platform that application developers require. The current fragmentation in 
this solution space is creating confusion among would-be WebApp developers and 
organizations who would otherwise invest in the Open Web Platform.

The goal of this workshop is to identify a clear path forward for innovation in 
the Open Web Platform related to offline Web application invocation and use.

More background information for this Workshop is available:
 http://www.w3.org/2011/web-apps-ws/#cfp_background

If you have any questions, please contact the chairs: Daniel 
Appelquist  and Matt Womer.

This announcement follows section 9 of the Process Document:
   http://www.w3.org/2005/10/Process-20051014/events#GAEvents

Ian Jacobs, Head of W3C Communications

--
Important Dates

  9 September: Call for Participation
30 September: Deadline for position papers
15 October: Program released
28 October: Deadline for Registration
  5 November: Workshop

--
Requirements for Participation

Participation will be governed by the following:

 - To ensure maximum interaction among participants, the number of participants 
will be limited to two from one company.
 - W3C membership is not required to participate in this workshop.
 - Attendees are required to submit a Position Paper by email 
to  by 30 September

For details on Position Paper and Statement of Interest, see:
 http://www.w3.org/2011/web-apps-ws/#cfp_participationRequirements

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

WebApps TPAC2011 meeting Oct 31 and November 1; request for agenda topics

[Arthur Barstow]

As indicated a few months ago [1], WebApps will have a f2f meeting 
during the October 31 - November 4 "TPAC" week:


  http://www.w3.org/2008/webapps/wiki/TPAC2011

We have a room reserved for Monday October 31 and Tuesday November 1. If 
you have any specific agenda requests, please send them to this list or 
add them to the wiki above.


As was done during our TPAC2010 meeting, my expectation is that we will 
use the beginning of each meeting day to identify topics of interest and 
insert those topics into open agenda slots.


-ArtB

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

RfC: LCWD of Touch Events version 1; deadline October 11

[Arthur Barstow]

On September 13, the Web Events WG published a LCWD of the Touch Events 
version 1 spec:


http://www.w3.org/TR/2011/WD-Touch-Events-20110913/

That WG explicitly asked the WebApps WG for comments.

Individual WG members are encouraged to provide individual feedback 
directly to the Web Events WG. If you have comments, please send them to 
the following list by October 11:


   public-webeve...@w3.org@w3.org
   http://lists.w3.org/Archives/Public/public-webevents/

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the WebApps WG can discuss it.


-AB

Re: Joystick support

[Arthur Barstow]

Hi All,

As Scott knows, and as suggested by some responses to this thread, the 
members of the Web Events WG are interested in adding the Joystick API 
to its charter [1]. As such, my expectation is the process to formally 
update Web Event's charter to add this API will begin soon.


-Art Barstow

[1] 
http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0041.html


On 8/24/11 3:23 PM, ext Scott Graham wrote:

Hello,

I noticed that Mozilla has started to prototype support for Joystick
events. There's some documentation on this effort
https://wiki.mozilla.org/JoystickAPI as well as a prototype
https://bugzilla.mozilla.org/show_bug.cgi?id=604039

I'm also interested in adding support for joysticks to Chromium and so
would like to open the discussion up to a broader audience. Do others
see this as a valuable API? Or have comments on the design?

scott

RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

[Arthur Barstow]

Hixie, Brian, Jonas, All,

Since Brian sent the original e-mail [1], there has been some Bugzilla 
activity and there are now 5 open bugs for Web Sockets. It appears to me 
(and please correct me if I'm wrong) the ".binaryType" issue Jonas 
raised on the list [2] will not result in any spec changes.


I agree 12510 and 13700 are editorial bugs and as such do not need to 
block LC.


Re the other open bugs, Brian suggests: 13104 and 13984 should be 
closed; 13777 be addressed "as outlined in the bug"; 13990 (which is now 
marked as Resolved Invalid)  also be addressed as indicated in the bug.


Ideally, all open bugs should be closed before a LC is published. 
However, we can also use an LC now to gather input on the open bugs.


Brian proposes an LC be published now with the spec as is. What do 
others think?


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1365.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html


On 9/9/11 6:05 PM, ext Brian Raymor wrote:

The IETF HyBi WG has moved beyond Last Call and has presented the WebSockets 
protocol to the IESG for approval:
  
	http://www.ietf.org/mail-archive/web/hybi/current/msg08640.html


Now that the protocol is more stable, I think that the current WebSockets API 
is feature complete and meets the requirements for publishing a Last Call 
working draft to encourage broader review and feedback.
  
Here is my review of the outstanding bugs (not closed, where resolution not Fixed). I recommend that the outstanding issues be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly.
  
9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put normative requirements in parenthesis

Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - This bug is a year old, likely out of date 
now, and from an anonymous contributor
  
12180 - give the name of url to download the Jetty server

Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor 
from 6 months ago. The API spec doesn't need to link to server implementations.
  
12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous

Reopened, Assigned to Ian Hickson
MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call
  
13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong();//allow client to receive response of ping

Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - It's not necessary to include API support 
for ping/pong. In addition, this bug has been inactive for two months.
  
13172 - The definition for [MessageEvent] is missing

Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - It's been inactive for a month and 
MessageEvent is defined in the HTML5 Web Messaging specification.
  
13700 - W3C SotD of this document still mentions whatwg.org version of the WebSocket protocol which is out of date.

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call
  
13777 - The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
  
13984 - Need a way to object detect which binary formats are supported before connecting

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: Close the bug. The original issue (binary support detection 
in Chrome) should be addressed in WebKit. The additional scenario (querying 
which binary types are supported) is not required in V1.
  
13990 - Need a spec for CloseEvent constructor

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
  
14057 - In section "The WebSocket interface" when describing the operation of the WebSocket constructor, the following statement is made: "Return a new WebSocket object, and continue these steps in the background (without blocking scripts). ...

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: Resolve the bug as duplicate (12510) and close.
  
In addition, there is a new discussion on design changes for binary message support related to the original discussions in 12102 - WebSocket protocol update time:
  
1-Sep-2011 ; [WebSocket API] .binaryType ; by Jonas, reply by Hixie

   http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html
   http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1199.html
  
  
MICROSOFT PROPOSAL:


We do not support the proposed changes. Our implementation experience has not indicated this requirement. We find that most developers use blobs when there is a need to consume data as resources addressed by a URI or to store data in Indexed DB. We have haven't heard of a 

Re: [editing] Using public-webapps for editing discussion

[Arthur Barstow]

Since some related functionality was included (at one point) in the 
HTML5 spec, it seems like we should ask the HTML WG for feedback on 
Aryeh's email.


Aryeh told me there are some related bugs:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423
  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13425

Maciej, Sam, Ruby - do have a sense if the HTML WG has a (strong) 
opinion on Aryeh's question below?


-Art Barstow

On 9/13/11 4:27 PM, ext Aryeh Gregor wrote:

For the last several months, I was working on a new specification,
which I hosted on aryeh.name.  Now we've created a new Community Group
at the W3C to host it:

http://aryeh.name/spec/editing/editing.html
http://www.w3.org/community/editing/

Things are still being worked out, but one issue is what mailing list
to use for discussion.  I don't want to create new tiny mailing lists
-- I think we should reuse some existing established list where the
stakeholders are already present.  Previously I was using the whatwg
list, but as a token of good faith toward the W3C, I'd prefer to
switch to public-webapps, even though my spec is not a WebApps WG
deliverable.  (If it ever does move to a REC track spec, though, which
the Community Group process makes easy, it will undoubtedly be in the
WebApps WG.)

Does anyone object to using this list to discuss the editing spec?

DOM4 published ; please use www-dom for related discussions

[Arthur Barstow]

DOM4 was published in /TR/ today 
.


Please use www-...@w3.org for all DOM4 discussions.

Re: RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

[Arthur Barstow]

As an update on this RfC, note that ATM, 13777 is the only non-editorial 
bug that remains open:




I would appreciate it, if people would please provide input on this bug.

-AB


On 9/9/11 6:05 PM, ext Brian Raymor wrote:
  13777 - The WebSocket protocol draft (hybi-10) restricts the value 
of subprotocols as follows: The elements that comprise this value 
MUST be non- empty strings with characters in the range U+0021 to 
U+007E not including separator characters as defined

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in 
this bug.

[widgets] Status of Packing, DigSig and view-modes Proposed Recommendations

[Arthur Barstow]

[ + public-webapps ]

 Original Message 
Subject: 	[widgets] Status of Packing, DigSig and view-modes Proposed 
Recommendations

Date:   Fri, 16 Sep 2011 06:58:24 -0400
From:   Arthur Barstow 
To: 	Marcos Caceres , Doug Schepers 
, Philippe Le Hégaret , Thomas Roessler 
, Rigo Wenning , Bert Bos , Daniel 
Glazman , Peter Linss 





On September 15, the Advisory Committee's "Call for Review: Widget
Packaging and XML Configuration, XML Digital Signatures for Widgets,
'view-mode' Media Feature are W3C Proposed Recommendations"
questionnaire ended, and the results are that all of the AC members that
responded, said they "supports publication as a W3C Recommendation as
is" (see the Member-only link at [1]).

AFAIU, a Recommendation for Packaging and Configuration spec should now
be possible (its only 2 non-REC refs are the WidgetDigSig and view-modes
PRs):

http://www.w3.org/TR/widgets/#normative-references

Doug, PLH - what needs to be done to move the Widget P&C spec to
Recommendation?

The other two PRs have issues that are blocking their advancement to
Recommendation:

1. XML Digital Signatures for Widgets - advancement to Recommendation is
blocked by the XML Security WG's XMLDigSig11 CR and the Signature
Properties CR and both of those specs are still blocked by an open
Patent Advisory Group (PAG):

http://www.w3.org/TR/widgets-digsig/#references

Rigo, Thomas - when do you expect the XML Security PAG to end?

2. view-mode Media Feature - advancement to Recommendation is blocked by
the CSS WG's Media Queries spec still being a CR:

http://www.w3.org/TR/view-mode/#normative-references

Bert, Daniel, Peter - when do you expect Media Queries to advance to PR?

-Art Barstow

[1] http://www.w3.org/2002/09/wbs/33280/widgets-2001-part1/results

[widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23

[Arthur Barstow]

Marcos, All,

To clearly state that WebApps' work on the Widget Requirements and 
Widget Landscape documents has ended, I propose they be published as 
Working Group Notes:


http://www.w3.org/TR/widgets-land/
http://www.w3.org/TR/widgets-reqs/

If anyone has any comments or objections to publishing those docs - as 
is (except for SotD updates) - as WG Notes, please reply by September 23 
at the latest.


-AB

Whoa! [Was: Re: [editing] Using public-webapps for editing discussion]

[Arthur Barstow]

Hi All,

This thread has taken a few twists and turns and is now relatively far 
from Aryeh's original question of "Does anyone object to public-webapps 
being used to discuss the HTML Editing spec?". I will start a separate 
RfC or CfC on that specific question.


In the meantime, if you want to continue discussions that go beyond the 
narrow scope of the original question, I ask that you *please* continue 
on some other Public list (perhaps www-talk or www-archive) and not use 
public-webapps. Some very good points about general process issues have 
been raised in this thread. I am not trying to stop discussions on the 
broader process issues. On the contrary, I encourage everyone to 
continue those discussions elsewhere (perhaps use www-archive as the 
default?).


(I have previously proposed the W3C create a Public mail list for 
general process-related discussions but received negative feedback. I 
will try again and will report back if I get some "joy").


-AB

On 9/16/11 2:20 PM, ext Tab Atkins Jr. wrote:

On Fri, Sep 16, 2011 at 10:44 AM, Charles Pritchard  wrote:

Yes, you have a public domain document, and yes, you're likely in the same
boat as Tab Atkins:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html
"The editor is the *lowest* level in the hierarchy of constituencies"

The "vendor" implementation is the highest level... Your company has the
full vertical.

Incorrect.  Browsers are below authors, who are below users.  The full
hierarchy of constituencies that I and several others subscribe to is:

1. Users
2. Authors
3. Implementors
4. Spec Authors / Theoretical Purity (these two levels are close
enough that they're not really useful to distinguish, I think)



They use that position to knock-down use cases. When a use case serves
Google Docs, or Gmail, it's heard. When it does not, it's shuttered.

That's quite a forceful statement.  It's also completely untrue.  For
example, I have never talked to the Gmail team about my work.  I've
talked to Docs, but only about CSSOM measurement APIs because it's
hard to gather concrete use-cases for some of these things even though
they're obviously useful.

I would appreciate not being publicly slandered in the future.

~TJ

Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23

[Arthur Barstow]

Hi Marcos,

On 9/16/11 10:14 AM, ext Marcos Caceres wrote:


On Friday, 16 September 2011 at 20:04, Arthur Barstow wrote:


Marcos, All,

To clearly state that WebApps' work on the Widget Requirements and
Widget Landscape documents has ended, I propose they be published as
Working Group Notes:

http://www.w3.org/TR/widgets-land/
http://www.w3.org/TR/widgets-reqs/

I think only the requirements should be published, because it was actually 
pretty useful in informing the standards development process. It's actually a 
pretty good document, if I do say so myself :)


FYI, there is some precedence for publishing Requirements docs as 
Recommendations (e.g. OWL UCs and Reqs) . If we want to go that route, 
it would presumably mean publishing a LC, skipping CR (not applicable 
for this spec) and then going to PR and REC. WDYT? Too much "make work"?



The landscape document was just created to inform the standardisation process 
of what was considered best practice at the time. If it's a W3C requirement 
that it be published as a WG Note, then it should be published as is (i.e., I 
don't wanna do any work on it unless I really have to).


I don't feel real strongly here (and I will check with PLH on the 
publishing requirements). Publishing a WG Note does make a clear 
statement that work on the spec has stopped. We could also update the 
SotD which is quite old (e.g. still points to the appformats lists). 
[BTW, I would be willing to help with the edits.]


-AB

Re: [editing] Using public-webapps for editing discussion

[Arthur Barstow]

Aryeh - coming back to your question below ...

Since you are the Chair of the HTML Editing APIs CG [CG], would you 
please explain what you see as the relationship between the CG and 
WebApps vis-à-vis the Editing spec? In particular, what role(s) do the 
CG and WG have?


For example [1] indicates the CG already has a mail list 
(public-editing) so when would it be used versus public-webapps?


-Thanks, AB

[CG] http://www.w3.org/community/editing/

On 9/13/11 4:27 PM, ext Aryeh Gregor wrote:

For the last several months, I was working on a new specification,
which I hosted on aryeh.name.  Now we've created a new Community Group
at the W3C to host it:

http://aryeh.name/spec/editing/editing.html
http://www.w3.org/community/editing/

Things are still being worked out, but one issue is what mailing list
to use for discussion.  I don't want to create new tiny mailing lists
-- I think we should reuse some existing established list where the
stakeholders are already present.  Previously I was using the whatwg
list, but as a token of good faith toward the W3C, I'd prefer to
switch to public-webapps, even though my spec is not a WebApps WG
deliverable.  (If it ever does move to a REC track spec, though, which
the Community Group process makes easy, it will undoubtedly be in the
WebApps WG.)

Does anyone object to using this list to discuss the editing spec?

Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23

[Arthur Barstow]

On 9/19/11 10:54 AM, ext Marcos Caceres wrote:


On Monday, September 19, 2011 at 2:08 PM, Arthur Barstow wrote:


FYI, there is some precedence for publishing Requirements docs as
Recommendations (e.g. OWL UCs and Reqs) . If we want to go that route,
it would presumably mean publishing a LC, skipping CR (not applicable
for this spec) and then going to PR and REC. WDYT? Too much "make work"?

I think it's "make work" (though I would have argued for this a few years ago). 
I think we should keep /TR/ for specifications that target user agents. It might also be 
too controversial to try to push a requirement document to REC independently of the 
specifications that meet those requirements.


The landscape document was just created to inform the standardisation process 
of what was considered best practice at the time. If it's a W3C requirement 
that it be published as a WG Note, then it should be published as is (i.e., I 
don't wanna do any work on it unless I really have to).

I don't feel real strongly here (and I will check with PLH on the
publishing requirements). Publishing a WG Note does make a clear
statement that work on the spec has stopped. We could also update the
SotD which is quite old (e.g. still points to the appformats lists).
[BTW, I would be willing to help with the edits.]

Ok, lets see what PLH says. Thanks for your offer of help; it's very much 
appreciated.


PLH says that ideally every spec ends as a WG Note or a Recommendation 
but in practice groups need to consider other factors. In the case of 
the Landscape doc, which was by definition (or at least by title) 
transient, so let's just drop it (and not publish it as a WG Note).


So, the proposal for the Landscape doc is amended: the proposal is to 
formally stop working on the Landscape document and to move it to 
PubStatus' "Specs NO Longer Active" table:


   http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active

If anyone objects to that, please reply by September 23 and understand 
that it would mean that you must do the editing work to produce a WG Note.


(The proposal to publish the Requirements doc as WG Note remains unchanged.)

-AB

Re: RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

[Arthur Barstow]

Yesterday, Hixie checked in a fix for 13777.

Bug 13104 (Enable keepalive on WebSocket API) was closed (WontFix) but 
reopened on September 18. Since various group members agree with not 
addressing this bug for v1, I will proceed with a CfC to publish a LC of 
the Web Socket API. (Perhaps this bug could be moved to the PostPoned 
state and (re-)considered for v2?).


Editorial bugs 12510 and 13700 will not block the LC (although it would 
be great if they were fixed ;-)).


If any new bugs are submitted after the RfC begins, we will consider 
those bugs as LC comments.


-AB

On 9/15/11 9:07 AM, Arthur Barstow wrote:
As an update on this RfC, note that ATM, 13777 is the only 
non-editorial bug that remains open:


<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777>

I would appreciate it, if people would please provide input on this bug.

-AB


On 9/9/11 6:05 PM, ext Brian Raymor wrote:
  13777 - The WebSocket protocol draft (hybi-10) restricts the value 
of subprotocols as follows: The elements that comprise this value 
MUST be non- empty strings with characters in the range U+0021 to 
U+007E not including separator characters as defined

New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in 
this bug.

CfC: publish a LCWD of Web Socket API; deadline September 27

[Arthur Barstow]

This is a Call for Consensus to publish a Last Call Working Draft of the 
Web Socket API using the following document as the basis:


  http://dev.w3.org/html5/websockets/

As noted in [1], this spec has two editorial bugs and one bug that some 
group members do not want to address for this version of the spec.


The Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is September 27. Please send all comments to: 
public-webapps@w3.org.


If any new bugs are submitted before this CfC completes and the LC is 
published, those bugs will be will be considered as LC comments.


-Art Barstow

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

Reminder: RfC: LCWD of Web Storage; deadline September 27

[Arthur Barstow]

Reminder: September 27 is the deadline for comments for this LCWD. The 
open bug list is:


http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Web%20Storage%20%28editor%3A%20Ian%20Hickson%29&resolution=---

 Original Message 
Subject:RfC: LCWD of Web Storage; deadline September 27
Resent-Date:Tue, 6 Sep 2011 14:19:41 +
Resent-From:
Date:   Tue, 6 Sep 2011 10:19:03 -0400
From:   ext Arthur Barstow 
To: public-webapps 



A new LCWD of Web Storage was published:

  http://www.w3.org/TR/2011/WD-webstorage-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Fwd: RfC: LCWD of Web Workers; deadline September 27

[Arthur Barstow]

Reminder: September 27 is the deadline for comments for this LCWD. The 
open bug list is:


  
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Web%20Workers%20%28editor%3A%20Ian%20Hickson%29&resolution=---


 Original Message 
Subject:RfC: LCWD of Web Workers; deadline September 27
Resent-Date:Tue, 6 Sep 2011 14:21:11 +
Resent-From:
Date:   Tue, 6 Sep 2011 10:20:49 -0400
From:   ext Arthur Barstow 
To: public-webapps 



A new LCWD of Web Workers was published:

  http://www.w3.org/TR/2011/WD-workers-20110901/

Please send all comments to public-webapps@w3.org by September 27.

Re: [editing] Using public-webapps for editing discussion

[Arthur Barstow]

On 9/19/11 1:56 PM, ext Aryeh Gregor wrote:

On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow  wrote:

Since you are the Chair of the HTML Editing APIs CG [CG], would you please
explain what you see as the relationship between the CG and WebApps
vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG
have?

I notice you asked a more general question here too that I didn't
answer.  My take is that the CG will be the group that publishes the
editing spec for the foreseeable future.  However, all discussion and
development should occur in preexisting, established fora, preferably
in the W3C.  This means using fora that are specific to particular
Working Groups, such as public-webapps, even though those Working
Groups aren't formally involved in developing the editing spec.

So currently, I don't see the WebApps WG as having any official role
in developing the editing spec.  I'd only like to be able to use its
discussion list, since a lot of interested parties are already
subscribed.


It seems to me, that by virtue of using public-webapps, it does give 
WebApps WG a role e.g. to at least comment on the CG's editing spec. 
[Whether such a role is "official" or not is probably just "splitting 
hairs".]


And speaking of the spec, would you please clarify which spec is in 
scope for the CG:


http://aryeh.name/spec/editing/editing.html
or:
https://dvcs.w3.org/hg/editing/


Eventually, if it turns out to be necessary to move the
spec to the REC track (although I hope it's not),


Would you also please explain what you mean by your hoping it will *not* 
be necessary for the editing spec to move to the W3C's Recommendation 
track (f.ex. why do you feel this way)?


Is there consensus within the CG to not move the spec to the REC track?

-AB

Re: [editing] Using public-webapps for editing discussion

[Arthur Barstow]

Thanks for your clarifications Aryeh. One follow-up below re 
"contributions" to the Editing spec ...


On 9/22/11 12:43 PM, ext Aryeh Gregor wrote:

On Thu, Sep 22, 2011 at 7:33 AM, Arthur Barstow  wrote:

It seems to me, that by virtue of using public-webapps, it does give WebApps
WG a role e.g. to at least comment on the CG's editing spec. [Whether such a
role is "official" or not is probably just "splitting hairs".]

I absolutely would like*comments*  from everyone who's interested,
whether individuals or organizations or Working Groups.


It appears you are intentionally using "comments" here to differentiate 
"contributions". Is that right?


I ask because, as I understand the CG process: before a person can make 
a contribution to a CG spec, they must agree to a CLA for all of the 
CG's specs; and a CG is only supposed to accept contributions from its 
CG members.


If your CG uses WebApps' list, how will contributions from non-CG people 
be managed/tracked and how will the FSA be managed e.g. if non-CG 
contributions are accepted?


-AB

Re: [editing] Using public-webapps for editing discussion

[Arthur Barstow]

Hi Aryeh, All - Aryeh's response below clarifies my last question about 
the relationship between the HTML Editing APIs CG and WebApps.


I think the main points are:

* The members of the HTML Editing APIs CG do not think the HTML Editing 
APIs spec is ready for Recommendation track (and I don't believe anyone 
that responded to this thread suggested/recommended otherwise).


* Given at least some parts of the spec originated in the HTML5 spec, 
this functionality is within the scope of WebApps' charter (as amended 
in 2010).


* The HTML Editing CG would like to use public-webapps (and not their 
list) for its discussions because so many of the interested parties are 
already subscribed.


* Contributions to specifications produced by the HTML Editing CG are 
governed by the Community Group CLA and the CG is responsible for 
ensuring that all Contributions come from participants that have agreed 
to the CLA for that group.


With this understanding, and having not noticed any objections to 
Aryeh's proposal, I think we should consider Aryeh's proposal as accepted.


-AB

On 9/22/11 5:54 PM, ext Aryeh Gregor wrote:

On Thu, Sep 22, 2011 at 2:44 PM, Arthur Barstow  wrote:

It appears you are intentionally using "comments" here to differentiate
"contributions". Is that right?

Right.


I ask because, as I understand the CG process: before a person can make a
contribution to a CG spec, they must agree to a CLA for all of the CG's
specs; and a CG is only supposed to accept contributions from its CG
members.

If your CG uses WebApps' list, how will contributions from non-CG people be
managed/tracked and how will the FSA be managed e.g. if non-CG contributions
are accepted?

I spoke with Ian Jacobs about this.  He clarified that "contributions"
only means spec text.  To date, I've written all actual spec text
myself, and I expect this to continue.  It's usual that only the
editor writes the actual text of the specifications they edit.  If for
some reason I wanted to accept spec text from someone else, they'd
have to submit it through the CG and we'd ensure it was properly
tracked for legal reasons.  As I understand it, it couldn't be
submitted on public-webapps, but that's not a problem -- I just want
to use public-webapps for discussion.

Re: Proposal to add Mouse Lock to the Web Events Working Group

[Arthur Barstow]

Hi Vincent, All - given there were no negative comments regarding 
Vincent's proposal, Doug and I will work toward updating WebEvents' 
charter to add the Mouse Lock API.


Additionally, as indicated in [1], we will also work toward adding the 
Gamepad API [2] (formerly know as the Joystick API) to WebEvents' charter.


-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1408.html
[2] http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html

On 9/15/11 1:52 PM, ext Vincent Scheib wrote:
A Mouse Lock API has been under discussion on the W3 public-webapps 
list "Mouse Lock"[1] and earlier "Mouse Capture for Canvas"[2].


The primary goal is to enable use cases such as first person 
perspective 3D applications. This is done by providing scripted access 
to mouse movement data while locking the target of mouse events to a 
single element and removing the cursor from view.


I have been working to formalize the discussions into a draft 
specification[3]. I propose that the Web Events Working Group consider 
adoption of Mouse Lock for formal specification.


Cheers, -Vince

1. 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960
2. 
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437

3. http://goo.gl/9G8pd

Additional discussions:
W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754

CfI: Progress Events is a W3C Candidate Recommendation

[Arthur Barstow]

Below is Call for Implementation for the Progress Events spec.

Anne, Ms2ger, what is the status of the Progress Events test suite (e.g. 
% complete)?


  http://w3c-test.org/webapps/ProgressEvents/tests/

 Original Message 
Subject: 	Progress Events is a W3C Candidate Recommendation (Call for 
Implementations)

Resent-Date:Mon, 26 Sep 2011 16:15:55 +
Resent-From:
Date:   Mon, 26 Sep 2011 11:15:51 -0500
From:   ext Ian Jacobs 
To: W3C Members 



Dear Advisory Committee Representative,

I am pleased to announce that Progress Events is a W3C Candidate Recommendation:
  http://www.w3.org/TR/2011/CR-progress-events-20110922/

[[ snip Member-confidential reference ]]

In response to the 9 August 2011 Last Call, only one comment was submitted and 
it resulted in editorial changes. The commenter agreed with the Editor's 
changes. There were no Formal Objections.

The WebApps Working Group plans to produce a test suite for this specification 
during the CR period.

This Call for Implementations follows section 7.4.3 of the W3C Process Document:
   http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

Thank you,

For Tim Berners-Lee, Director,
Philippe Le Hégaret, Interaction Domain Lead, and
Doug Schepers, Rich Web Clients Activity Lead;
Ian Jacobs, Head of W3C Communications

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

Publishing specs before TPAC; Oct 14 is last day to start a CfC

[Arthur Barstow]

The upcoming TPAC meeting (Oct 31 - Nov 01) provides an opportunity for 
joint WG meetings and lots of informal sharing. As such, some groups 
make spec publications right before TPAC.


Note there is a 2-week publication blackout period around the TPAC week 
and Oct 24 is the last day to request publication before TPAC.  Given 
our 1-week CfC for new publications, weekends, etc., the schedule is:


* Oct 14 - last day to start a CfC to publish
* Oct 24 - last day to request publication
* Oct 27 - last publications before TPAC
* Nov 07 - publications resume

*A lot of groups wait until the deadline so if you want to publish 
before TPAC, I encourage you to propose publication as soon as possible 
and by October 14 at the latest.

*
Some specs I'd like to see published before TPAC 
():


* Clipboard APIs and Events - I think Hallvord has made quite a few 
changes since last publication on 12-Apr-2011. WDYT Hallvord?


* D3E - not sure if next pub is CR or LC. Doug, Jacob?

* File API (last published in 26-Oct-2010) - Arun, Jonas - what's up 
with this spec?


* File API: Writer and Directories & System - WDYT Eric? Are the changes 
since the April 2011 publication significant?


* Indexed Database API - is this ready for LC?

* Server-sent Events - 8 open bugs so I presume a new WD at this point.

* Web Messaging - 6 open bugs so I presume a new WD at this point.

-AB

RfC: Last Call Working Draft of Web IDL; deadline October 18

[Arthur Barstow]

On September 27 a Last Call Working Draft of Web IDL was published:

  http://www.w3.org/TR/2011/WD-WebIDL-20110927/

The deadline for comments is October 18 and all comments should be sent to:

public-script-co...@w3.org

The comment tracking doc for the previous LC is:

  http://dev.w3.org/2006/webapi/WebIDL/lc1.txt

Cameron, Philippe - if you think it is necessary, please fwd this e-mail 
to ECMA TC39.


-AB