<anne> hey chaals

<anne> long time

<Ms2ger> Hai :)

<Ms2ger> anne, look over your shoulder, perhaps? :)

<anne> maybe if you're a woman and working here

<anne> at the Marriott that is

<dom> nice way to hide yourself!

<ArtB> Scribe: Art

<Ms2ger> Just you? :)

<krisk> +present

<Josh_Soref> Scribe: Josh_Soref

ArtB: the way we've run these big tpac meetings is to try to get as much flexibility to the topics in the meeting room
... we have a very large list of identified topics that we (i and the group) have identified
... given this, we can use some time to determine what to talk about tomorrow
... it's hard for me to determine how much time the things i've allocated for today will take
... it's possible we'll have holes, and we can either take breaks or pull in topics from tomorrow
... we want to be flexible and be able to hash out big issues
... let's start by looking at potential topics for tomorrow
... is there a lot of interest on talking about these things, and if so, when do we want to talk about them
... what we did last year was count how many people are interested (show of hands)
... testing - 11
... joint meetings w/ other WGs
... -- that people want to shoehorn
... Joint Meetings - 0
... XBL2 ... has been a deliverable for 5 years or so... there was a thread, "is it dead?"
... XBL2 - 13
... DOM Mutations ...

[ not dominique mutations -- laughter ]

<anne> dom.clone()

ArtB: ... and there's the admn ...
... DOM Mutations - 11
... XHR1 ... there was a notion (by anne ) should we give up on XHR1 and just spec XHR2
... do we want a time slot for that?

[ no one expresses interest ]

anne: not even me, i think we can just do it in a few minutes

ArtB: let's do it during the pubstatus time slot today
... XHR1 - 0
... DOM Parsing and Serialization
... do we want to formally add it to webapps when we recharter?

heycam: is there a slot for DOM4?

[ DOM4 would be in generic chartering ]

scribe: DOM Parsing and Serialization - 0

ArtB: is aryeh here?
... HTML Editing API - 0

[ to be done in chartering ]

ArtB: is Ian F here?
... Storage Quota - 0
... API Design ...

<chaals> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1666.html -> Storage quota API

ArtB: -- Robin had put together a rough outline

<Ms2ger> http://dvcs.w3.org/hg/webapps/raw-file/b941da0491a8/api-design/Overview.html

ArtB: API Design - 16
... Stream API proposal (from Microsoft, that Adrian sent to the list)
... -- and File API
... Stream API and File API - 10

<Ms2ger> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0577.html?

ArtB: Index DB - 5

<bryan> Proposal for discussion of server-sent events extension for connectionless push support: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0577.html

/

ArtB: proposal by bryan to add a slot for server sent event extensions
... Server Sent Event Extensions - 4

[ Scribe takes a break while ArtB resequences things on screen unsaved in Wiki TPAC2011 ]

[ ArtB commits Schedule to Wiki -- http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 ]

anne: I need to leave, but we should talk about CORS

ArtB: CORS has been important... so important that a WG has been made for it

Spec status and plans

ArtB: Web Application Security Working Group

[ Scribe takes a break while anne outlines the history of the creation of that group with a dose of skepticism ]

<chaals> Josh_Soref: There are a couple of community groups created to edit a spec, so maybe stuff gets done in community groups and webapps gets used to handle formal publishing for it.

[ ArtB reviews pub status ]

ArtB: do we need to add an Errata to DOM Core?

[ Chatter about Element Traversal and DOM4 ]

<Marcos> +nvbalaji

DRAFT ACTION: Barstow work with Doug

<anne> http://www.w3.org/TR/web-forms-2/

<anne> ^ same thing

<chaals> AvK/Shepazu: Element traversal to point towards DOM4 as where the future work gets done (e.g. errata)

