13:04:20 RRSAgent has joined #tagmem 13:04:20 logging to http://www.w3.org/2013/09/30-tagmem-irc 13:04:22 RRSAgent, make logs public 13:04:22 Zakim has joined #tagmem 13:04:24 Zakim, this will be TAG 13:04:24 ok, trackbot; I see TAG_f2f()8:30AM scheduled to start 34 minutes ago 13:04:25 Meeting: Technical Architecture Group Teleconference 13:04:25 Date: 30 September 2013 13:04:37 ht has joined #tagmem 13:04:45 scribe: Henry 13:05:15 trackbot, start meeting 13:05:16 dka has changed the topic to: http://www.w3.org/wiki/TAG/Planning/Sept-2013-F2F 13:05:17 RRSAgent, make logs public 13:05:19 Zakim, this will be TAG 13:05:19 ok, trackbot; I see TAG_f2f()8:30AM scheduled to start 35 minutes ago 13:05:20 Meeting: Technical Architecture Group Teleconference 13:05:20 Date: 30 September 2013 13:05:28 Agenda: http://www.w3.org/wiki/TAG/Planning/Sept-2013-F2F 13:05:30 scribenick: ht 13:05:35 scribe: Henry S. Thompson 13:05:45 Chair: DKA, PL 13:06:17 Present: DKA, TBL, SK, YL, YK, AR, PL, NM, HST 13:06:28 Topic: Agenda planning 13:06:39 Regrets: JT 13:07:31 YK: Zip URL discussion exciting because it involves fragid and semantics and I was hoping JT would contribute 13:08:03 DKA: Let's go through the agenda topics and see which ones we would like JT involved in 13:08:45 YK: RDF and XPoionter experience relevant. . . 13:09:34 csswg has joined #tagmem 13:09:34 timbl has joined #tagmem 13:10:22 [Minutes suspended while chairs manage agenda planning] 13:11:34 annevk: yep. 13:20:56 Present: DKA, TBL, SK, YL, YK, AR, PL, NM, HST, AvK 13:23:08 annevk has joined #tagmem 13:41:21 Topic: HTTP updates 13:41:38 DKA: Multipath TCP? 13:43:37 https://tools.ietf.org/wg/httpbis/ 13:44:17 YK: HTTP1.1 new versions published recently, in the run up to Last Call 13:44:37 s/YK:/YL:/ 13:45:14 Curious: my impression was that HTTP 1.1 is mainly clarification and with no (other) functional changes. Is my recollection collect? 13:45:34 YL: HTTP2 also has a new release, with stuff on compression and upgrade path (from 1.1 to 2) 13:46:00 YL: Some requests to put some text in p1 of HTTP1.1 about security and interception 13:46:27 Noah, yes, that's right 13:46:58 YL: Server push is one of the new things in HTTP2 13:47:22 ... It's a way to give to the client proactively things that might be useful 13:47:50 NM: Not true push, because the connection has to be there first, initiated by the client 13:48:14 AR: Still not what was requested 13:48:21 NM: Right 13:49:14 YL: It's new wrt the HTTP1.1 model 13:49:27 HST: What would it mean for a client to say "I support this" 13:49:54 YL: I think this is the most important thing for the TAG to consider in HTTP2 13:50:37 YL: Push is a bit similar to ZIP archives, in that you may get more than asked for in either case 13:51:06 NM: If this changes things' names, then that's an architectural issue 13:51:27 DKA: Hold that thought for the Zip Archive discussion 13:52:49 YL: There are some experimental implementations out there . . . 13:53:07 AR: What are the things you thing are important for us to look at in push? 13:53:37 HST: Remember pre-fetching indiscriminately -- bad thing -- that kind of vulnerability shouldn't be opened up again, for example 13:53:50 YL: What about script concatenation as a parallel? 13:54:02 s/YL/YK/ 13:54:18 YK: So isn't this just moving that into HTTP instead of a hack 13:54:32 NM: Well, at least the server doesn't have to lie any more 13:54:48 YK: Yes, it sucks for caching if you lie 13:55:07 ... So that opens the question of how this interacts with caching 13:56:21 AR: So how do you send cache controls back to the server early in a connection when you don't know what might be pushed at you 13:56:55 DKA: Is there a worked example comparison, for example between script concat and push? 13:57:20 AR: This is a job for Bloom filters, perhaps 13:58:04 YK: So, broader question is what additional client->server communications are allowed/required to manage push 13:58:43 AR, YK: [start to do design] 13:59:03 HST: Pop this until we can have someone from HTTPWG to help 13:59:09 YL: I'll see who I can find 13:59:23 PL: I'm also worried that it breaks conneg 13:59:59 AvK: Server first sends a push promise, to which the client can say 'no' 14:00:06 TBL: NNTP? 14:00:14 s/NNTP/NNTP, anyone/ 14:00:16 https://tools.ietf.org/html/draft-ietf-httpbis-http2-06#section-6.6 14:00:43 http://www.mnot.net/talks/http2-challenges/spec.html#PUSH_PROMISE 14:00:59 HST: Clear this needs our input 14:01:32 wycats_: The header block describes the resource 14:01:36 DKA: We'll try to do this later in the week if we can find 14:01:52 s/find/find someone from the HTTP WG who can join us/ 14:02:18 annevk: the issue is that you need a bunch of handshaking now 14:02:36 the server can't push until it gets an answer back from the client 14:02:39 henry: on con-neg - I did some data gathering. 14:02:43 which can be slow/flaky/etc 14:02:55 wycats_: it can push actually 14:03:03 wycats_: there's no requirement for a handshake 14:03:10 it has to send the PUSH_PROMISE first 14:03:12 wycats_: it just allows for cancellation, potentially late 14:03:22 yes, how do you not see how that is problematic? 14:03:22 … I looked at 2 weeks of traffic through our proxy - university (of Edinburgh) default setting is that student traffic go through proxy. I looked a 2 weeks of traffic and found very little con-neg. 14:03:43 wycats_: ? 14:04:43 Yehuda: I know that anyone using j-query with rails is using [accept header] con-neg. 14:04:49 Henry: yes, I can't detect that. 14:05:08 Yves: are you able to see if there was a vary header? 14:05:16 Henry: no. Not logging headers - just status codes. 14:05:40 Yehuda: you have no way to know for sure if con-neg occurred in the server. 14:06:03 Yehuda: i know that con-neg happens with rails apps, but I don't know how often it happens. 14:07:29 Henry: I intend to push pack to the http working group - re: proactive con-neg - to say "this never happens." I don't have any evidence that people use it. We don't talk about it in webarch. It ought to be fixed between http 1.0 and 1.1. 14:07:40 Yves: Not sure you have a good way to figure it out. 14:07:58 Henry: yes you do - if you get a 306 response - I have about 150 of those out of 10M requests. 14:11:10 marcosc has joined #tagmem 14:11:15 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-24#section-2 14:13:11 marcosc_ has joined #tagmem 14:13:44 marcosc__ has joined #tagmem 14:15:37 ht, see https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-24 14:17:05 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-2 14:17:35 HST: There is also the question of the philosophical introduction at the beginning of p2 14:17:54 HST: I would prefer to see it pulled or fixed, but fixed is much harder 14:18:13 YK: If we can't agree on what to put in, we should take it out 14:18:36 NM: But if you leave it out, you open the door to conflicting interpretation 14:18:44 s/interpretation/interpretations/ 14:21:25 HST: I haven't yet been willing to submit an issue on this topic 14:34:06 Topic: TC39 report 14:34:35 YK: We achieved consensus on a new scheduling process by which TC39 works 14:34:47 ... It will look more like the W3C process 14:35:21 YK: The primary goal is to allow features to progress independently if they don't have complex dependency 14:35:40 NM: Is this a move away from big blocky releases 14:35:52 s/releases/releases?/ 14:36:08 YK: No, not like that -- not lots of little specs 14:36:27 YK: Library-like modules, yes, maybe 14:36:39 AR: But the integration step is crucial still 14:36:43 "We have CSS as example of doing it wrong." hear hear 14:37:14 AR: We're also trying to stop re-opening topics if possible 14:37:43 YK: So we work on pieces individually, through the process to 'recommendation' 14:38:05 ... Implementators can implement anything that gets to 'rec' 14:38:17 ... You can't get to 'rec' with a dependency on something that isn't a 'rec' 14:39:00 ... Then once a year, when ECMA meets, we'll take all the 'rec's, put them into a release, and send them to ECMA 14:39:37 YK: some questions remain about tooling, which would make the 'editor' more like an editor and less like an author 14:40:13 ... Also, putting much stronger requirement that actual spec. language is produced much earlier 14:41:00 YK: This will, I hope, get some features that have been languishing out the door 14:41:17 YK: Some technical stuff 14:41:38 1) Creation of JS object 14:42:11 ... This currently requires some C++ code somewhere , which causes a problem with creating subclasses 14:42:24 marcosc has joined #tagmem 14:42:36 ... So there is now a hook at pre-creation time, which allows an override 14:43:02 ... More flexibility, but default behaviour is unchanged 14:43:14 ... Now possible to subclass DOM objects 14:43:14 marcosc has joined #tagmem 14:43:29 AR: @atcreate 14:43:40 s/@atcreate/@@create/ 14:44:14 (@@create is a temporary name in the specification, it'll prolly end up being an identifier you get through Symbol.create) 14:44:21 AR: Gives a hook into putting privileged/exotic behavious in a box 14:44:50 AR: Resolves a long-standing fight over who owns the constructor body 14:45:20 ... because there's no concept of a partially-initialized object, not easy to resolve 14:45:26 ... but now we can 14:46:11 AR: Now puts pressure on DOM spec authers to specify special-requirement constructors via @@create 14:46:36 ... rather than insisting on their own (C++) constructor 14:47:01 ...and not providing them to JS 14:47:13 And this is good! 14:47:21 "new" should be universally useful across the DOM 14:47:33 AvK: [scribe missed] 14:47:44 TL;DR We need mixins! 14:47:54 AR: DOM has exposed classes, which are not concrete objects 14:48:05 AR: This doesn't fit at all with the JS worldview 14:48:40 AR: The good news is that we have solutions for the concrete classes 14:48:56 AR: We still don't have a solution to the abstract class problem 14:49:10 ...but "new" should still work with "nonsensical" things 14:49:22 YK: The Event class is an example we can't manage yet 14:49:38 DKA: Exactly where is all this process stuff? 14:50:00 YK: Concensus, but not fully speced in prose yet -- aiming for the end of the year 14:50:12 DKA: What's usable now/soon on the technical side? 14:50:23 AR: [list] 14:50:47 spread/rest operators, iteration (for...in), Maps/Sets 14:51:05 YK: Hard to predict when things will come, because different browsers roll stuff out at different rates 14:52:13 AR: Implementation is particularly complicated wrt WebKit and JS 14:52:40 s/Implementation/Implementation timing and progress/ 14:54:06 YK: Note that @@create is a name in the spec, which will need a concrete manifestation in code, so we will have an indirection via Symbol 14:54:20 ... which hasn't quite settled down yet 14:55:19 ... The goal of Symbol is to expose properties guaranteed not to collide with user-land string-named properties 14:56:27 http://wiki.ecmascript.org/doku.php?id=strawman:unique_string_values 14:56:51 twirl: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-6.1.7.4 14:57:19 YK: What's controversial is sharing symbols across 'realms' -- e.g. multiple iframes, which share a heap 14:58:10 (I am sad to see a language using @@ which I have used for many years in all programming as something which will not compile to leave marker where stuff is unfinished but there we go, I guess I'll just have to use three :-) 14:58:17 YK: This is potentially a TAG-relevant issue -- architectural, in other words 14:58:55 import { create } from "std:object" 14:59:04 constructor[create] = Node[create] 15:00:08 AR: Same-origin iframes is really the only place this happens 15:00:18 YK: I argued it can't occur across workers 15:00:28 ... all there is there is a serialization pblm 15:00:30 (and I concur) 15:00:41 YK: 2) Models 15:01:01 YK: We've punted the question of bundling to the network layer 15:01:21 timbl: Allen is using @@ for exactly that purpose ;-) 15:01:26 timbl: it's not part of ECMAScript 15:01:44 ... We were trying to find syntactic mechanisms to assist concatenation including models 15:02:04 s/Model/Module/g 15:02:12 s/model/module/g 15:02:37 ... But that just wasn't winning, so we pushed that over to the network layer 15:03:32 YK: You do eventually get a URL when you import a module via shortname 15:03:54 AvK: Normalize/Resolve/Fetch/Translate/Link 15:04:12 https://github.com/jorendorff/js-loaders is the GitHub around ES module loaders 15:04:26 TBL: Normalize? 15:04:48 YK: Map shortname to another, e.g. ../foo 15:04:57 https://people.mozilla.org/~jorendorff/js-loaders/loaders.html#section-21 has a description of the loader hooks 15:04:58 TBL: Base URIs? 15:05:02 AR: No such thing 15:05:06 TBL: Why not? 15:05:32 AR: Don't want to constrain runtime to have that notion, e.g. when running not on the Web 15:06:03 YK: [you can choose to ...] 15:06:30 YK: Suppose you want to depend on jQuery -- w/o commiting to a particular location 15:07:05 TBL: Checksum? 15:07:13 YK: Implement that using the fetch hook 15:07:18 s/fetch/Fetch/ 15:07:36 TBL: W/o that, how to avoid being hacked? 15:07:56 marcosc_ has joined #tagmem 15:08:01 YK: Not the business of the _language_ 15:08:18 AR: JS lives at an uneasy location in the pipeline 15:08:28 ... everything that isn't 'magic' 15:08:51 AR: You could do almost everything above the bits off the network in JS 15:09:02 ... but it _is_ just a language 15:09:19 ... with provision for _hooks_ which appeal to the gods 15:09:32 marcosc has joined #tagmem 15:09:47 TBL: Do the gods always have to be invariant? 15:09:51 AR: No 15:10:13 AR: The language itself has no networking, it's up to the environment 15:10:21 TBL: I'm worried about that 15:10:52 YK: We _do_ think the environment should provide a loader wrt certain invariants 15:11:07 ... In particular, wrt the browser environment 15:11:41 TBL: I prefer to ask for modules with http: URIs 15:11:49 AR: You can do so 15:12:32 NM: What about Atom -- they wanted the simplicity of shortnames, with the explicitness of URIs 15:12:45 ... so you get a registry that does the mapping 15:13:10 YK: That's what we're supporting, via conversion hook 15:13:22 NM: But I want a _spec_ level hook 15:14:02 AR: Things in the _spec_ will have expansions _in_ the spec. for all the shortnames that occur _in_ the spec 15:14:23 Fix me^^^^ 15:14:47 (looks fine for what I said) 15:15:24 YK: Any requirement on the _browser_ is outside the language, but could for example require all input to Normalization be URLs 15:16:24 TBL: So I would like to be able inline (script/CSS/image/...) are bad, better to have URLs for them 15:16:35 Zakim has left #tagmem 15:16:57 s/So I would like to be able/current advice is that/ 15:17:14 TBL: So I would like to use directory structure to organise this 15:18:21 So if I have a script directory, I want relative references in something fetched from there to be relative to that directory, just as it already works from the CSS subdir 15:18:47 s/So/TBL: So 15:19:03 @@fixme^^^ 15:19:10 S/So/TBL: So/ 15:19:36 YK: I agree that ./ and ../ should work that way in the browser, and we think we have a way to do that 15:19:55 TBL: And get consistency wrt running on the Web, or with Node.js 15:19:57 YK: Yes 15:22:40 HST: I hear violent agreement -- there's a place to do the mapping for module names, just as it happens for CSS, _except_ that it works for "./foo", not "foo" 15:23:33 TBL: I'm willing to use "./foo" to distinguish what I want from 'magic' module names 15:24:50 YK: The default behaviour will look relative to the embedding HTML [?] 15:25:42 NM: The user doesn't know about binding jQuery to something 15:26:12 YK: We anticipate the e.g. jQuery.com will give you HTML to paste in to register the mapping 15:26:37 ... we may need an HTML5 element for that 15:27:27 NM: I was looking forward to a situation when some shortnames get so well-known that it doesn't need that -- then the Atom experience gets relevant 15:27:37 YK: We haven't supported that yet 15:28:19 TBL: So a server can map jquery to their own, hacked, implementation 15:28:38 AR: Only in pages from that server, yes 15:29:10 NM: So more like a namespace prefix than a namespace URI 15:29:33 AR: _Everything_ happens fresh with each page context 15:30:03 SK: Can a script redefine the binding? 15:30:32 YK: Yes, if you don't want 3rd-party scripts to do that, you should use CSP [Cross-Site ??] 15:31:08 Content Security Policy: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html 15:31:24 See: http://www.html5rocks.com/en/tutorials/security/content-security-policy/ 15:31:49 YK: Service-worker -- may override network layer 15:32:28 YK: Service workers provide for asynchronously intercepting http requests, e.g. for local caches 15:33:03 YK: But we don't want caching behaviour implemented in the module loader 15:33:30 ... so we don't make that easy -- you should use the browser (service worker) for that 15:34:08 YK: Fetch hook talks to the service worker, which gets a response object which is opaque 15:34:28 AvK: You don't need service worker 15:34:48 AR: True, all you need is the cross-origin-response object, however that's provided 15:35:39 YK: The CSR then goes through the pipe from Fetch to Translate at which point the browser does the unwrapping 15:35:53 [scribe gives up] 15:36:49 s/CSR/c-o-r-o/ 15:38:26 YK: 4) Promises 15:39:15 YK: Since the module loader wants promises, people really pushed it forward, and so it looks likely that promises will be in ES6 and used by the module loader 15:39:36 AR: Chrome is shipping support now 15:40:21 YK: And given @@create, promises are subclassable 15:41:30 YK: Having a primitive for async data is good, but that actually makes getting streams even more important, so that we _don't_ end up using promises as a hacked workaround 15:42:36 AR: For example web crypto needs streams for decent performance, as well as a promise for total success/failure 15:43:08 YK: No streams in ES6, but we hope to get it out independently via the new process 15:43:26 DKA: What's the alternative right now 15:43:55 AR: Lots of _ad-hoc_, mutually incompatible solutions 15:44:29 DKA: So there will be a lag between promises shipping, and streams shipping 15:45:03 ... and we need some prose saying "Don't use promises when what you are really doing is streams" 15:45:18 ... So we'll come back to this when we talk about the API Guide 15:45:36 AR: I'm hoping to get started on streams soon 15:46:05 DKA: You described TC39 as an oversight group, with [Champion Groups] -- is that how this works? 15:46:34 YK: Yes, so Modules came from a Champion Group, and got consensus from the TC 15:48:58 Topic: Promises 15:49:13 TBL: Promises help, but don't get me everything I need 15:49:27 ... Is there more coming, e.g. catching an error 15:49:38 AR: Yes, if you also make it asynchronous 15:49:59 AR: [gives detail] 15:50:14 AR: Async is poisonous 15:50:21 TBL: That is, it spreads? 15:50:25 AR: Yes 15:51:01 YK: Example on board: 15:51:28 YK: 'spawn' primitive, which returns a promise 15:55:47 AR: This gets us out of the 'triangle of doom' 15:58:22 Adjourned until 1300 16:25:47 jeff has joined #tagmem 16:26:47 Topics for today: http://www.w3.org/wiki/TAG/Planning/Sept-2013-F2F#Monday 16:39:45 marcosc_ has joined #tagmem 16:42:43 Scribe: Alex 16:44:11 JJ: chairs are planning to work issue-by-issue 16:44:26 YK: why do we think this won't get gummed up at the end instead of the beginning? 16:44:56 JJ: we don't know. I look at it this way: the web community as a whole needs a DNT standards. Everyone seems to agree with that statement. 16:45:14 JJ: having no DNT standard seems untennable 16:45:49 JJ: my hope is that if we go through issue-by-issue and work diligently to get consensus, stakeholders will acknowledge that no standard is worse 16:45:54 JJ: there's a lot of skepticism 16:46:24 JJ: we've documented the skepticism using a poll in the WG. It asks: should we unlink TPE/Compliance, only TPE, or give up? 16:47:01 YK: a broad question: my uneducated reading of the tea-leaves is that advertisers will accept something nobody will use, while privacy advocates want something most people would use 16:47:07 YK: that's the core dissagreement 16:47:15 JJ: I think it's true 16:47:32 YK: "advertisers would be willing to go along with anything as long as nobody uses it" 16:47:44 JJ: there's tremendous value to me that I get tracked (as a consumer) 16:48:07 JJ: a good DNT standard puts the onus on advertisers to help build understanding 16:48:19 JJ: also, what do we allow? 16:48:26 (use, data handling, etc.) 16:48:43 JJ: there are a lot of unknowns here 16:48:57 YK: are advertisers willing to expose the mechanisms that they use to track? 16:49:00 JJ: not really 16:49:05 YK: so the discussion is foreclosed? 16:49:13 JJ: a challenge 16:49:20 twirl has joined #tagmem 16:49:47 JJ: all our standards are voluntary, and advertisers may choose to ignore. If that happens, you move to the next level: public outcry, legistlation, etc. 16:50:16 DKA: in the context of the CA legislation and EU privacy law, there are more controls -- signposting, cookie warnings, etc. 16:50:39 DKA: controversy results 16:50:50 YK: isn't it self evident that login cookies != tracking cookies 16:51:05 TBL: to people making privacy legislation? NO. 16:51:41 TBL: the difference...the extent that FB tracks with the "like" button when you don't even use it....most don't realize 16:52:38 HT: historically, there are very different assumptions on different sides of the atlantic. The US side assumes "opt out", while the EU default is "opt in" 16:53:00 HT: the expectation has been that there would be different defaults depending on geography. Has that been resolved? 16:53:27 JJ: the consensus of the WG is that the default should be neither opt-in nor opt-out and that there has to be definitive user action about "opt in" vs. "opt out". 16:53:40 JJ: more similar the the EU mode. 16:54:11 JJ: that you have to have a null default is being ignored by IE, and is being set to "DNT" 16:54:34 JJ: the advertisers are saying "since there was no user action, we have license to ignore user signals since they're not reliable" 16:55:31 JJ: the default question is bizarre because when I happen to buy a PC that happens to have a browser in it, and it's being set up by the Geek Squad from Best Buy, or the IT team sets it up...who the user is is difficult to define 16:56:09 YK: IIRC, the IE startup screen DOES show a choice and you have to click "next". 16:56:30 YK: so WRT the letter of the law, IE does require user ction 16:56:44 YK: it's the canonical opt-in/out issue 16:57:14 JJ: I agree. But from the advertiser's perspective, they dont' care...they think it doesn't 16:57:47 DKA: is there something the TAG can do here? 16:57:51 JJ: glad you asked.... 16:58:03 JJ: I don't think there's a lot the TAG can do collectively 16:59:04 JJ: many of the views are far apart. The WG needs more people who can think deeply about it and contribute technical ideas and text to help bridge them 16:59:37 YK: when you say that everyone needs a DNT standard, can you say what you think everyone would agree to? 17:00:41 JJ: that users should be able to specify "DNT", that there should be only one signal, and that if I say "I don't want to be tracked" we should be able to attach meanging to that signal 17:00:54 JJ: the advertisers agree that there should be a compliance part, but want to define it 17:01:21 JJ: you can google the DAA guidelines that they've published, and presumably they'd agree to those 17:01:40 JJ: some people think legislation is the right answer 17:02:20 JJ: many vendors are fearful that they'll have to implement 30 versions if we don't get something unified 17:03:28 YK: seems plausible that legislation will create scattered standards 17:03:59 DKA: the oven broke in our house, so I've been searching for ovens...now everywhere I go on the web, OVENS ARE FOLLOWING ME, and I have DNT turned on 17:04:06 YK: why do you think this is bad? 17:04:13 DKA: I'm less likely to buy an oven that's stalking me 17:04:47 JJ: the real problem is they're not tracking you enough! If they tracked more, they'd know you're the sort of person who would be turned off by that 17:04:59 NM: I don't think you can generalize 17:05:38 NM: I don't like the fact that I can't find things without parties I don't know tracking me 17:06:16 NM: if I were looking for information about bars and not ovens, there are things like disease treatements, etc. that are much more private 17:06:46 YK: there are folks with ad platforms who are experimenting with remarketing and have found it effective 17:11:20 [TAG applies Brandice court standards] 17:11:38 JJ: there are attacks against privacy and security 17:11:56 DKA: wendy will be joining us tomorrow 17:13:10 DKA: DNT won't protect anyone against bad govt actors, and that was before we knew how bad the govts were 17:13:33 DKA: other things on our list: we just finished with TC39 topics...would be good to talk about working together 17:14:03 YK: we brought up the prospect of TPAC, but the time and travel made it a non-starter 17:14:30 YK: last time it sounds like TC39 was given a room and that there wasn't much engagement 17:14:45 YK: that said, Norbert Lindberg was much more positive 17:14:56 YK: they felt they weren't participating 17:15:14 YK: we represented that wasn't the spirit of this invitation 17:16:47 JJ: last time was before my time, but when we invited TC39 to Shenzen, our intent was that they could be observers and interact however was most effective 17:19:35 [ agreement that we need to try again for next year ] 17:20:56 JJ: the existing bodies that we've got do a pretty good job than, say, the UN would...but we have an obligation to reach out to be effective in making the case that we're effective stewards. Having TPAC in China is good for that 17:22:23 JJ: next year is likely to be Santa Clara. 17:22:58 JJ: that's the 20th W3C anniversary too. 17:23:06 DKA: how about TPAC 17:23:40 JJ: as we're setting up the agenda for the Plenary, it'll be a little different, and it'll be 60/70% unconference and a bit more time plenary time 17:23:59 JJ: we thought it would be beneficial for the community to get an update from the TAG 17:24:13 JJ: there was a lot of feedback from the AC that they hadn't heard from the TAG 17:24:48 NM: what have we been doing? We needed some space...what's happening now? 17:25:20 JJ: there was some euphoria thanks to contested TAG and AB elections...now the community wants to hear what's new 17:25:59 JJ: there's a pent-up interest in understanding what the results have been...you can do that however you like, but there's a sense from the PC that we'd like to hear from the TAG 17:26:18 YK: we've done fewer things as concrete deliverables, but are taking on a stronger coordination role 17:26:57 YK: Brian Kardell's post regarding twirl's election outlined many of those activiteis and work like Promises should be viewed as TAG deliverables 17:27:10 DKA: having a lot of talking heads on stage might be less useful than something like an interactive Q&A 17:27:38 NM: what if the chairs presented what they think the priorities are + some Q&A 17:27:56 NM: the communities you're working with know you're there, but the rest of the world isn't hearing enough 17:28:07 JJ: the survey said they don't like talking heads but they enjoy the Q&A 17:28:50 AR: could do a google moderator + some live questions 17:29:44 DKA: AB work on chapter 7 process revisions 17:30:14 JJ: for those who don't know, Chapt. 7 walks you through the publication process: FPWD, WD, LC, CR, TR 17:30:25 JJ: some people like it, some people think it's overstasted and hurts agility 17:30:43 JJ: the AB has spent a lot of time over the past couple of years trying to figure out how to make it more agile...fewer process steps 17:31:28 https://dvcs.w3.org/hg/AB/raw-file/default/tr.html 17:31:43 (thanks, jeff!) 17:32:03 JJ: combines LC + CR...don't see why they need to be different 17:32:13 JJ: also removed the Proposed Recommendation step 17:32:36 JJ: also we've tried to remove the semi-prescriptive steps and move to something like a guidebook 17:32:46 YK: does the new step say when to start implementing? 17:32:53 JJ: no, not any more 17:33:35 YK: the blink process doc cites the W3C process document 17:34:11 AvK: you might be conflating shipping with implementing? 17:34:30 JJ: we wanted to be more agile, aligns with documents that related to it (e.g. the Patent Policy) 17:35:04 JJ: there might be things we're not aware of, but the document is at the level of maturity where we should be getting more eyes on it 17:35:40 http://www.w3.org/community/w3process/ 17:36:23 JJ: Chaals have been a great editor, issues are being worked through, and at TPAC we're likely going to be at LC-alike status 17:36:44 JJ: if the TAG could look it over, the feedback would be appreciated 17:37:12 DKA: how should we provide that feedback? 17:37:36