/irc-logs / w3c / #webapps / 2009-11-04 / end

Options:

  1. # Session Start: Wed Nov 04 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:00] <chaals> ... Since synch is app-controlled there are difference to appcache. timing is different - has to happen when the app kicks in. 2nd, data items to be fetched have to be identified.
  4. # [00:00] * chaals wonders if jorlow wants to ask his question.
  5. # [00:00] <chaals> see example 4.1.1 in datacache draft
  6. # [00:00] <jorlow> chaals: I can do it on list
  7. # [00:01] <chaals> ... roughly equivalent to what you do in app cache. app cache doesn't provide direct access, but data cache needs that to decide what further stuff gets synched. Ususally happens in a long-running single transaction. API provides a way to control synch, or do offline transactions - instead of doing capture by a URI alone you can do offline transaction specifying URI and the bits representing the URI that could be used later in a request made by
  8. # [00:01] <chaals> the app.
  9. # [00:02] * arun jorlow, use a comma when addressing a person, lest it seem like he said it during the discussion (how minutes are generated)
  10. # [00:02] <mjs> q+
  11. # [00:02] * Zakim sees jorlow, mjs on the speaker queue
  12. # [00:02] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  13. # [00:02] <chaals> ... Understand this raises concerns and we should discuss. As well as GET and HEAD you can use PUT POST or DELETE where there is an interceptor registered on the navigator object similar to protocol handlers.
  14. # [00:03] <jorlow> q-
  15. # [00:03] * Zakim sees mjs on the speaker queue
  16. # [00:03] <timeless> ack mjs
  17. # [00:03] * Zakim sees no one on the speaker queue
  18. # [00:04] <chaals> MJS: You mentioned ffedback was about relation of this to appcache. (I gave some) looking at the draft it looks like at least two of my most important points are not addressed. If I ahve both appcache and datacache, how do they intersect. Your spec doesn't decsribe taht. Would prefer a single API with union of capabilities.
  19. # [00:04] <arun> s/ffedback/feedback
  20. # [00:05] * Quits: jorlow (jorlow@72.254.58.121) (Quit: jorlow)
  21. # [00:05] * Quits: michaeln (michaeln@72.254.82.239) (Quit: michaeln)
  22. # [00:06] * Quits: adrianba (adrianba@72.254.111.48) (Quit: Bye!)
  23. # [00:06] <Zakim> -Chris
  24. # [00:07] * Parts: pcastro (d0735eed@128.30.52.43)
  25. # [00:07] <Zakim> -[Microsoft]
  26. # [00:08] * Quits: eric_uhrhane (48fe5208@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
  27. # [00:08] * Quits: pererik (pe@72.254.103.214) (Ping timeout)
  28. # [00:10] * Quits: ifette (kvirc@72.254.95.41) (Ping timeout)
  29. # [00:10] * Quits: Magnus (rooms@72.254.104.46) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
  30. # [00:12] <Zakim> disconnecting the lone participant, apis-db-stuff, in Team_(webapps)21:35Z
  31. # [00:12] <Zakim> Team_(webapps)21:35Z has ended
  32. # [00:12] <Zakim> Attendees were apis-db-stuff, +1.206.369.aaaa, Chris, [Microsoft]
  33. # [00:15] * Joins: tlr (tlr@128.30.52.169)
  34. # [00:16] <chaals> Topic: second CORS
  35. # [00:17] * Joins: pererik (pe@72.254.103.214)
  36. # [00:20] * Joins: annevk (opera@72.254.82.30)
  37. # [00:22] <arun> scribenick: arun
  38. # [00:22] * Quits: gsnedders (gsnedders@83.252.226.150) (Quit: gsnedders)
  39. # [00:22] <chaals> q+ mjs
  40. # [00:22] * Zakim sees mjs on the speaker queue
  41. # [00:22] * Quits: JonathanJ (hollobit@72.254.93.129) (Quit: JonathanJ)
  42. # [00:22] <arun> mjs: [May present a short slide show]
  43. # [00:24] <chaals> ack mj
  44. # [00:24] * Zakim sees no one on the speaker queue
  45. # [00:24] <annevk> hmm, no adam :/
  46. # [00:24] <chaals> rrsagent, draft minutes
  47. # [00:24] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html chaals
  48. # [00:24] * Quits: tlr (tlr@128.30.52.169) (Ping timeout)
  49. # [00:24] <arun> +JeffHodges
  50. # [00:24] * Zakim wonders where JeffHodges is
  51. # [00:24] <chaals> Jeff Hodges, Paypal
  52. # [00:24] * Quits: shiki (sokasaka@72.254.102.153) (Quit: shiki)
  53. # [00:25] <arun> mjs: Gives a presentation on CORS that he commits to putting online soon.
  54. # [00:27] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  55. # [00:27] <chaals> Present+ Marcos
  56. # [00:30] * Joins: shiki (sokasaka@72.254.102.153)
  57. # [00:30] * Joins: tlr (tlr@128.30.52.169)
  58. # [00:30] <arun> MM: [Points out that "secret token" addresses issues in Origin]
  59. # [00:31] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  60. # [00:34] <chaals> Present+ Benoit
  61. # [00:35] <chaals> MJS: In access grant (CORS case) you need to add origin check or token (as normal) to protect against CSRF.
  62. # [00:36] * arun thanks chaals
  63. # [00:36] * Quits: darobin (robin@72.254.94.220) (Ping timeout)
  64. # [00:38] <arun> mjs: [In the common case, where you're logged in, and permission is granted, diagram illustrates CORS]
  65. # [00:38] * Joins: hodges (hodges@72.254.87.82)
  66. # [00:38] <arun> TC: There's an implicit trust relationship between the Events site and the Calendar site.
  67. # [00:39] <arun> TC: The party that could be attacked here -- the Calendar (via confused deputy) -- could be attacked by Event page. Event page (Server B) can trigger an inadvertent action on Server A (the Calendar site)
  68. # [00:40] * hodges is now known as JeffH
  69. # [00:41] <arun> TLR: Turn Server A into an AtomPub server. You want to create a resource, you get the identifier for the resource returned. A page on B uses AtomPub to do something on Server A
  70. # [00:41] <arun> s/A page on B/resource on Site B
  71. # [00:42] <arun> TLR: B, the event Page, creates a resource on A. B does not know in advance what the URI of the event would be. A returns a URI. B could inadvertently phone home to A and create [error condition]
  72. # [00:42] <arun> MJS: If Server A only responded with the path part of the URI, there would be no such vulnerability.
  73. # [00:43] <arun> TC: But this may also eliminate valid use cases!
  74. # [00:43] <arun> MM: Let's contrast this with the same scenario, where you're using a per-resource secret token, along with the designator. In that case, access is allowed based on presented authorizing info. When you go to AtomPub service....
  75. # [00:44] <arun> TC: when this slide was presented, he asserted there was no confused deputy possible in this scenario. But with little effort, I created a confused deputy here.
  76. # [00:44] <Hixie> ...by introducing a new protocol that has a vulnerability
  77. # [00:44] <arun> MJS: [slide show continues]
  78. # [00:45] <arun> MJS: Server M can't forge Origin in browser, combination of cookie + Origin identifies request as valid
  79. # [00:46] <arun> MJS: Fancier scenarios can have confused deputy. Site A asking Site B to do something on Site C
  80. # [00:46] <arun> MJS: Can also have confused deputy problems without CORS. For example poorly implemented secret tokens.
  81. # [00:47] <arun> MJS: [Diagrams this on paper]
  82. # [00:47] <arun> MJS: [ Draws sites A, B, C]
  83. # [00:48] <arun> MJS: illustrates a scenario where B,and C have an understanding with shared tokens.
  84. # [00:49] <arun> MJS: It's an isomorphic problem. A only tells B a resource to act on. B then talks to C. This creates a vulnerability since what A asks B might not be what B is expecting to do.
  85. # [00:49] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
  86. # [00:49] <arun> TC: THe thing that makes CSRF prevalent is that the two initial messages between B and C happen implicitly and automatically.
  87. # [00:49] <arun> MJS: CSRF is different. I am simplifying here by considering only servers.
  88. # [00:50] <arun> MJS: With CORS, in my simple scenario, doing the dumbest possible thing will be safe.
  89. # [00:50] <arun> JS: The simplest way to do authorization on the web today is to use cookies; ergo CSRF problems common
  90. # [00:50] * Quits: VagnerW3CBrasil (chatzilla@72.254.100.54) (Ping timeout)
  91. # [00:51] <arun> MJS: Here is my claim on how to avoid confused deputy problems: don't be a deputy! If you follow this discipline, purely local to your server, you will not have a confused deputy problem.
  92. # [00:51] <arun> MM: But you will also have a lack of composability amongst servers!
  93. # [00:51] <arun> MM: I think there might be the issue of "on behalf of." In Tyler's scenario, the "on behalf of " is not that Tyler made a request on behalf of the deputy.
  94. # [00:52] <arun> MJS: That has to count as on behalf of.
  95. # [00:52] <arun> TC: This means that whenever you send in a request, you have to make sure it doesn't include data you got from anyone else.
  96. # [00:52] <arun> MJS: It means that if it does, it is distinguishable from any data from that particular server.
  97. # [00:53] <arun> IH: Or you make sure sanitization takes place (a la SQL injection)
  98. # [00:53] <arun> TLR: If you want to sanitize, then you must know what the consumer might possibly trigger
  99. # [00:53] <arun> MJS: [slideshow continues]
  100. # [00:54] <arun> MJS: [gives the example of GMail / Linked In where LinkedIn asks for GMail passwords]
  101. # [00:54] <arun> MM: They would prefer to do something else.
  102. # [00:54] * Quits: markusm (mmielke@72.254.93.74) (Ping timeout)
  103. # [00:54] <arun> MJS: What are non - CORS solutions that could work?
  104. # [00:55] <arun> MJS: OAuth could work, generally requires server to server communication. Bilateral agreement (shared secret)
  105. # [00:55] <arun> MJS: [Diagrams an OAuth scenario]
  106. # [00:55] <arun> MJS: [It is a complex diagram]
  107. # [00:55] <arun> JH: [Has a better diagram]
  108. # [00:56] <arun> MJS: This is not only in your user agent; it must be programmed in server software.
  109. # [00:56] <arun> MJS: You cannot send your shared secret to the client.
  110. # [00:56] <arun> MM: This is per request?
  111. # [00:56] <arun> MJS: It doesn't have to be per request. The protocol allows token to be valid for e.g. 1 hour.
  112. # [00:57] <arun> MJS: [discusses OAuth; ] Request token is combined with a particular user; get an authorization token from Site B (combination of particular user, etc.). Event page has to redirect, etc.
  113. # [00:57] * Joins: Marcos (Marcos@72.254.89.39)
  114. # [00:58] <arun> MJS: [Continues discussion of OAuth] Redirects are part of the model.
  115. # [00:58] <JeffH> http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/
  116. # [00:58] <arun> MJS: [ Discussion of OAuth model] Flaws: server to server communication is mandatory. And it's hard to implement correctly.
  117. # [00:59] <chaals> q?
  118. # [00:59] * Zakim sees no one on the speaker queue
  119. # [00:59] <arun> MJS: Discusses why CORS is an improvement of what is done today.
  120. # [00:59] <arun> RE: Also worth discussing is JSONP, which is horrendously evil.
  121. # [01:00] <arun> q?
  122. # [01:00] * Zakim sees no one on the speaker queue
  123. # [01:00] <arun> JS: Asks Microsoft -- have you disabled Cookies for cross-site script requests?
  124. # [01:00] <arun> AB: [Responds yes]
  125. # [01:00] <chaals> q+
  126. # [01:00] * Zakim sees chaals on the speaker queue
  127. # [01:00] <arun> MJS: That fixes vulnerability on the site serving the script....
  128. # [01:01] <arun> MJS: I hope to have brought folks up to speed [slide show].
  129. # [01:01] <MikeSmith> some other OAuth diagrams: http://old.sitepen.com/labs/code/ttrenka/oauth/oauth-sequence.png http://oauth.googlecode.com/svn/spec/branches/1.0/drafts/6/diagram.png
  130. # [01:01] <arun> CMN: This is the model used by "Verfied by Visa" right?
  131. # [01:02] <arun> CMN: If this is the same basic schema used by Visa and MasterCard, then that gives you proof that the (OAuth) model is used and in circulation.
  132. # [01:02] <arun> MJS: I would not claim it is impossible to implement.
  133. # [01:02] <arun> MJS: But it might be hard for the casual site developer.
  134. # [01:02] <chaals> q+ tlr
  135. # [01:02] * Zakim sees chaals, tlr on the speaker queue
  136. # [01:02] <chaals> ack chaals
  137. # [01:02] * Zakim sees tlr on the speaker queue
  138. # [01:03] <Hixie> q+
  139. # [01:03] * Zakim sees tlr, Hixie on the speaker queue
  140. # [01:03] <chaals> q+ markM
  141. # [01:03] * Zakim sees tlr, Hixie, markM on the speaker queue
  142. # [01:03] <Hixie> q-
  143. # [01:03] * Zakim sees tlr, markM on the speaker queue
  144. # [01:03] <chaals> ack tlr
  145. # [01:03] * Zakim sees markM on the speaker queue
  146. # [01:03] <arun> AR: [Points out that we did this to improve the world]
  147. # [01:04] <arun> TLR: Two frames, + postMessage. Wouldn't that address this problem?
  148. # [01:04] <arun> MJS: So a frame (content that's meant to be loaded in an iFrame) is a cross-site data API. If you use it in the kind of way that Tyler Close identified, it would also have the same mechanism.
  149. # [01:05] <arun> s/same mechanism/ same Confused Deputy Vulnerability.
  150. # [01:05] <chaals> q+ tyler
  151. # [01:05] * Zakim sees markM, tyler on the speaker queue
  152. # [01:05] <arun> MJS: Additionally, it needs client side scripts making requests to the API.
  153. # [01:05] <arun> TLR: The distinction is that client side code checking origin occurs on the client, as opposed to the server.
  154. # [01:05] <arun> MJS: Our worry is not about people making the origin check, but in drawing the wrong conclusion about the origin check.
  155. # [01:07] <arun> s/about the origin check/about the implications of the Origin check
  156. # [01:07] <Hixie> IH: You can have a dedicated API with a server-provided API or a JS API
  157. # [01:07] <chaals> ACTION: Nikunj to respond to Maciej about how to use appcache and data cache together on a client, and whether there can be an API which is the union of appcache and datacache
  158. # [01:07] * trackbot noticed an ACTION. Trying to create it.
  159. # [01:07] * RRSAgent records action 9
  160. # [01:07] <trackbot> Created ACTION-441 - Respond to Maciej about how to use appcache and data cache together on a client, and whether there can be an API which is the union of appcache and datacache [on Nikunj Mehta - due 2009-11-11].
  161. # [01:07] <arun> MM: I want to make the proposal that the GuestXHR proposal can meet all requirements. Requirements: grant permission once, no manual steps to copy data between sites, AJAX UI, no server to server, no need for prior bilateral agreement between servers.
  162. # [01:08] * Joins: darobin (robin@72.254.94.220)
  163. # [01:08] <arun> MJS: I'd like to analyze this like we've analyzed CORS
  164. # [01:08] <arun> TC: I'd like to show you a solution that is more secure, and doesn't use an Origin header, would that satisfy your concerns?
  165. # [01:09] <arun> MJS: I'm interested in seeing solutions that satisfy the requirement that doesn't introduce protocol complexities, etc., and I'm interested in understanding that given that some browsers ship CORS, I'd like to understand whether the compatibility issues are worth it.
  166. # [01:10] <arun> CMN: I am concerned that we don't work in vacuums, we work in places where people have products. I am generally concerned in standards work about shifting goal posts. One more example, one more thing... I understand that you might feel that way. Such is the lay of the standards land. I would like to see
  167. # [01:10] <arun> CMN: .... a worked example.
  168. # [01:10] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  169. # [01:11] <arun> MJS: I shall send it to the list.
  170. # [01:11] <chaals> ACTION: Mark to make a worked example of how e.g. GuestXHR would meet the requirements with improved security
  171. # [01:11] * trackbot noticed an ACTION. Trying to create it.
  172. # [01:11] * RRSAgent records action 10
  173. # [01:11] <trackbot> Created ACTION-442 - Make a worked example of how e.g. GuestXHR would meet the requirements with improved security [on Mark Miller - due 2009-11-11].
  174. # [01:11] <arun> MJS: In a standards compliant format, so that nobody has to live with my company's proprietary format (Keynote)
  175. # [01:12] <arun> CMN: ONe of the things that make high bars is that we're going to open up our users to abuse. There comes a time when you turn off services.
  176. # [01:12] * Joins: Kai (chatzilla@72.254.88.78)
  177. # [01:12] <arun> MJS: There's a balance between security and compatibility. If there's a vulnerability where you break compat by fixing it, I'm sure all browser vendors would be eager to do it. If there's a vulnerability that's [mild] e.g. visited links, we may not break it.
  178. # [01:12] <chaals> q?
  179. # [01:12] * Zakim sees markM, tyler on the speaker queue
  180. # [01:12] <arun> s/we may not break it/we may not break compatibility
  181. # [01:13] <chaals> ack mar
  182. # [01:13] * Zakim sees tyler on the speaker queue
  183. # [01:13] <arun> TC: A lot has been made of the existing deployment of CORS. From my study of the specs, there are significant differences between implementations...
  184. # [01:13] <arun> q+
  185. # [01:13] * Zakim sees tyler, arun on the speaker queue
  186. # [01:14] <arun> CMN: These are [decisions made] by implementors based on the perceived cost to them.
  187. # [01:14] <MikeSmith> RRSAgent, make minutes
  188. # [01:14] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith
  189. # [01:14] <arun> q+
  190. # [01:14] * Zakim sees tyler, arun on the speaker queue
  191. # [01:14] <arun> CMN: I don't think security is an on and off thing.
  192. # [01:15] <chaals> TC: And therefore I am wondering if there is significant content in reality.
  193. # [01:16] <chaals> AR: There is shipping and compatibility, in apps tehre is erally only geonames, nota great deal of other adoption
  194. # [01:16] <arun> https://developer.mozilla.org/En/HTTP_access_control
  195. # [01:16] <chaals> s/tehre/there/
  196. # [01:16] <chaals> s/erally/really/
  197. # [01:16] <arun> 'http://arunranga.com/examples/access-control/
  198. # [01:16] <arun> http://arunranga.com/examples/access-control/
  199. # [01:16] <chaals> s/nota/not a/
  200. # [01:17] <arun> The URL above shows content working in safari and firefox
  201. # [01:18] * Joins: Marcos (Marcos@72.254.89.39)
  202. # [01:19] <arun> [General discussion on TC39/WebIDL]
  203. # [01:20] * Quits: pererik (pe@72.254.103.214) (Quit: .)
  204. # [01:21] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  205. # [01:21] * Quits: weinig (weinig@72.254.102.177) (Quit: weinig)
  206. # [01:22] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  207. # [01:25] * Joins: JonathanJ (hollobit@72.254.93.129)
  208. # [01:30] * Joins: tlr (tlr@128.30.52.169)
  209. # [01:38] <chaals> Topic: Multi-touch events
  210. # [01:38] <annevk> scribe: annevk
  211. # [01:38] * Joins: weinig (weinig@72.254.102.177)
  212. # [01:38] * chaals shepazu??
  213. # [01:38] * Quits: JeffH (hodges@72.254.87.82) (Quit: leaving)
  214. # [01:38] <annevk> AR: Safari is shipping multi-touch (mt), Firefox will be soon
  215. # [01:39] <annevk> AR: there are patent risks, but I think we should wait for the exclusion period and see what happens
  216. # [01:40] <annevk> AR: I think the charter allows for mt
  217. # [01:40] <chaals> http://www.w3.org/2005/06/tracker/webapi/issues/33
  218. # [01:40] <chaals> q+
  219. # [01:40] * Zakim sees tyler, arun, chaals on the speaker queue
  220. # [01:40] <annevk> DS: people disagree on whether it is in the charter
  221. # [01:40] <chaals> q- tyle
  222. # [01:40] * Zakim sees arun, chaals on the speaker queue
  223. # [01:40] <chaals> q- arun
  224. # [01:40] * Zakim sees chaals on the speaker queue
  225. # [01:41] <annevk> DS: it is not listed as deliverable, but is in scope
  226. # [01:41] <annevk> DS: if someone in the WebApps WG disagrees it is in the charter we have to re-charter in order to do it
  227. # [01:42] <annevk> RI: we might want to talk to the Device APIs WG
  228. # [01:42] <chaals> s/RI:/RE:/
  229. # [01:42] * annevk oops
  230. # [01:42] <annevk> AR: also include orientation event in mt
  231. # [01:42] <annevk> DS: I believe they are orthogonal so they can be separate
  232. # [01:43] <annevk> AR: I believe the same group can do it
  233. # [01:44] <annevk> CMN: we had an issue in the last WG that we inherited about multiple devices interacting with a single device
  234. # [01:44] * Quits: Travis (48fe5fc5@128.30.52.43) (Quit: CGI:IRC)
  235. # [01:44] <annevk> CMN: sort of similar to mt
  236. # [01:44] * Joins: Travis (d8341cc5@128.30.52.43)
  237. # [01:44] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  238. # [01:44] <annevk> JS: I think it is different, not just in semantics
  239. # [01:45] <annevk> CMN: write a spec for mt events
  240. # [01:45] <annevk> CMN: the spec says it expects to be included in DOM4 Events
  241. # [01:46] <annevk> AR: I favor separate specs
  242. # [01:46] <annevk> [bikeshed]
  243. # [01:47] <annevk> AR: I am willing to co-edit
  244. # [01:47] * Joins: Marcos (Marcos@72.254.89.39)
  245. # [01:47] <annevk> DS: I like to co-edit
  246. # [01:47] <annevk> AR: I like to check with OP
  247. # [01:48] * Joins: ArtB (48fe5d4c@128.30.52.43)
  248. # [01:48] <ArtB> RRSAgent, pointer?
  249. # [01:48] <RRSAgent> See http://www.w3.org/2009/11/02-webapps-irc#T00-48-19
  250. # [01:49] <annevk> [bikeshed on charter]
  251. # [01:50] <annevk> CMN: are there objections to adding new events?
  252. # [01:50] <annevk> RESOLUTION: specifications for new events are in our charter
  253. # [01:50] <annevk> CMN: we have proposals for mt, orientation, gestures, and pen-tablets
  254. # [01:51] <MikeSmith> I believe the Geolocation WG is also looking at spec related to Orientation
  255. # [01:51] <annevk> CMN: we have volunteers; DS and AR
  256. # [01:51] <annevk> [group overlap bikeshed]
  257. # [01:52] <annevk> RESOLUTION: DS and AR edit multi-touch, orientation, gestures, and pen-tablets event specifications
  258. # [01:53] <annevk> [pen-tablet bikeshed]
  259. # [01:54] <annevk> SO: joystick etc. events?
  260. # [01:54] <annevk> CMN: if you have proposals
  261. # [01:54] <annevk> Topic: joint meeting with widget fanboys
  262. # [01:55] <ArtB> http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications
  263. # [01:55] <ArtB> http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
  264. # [01:55] <annevk> AB: editors please fix if there are mistakes
  265. # [01:55] <shepazu> s/event specifications/events specification/
  266. # [01:56] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  267. # [01:56] <annevk> MC: I wonder how XMLHttpRequest and CORS are going to be tested
  268. # [01:56] <annevk> SW: You can use one domain with two different ports
  269. # [01:57] <annevk> DS: we can ask the systems team
  270. # [01:57] <chaals> send mail to team-webapps@w3.org
  271. # [01:58] <annevk> DS: can we start a wiki page with a list of required features for tests?
  272. # [01:59] * Joins: pererik (pe@72.254.103.214)
  273. # [01:59] <annevk> AB: we have two dependencies; Web IDL and Web Storage
  274. # [02:00] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
  275. # [02:00] <annevk> SW: Web IDL will use ECMAScript 5 concepts which is an invasive change
  276. # [02:00] * Quits: Nikunj (Adium@72.254.104.65) (Quit: Leaving.)
  277. # [02:00] <annevk> SW: we want to add tests based on DOM2 IDL converted to Web IDL so we can test the various concepts in Web IDL
  278. # [02:00] * Quits: darobin (robin@72.254.94.220) (Ping timeout)
  279. # [02:01] <annevk> SW: we can use that to allow specification editors to move forward with more certainty
  280. # [02:01] <annevk> JS: I volunteered for some amount of that testing
  281. # [02:01] * Quits: JonathanJ (hollobit@72.254.93.129) (Quit: JonathanJ)
  282. # [02:02] <annevk> CMN: you can move ahead in the Rec-track process with a dependency but you have to argue your case
  283. # [02:02] <annevk> s/dependency/dependency on Web IDL/
  284. # [02:02] <annevk> AB: when is there a new draft?
  285. # [02:03] <annevk> SW: I'm new to editing so I don't really know at this point
  286. # [02:03] <annevk> MJS: the question is how much editing needs to be done before we want to publish again
  287. # [02:04] <annevk> MJS: maybe the goal should be to do the ECMAScript 5 conversion and publish after that
  288. # [02:04] <annevk> IH: Web Storage will go to Last Call this month
  289. # [02:05] * Joins: Nikunj (Adium@72.254.104.65)
  290. # [02:05] <annevk> CMN: we want to move to a model where Last Call means the Working Group considers the work to be good
  291. # [02:06] <annevk> IH: I believe there are no outstanding issues
  292. # [02:06] <annevk> IH: The W3C side will not be blocked by the WHATWG
  293. # [02:06] <annevk> IH: I don't perceive major changes to Web Storage ever
  294. # [02:07] <ArtB> ACTION: barstow send out a pre-LC request for comments for Hixie's specs
  295. # [02:07] * trackbot noticed an ACTION. Trying to create it.
  296. # [02:07] * RRSAgent records action 11
  297. # [02:07] <trackbot> Created ACTION-449 - Send out a pre-LC request for comments for Hixie's specs [on Arthur Barstow - due 2009-11-11].
  298. # [02:07] <annevk> CMN: we found someone to edit ??? and agreed to move XMLHttpRequest to Last Call
  299. # [02:08] <annevk> CMN: Web Database was only going to be done by 3 out of 5
  300. # [02:08] <annevk> CMN: more interest in WebSimpleDB
  301. # [02:10] <annevk> CMN: alternate proposal for CORS which needs further discussion; DOM Events ready
  302. # [02:11] <annevk> CMN: we did not get into Selectors API 2
  303. # [02:11] <annevk> AB: news on XBL2?
  304. # [02:11] <annevk> JS: I'm on temporary project for a while, but I worked on a quarter for it and will get back to it
  305. # [02:12] <ArtB> ACTION: barstow start a CfC to publish FPWD of File API
  306. # [02:12] * trackbot noticed an ACTION. Trying to create it.
  307. # [02:12] * RRSAgent records action 12
  308. # [02:12] <trackbot> Created ACTION-450 - Start a CfC to publish FPWD of File API [on Arthur Barstow - due 2009-11-11].
  309. # [02:12] <annevk> [thanks bikeshed]
  310. # [02:13] * Quits: weinig (weinig@72.254.102.177) (Quit: weinig)
  311. # [02:13] <annevk> adjourned
  312. # [02:13] * Quits: Nikunj (Adium@72.254.104.65) (Quit: Leaving.)
  313. # [02:15] * Quits: ArtB (48fe5d4c@128.30.52.43) (Quit: CGI:IRC (EOF))
  314. # [02:16] * Quits: pererik (pe@72.254.103.214) (Ping timeout)
  315. # [02:16] * Joins: markusm (mmielke@72.254.81.11)
  316. # [02:17] * Quits: sicking (chatzilla@72.254.57.85) (Ping timeout)
  317. # [02:17] * Quits: shiki (sokasaka@72.254.102.153) (Quit: shiki)
  318. # [02:18] * Joins: shiki (sokasaka@72.254.102.153)
  319. # [02:18] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  320. # [02:20] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  321. # [02:20] * Quits: Lachy (Lachlan@72.254.56.137) (Quit: This computer has gone to sleep)
  322. # [02:21] * Quits: arun (arun@72.254.62.163) (Quit: arun)
  323. # [02:21] * Quits: chaals (chaals@72.254.82.7) (Quit: chaals)
  324. # [02:23] * Quits: Vladimir (chatzilla@72.254.119.66) (Ping timeout)
  325. # [02:29] * Joins: pererik (pe@72.254.103.214)
  326. # [02:30] * Quits: timeless (timeless@72.254.56.103) (Quit: timeless)
  327. # [02:30] * Quits: shiki (sokasaka@72.254.102.153) (Quit: shiki)
  328. # [02:31] * Joins: shiki (sokasaka@72.254.102.153)
  329. # [02:32] * Quits: shiki (sokasaka@72.254.102.153) (Quit: shiki)
  330. # [02:34] * Joins: timeless_mbp (timeless@72.254.56.103)
  331. # [02:35] * Joins: Marcos (Marcos@72.254.89.39)
  332. # [02:38] * Quits: timeless_mbp (timeless@72.254.56.103) (Ping timeout)
  333. # [02:41] * Quits: Travis (d8341cc5@128.30.52.43) (Quit: CGI:IRC (EOF))
  334. # [02:44] * Quits: annevk (opera@72.254.82.30) (Quit: annevk)
  335. # [02:44] * Quits: pererik (pe@72.254.103.214) (Quit: .)
  336. # [02:46] * Quits: mjs (mjs@72.254.84.91) (Quit: mjs)
  337. # [02:48] * Quits: Marcos (Marcos@72.254.89.39) (Ping timeout)
  338. # [02:48] * Joins: tlr_ (tlr@72.254.89.250)
  339. # [02:50] * Joins: annevk (opera@72.254.82.30)
  340. # [02:50] * Joins: Marcos (Marcos@72.254.89.39)
  341. # [02:52] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  342. # [02:53] * Quits: tlr_ (tlr@72.254.89.250) (Quit: see you later)
  343. # [02:56] * Joins: tlr_ (tlr@72.254.89.250)
  344. # [02:56] * Joins: Marcos (Marcos@72.254.89.39)
  345. # [02:59] * Quits: tlr_ (tlr@72.254.89.250) (Quit: see you later)
  346. # [03:00] * Joins: tlr_ (tlr@72.254.89.250)
  347. # [03:02] * Joins: weinig (weinig@67.180.35.124)
  348. # [03:02] * Quits: weinig (weinig@67.180.35.124) (Quit: weinig)
  349. # [03:03] * Quits: tlr_ (tlr@72.254.89.250) (Quit: see you later)
  350. # [03:04] * Joins: tlr_ (tlr@72.254.89.250)
  351. # [03:05] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  352. # [03:05] <MikeSmith> RRSAgent, make minutes
  353. # [03:05] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith
  354. # [03:06] * Quits: tlr_ (tlr@72.254.89.250) (Quit: see you later)
  355. # [03:06] <annevk> MikeSmith, you wanna join us to the mall?
  356. # [03:06] <annevk> MikeSmith, Lachlan and Marcos are also coming, not sure who else
  357. # [03:08] * Joins: Marcos (Marcos@72.254.89.39)
  358. # [03:08] <MikeSmith> annevk: I'm got to be at the AC meeting, but can catch up with you guys later
  359. # [03:08] <MikeSmith> what's at the mall?
  360. # [03:08] * Joins: tlr_ (tlr@72.254.89.250)
  361. # [03:12] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  362. # [03:14] * Quits: tlr_ (tlr@72.254.89.250) (Quit: see you later)
  363. # [03:20] * Joins: tlr_ (tlr@72.254.89.250)
  364. # [03:20] * Quits: tlr_ (tlr@72.254.89.250) (Client exited)
  365. # [03:38] * Joins: Nikunj (Adium@24.130.214.77)
  366. # [03:45] * Quits: Nikunj (Adium@24.130.214.77) (Quit: Leaving.)
  367. # [04:17] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  368. # [04:43] <annevk> we're not at the mall
  369. # [04:45] <annevk> hmm
  370. # [04:45] <annevk> you're gone
  371. # [04:46] * Quits: markusm (mmielke@72.254.81.11) (Ping timeout)
  372. # [04:48] * Quits: annevk (opera@72.254.82.30) (Ping timeout)
  373. # [04:49] * Joins: sicking (chatzilla@69.181.197.163)
  374. # [04:50] * Quits: sicking (chatzilla@69.181.197.163) (Client exited)
  375. # [05:43] * Joins: jorlow (jorlow@216.239.44.65)
  376. # [05:45] * Quits: jorlow (jorlow@216.239.44.65) (Quit: jorlow)
  377. # [05:49] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  378. # [06:33] * Joins: timeless_mbp (timeless@24.6.182.21)
  379. # [07:11] * Joins: Marcos (Marcos@72.254.89.39)
  380. # [07:13] * Joins: Lachy (Lachlan@72.254.97.4)
  381. # [07:44] * Joins: weinig (weinig@67.180.35.124)
  382. # [08:12] * Quits: arve (arve@212.251.179.162) (Ping timeout)
  383. # [09:08] * Quits: Marcos (Marcos@72.254.89.39) (Quit: Marcos)
  384. # [09:56] * Joins: gsnedders (gsnedders@83.252.226.150)
  385. # [10:08] * Quits: timely (timeless@65.75.195.122) (Ping timeout)
  386. # [10:09] * Quits: gsnedders (gsnedders@83.252.226.150) (Quit: gsnedders)
  387. # [10:43] * Joins: arve (arve@213.236.208.22)
  388. # [11:01] * Joins: shepazu (schepers@128.30.52.169)
  389. # [12:05] * Joins: timely (timeless@65.75.195.122)
  390. # [12:13] * Joins: mjs (mjs@69.181.42.237)
  391. # [12:20] * Joins: karl (karlcow@128.30.54.58)
  392. # [14:19] * Joins: arun (arun@75.36.190.9)
  393. # [14:23] * Joins: ArtB (c0646811@128.30.52.43)
  394. # [14:23] <ArtB> RRSAgent, pointer?
  395. # [14:23] <RRSAgent> See http://www.w3.org/2009/11/02-webapps-irc#T13-23-36
  396. # [14:41] * Quits: timely (timeless@65.75.195.122) (Ping timeout)
  397. # [15:27] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  398. # [15:27] * Joins: arve (arve@213.236.208.22)
  399. # [15:28] * Quits: arun (arun@75.36.190.9) (Quit: arun)
  400. # [15:49] * Joins: aroben (aroben@71.58.77.15)
  401. # [15:55] * Joins: annevk (opera@72.254.82.30)
  402. # [16:28] * Joins: myakura (myakura@72.254.122.171)
  403. # [16:34] * Joins: Nikunj (Adium@24.130.214.77)
  404. # [16:34] * Quits: ArtB (c0646811@128.30.52.43) (Quit: CGI:IRC (EOF))
  405. # [16:37] * Quits: Nikunj (Adium@24.130.214.77) (Quit: Leaving.)
  406. # [16:38] * Joins: timely (timeless@65.75.195.122)
  407. # [16:43] * Quits: weinig (weinig@67.180.35.124) (Quit: weinig)
  408. # [16:58] * Quits: timeless_mbp (timeless@24.6.182.21) (Quit: timeless_mbp)
  409. # [17:07] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  410. # [17:16] * Joins: arun (arun@72.254.93.237)
  411. # [19:21] * Disconnected
  412. # [19:22] * Attempting to rejoin channel #webapps
  413. # [19:22] * Rejoined channel #webapps
  414. # [19:22] * Topic is 'WebApps WG; this channel is logged: http://krijnhoetmer.nl/irc-logs/'
  415. # [19:22] * Set by ArtB on Wed Nov 04 17:58:38
  416. # [19:22] * Joins: Nikunj (Adium@72.254.62.242)
  417. # [19:22] * Quits: Nikunj (Adium@72.254.62.242) (Quit: Leaving.)
  418. # [21:22] * Disconnected
  419. # [21:23] * Attempting to rejoin channel #webapps
  420. # [21:23] * Rejoined channel #webapps
  421. # [21:23] * Topic is 'WebApps WG; this channel is logged: http://krijnhoetmer.nl/irc-logs/'
  422. # [21:23] * Set by ArtB on Wed Nov 04 17:58:38
  423. # [21:29] * Joins: Lachy (Lachlan@72.254.97.4)
  424. # [21:34] * Joins: Marcos (Marcos@72.254.82.149)
  425. # [21:38] * Quits: arun (arun@72.254.93.237) (Quit: arun)
  426. # [21:54] * Quits: Lachy (Lachlan@72.254.97.4) (Quit: This computer has gone to sleep)
  427. # [21:54] * Joins: Nikunj (Adium@72.254.62.242)
  428. # [21:56] * Quits: Marcos (Marcos@72.254.82.149) (Quit: Marcos)
  429. # [21:56] * Parts: Nikunj (Adium@72.254.62.242)
  430. # [21:59] * Joins: Lachy (Lachlan@72.254.97.4)
  431. # [22:00] * Joins: Marcos (Marcos@72.254.82.149)
  432. # [22:05] * Quits: Lachy (Lachlan@72.254.97.4) (Quit: This computer has gone to sleep)
  433. # [22:06] * Joins: Lachy (Lachlan@72.254.97.4)
  434. # [22:14] * Joins: Kai (chatzilla@72.254.84.216)
  435. # [22:17] * Quits: Marcos (Marcos@72.254.82.149) (Quit: Marcos)
  436. # [22:17] * Quits: Lachy (Lachlan@72.254.97.4) (Quit: This computer has gone to sleep)
  437. # [22:23] * Joins: darobin (robin@72.254.50.106)
  438. # [22:24] * Joins: Nikunj (Adium@72.254.62.242)
  439. # [22:28] * Joins: Lachy (Lachlan@72.254.97.4)
  440. # [22:29] * Quits: gsnedders (gsnedders@83.252.236.152) (Client exited)
  441. # [22:29] * Quits: Lachy (Lachlan@72.254.97.4) (Connection reset by peer)
  442. # [22:29] * Parts: Nikunj (Adium@72.254.62.242)
  443. # [22:29] * Joins: gsnedders (gsnedders@83.252.236.152)
  444. # [22:29] * Joins: Lachy (Lachlan@72.254.97.4)
  445. # [22:29] * Joins: shiki (sokasaka@72.254.99.40)
  446. # [22:31] * Joins: myakura (myakura@72.254.122.171)
  447. # [22:32] * Joins: annevk (opera@72.254.82.30)
  448. # [22:35] * Joins: tlr (tlr@128.30.52.169)
  449. # [22:37] * Joins: JonathanJ (hollobit@72.254.50.177)
  450. # [22:38] * Joins: arun (arun@72.254.93.237)
  451. # [22:41] * Joins: ArtB (c0646811@128.30.52.43)
  452. # [22:49] * Quits: shiki (sokasaka@72.254.99.40) (Quit: shiki)
  453. # [22:53] * Quits: Lachy (Lachlan@72.254.97.4) (Connection reset by peer)
  454. # [22:53] * Joins: chaals (chaals@72.254.61.128)
  455. # [22:53] * Joins: Lachy (Lachlan@72.254.97.4)
  456. # [23:03] * Quits: ArtB (c0646811@128.30.52.43) (Quit: CGI:IRC (EOF))
  457. # [23:04] * Joins: ArtB (c0646811@128.30.52.43)
  458. # [23:05] * Quits: Lachy (Lachlan@72.254.97.4) (Connection reset by peer)
  459. # [23:05] * Joins: Lachy (Lachlan@72.254.97.4)
  460. # [23:17] * Quits: JonathanJ (hollobit@72.254.50.177) (Quit: JonathanJ)
  461. # [23:20] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  462. # [23:29] * Quits: Lachy (Lachlan@72.254.97.4) (Connection reset by peer)
  463. # [23:29] * Joins: Lachy (Lachlan@72.254.97.4)
  464. # [23:30] * Joins: phenny (phenny@80.68.92.65)
  465. # [23:34] * Joins: Marcos (Marcos@72.254.82.149)
  466. # [23:36] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  467. # [23:36] * Quits: Marcos (Marcos@72.254.82.149) (Quit: Marcos)
  468. # [23:40] * Quits: gsnedders (gsnedders@83.252.236.152) (Quit: gsnedders)
  469. # [23:44] * Joins: shiki (sokasaka@72.254.99.40)
  470. # [23:47] * Quits: shiki (sokasaka@72.254.99.40) (Quit: shiki)
  471. # [23:50] * Quits: weinig (weinig@17.246.16.97) (Quit: weinig)
  472. # Session Close: Thu Nov 05 00:00:00 2009

The end :)