<chaals> ACTION: Art to talk to Doug about the traversal from Element Traversal to DOM4 [recorded in http://www.w3.org/2011/10/31-webapps-minutes.html#action01]

<trackbot> Created ACTION-628 - Talk to Doug about the traversal from Element Traversal to DOM4 [on Arthur Barstow - due 2011-11-07].

Eric: File APIs and Directory
... there are some bigger and smaller changes coming
... implementation status is not up to date
... chrome only, but it's more implemented

ArtB: can any other implementers speak about Writer and Directories and systems?

chaals: we have an implementation because we internally use it
... we want to get it done
... right now we ship our own

<smaug> Isn't it still unclear whether we need the whole Directories stuff

chaals: we expect it to change

<smaug> (ah, sicking is talking)

jonas: we have plans

macie: apple has plans

anne: I think apple's position is more in line with the last two

<weinig> Josh_Soref: I'm not weinig, Sam Weinig

eric: File Saver ...

ArtB: From Origin header ...
... what's the implementation status?

anne: I don't think anyone has implemented it

ArtB: Progress Events ...

anne: I think the main thing blocking implementations is Constructor
... I guess WebKit has that
... it's fairly simple (just properties/methods) since dispatch is covered in other specs

jonas: we haven't started on constructors, since it's non trivial
... probably somewhat soon, but next year

anne: similar for us
... it's easier but not a priority

ArtB: Selectors
... it's blocked by WebIDL

Josh_Soref: is WebIDL going to be a topic

ArtB: there's a slot available and heycam is sitting next to you :)
... Server Sent Events
... when I left Boston, we were down to 0 bugs

anne: it doesn't cover Cross Origin
...
... It's going to get another argument in the constructor to cover cross origin

ArtB: the main thing is that changes are coming, so it doesn't make sense to go to LC
... WebIDL
... it had LC2

<chaals> s/to cover cross cross origin/to cover cross origin and opting in to credentials exchange/

heycam: there are some non controversial issues
... and then a question of whether it should be less non JS specific

ArtB: we have a slot for tomorrow at 4

<anne> EventSource will get the same cross-origin story as XMLHttpRequest basically

<anne> is what I said

<anne> and everyone is on board, change just needs to be made (well everyone that voiced an opinion)

ArtB: PostMessage
... Web Workers
... Marcos: widgets...?
... widget interface is blocked by webidl and webstorage
... i think W3 Team has agreed on changes to pub reqs re:HTML5
... WARP had been stalled ... PAG has been active recently, and there's reason to believe that the PAG will conclude relatively soon

[ Marcos gives a summary ]

dom: is there an eta for the report?

Marcos: shortly after TPAC, it needs a bit of clean up

chaals: there is a draft

ArtB: DigSig (for Widgets)
... that spec is in PR, it's blocked by XML Sec PAG
... Widget URI moved back to WD in September

Marcos: trying to align it with File API... responding as a fake http server
... hopefully it'll have fairly similar behavior
... and move to LC

ArtB: View Mode media feature is in PR
... and will move to Rec when Media Queries advances to PR
... Widget Updates

[ Break until 10:30a ]

<Ms2ger> 10:30

<dom> glazou has joined #webapps

<Ms2ger> Not 11 either, apparently

[ We're about to resume ]

ArtB: we have 3 or 4 WGs here
... ask that observers make room around the table for WG members

[ ArtB introduces ]

<dbaron> [joint meeting of Web Apps, Web App Security, Web Fonts, and CSS]

CORS

[ ArtB introduces the groups who have dependencies on CORS ]

vladimir: It started with the development of the Web Open Font Spec
... when same origin was selected
... but the comment was made that it isn't specific to Web Font
... and it was suggested to make the Same Origin specification be made on a link specific basis
... The requirement was marked as at-risk
... and moved toward CSS

<anne> same-origin policy

<anne> From-Origin header

<ArtB> From-Origin spec: http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

vladimir: CSS needs to decide which to use to relax the restriction

jdaggett_: I'm the editor of the CSS Fonts Spec
... the spec today says fonts are same-origin by default with CORS to relax it
... the question is what's the mechanism
... should it be From-Origin
... and people who put a font on their server
... should people use CORS to relax it?
... there's a fundamental issue
... From-Origin/CORS
... If I say "allow all origins" (with CORS) and "from-origin same"
... how do they mesh together?

anne: From-Origin would Win

<tcelik> greetings (CSSWG member, representative from Mozilla Foundation).

anne: From-Origin integrates with the fetch algorithm

tab: From- would stop it first

anne: yes, CORS would just see a fault and couldn't do anything to unfault it
... everything that fetches should be defined in terms of the fetch algoritm
... that's a bug in the fonts spec, it doesn't reference the fetch algorithm

clilley: could you provide text?

anne: the CORS specification requires specific invocation of the request algorithm

jdaggett_: so any spec with a same-origin restriction needs to have specific text?

anne: yes

clilley: the host language has to invoke the fetch algorithm in order to trigger it

anne: the specification [CORS] specifically lists the text to trigger invocation

shepazu: Maybe we should have a FAQ somewhere for how to integration

weinig: Section 8 of CORS has this text

<ArtB> http://dev.w3.org/2006/waf/access-control/

Marcos: do you have specs that use it?

<chaals> http://www.w3.org/TR/cors/#cors-api-specification-advice -> advice on using CORS in other specs

anne: HTML and XHR

<dbaron> (should we move back to the main topic?)

anne: it is quite intricate
... since there are credentials and other things
... if you have a model that sends credentials by default

<glazou> ArtB: let's focus back on main topic please

anne: and you want to do something else
... XHR uses a withCredentials attribute
... HTMLxxx has something else

jdaggett_: that isn't the most important topic

tab: you have a paragraph that says anyone wanting to use CORS
... must specifically reference the algorithm and set particular variables
... what would be helpful is specific example text

ACTION tab to write proposed text

<trackbot> Sorry, couldn't find user - tab

anne: we have two specifications which do things differently because it's rather different for different environments

sicking: one of the issues specifically about fonts
... is the whole thing about whether it makes sense about embedable
... and there's the question about exposing the resource to the embedder
... Can we skip the embedding and just make it readable to the world
... Any time we've tried to expose a resource without letting the page see the resource, we've failed
... e.g. with images we leaked image dimensions to the web page
... with WebGL, we accidentally leaked pixel data through a timing channel
... it's possible you can leak other data from transparency
... with fonts it's even more likely since you can get information from timing
... can we say that fonts are inherently non private and we can share with anyone on the web?

florian: the answer is that in general fonts do not contain private data
... it seems that people believe that in some edge cases they do
... the font itself doesn't contain private data, but the presence does indicate that the product exists
... it doesn't seem necessary to restrict by default

clilley: i agree in general
... a WOFF font can contain licensee and licensor
... it's not quite private
... but that's leakable
... i believe that form-origin is appropriate

dbaron: one other case with private data
... is font-subset
... which is common with EOT
... and it's likely we'll get that for WOFF
... and if you subset for WOFF specifically to a page
... then you leak the contents of the page

tab: the distinction on the table
... is whether an embedded resource
... embedding-vs-reading

dbaron: the argument jonas made is that every time we tried to make that distinction, we've failed

tab: right, can we say "embedding means reading"
... because we've failed each and every time we've tried

weinig: leaking licensee/licensors...
... while i understand that we leak some info
... how would we leak licensee/licensor?

clilley: that only happens if you don't make the distinction between reading and embedding
... there is an extension for firefox that enables that through an internal api

weinig: is that available to webcontent?

clilley: it isn't available to web content (only chrome)

weinig: you obviously could mask some things
... the non visual elements are easily maskable

vladimir: the way i understand tab's argument
... is that each time we make the distinction between embedding/reading
... is that it's easier to not do it
... i don't see why embedding-origin is the simple approach

mjs: a couple of people have claimed that reading/embedding distinctions have always failed
... i bet none of you would make all images world readable
... the fact is that there is still a distinction
... when it's too easy, we usually consider it a security bug
... and try to fix it
... it's true that it's hard to maintain that distinction
... i think people are wrongly trying to make the claim that there is no distinction

<anne> and also for new ones such as video

jdaggett_: we're not in the same case as images
... this is a new resource type
... we can define a behavior
... with fonts, there are any number of ways
... you can't do the type of tainting with canvas
... with fonts, you can infer character set, or metrics, or ...
... trying to analyze all of the apis is too hard
... back to what jonas said
... if we define that all cases are readable
... maybe we make it by default origin restriction

clilley: the claim is made that for fonts that we don't make the distinction for embedding-reading

dbaron: i probably made the claim too strongly

clilley: and i interpreted this for fonts that we shouldn't be doing it

sicking: for browser vendors, the pain is addressing security issues
... instead of working on features

<dbaron> dbaron: ... and instead of saying it always failed, should have said it either always failed or led to lots of pain trying to prevent it from failing

sicking: for images, we now have an api where we have to add this tainting thing
... if we had CORS on images from the beginning
... we'd probably have more mashupable
... we don't because 3rd parties can't get this stuff easily
... we won't expose license info for similar reasons
... if sites can opt into with shared by default
... if people have to make a decision by adding cors headers
... then they'll actively make the decision
... then they'll go through a security review
... if they don't have to go through a security review (putting up CORS), they won't think about it

ArtB: anne are you coming up with additional constraints?
... is this more UC clarification?

anne: there's nothing that needs to be changed in CORS or From-Origin
... the question is if Fonts should work like Images or XHR
... and i stopped caring a long time ago

tab: so john, make a decision

clilley: where are we in the process
... are both CORS and From-Origin is in where?

ArtB: CORS is a joint from Sec+WebApps
... From-Origin is in WebApps only
... I saw Brad walk in

clilley: follow up, where are the issue lists for these specss?
... pointer?

BradL: CoChairing Web Apps Sec WG
... Web Apps Sec is co delivering it with Web Apps to drive it through
... to keep IPR grants
... there are some small issues
... including Best Practices
... additionally our tracker has some other small issues
... which we may move to bugzilla
... the primary issue before REC is a test suite

<ArtB> CORS: bugs: http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Access+Control&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_statu

BradL: anne is working on it
... we're new so we'll be Workshop with Staff

clilley: and for F-O?

BradL: that's not in our charter

<Zakim> Josh_Soref, you wanted to ask where it is

<ArtB> From-Origin: http://www.w3.org/TR/from-origin/

vladimir: from everything i've heard so far, we seem to lean to same-origin with CORS
... and third resources come from my question was the same as clilley's - already answered

chaals: we seem to be leaning that way
... How many people Same Origin by default
... Same-Origin - 25
... Against Same-Origin - 8

clilley: follow on question ...

chaals: is this a strong Objection, if we resolved to use Same Origin, would you argue, or can you live with it?
... if you can't live with that decision, justify why we should continue arguing

Bert: for Fonts, i really like the restriction to be on a higher level than the protocol
... something that isn't http
... for animations

tab: i don't believe this is restricted to any protocol

[ jdagget points out to tab that CORS is http ]

[ and clilley explains that you can reference ftp resources ]

Adam: that's a general problem with CORS everywhere
... when we introduce other protocols
... we'll demand that they support CORS

<dbaron> (Adam == Adam Barth)

tab: and patch ftp

Bert: How about email?

anne: how do you envision?

Bert: anything with a url must have a

anne: so emails include fonts?

Bert: yes

anne: then they're same origin

Bert: what about bittorrent?

<Ms2ger> s/Adam:/Adam Barth:/

vladimir: if you want to make it available across origins, then you could do it?

mjs: email messages might have a same-origin problem
... the main resource comes from mid: and cid:

sicking: any protocol that people are starting to more actively use
... people are going to have to deal with cross origin issues
... anyone that wants to seriously start doing web deployment over other protocols will have to define how this works

Bert: the protocol is not important, it's the resource that's important

sicking: we've defined domains
... and said that everything in a domain is owned by the same person
... every other protocol will have to define something like that

Bert: that's a hack

clilley: I agree that specific protocols saying

<anne> the web is a hack. film at 11

clilley: that cids of a mid are the same as the mid
... that's not the question
... is there an objection

mjs: if the spec says that embedding fonts in email never works, i'd have to object

chaals: embedding stuff in email is a real thing
... it happens in Opera
... we have questions around that
... with images, do they automatically render?
... do you run JS from another source?
... the issue of clilley/Bert
... is do we make a protocol agnostic work
... but we live on HTTP
... we don't object to people expanding things to other protocols
... i agree with mjs
... if we say you're not allowed to embed things except in http resources
... that would be beyond what is reasonable for a spec
... (this is a personal position)
... clilley's question is
... do we have someone who objects to that proposal
... of us focusing on http
... to Bert's objection
... that we have a hack, and forcing others to work with us

dom: people send newsletters in html
... and they rely on w3c of sending fonts in emails

Florian: using http
... implicitly prevents other protocols from using it cross-origin

jdaggett_: the wording is that cross origin is not allowed
... unless explicitly relaxed using CORS

<anne> I do think it should be defined for things that are fetched within a "browsing context" which is more than HTTP

clilley: in the context of this question
... sure email is a case
... it would be possible to resolve cid: in CORS

sicking: it's a good idea to say if it's HTTP use CORS
... but for other protocols, fall back to their protocol for addressing this issue

Florian: if you're using HTTP then use CORS
... and saying if you're not HTTP then use the CORS equivalent
... is going too far

glazou: this is a problem
... because we don't know if there's an equivalent for other protocols
... we don't know their schedules
... this isn't reasonable

anne: what do you propose instead?

glazou: the w3c has dealt in the past
... with protocols that do not belong to the web strictly
... we can deal with them later

vladimir: i don't think this should hold us

jdaggett_: Florian's point is that he wants to restrict it to Only http
... the wording now is 'same-origin' and leaves it at that

Florian: do not speak about restrictions for not http

anne: there are 3 cases
... same-origin

s/..../.../

scribe: cross origin where the api fetching has http origin
... the scheme is not http and there's a cross origin for the other

Florian: in the spec we're talking about
... we say 'for http do this, cross origin use CORS'
... we leave it up in the air
... for a later version or another group/spec

chaals: Is there any reason to continue?
... Are there objections to
... saying that we define this for the first two cases anne mentioned

<anne> I would object to making the decision in a synchronous manner

chaals: and for the third case, we leave it as "if you're using another protocol, you figure it out"

anne: i don't want us to make synchronous decisions

<hober> anne++

chaals: i agree
... but for the sake of getting out of the room
... Is there anyone who can not live with Florian's suggestion?

[ No one ]

<anne> shepazu, just wanted to clarify as there's more than WebApps in this room

chaals: is there anyone who can not live with a policy of by default we use Same-Origin
... for fonts

<anne> shepazu, no need for tss sounds

chaals: and you use CORS

[ No objection ]

chaals: we're out of time
... thanks very much

[ Applause ]

<Ms2ger> s|s/..../.../|

<shepazu> (anne, I don't feel it's useful to keep bringing up the decision policy when it's well established, and since any decision will *always* be subject to later discussion, in any group in W3C I've been in)

<Ms2ger> s|s/..../.../||

animations [cont'd]

<Bert> Sorry

<smaug> Josh_Soref: so is the agenda for tomorrow somewhere?

<smaug> I'd like to know when MutationObserver will be discussed

<smaug> if it will be discussed

<Ms2ger> http://www.w3.org/2008/webapps/wiki/TPAC2011

<heycam> s/Topic: animations [cont'd]//

<Ms2ger> The Return of the Josh

<Ms2ger> dom, I hear you're needed

Charter, re-chartering and scope

<MikeSmith> ArtB, http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

s/present+WayneCarr/present+ WayneCarr

s/present +stpeter/present+ stpeter/

<stpeter> Josh_Soref: thanks

s/Josh_Soref: thanks//

Charter/Rechartering

ArtB: Items
... WebIntents

<Ms2ger> s|s/present+WayneCarr/present+ WayneCarr|

ArtB: -- where should it be, DAP/WebApps

chaals: Can we push Widgets to the top of the stack (TAG will start shortly)

[ Introductions ]

<Ms2ger> shepazu: Doug Schepers, Microsoft

<Ms2ger> ... er, W3C

ArtB: welcome everyone
... dan you wanted to say something about widgets?

DanA: no... not really
... there's a meeting on Saturday on Offline Applications
... which I'm coordinating

ArtB: this morning we did PubStatus
... we also have on the agenda a block of time from 5-6pm tonight titled web application packaging v2

chaals: What i really wanted to do
... it seems the widget work we charter for and did is done / about to be done
... as DanA said, there is this workshop coming up
... we have widgets
... appcache
... installable widgets
... offline apps
... If we go to do a version 2, is that something we'd do in this group?

mjs: preferably not

shepazu: in the early days of this group
... it was a shotgun approach
... i think we started focusing on apis
... we had the experience of only some of the people focusing on widgets work
... it doesn't seem like a good fit

sicking: from mozilla's point
... i think what's interesting is ... packaging
... if that's not in the same group, that's ok

shepazu: we're talking about the scope of this group, Web Apps
... there may be another group working on installable web apps

sicking: are we talking about moving all of the widgets stuff?

Marcos: we wouldn't move any of the stuff here, since it's all effectively done
... we could move or keep any future work
... i'm happy to go wherever the discussion is
... since we put in 5 years on the spec
... from an ipr perspective, i'm happy with where it is
... but moving it to another group would enable us to see who's interested
... so we don't just have Marcos on a mailing list emailing himself

DanA: thanks for the invite
... one of the things i wanted to say
... is that one of my hopes for the workshop on Saturday
... is to clarify things for offline/appcache/widgets
... and for things outside w3
... which have prominense
... I don't think what will come out will be widgets2.

s/2./2.0/

scribe: people do use things offline and do want to install them offline
... it comes back to, i hope we have a coherent discussion on Saturday
... and out of that comes a mandate for doing work in this space

chaals: sicking asked if this was just packaging
... my answer is no
... packaging is important
... but a key is looking at applications and how they work
... one of the thing for widgets is to let them work in more weblike ways
... we want appcache based things to work more like widgets
... appcache is at its basics packaging
... like Marcos, we don't really care whether it happens here, or somewhere else
... there is a question, because we're at w3c
... because we deal with objections/strong objections relating to chartering
... if there's some clear thing we should know

bryan: to underscore what DanA said
... we have similar views
... we see widgets as a base for web applications
... we see some challenges
... for how it works with the web
... in terms of security model
... it's broader than packaging
... than any specific api
... it's more about how they fit into the overall web architecture

shepazu: i'd like to limit the scope to Web Apps Charter
... I'm proposing that the next charter from Web Apps not include Widgets

chaals: when PAG is done, they should move to REC

shepazu: do we delay the chartering of Web Apps until they're done?

Marcos: we just adjust the text to say that Widgets is scope limited to the current deliverables being delivered

DanA: i'd like to wait until after the Workshop

[ ArtB does a time check ]

Charter/Web Intents

jgraham: Web Intents
... is based on Android Intents
... it allows a site to talk about how they handle actions
... and allows client sites to ask about an action
... and lets the user pair them
... picking the service the user wants to use
... It's a solution to the "nasgar problem"
... -- Share with 40 items

<heycam> s/nasgar/nascar/

jgraham: this is a short term communication ipc
... it was in the scope of DAPI

plh: Web Intents is also in the scope of DAP

darobin: It was deliberately put into the DAP charter
... it wasn't listed as Web Intents

plh: is that WG working on it?

darobin: I proposed doing it in DAP because we're already chartered to do it

plh: what about Joint?

darobin: I'm always worried about joint deliverables

MikeSmith: what's the value of Joint?
... except additional process?

plh: you get more patent commitments since you have commitments from members of both groups

sicking: in my experience

<MikeSmith> tantek, likely nothing about UX, just about whether to take up the technology in the WebApps WG

sicking: I would see the problem of discussions getting split up across 3 mailing lists
... unless we add a third mailing list

dom: getting a sub mailing list is trivial
... the difficult part is getting people to subscribe to it
... the other thing is that web intents relates to discovery
... and DAP already has that in its charter

ifette: part of the important consideration
... it may be in DAP's charter
... being in a charter may be expedient
... but it may not be the right solution
... we've talked about Web Intents as a possible solution for Permissions problems
... there's a lot of tie in potentially between Web Intents and other work in this WG
... I think this group already has the relevant members
... it's nice, I appreciate that DAP did outreach

<tantek> MikeSmith - without UX being the focus/driver, I'd suggest not bothering with taking up any such technology in any working group.

jgraham: relating to device interaction
... I agree those will happen

<tantek> without UX being nailed first, intents is pretty much doomed

jgraham: the way that the api is written
... is so generic

<tantek> or we can all repeat the lessons learned by OpenID trying to solve the NASCAR problem (where UX was also neglected)

<chaals> ... that it doesn't matter whether it ties to the device or not.

<ifette> s/jgraham/jhawkins/

s/jgraham/jhawkins/

dom: I think the fact that DAP is pushing quite heavily on service and discovery
... means that we want to be involved

MarkV: Mark V.. Comcast

<mav> http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison

MarkV: Part of the reason we're interested

s/MarkV/mav/

scribe: Comcast and Cable Labs
... and Webinos have proposals
... It's in the charter of DAP currently
... it may be more appropriate here

chaals: +1
... literally
... we have a proposal for discovery
... I'm speaking for Opera
... a lot of the people who need to be in the discussion are in DAP
... a joint deliverable has a little bit of value
... a wider IPR commitment
... more pain from split discussion

<tantek> How about a CG instead?

chaals: more lists is hell
... there's a proposal of merging DAP and Web Apps
... it's part of our position

[ amusing proposal and laughter ]

chaals: We would lean towards
... DAP *was* a pretty dysfunctional, pointless, stupid thing, 2 years ago
... it is no longer

jhawkins: Web Intents and Discovery are similar, but they are not the same

mjs: As a point of information
... Apple is unlikely to ever join DAP
... because of IPR concerns and others
... we are somewhat interested in Web Intents
... and would try to comment if it were in Web Apps or joint in Web Apps
... we would not if it were solely in DAP

shepazu: I'm hearing concrete reasons to have it in both
... that sort of supports having it as Joint

darin: Darin, Google
... we work together with Apple
... it's fairly important that we be in the group with Apple talking about Web Intents

chaals: two things
... permissions
... permissions as we all know is a flaming ungodly mess
... it comes up in web apps
... it comes up with almost everything that DAP does
... DAP will fail in everything if it isn't solved
... If Google and Apple are working together with everything
... why does it matter?
... Apple can have Google present the point

darin: it's much easier if things are only in one room
... we are developing Web Intents with Mozilla
... it would be nice if everyone was in one room
... trying to maintain the conversation in different WGs is probably similar

shepazu: both groups do all their work in the public
... web apps is a public mailing list the everyone can subscribe to

ifette: the same argument could be made for whatwg

[ shepazu and darin share the mic to talk about mailing lists / where work is ]

dom: what darin is saying is that if the work was only in DAP
... then since apple couldn't be in DAP
... that it would require someone to do work to share with apple

sicking: any outcome where all the parties can't be at the table is a failure

[ ArtB time check ]

ArtB: Would anyone object to a joint deliverable?

ifette: capital O object?
... I think it would be better if it was a single list, a single WG
... I don't think we'd Object, but we have a preference against
... If DAP folks don't object to doing work in web apps, why don't we do the work here?

shepazu: to clarify, you don't want it to be a joint deliverable?

darin: DAP folks don't mind to do work in web apps
... so why not do work in web apps?

chaals: just as ifette won't formally object to a Joint deliverable
... we would rather that the work happen in DAP
... it's not DAP saying we should merge the group
... it was darobin tossing up the idea

darobin: i'm not even sure myself it's a good idea

dom: one way is to go back to DAP
... maybe there are people in DAP who would want to be involved but can't join Web Apps

ArtB: I'd like to move on to the next topic

jhawkins: I've made a proposal
... that we upload the docs
... and get a thread started
... it sounds like it's not going to be in dap specifically
... it could be a joint effort
... it could move to a third mailing list
... after the fact

chaals: as a way of moving forward
... Web Apps is not chartered to do that
... if DAP does the work and uses Web Apps

ifette: No. no

chaals: you want to wait until chartering?

shepazu: do people object to adding Web Intents to the Web Apps charter?
... we can always decide on Joint later
... I ask the chairs to make that call

ArtB: Does anyone object to adding Web Intents to the Web Apps charter?

Suresh: Suresh, RIM
... so, trying to understand...
... what are the implications on the DAP charter?

shepazu: we're just talking in this WG about this charter

heycam: in terms of initial discussions before chartering discussions are made
... we've discussed things before the decision was made
... as we did for Editing

[ Time check, 5 mins to 2pm ]

weinig: How would it be added?

shepazu: how it would be added would be a deliverable, discussed on the list

mav: if that's concluded, i would ask that the same thing happen for discovery api
... because there's a lot of overlap

chaals: +1
... we would be upset if one happens in DAP and one happens in Web Apps
... we would likely to formally object

RESOLUTION: No objection to adding Web Intents to the Web Apps Charter

Charter/Merge DAP into Web Apps

darobin: the general process of W3C
... is that we put things in DAP
... people say it sucks
... two years later, we try to move them to Web Apps
... i'm not sure it's a good idea
... but i just wanted to throw the idea out there

[ Beep ]

ifette: There's not enmity with DAP
... for the things that we work on, we want to make sure we have all the browser vendors there
... I know Microsoft joined, and that's great
... but we heard Apple won't
... For us, we need all the browsers to give input
... if we don't get that, there's not much point

ArtB: Would any of the Web Apps members object to us merging DAP into Web Apps?

chaals: Personal objections?

Personal objections - 9

chaals: are any of those Formal Objections?

[ There were two Objections likely ]

Charter/Web Notifications

ArtB: what anne wanted to discuss was taking the deliverables from Web Notifications
... and closing Web Notifications

shepazu: I'd like to here why

anne: the rationale would be that it's very hard to move it forward within the scope of Web Notifications
... the editor is overworked
... it's a very small group, I think 6 people
... not enough to pay attention

ArtB: I should have noted that before the Web Notification WG was formed
... some members opposed in Member Confidential way to it being added to the Web Apps WG
... I remind people that they were Member Confidential

shepazu: speaking as staff contact, I don't think it's that easy to find editors here

anne: I could use chair time

Marcos: can we take a poll of who would implement the spec?

ArtB: who is actually interested in implementing this spec?
... Google, Apple, Opera, Mozilla

adrianba: I didn't commit, because often we don't talk about things we're going to do, until we do them
... and when we do say we're interesting, that isn't a binding commitment either

shepazu: i'd like to repeat that we tried before, and i don't think it will work
... this time

chaals: Opera would be happy with it being here
... but we expect it to fail again

ArtB: The chairs tend to think that if we made the proposal to add it to the charter
... that it would fail due to a formal objection

chaals: we will put up the proposal to merging Web Notifications subject to Web Notifications being amenable

Charter/DOM Mutations

<anne> euh used to be called "Mutation Events"

ArtB: from the perspective of the current charter
... There was a deliverable of "ADMN"
... there was a thread from adam klein
... from the charter perspective, how do we move forward
... is this a new specification, or do we add to dom4?

anne: do we have to specify where it goes in the charter?
... as long as we say we're going to do it

shepazu: I don't think that's a requirement
... we just need to clarify that we will do that work

heycam: do we need a specific name in the charter?

chaals: we need "managing changes to the dom and how they happen"

<heycam> s/managing/monitoring/

<dom> s/the dom/the DOM/

<MikeSmith> rniwa, http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

RESOLUTION: add "monitoring changes to the DOM and how they happen" to the charter"

Charter/XHR

<rniwa> MikeSmith: thanks

anne: basically everyone is focusing on XHR2
... I don't think that it makes sense to maintain version 1
... the effort far exceeds any imaginable benefit
... no one is focused on getting it finished

adrianba: I agree with anne on this specific case
... I'd like to avoid setting a precedent
... but for this case, I think it makes sense to stop working on level 1

sicking: I don't have a specific preference
... but I would kind of like to see it shipped
... if we could do that in a short order

anne: Last summer, summer of 2010
... I wrote the spec, I wrote the test suite
... and no one followed up, none of the implementers

chaals: like adrianba, I think it's a bad precedent
... to not ship specifications, that are already implemented and done
... anne works on a lot of things, Opera would much rather he work on XHR2, than level 1
... as chair,
... does someone feel like we all do, and feel like finishing it?

Marcos: why don't we just drop the '2' from XHR spec?

chaals: there is an XHR1, it's probably pretty much done
... I don't see much point in playing a numbers game

[ What prevents us from it being done? ]

anne: lack of implementers trying to pass the test suite
... it is not done, it just requires maintenance costs

Marcos: why is XHR2 dependent on XHR1

anne: XHR2 isn't dependent on XHR1

Marcos: so kill it!

<dom> but are there other specs depending on XHR1?

<dom> we should probably check before taking such a decision

shepazu: is the test suite complete?

anne: the test suite is pretty much complete

shepazu: why aren't people passing the tests?

adrianba: i think there are people that are passing all the tests
... i think the changes that are required to pass the tests are probably not high priorities to the vendors
... since the web kind of works

shepazu: if we can't get two implementations to pass the test
... then we remove that requirement from the charter

chaals: does anyone object such that they're willing to do the work

shepazu: i'm willing to review the work necessary

anne: i'd object to a watered down version of the spec

Marcos: i would object to having a spec with duplicate text
... on the grounds of having confusion

shepazu: that's the situation we're in now

Marcos: that's a process problem

<darin> is this the test suite: http://tc.labs.opera.com/apis/XMLHttpRequest/testrunner.htm ?

<anne> My main point is that a specification should be complete and not leave out all kinds of requirements

chaals: we have a deliverable
... that is of risk of being taken further

<anne> darin, yeah, one of the copies

chaals: and having objections raised later

<anne> not sure if my harness works a 100%, been a while

<darin> anne, ok... looks like chrome and firefox fail a lot of tests

<anne> yeah, mostly edge cases

chaals: it seems clear that we don't have anyone who is going to finish the spec
... with the possible exception of shepazu
... so are we happy to make the spec...

ifette: "if the spec got finished, would all the browsers care, and go back, and become fully compliant? if not, then it doesn't seem worth doing"

sicking: it's at the point where all that needs to happen is implementation

dom: to implement XHR2, XHR1 needs to be done

mjs: I don't have a strong opinion about carrying forward
... but i'd rather a strong opinion to not have it in limbo

adrianba: I agree with mjs
... the value of completing an XHR1
... that describes currently implementations with whatever vagueness is necessary
... getting that to REC is when the IPR obligations kick in

chaals: that's important
... how many organizations in this room make browsers?
... because it's more than 5

<Ms2ger> [ Amaya ]

chaals: Nokia makes, RIM, W3C (Amaya)

s/makes/makes one/

scribe: there is some value to other future vendors
... there is some value
... if we include XHR1 as a deliverable, not that it does not have an active editor, and may be abandoned
... does anyone object?

mjs: I'd object to keeping it in limbo

anne: I'd end up maintaining it

shepazu: If i don't do it in 6 months, I won't do it

chaals: does anyone object to just dropping it?

bryan: does that mean XHR2 will never be finished?

chaals: no, it means the things that need to be done in XHR1 won't be done until we finish the XHR2 spec

PaulK: how much of XHR1 is just a subset of XHR2?

[ Everything ]

scribe: I don't understand this talk
... the problem is you don't have implementations or people willing to do testing

anne: comments still come in
... for instance defining Garbage Collection

s/../.../

scribe: but since XHR1 and XHR2 define events [or similar?] differently
... then editing it isn't that simple
... just because there's a CR version listed on the W3C page
... doesn't mean it's the latest version
... the latest version is the editor's draft

mjs: for almost XHR's history, there have been two versions
... one to spec the original behavior
... and one to define the new cool features
... everyone interested was interested in the latter
... in retrospect, maybe this was a mistake

chaals: mjs maintains his objection, shepazu withdrew his

dom: one thing to check, is to see if anyone has a normative dependency on XHR1

chaals: issues like that I expect to come out during chartering

dom: chartering is a messy process

<dom> s/messy/AC/

ACTION chaals to make sure that the webapps process is taking to the attention of the Chairs

<trackbot> Created ACTION-629 - Make sure that the webapps process is taking to the attention of the Chairs [on Charles McCathieNevile - due 2011-11-07].

RESOLUTION: Drop XHR1 from our deliverables

Charter/Parsing and Serialization

<Ms2ger> Hi

chaals: is there any objection to adding this to our charter?

<Ms2ger> Sorry, my connection is spotty

chaals: does anyone object? does anyone propose that we add the work?
... does Ms2ger plan to do the work?

<Ms2ger> It doesn't matter to me, but I don't plan to put a lot of time in W3C-specific stuff

<Ms2ger> The spec is in the public domain, if someone wants to push it at the W3C, that's fine with me

shepazu: is it our policy that we only add specs that we have editors for?

chaals: we don't have that policy

<Ms2ger> I plan to keep doing the technical editing, but it's rather low-priority for me

chaals: we tend to try to have an editor

<tantek> Ms2ger - what do you think of placing the spec in a Community Group? w3.org/community

ArtB: we have some new stuff, web intents
... preferably we'd have at least two vendors interested in implementing it

sicking: i don't think we'll have a shortage of implementations
... of course that was the case with XHR1

<Ms2ger> tantek, don't feel like spending time on that

<weinig> /msg anne

chaals: and look at how useful that was

s|/msg anne||

<tantek> Ms2ger - I sympathize.

ArtB: i don't object adding it

chaals: my preference is not to add stuff without an editor

shepazu: i think this specification would be of particular interest to the SVG WG
... as someone from the SVG WG, i'd like to see this in the group that works on DOM

ACTION shepazu to ask the SVG WG for editors

<trackbot> Created ACTION-630 - Ask the SVG WG for editors [on Doug Schepers - due 2011-11-07].

RESOLUTION: Add Parsing and Serialization to Charter

Charter/Editing

ArtB: I know Aryeh was working on Editing
... but he didn't make a commitment
... do we let him continue working in the CG
... do we pick it up now, pick it up later?

ryosuke: i'd like to see it in the charter

ArtB: aryeh felt that having it in a CG to do work forward
... but he didn't object to this WG finalizing it

chaals: in the absence of someone driving it in Web Apps
... I think it would be a bad idea
... especially without the resources

Josh_Soref: How is this any different from the previous charter item?

<smaug> #whatwg: AryehGregor "Microsoft Corp. has joined the HTML Editing APIs Community Group"

chaals: I am proposing that we reject Editing APIs under similar circumstances
... given that there is a CG
... I feel we should let them alone given they already have a CG and we aren't likely to add much

ryosuke: there's a difference in complexity
... Editing is much more complicated
... I think it will take a couple of years before it's ready

adrianba: Microsoft just joined the CG with the intent of helping it there

chaals: does anyone propose that we move editing into the WG?

RESOLUTION: We will not move Editing into this WG

ArtB: MikeSmith asked me to add IME
... and I had a generic item related to work mode

MikeSmith: I was hoping ifette was going to be here

Charter/IME

MikeSmith: if you type on a computer in Japanese/Chinese, and to some extent Koreans

s/Koreans/Korean/

scribe: You type in Latin, and then you press a (compose) key to convert the text into a final character
... There are times when you're using a web application that you want the web application to be aware that you're using an IME
... The use case is when you want to do completion
... The IME is a platform level application running alongside the browser
... The browser would need to have access to the system IME
... and expose it to web applications
... web applications do not have access today to the system IME

MikeSmith: it's very hard to explain this to people unfamiliar with IMEs
... a video showing this demoing web suggested autocomplete
... it's pretty simple, but it isn't self explanatory

<ArtB> … IME spec: http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

chaals: given two google editors
... is google proposing that it go into web apps?

ryosuke: yes, we'd like it to be in this WG
... if you're using Google Docs, then a web browser doesn't know that you're editing
... and thus can't enable IME

<Zakim> Josh_Soref, you wanted to note that IMEs are incredibly buggy, crash prone and such exposure is a security hazard

ryosuke: Google would like to simplify this so that IME can be turned on and off

<dom> Josh_Soref: IME are incredibly buggy, crash prone, and such exposure is a security hazard

<heycam> Josh_Soref: I'd like to note that I've worked on Mozilla for >10 yrs, one thing I looked at was crashes

<heycam> ... got lots from X11 IME

<heycam> ... more recently I worked at Nokia on Maemo, we had an IME, not shipped, but we had it

<heycam> ... it also wasn't particualrly wonderful

<heycam> ... more recently we had some great crashes frmo a web based IME in windows, from mozilla

<heycam> ... the IME is actually cloud based

<heycam> ... when their cloud went down, everyone using that IME started crashing

<heycam> ... any time we expose system level things to the web, it hasn't had experience with bad inputs

<heycam> ... nobody thinks you'll get bad input, and that'sb ad

<heycam> s/sb ad/s bad/

mjs: one thing i'd like to see more clearly explained
... is the specific use cases for this api
... I don't have the experience that Josh_Soref does
... but i don't know there's much need
... it sounds like there's a work around
... the main downside is that it's inconvenient, or a hack
... that doesn't seem like a big deal

ifette: i think there's a lot of reasons for adding the IME api
... if you look at google instant
... having access to the list
... having access to state makes it better
... gives a chance to give better results
... better services

mjs: I think it would be good if someone could give a list of use cases where someone could do things you couldn't do today
... from skimming the document, i couldn't figure out what you could do
... that you couldn't do otherwise

chaals: is that an objection?
... an objection until you get further information?

mjs: i think it would be better for the WG to have more information

ryosuke: could we add the item to the charter

chaals: we could add the item, we could talk about it before or after, we could add it next time

ArtB: can someone take an ACTION to address mjs

ifette: we can certainly come up with that list of use cases
... I can make sure we to get someone from our organization to provide this use case
... If we're going to kill editing, we're going to need to get access

shepazu: we're not going to kill editing

<Zakim> Josh_Soref, you wanted to talk about passwords in Mameo5

<heycam> Josh_Soref: the other thing is that for Maemo 5 there was a time when the input method would warn everything you type into the xterm

<heycam> ... including when you typed ssh passwords

<heycam> ... whatever random letters you type into the browser

<heycam> ... the solution was that IMEs were turned off entirely

<heycam> ... having access as a web page to things that I might type, e.g. if I'm on a form, all the completion things in the forsm -- I think Opera did a good job with the wand -- otherwise all your form information and CC numebrs would automatically be filled in

ifette: we all agree there are potential security considerations to take into account

s/numebrs/numbers/

scribe: we have a team from the tokyo office
... it's important for affected usrers

s/usrers/users/

shepazu: this isn't a place for technical feedback

<darobin> +1 to having IME

sicking: that's fine

chaals: is there an objection to adding this to the charter?

sicking: before we were talking about seeing use cases before the charter

chaals: you could cut it out during chartering

sicking: i'd like to see use cases before committing to it
... if the use cases are editing and canvas

ArtB: i think the charter is good until spring
... historically it takes a long time to get our charter added

s/added/updated/

scribe: there's a 4 week AC review
... we need several weeks for WG discussion
... the earliest to the AC would be Jan or Feb

chaals: is there any objection to not putting this in the charter now
... given we would put it before the WG before the end of the year

<dom> shepazu, adding a link to http://www.w3.org/2010/webapps/charter/ from http://www.w3.org/2008/webapps/charter/ would be useful

chaals: with an action on chairs to put it before the group
... ?

shepazu: i'd rather it be in the Charter proposal
... given that it could be cut later

mjs: i'd object
... i'd like to be informed enough about this
... it seems like that wouldn't take a lot of time

adrianba: I agree with mjs

ifette: there's so much time to object
... if you look over the use cases
... there's plenty of time to object
... I could list use cases
... there is a large class of users who are not well served by a number of sites
... everyone who is objecting
... yes, we could have done a better job of preparing our case
... but the objectors aren't affected

mjs: i believe people should be required to present their case

chaals: like mjs, i object the implications

<weinig> yes

s/mjs/weinig/

s/yes//

chaals: if you're willing to do the legwork
... it seems like we have 2 1/2 objections
... so it seems like you should do the legwork
... the concrete path forward is that we expect you to further motivate this proposal
... if you're prepared to put in the legwork
... around mid december
... so you give us material
... i'll take an action for Dec 1

[ No Objections ]

ACTION ifette to talk to people at google to get more support for the proposal

<trackbot> Created ACTION-631 - Talk to people at google to get more support for the proposal [on Ian Fette - due 2011-11-07].

ACTION chaals to put IME in Charter on the discussion for Dec 1

<trackbot> Created ACTION-632 - Put IME in Charter on the discussion for Dec 1 [on Charles McCathieNevile - due 2011-11-07].

<chaals> Scribe: chaals

<ArtB> ACTION: barstow should XHR1 be published as a WG Note? [recorded in http://www.w3.org/2011/10/31-webapps-minutes.html#action02]

<trackbot> Created ACTION-633 - Should XHR1 be published as a WG Note? [on Arthur Barstow - due 2011-11-07].

Websockets

AB: We're late, and may cut into the next item. Peter will update on protocol and IETF side, we'll look at other topics, testing, future directions...

PSA: Co-director of applications at IETF
... [quick explanation of IETF structure]
... HyBi WG is a group in my area. Between IETF/W3C we have had IETF doing protocols, W3C doing APIs. (generally)
... Hybi has been formalising web socket protocol, Hixie - Ifette - Alexey...
... and extensions, sub-protocols, and so on
... Current status is sockets protocol has been approved after last call, is in queue to be published as RFC.
... Think we ha good coordination with W3C on the API.
... Think we want to try to coordinate better from IETF.
... Extensions - multiplexing, compression, are topics people have talked about.
... will come forward in the next few months. Also looking at sub-protocols - I come from Jabber/XMPP, and we want to have a sub-protocol to replace long polling, there are others.
... Once the API is finished I think we will get a lot of experience in the next few years, I foresee a cleanup version.

IF: Maybe a few months...

PSA: Maybe. I think we will need one at some point, anyway.

AB: Last call for WS API ended about a week ago

IH: 2 bugs closed, only 2 left.

AB: First looks like editorial

IH: Yep.

AB: 14474 been discussed quite a bit, no?
... we could talk about it today. Julian submitted a comment, not exactly an objection. Some URL processing got deleted from spec, added to API - hixie can elaborate on that. We need to figure out whether it pushes us back to last call, along with closing the outstanding bug.

JS: Sounds like MS is agreeing with 14474 - curious if google has opinion.

IF: If browser sends close frame, and server has meesages in flight before it closes - do those messages get delivered?
... want to avoid half-duplex connections in protocol - one side can send but not receive. THe protocol doesn't address what happens here. Either answer would be OK (dump the messages or deliver them)

JS: And messages in buffer etc...

IF: Right. We just need to agree on what we decide.

??: COmments are in the bug, agree we should just decide one way - don't have two versions.

IF: Agree.

??: We are in violent agreement.

AB: Hixie, do you have what you need to close it?
... would that necessitate a last call?

IF: Think it is a clarification not a change.

ABate: agreed

ArtB: outstanding issue is comment from JR:

<krisk> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html

<stpeter> Julian's comment was http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0084.html ?

[Robin waltzes in 30 minutes late]

AB: Is this some kind of showstopper? Is the change substantive enough to go back to last call?

IF: Original text was algorithmic parsing of URI. Got taken out of processing, but added into API spec. Question is whether a clear description of how to parse a URL is substantive

MJS: SOunds like a good change, sounds substantive.

<Josh_Soref> s/SOunds/Sounds/

IF: Didn't change behaviour, it is like a clarification of parsing a URI

<stpeter> Julian's message was "I just noted that as of yesterday, the API spec contains the custom URI

<stpeter> ... parsing algorithm that we removed from the protocol spec a long time ago."

IF: doesn't change the browser, just trying to be clear on corner cases. Intent is to specify what browsers do, not change anything.

MJS: reads "substantive change" from process...
... personally it sounds like a good change.

CMN: Would you have expected to parse a URI differently? If not I don't think it is a substantive change.

MJS: If you change the text, you might introduce a change.

IF: If you did a review it seems that you would have read it in one place or the other. Doesn't seem like an actual change

AvK: At best it is a 3-week difference. Do we need to argue one way or another?

DS: Process is to get good reviw, and resolve difference of opinion. If people don't think there was harm, I don't think that the process requirement is active.

MJS: Last call is for people outside the WG. The fact taht people here like it doesn't matter, it gives a fair opportunity to comment for people outside the WG.

DS: Right. In this case it got moved from one place to another.

<Josh_Soref> +1 to MJS's note

MJS: Sure, but it went from one organisation to another.

<Josh_Soref> s/taht/tat/

<Josh_Soref> s/tat/that/

MJS: prefer in the case of doubt that we are clear we follow the process, rather than beng sloppy.
... being only a few weeks difference, it sounds like it won't change anyone's plans

ABate: Sounds like no consensus to move to CR, another last call is appropriate.

RB: Operative word is reasonable, I don;t think there is reasonable doubt it would change anyone's review.

DS: Think ths call is up to the chairs

<Josh_Soref> s/don;t/don't/

<Josh_Soref> s/ths/this/

CMN: Anyone object moving through to CR, and claiming the change is not actually one that would materially affect a review?

[no objection]

RESOLUTION: We don't need to return to Last Call.

<ArtB> ACTION: barstow start a CfC to publish a CR of WebSockets API (after Hixie closes 14474) [recorded in http://www.w3.org/2011/10/31-webapps-minutes.html#action03]

<trackbot> Created ACTION-634 - Start a CfC to publish a CR of WebSockets API (after Hixie closes 14474) [on Arthur Barstow - due 2011-11-07].

ABate: Shipping implementation of WS we also submitted some test cases. To test, you need a websocket server - we have a temporary server hosted.
... getting that hosted by W3C and letting others build test that run on the server side seems essential. Can W3C / systems team figure out how we deliver that?

<ArtB> ACTION: barstow work with Chaals and the Team re infrastructure to test WebSockets API [recorded in http://www.w3.org/2011/10/31-webapps-minutes.html#action04]

<trackbot> Created ACTION-635 - Work with Chaals and the Team re infrastructure to test WebSockets API [on Arthur Barstow - due 2011-11-07].

s/deliver that/we get the server hosted by W3C/

IF: You mean a server you could run internally?
... we have a python thing you could install and run.

ABate: No firm criteria, people want to test the browser without having to run something locally, would be helpful if it could be hosted as well as people having to set up their own.
... Our current server is open source but we don't care much. Key thing is being able to support a server within W3C that people can write tests for.

JG: Absolute requirement that we can run it internally.
... Also running on W3C server is fine. Think the security makes this a reasonably hard problem to solve because it has to be secure - pywebsocket is known not to be secure.

DS: We'd have to check with systems team of course, I can ask them...

DHM: Asked systems team. Main thing is to have something that we don't have a lot of maintenance for. I was imagining running a node.js server with sockets, limiting the maintenance required. That could fly, but we need a concrete thing to run and to check.

ABate: So how do we move forward? We're not sur what we could propose, you're not sure what will be proposed...

DHM: Need something open source, ideally something with maintenance process...

ABate: Not sure we have that right now in a way that allows 3rd party submissions...

<smaug> uh, websocket CR o_O

CMN: If someone has something, let's look at it and see whether it works for us.

DS: Yeah, explain how to run it.

KK: Right. People will test this - so if it isn't being run it isn't any good.

IF: Yes, we need something we can run locally, but don't object to something running hosted.
... if we can run it, presumably it could be run externally too.

JG: If running it externally turns out to be difficult, we could do without that.

IF: Think we could figure that problem out. Let's try to make it happen.

JG: Right. make a decision on a framework so people can write tests sooner rather than later.

IF: Don't hear disagreement, but not sure we will resolve right now which framework we'll use. Someone needs to come up with a submission.

<scribe> ACTION: Kris to propose a framework for running testing. [recorded in http://www.w3.org/2011/10/31-webapps-minutes.html#action05]

<trackbot> Created ACTION-636 - Propose a framework for running testing. [on Kris Krueger - due 2011-11-07].

AB: Adrian, do you want to talk about future direction?

ABate: not really.

PSA: Seen proposed extensions for multiplexing and compression, heard number of people say this would be useful, so expect to see those but nothing concrete here.

SW: Do you imagine it would be a non-backwards-compatibile change?

IF: Imagine an extension that is negotiated - non-multiplexing client could talk to a multi-plexing server, althugh the server might refuse to answer as policy rather than protocol

SW: Server could serve both ways?

IF: Yes. Client sends handshake with capability, server can accept a connection that works, or reject it, without changing the base protocol.

DOM3 Events, DOM4

<Josh_Soref> Scribe: JonathanJ

<Josh_Soref> Scribe: Josh_Soref

ArtB: Status of DOM3 Events
... a CFC for Candidate was made 3 weeks ago
... and ended
... with Ms2ger Objecting
... Ms2ger had 3 objections in his email

<ArtB> http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0108.html

shepazu: ...
... 1. issue 123
... - by anne

<ArtB> AB: here is the IRC log from Oct 25 (Art, Doug and Olli): http://krijnhoetmer.nl/irc-logs/webapps/20111025

<heycam> s/123/123, which contradicts DOM4's statement that no new feature strings should be minted/

shepazu: svg uses feature strings

mjs: there's the whole substantial discussion about feature strings being a good or bad idea
... as far as the DOM spec's view of feature strings
... it only supports a fixed, non extensible set of strings
... if another spec wants to say that it modifies what that spec says
... it could

shepazu: one could argue that what DOM4 says is violating what DOM3 says

jrossi2: I agree that this i

s/this i/this is/

scribe: strange
... i gave personal feedback against removing this from the platform

anne: among most people, feature strings seem to be a bad idea
... you can claim to support a feature by claiming to support a feature
... but not actually support a feature
... a feature can be composed of multiple parts
... and you can only implement some of them
... whereas feature detection is robust against this

chaals: I agree that feature strings as used by DOM are a failure
... i'm not so sure that the DOM spec should throw out the ability to define them

<smaug> there is no robust feature detection for events

[ scribe lost the correct wording and used robust instead ]

scribe: and even if DOM throws these functions out and washes its hands of it
... it doesn't ...
... "you MUST not" is a whole nother ball of wax

anne: as a group, we agree that we shouldn't do this
... but, where else would we put it

[ scribe is not catching full text, sorry ]

shepazu: i don't think we made this RESOLUTION
... as editor of the DOM3 spec, I don't think I was informed of this

Marcos: let's do it now!

shepazu: we don't make decisions in ... [cut off]
... one of the reasons that they haven't been successful in the past
... is that they weren't fine grained

anne: so you have to make them more complex?

shepazu: i didn't say complex, i said precise

mjs: if we make them sufficiently precise, you might as well use feature detection

jgraham: what's the technical reason for this

<smaug> jgraham: there is no good way to feature detect events

anne: if event objects are forced to be exposed by webidl

mjs: it's better if events ....

<smaug> that is event objects, not event types

<anne> burn the witch!

mjs: it's better to burn feature strings to the ground

weinig: historically, in our implementation, we have not been very good at keeping feature strings matching our implementation

alexr: i want to second that

s/alexr/slightlyoff/

shepazu: i'm not going to fight the issue
... we can remove them
... jrossi2 : you have the implementation of this

jrossi2: I don't know that it harms the implementation
... the extended implementation
... we've seen some compat issues, in terms of consumers
... i think jQuery uses it

anne: i do not, and never have proposed, support removing older elements

[ the dom4 spec just freezes the old list ]

mjs: to get out of this philosophical issue of whether dom4 can tell what other specs say
... we could define the functions to return true for a specific list of strings
... [ which effectively removes any relation of the feature to the function ]

jrossi2: it could be marked as AT-RISK
... and discussed on the list

anne: it seems easier to remove

shepazu: no, that would require another LC

mjs: you can remove features marked as AT-RISK without going back to LC
... it sounds like there's sufficient resistance to this feature
... to prevent this group from formally going to CR
... because the group doesn't support the feature

shepazu: I'm fine with removing them if jacob is fine with removing them

jrossi2: if that's considered a substantial change which would force us to go to LC, then i'd object

shanec: Issue 2

[ shepazu reads from the objections ]

s/shanec/shepazu/

<ArtB> … Issue 2 is "Second (issue 179), it ignores the consensus about using DOMException instead of custom exception types like EventException, as noted in WebIDL, [3] which I reported. [4]"

anne: mozilla already removed EventException

sicking: we have not removed it
... we were planning on it

heycam: window.EventException does not exist in my nightly build

jrossi2: the new exception type was brought up prior to the LC
... before the consensus of how to move forward
... and we found them useful
... since then the feedback that our resolution was incompatible with that
... was after the LC

anne: that was on a call with few members
... and I sent comments on them
... and they were not addressed for months

chaals: can we stop arguing about process, unless we have a formal objection on process

anne: i think it matters on how we develop drafts

chaals: yes it matters, and in particular, the chairs allowed the editors to screw up
... the question is whether there's a technical reason to fix what came out of the process

sicking: if the D3E spec is specifying an exception type which we don't implement
... i'd object to that
... i'd imagine that other implementations feel that way

jrossi2: there's already some implementations implementing it

<smaugN900> we did implement that exception type

jrossi2: there are at least 2 interoperable impls

<smaugN900> but we moved to dom 4 exceptions

jrossi2: DOM4 is free to evolve that idea

sicking: i'm not convinced if 2 browsers have implemented it
... what matters is what all browsers can implement

jrossi2: i think that web developers care about previously shipped implementations

mjs: if we agree to remove it later
... over time
... then codifying it will make it harder
... because people will complain that browsers are incompatible

<smaugN900> also, I thought it was agreed that D3E will use dom4 exception type.

heycam: given that D3E is not using WebIDL
... i don't think there's a normative way to detect this

anne: constants

heycam: number 2, it's not useful
... it's unlikely that users would .name = eventexception
... i wonder if content use this
... and checking that code relies on it

[ scribe repeats what smaugN900 said for the room ]

anne: there's a desire to get D3E to REC
... people working on D3E want to get to things to REC and generally agree with the direction it's going
... but some are concerned about time target

jrossi2: shepazu do you recall us changing?

shepazu: i don't care at this point
... it doesn't matter, it shouldn't affect anything
... except possibly script libraries

<ArtB> Jacob, here is the IRC log from the call I had with Doug and Olli: http://krijnhoetmer.nl/irc-logs/webapps/20111025

sicking: which browsers have shipped this, and for how long?

anne: only one that ...

weinig: I think WebKit has been shipping it for many many years

jrossi2: I think WebKit and IE and I thought Opera had passed the test case

shepazu: the final thing is WebIDL
... i'd like to have heycam speak to how long before WebIDL is stable.. i.e. to REC

heycam: how many recommendations do you have?
... to get to rec, you need test suites, and passing implementations

shepazu: regarding normative, instead of informative
... i'd suggest we go to CR
... and if WebIDL makes faster progress

<heycam> s/recommendations do you have/requirements are there in the spec/

shepazu: I don't want to make D3E gate on WebIDL

jgraham: regarding testing
... some things have a tendency to rely on WebIDL

anne: how can you not define the binding to JS and still test it?

<smaugN900> (I think there are still quite a few open webidl spec bugs. and more coming when it is being implemented.)

shepazu: i think we should try to go with what we have
... and see how far we go
... i think a snapshot is useful
... there are plenty of test suites that do not use webidl

jgraham: there's not a great tradition of test suites

anne: those specs defined a binding

Marcos: i want to second just about everything that anne is saying
... webidl defines a bunch of stuff

<heycam> Presumably Anne is thinking of something like http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html.

Marcos: it defines how to implement everything
... and i can generate tests from it

shepazu: we have 2 passing implementations
... is it less useful to have D3E actually out there
... pushing forward on the keyboard model
... i think it's much more useful to have a keyboard model than some actual architecture astronaut

Marcos: it's rhetorical
... what's the aim of the spec

shepazu: by going to CR, we can get more implementations of those features

Marcos: the implementers at the table, saying we don't like how it's written
... we want it in WebIDL

shepazu: does everyone agree that it's more important to have it in WebIDL?

<smaugN900> marcos: really?

chaals: who thinks we should not go forward before D3E normatively references WebIDL

mjs: scanning over the normative idl in the spec
... and non-normatively in webidl
... they seem to define different behaviors
... that makes me uncomfortable

jrossi2: that's a great bug to file

chaals: who thinks we should go forward with this without making webidl a normative requirement
... jrossi2 and shepazu against, and everyone else with an opinion of waiting on webidl
... which was a fairly broad collection

shepazu: as a point of order

<smaugN900> that is ok

shepazu: i believe we have 2 implementations passing most of the items

s/that is ok//

scribe: and i believe in short order that we will have 2 implementations for all

sicking: i think all of the time that when all of the vendors have said we will not go forward
... that we have not gone forward
... i can't think of any times when even one has said no that we've moved forward

mjs: in general, we don't move to CR without support

chaals: i think the general sense has been that we want to move forward with specs that everyone will implement
... i think getting D3E to REC would be useful
... getting another spec that isn't finished
... would be bad

s/.. getting/... getting/

chaals: i agree with mjs, i don't see a requirement that this group be consistent in its processes
... i would object to any formal requirement that everything be agreed by everybody
... i think it's a good rule of thumb
... as chair, the job is to get consensus
... and it seems we don't have a consensus to go forward without webidl
... sometimes we need to acknowledge that we are not that good at achieving our goals

jeff: is there a plan to get webidl as normative?

chaals: one of the things is waiting until WebIDL is done

shepazu: we have an informative WebIDL reference
... it's just a matter of making it normative

<smaugN900> does that mean that we give up with D3E and move to D4E?

shepazu: and then waiting for WebIDL to be `done`

heycam: how much done do you need?
... what's the comparison in times between WebIDL and D3E?

dom: processwise, if D3E depends on WebIDL
... then D3E can't go to REC without WebIDL done
... we have special rules for HTML

shepazu: that's not in the process documentation
... it's a policy
... it's somewhat of a catch-22
... at what level of webidl implementations can we have to get it to move forward

<dom> [the policy enacts a director decision, so it's as powerful as the process document afaik ]

shepazu: i'm fine with making changes to the admin exceptions

<heycam> s/admin/event/

shepazu: i'd like a bounded requirements on the specifications
... it sounds like we're going back to LC

anne: some of these issues were raised pretty early on
... as in March

shepazu: that's not very early on

jeff: what does the dependency on webidl look like?
... i didn't get an answer

chaals: i think the answer we got
... is that if we make it dependent on webidl
... we don't have an expectation that webidl is racing along to webidl
... shepazu suggests there are a small number of issues before D3E can go to CR
... if it is held up by WebIDL, then that could be a very long wait in CR
... we may ask the Director to wave the convention
... we're going to put WebIDL specs through to REC
... because we need specs out there to get WebIDL done
... although he generally doesn't want to use that authority
... an exception has been granted for HTML5

anne: what's being missed by your comment

<smaugN900> (so assuming webidl is stable late next year, D3E could be rec in 2014)

anne: is that currently it doesn't define JS bindings

<smaugN900> er 2013

anne: WebIDL defines a language and the binding from that language to javascript

jeff: smaugN900 's answer answers my question

jgraham: since WebIDL defines a semantic
... and since browsers implement in terms of WebIDL
... it seems like not claiming to rely on WebIDL is a lie

heycam: the number of most recent LC comments was 15
... and most are pretty simple
... the comments could be resolved in a month or two

mjs: so less than a year to get to CR?

heycam: so LC if we make normative changes
... and then 3 months and then CR

mjs: so, optimistically?

heycam: the big time bit is moving from CR to REC
... it's getting implementations

sicking: are there specifications that use "all" of the features of WebIDL?

mjs: for each webidl feature, is there at least one spec using it?

Josh_Soref: is there at least one W3 spec for each WebIDL feature?

heycam: there is a feature which we'd probably drop that wouldn't

s/wouldn't/is only used outside/

chaals: if we take the RESOLUTION that we make those changes and send it back to LC
... and send it through with the statement that D3E would be LC specifically scoped to those changes

sicking: does that include deprecating the EventException interface?

chaals: yes, all three changes

anne: i guess it's ok
... but there are various minor comments raised
... and i'm not sure how they were addressed relating to DOM4
... initEvent

s/../.../

scribe: there's something which is prohibited, although jackal said it might be allowed if you interpret the spec in an interesting way

ojan: my general experience w/ D3E
... is that the push to get it to REC has generally trumped technical issues
... it's hard to retroactively make it good
... i'd rather consider it a sunk cost
... and just look toward DOM4

shepazu: are you talking about new features, or the way things are actually specified currently
... i know i said i wasn't adding new features

ojan: not adding new features is totally ok

chaals: so you're supporting anne in not being certain about other little things

<smaugN900> (DOM4Events, not just DOM4)

Marcos: i've also tried implementing things from D3E
... and i've had to fall back to DOM4
... there's good bits in the spec, but i think it's overreaching
... the stuff that anne 's done in DOM4
... he's make the event dispatch really clear
... the mouse/keyboard stuff is great
... the web is going to be underpinned by DOM4 and WebIDL

chaals: if as chairs

<smaugN900> if event dispatch is not clear in D3E, please file a bug

chaals: we proposed to make an LC with only the new changes
... are there people who would object

mjs: i would object because i don't think the process supports that

chaals: there's precedent

shepazu: it doesn't disallow it

chaals: i don't want a question, just a technical objection

sicking: are there things where D3E is in direct opposition to what DOM4 says?

shepazu: in D3E we tried to match what implementations did

anne: but you didn't

jrossi2: the initEvent is the only other thing i've ever seen

anne: if you create an event, what does event.type return?

chaals: we should leave it undefined until DOM4

sicking: i don't want to run into issues doing DOM4 because it conflicts we things D3E says

shepazu: D3E is generally a subset of DOM4

anne: there are some contradictions
... initEvent, things that are not defined

chaals: things that are not defined is not a contradiction

sicking: i'm not worried about undefined
... just things that it does say which contradicts what it actually does say

Marcos: we can't just do levels/errate

s/errate/errata/

<smaugN900> (I think I.ve missed what is wrong with initEvent)

chaals: option 1: we go forward with the spec, making the 3 changes outlined in the 3 issues
... and moving forward based on that
... restricting the LC scope to that
... there are 3 4 objections

s/3 4/3 ... 4/

chaals: are there objections to:
... we will go through and open an LC with an open scope
... and with an explicit plan that we will
... that any further LC will be restricted
... and we expect to move forward
... are there objections - One open LC and one further limited to issued raised in that LC
... there is precedent to that, not in this group, but in others

mjs: i'm dubious, but i don't object

chaals: does anyone expect that they're going to keep saying "no, no, no"

Marcos: it's not a bad spec
... it's just there's too much conflict between two specs

<smaugN900> what are the conflicts

chaals: i'm going to table that question

<smaugN900> one exception type

Widgets v2

D3E

AlexRussel: there is a v3/v4 tension

jrossi2: there's a lot in D3E events which is not really for DOM4

AlexRussel: and there's a question of dropping D3E

ArtB: looking at the Agenda
... is this the 9-11 slot?

shepazu: you mean when i'm @WebEvents?

ArtB: how about 10?

Widgets v2

ArtB: Web Application Packaging v2

Marcos: I don't remember proposing tihs
... i'm not going to waste people's time here
... given the workshop on saturday
... i think that will determine if we'll have a v2
... i'm happy to listen to requirements
... thanks everyone

ArtB: any other comments?

Josh_Soref: i'm unhappy with the day being Saturday

[ Adjourned ]

RRSAgent: make minutes

trackbot: end telcon

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/I think//
Succeeded: s/12/13/
Succeeded: s/Zakim: [IPcaller] is Olli_Pettay//
Succeeded: s|/me thanks Ms2ger ||
FAILED: s|!/me thanks Ms2ger !!||
Succeeded: s/s!!!//
Succeeded: s/me thanks Ms2ger//
Succeeded: s/me thanks Ms2ger//
Succeeded: s|!/ !!||
Succeeded: s/s|||//
Succeeded: s|/||
Succeeded: s/Josh/Josh_Soref/
Succeeded: s/Jonas Sicking/Jonas_Sicking/
Succeeded: s/macie/weinig/
FAILED: s/Josh_Soref: I'm not macie, Sam Weinig//
Succeeded: s/Josh_Soref: it's ok//
Succeeded: s/Sever/Server/
Succeeded: s/and anne-xxx-something-else//
FAILED: s/to cover cross cross origin/to cover cross origin and opting in to credentials exchange/
Succeeded: s|s/Josh_Soref: I'm not macie, Sam Weinig//||
Succeeded: s/update had/Warp had/
Succeeded: s/Warp/WARP/
Succeeded: s/CORS was selected/same origin was selected/
Succeeded: s/issu/issue/
Succeeded: s/artb: yes//
Succeeded: s/clilly/clilley/
Succeeded: s/needs ot/needs to/
Succeeded: s/time/type/
Succeeded: s/... for images/sicking: for images/
Succeeded: s/Form-Origin/From-Origin/
Succeeded: s/F-O is in Sec only/From-Origin is in WebApps only/
FAILED: s/Adam:/Adam Barth:/
Succeeded: s/and/and sub resources come from/
Succeeded: s/dom/daniel/
Succeeded: s/daniel/glazou/
FAILED: s/..../.../
FAILED: s|s/..../.../||
FAILED: s|s/..../.../||
FAILED: s/Topic: animations [cont'd]//
FAILED: s/present+WayneCarr/present+ WayneCarr/
FAILED: s/present +stpeter/present+ stpeter/
FAILED: s/Josh_Soref: thanks//
FAILED: s|s/present+WayneCarr/present+ WayneCarr||
Succeeded: s/meeting/Workshop/
Succeeded: s/spec/specs/
FAILED: s/2./2.0/
FAILED: s/nasgar/nascar/
Succeeded: s/3/2/
Succeeded: s/sub/third/
FAILED: s/jgraham/jhawkins/
FAILED: s/jgraham/jhawkins/
FAILED: s/MarkV/mav/
Succeeded: s/object/Object/
FAILED: s/managing/monitoring/
FAILED: s/the dom/the DOM/
FAILED: s/makes/makes one/
FAILED: s/../.../
FAILED: s/messy/AC/
FAILED: s|/msg anne||
FAILED: s/Koreans/Korean/
FAILED: s/sb ad/s bad/
FAILED: s/numebrs/numbers/
FAILED: s/usrers/users/
FAILED: s/added/updated/
FAILED: s/mjs/weinig/
FAILED: s/yes//
FAILED: s/SOunds/Sounds/
FAILED: s/taht/tat/
FAILED: s/tat/that/
FAILED: s/don;t/don't/
FAILED: s/ths/this/
FAILED: s/deliver that/we get the server hosted by W3C/
FAILED: s/123/123, which contradicts DOM4's statement that no new feature strings should be minted/
FAILED: s/this i/this is/
FAILED: s/alexr/slightlyoff/
FAILED: s/shanec/shepazu/
FAILED: s/recommendations do you have/requirements are there in the spec/
FAILED: s/that is ok//
FAILED: s/.. getting/... getting/
FAILED: s/admin/event/
FAILED: s/wouldn't/is only used outside/
FAILED: s/../.../
FAILED: s/errate/errata/
FAILED: s/3 4/3 ... 4/
Found Scribe: Art
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Found Scribe: chaals
Inferring ScribeNick: chaals
Found Scribe: JonathanJ
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Scribes: Art, Josh_Soref, chaals, JonathanJ
ScribeNicks: Josh_Soref, chaals

WARNING: Replacing list of attendees.
Old list: +1.408.988.aaaa Olli_Pettay tpac
New list: tpac

Default Present: tpac
Present: Art Charles chaals Dom Cameron JonathanJ Laszlo_Gombos Eliot Graff Sam Weinig Jacob Rossi anne Josh_Soref pererik Kris Krueger magnus shepazu SungOk_You Dowan Bryan_Sullivan Jonathan_Jeon Marcos Robin Jonas_Sicking israelh DanielAppelquist mjs dcooney stpeter manyoung adrianba WayneCarr darin Soonho_Lee Jeff ifette spoussa
Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31
Got date from IRC log name: 31 Oct 2011
Guessing minutes URL: http://www.w3.org/2011/10/31-webapps-minutes.html
People with action items: art barstow kris

WARNING: Possible internal error: join/leave lines remaining: 
        <dom> glazou has joined #webapps
        <smaug> #whatwg: AryehGregor      "Microsoft Corp. has joined the HTML Editing APIs Community Group"



WARNING: Possible internal error: join/leave lines remaining: 
        <dom> glazou has joined #webapps
        <smaug> #whatwg: AryehGregor      "Microsoft Corp. has joined the HTML Editing APIs Community Group"