18:03:13 RRSAgent has joined #tagmem 18:03:13 logging to http://www.w3.org/2012/02/16-tagmem-irc 18:03:15 RRSAgent, make logs public 18:03:17 Zakim, this will be TAG 18:03:17 ok, trackbot, I see TAG_Weekly()1:00PM already started 18:03:18 Meeting: Technical Architecture Group Teleconference 18:03:18 Date: 16 February 2012 18:03:31 +Jonathan_Rees 18:03:48 scribe: Jonathan Rees 18:03:51 scribenick: jar 18:04:05 chair: Noah Mendelsohn 18:04:19 topic: Convene 18:04:34 +Yves 18:05:04 +??P12 18:05:14 regrest recorded in agenda 18:05:53 +darobin 18:06:16 HT can scribe on the 23rd, until quarter past 18:06:27 topic: Approve minutes of prior meeting 18:06:46 acclaim 18:06:48 http://www.w3.org/2001/tag/2012/02/09-minutes 18:07:02 RESOLVED: http://www.w3.org/2001/tag/2012/02/09-minutes accepted as a true record 18:07:10 JeniT has joined #tagmem 18:07:30 topic: Administrative 18:07:49 +??P17 18:08:30 Announcement needed for the two notes (HTML/XML and client-side state) - Yves to do 18:08:57 noah: Actions to close? 18:09:04 Yves: Will check later 18:09:21 topic: Note to Jeff Jaffe 18:10:26 (agenda review) 18:10:36 I had an off-list discussion about SSL and privacy which I can summarize some time, if there's interest, but I won't bring up the topic unless others want to open it. 18:12:01 Our note to Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html 18:12:20 Response from Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0054.html 18:13:00 Regarding the Certificate Authority system, Jeff asks: 18:13:08 "While this is clearly a problem for the Web, it is less clear to me who the 18:13:08 TAG thinks should be addressing the topic. If the issues are SSL security, 18:13:08 it would presumably be addressed at the IETF. Did the TAG decompose the 18:13:08 problem enough to identify who should be doing what?" 18:13:35 Short answer to Jeff's question is: no 18:14:00 We did not decompose the problem enough to identify who should be doing what 18:14:03 Going over Jeff's email... 18:14:24 JJ asks, who should be doing what on CA issue? 18:15:13 yves: Followup on www-tag Mike Belshi. Even if we are decomposing, the main issue is the way centralization of trust in key mgmt syste, works, and that goes beyond technical. Huge topic 18:15:20 My opinion is that W3C Security activity should engage with the TAG, IETF security directory, W3C WebAppSec, and IETF WebSec groups should engage in this. 18:15:25 s/Belshi/Belshe/ 18:15:35 http://lists.w3.org/Archives/Public/www-tag/2012Feb/0053.html 18:16:08 lm: (as entered in IRC) Whether the problem can be addressed by those group, I don't think we can analyze, as much as encourage, and agree to review plans if some arise 18:16:14 +1 to Larry 18:16:20 +1 18:16:23 s/directory/directorate/ 18:16:24 +1 too 18:16:37 Proposed text: The TAG did not "decompose" the question in the sense you mean. We do agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. 18:16:40 noah: Drafting... 18:17:31 AM: remove first sentence 18:17:34 ashok: remove the first sentence 18:17:41 The IETF is pursuing DANE: https://datatracker.ietf.org/wg/dane/charter/ which might be a solution 18:17:58 yl: mention the security directorates liaison 18:17:59 We should ask the liaison group to make sure this topic is covered 18:18:11 "We do agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity 18:18:20 s/do agree/agree/ 18:18:54 lm: There's an overall liaison between IETF and W3C, maybe a more specific security one too. Philippe & Thomas? 18:19:30 "We agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity at 18:19:51 I would remove "most of" 18:20:10 "We agree that the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and 18:20:11 Last sentence is incomplete 18:20:23 "We note that ..." 18:20:50 "Part one: We agree that the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. " 18:21:00 part 2: "We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and of course there is also overall W3C to IETF corrdination, which is managed on the W3C side by Philippe le Hegaret and Thomas Roessler, and for IETF by Mark Nottingham." 18:21:15 "likely" ... 18:21:54 forget my "" then 18:22:02 we did hear about DANE but didn't analyze it 18:22:10 +1 18:22:17 +1 18:22:21 +1 18:22:31 No objection to using Noah's text in response to Jeff. 18:22:55 Jeff further wrote: "Among many other important concerns, the impact on the W3C specifications 18:22:55 level needs to be assessed." 18:23:33 (looking at the reasons we care about CA issue, and Jeff's comment) 18:23:50 noah: The WGs should tak the lead on reviewing Yves specs. 18:23:55 s/Yves/W3C/ 18:24:07 OK, Yves +1 is to what JAR just scribed me saying 18:24:28 is there an interaction with SPDY? 18:24:58 i dont' actually know what it means, "impact on W3C specifications level" 18:25:04 yves: SPDY is orthogonal to CA question. 18:25:31 … doesn't enter in here 18:25:32 I'm guessing that the word "level" should not be emphasized in understanding Jeff's quesiton. 18:25:39 s/quesiton/question/ 18:26:02 I don't know what he means 18:26:12 I don't think there is any impact on W3C specs, personally 18:26:21 "We agree that the impact on W3C specifications should be assessed, and propose that this should be done by the appropriate WGs" 18:26:24 I can't think of any off hand. 18:26:34 I don't even know what WGs I would ask 18:26:54 Proposed response: we agree. We expect that individual working groups should take the lead in dealing with impact on particular specifications, and as noted above, the TAG will continue to play an oversight role, being alert for new issues, or for impact on specifications that others are missing. 18:26:54 it has an impact on trust-related things, like provenance, but it's up to the group who are designing things based on trust to assess the impact 18:26:56 Or what I would ask them to assess 18:27:06 I don't think this affects digital signatures 18:27:27 The analysis I got from internal Adobe security consultants is that this doesn't affect digital signatures 18:28:12 I think the previous statement covers this too 18:28:15 noah: Send out a general request - if you think your WG's work is affected please look into it? 18:28:47 LM: That's not a clear instruction 18:29:23 noah: Consider potential impact... 18:29:49 How about "b, and to work with IETF and others to ensure that the solutions are as satisfactory as possible, and impact on W3C specs considered." 18:30:11 Possible note to chairs: "We note there have recently been compromises to the CA system; there will likely be more. You should assess whether such compromises will affect the technologies for which your WGs are responsible." 18:30:45 Until there are proposed solutions, there's no benefit to assessing impact of the problem. 18:30:59 noah: Is it clear that this is mainly an IETF thing, that sec domain is responsible regarding impact on W3C specs? 18:32:13 Proposed response: we agree. We expect that individual working groups should take the lead in dealing with impact on particular specifications, and as noted above, the TAG will continue to play an oversight role, being alert for new issues, or for impact on specifications that others are missing. 18:32:21 lm: That's fine 18:32:25 +1 18:32:33 +1 18:32:38 general agreement 18:32:50 Possible note to chairs: "We note there have recently been compromises to the CA system; there will likely be more. You should assess whether such compromises will affect the technologies for which your WGs are responsible." 18:33:04 ask Security activity to sponsor this 18:33:06 plinss: Did that agreement include note to chairs? 18:33:10 +1 18:33:22 (don't think this was agreed) 18:33:25 i'd rather ask Thomas to alert chairs and manage responses. 18:33:44 just trying not to put the TAG into the loop if it's not needed 18:33:44 +1 to Larry, think Thomas should be able to frame appropriate message 18:34:03 Part 1: We agree that the technical work will happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. 18:34:08 Part 2: We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and of course there is also overall W3C to IETF corrdination, which is managed on the W3C side by Philippe le Hegaret and Thomas Roessler, and for IETF by Mark Nottingham. We suggest that the W3C Security Activity ensure that other concerned WG's are aware of the problems with the CA system. 18:34:15 +1 18:34:18 +1 18:34:25 agreement 18:34:29 AGREED WITHOUT OBJECTION 18:34:56 Next: mobile 18:35:08 Jeff's comment on mobile Web vs. native mobile: 18:35:10 "This is a key area of concern. Did the TAG produce a specific list of 18:35:10 features that would be appropriate for the Web platform to help it catch up 18:35:10 in areas where it is currently behind?" 18:35:54 jenit: There is a list, at a high level, in the note we sent 18:36:33 rb: Not detailed, but it says something. Not sure we can be specific 18:36:39 lm: It's as specific as it should be. 18:37:09 lm: PhoneGap ? 18:37:10 PhoneGap is an example of bridging technology 18:37:11 Proposed response: Only insofar as we included a high-level list in our note to you. We believe the Mobile Web Activity is tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed. 18:37:34 http://phonegap.com/ 18:38:00 rb: Do we still have a mobile web activity? Now split over ubiweb and the other one (webapps)? 18:38:19 PhoneGap is open source platform that might mitigate some of these 18:39:06 noah: There's no list of activities? 18:39:28 I had another thought - Platform apps are typically vetted by the platform, WebApps are not 18:39:40 lm: This topic came from Robin, yes? But we didn't talk about it much. 18:39:48 http://www.w3.org/2007/uwa/Activity.html 18:39:58 … I wonder if PhoneGap [missed]? 18:40:38 noah: PhoneGap-using apps install like native apps 18:40:51 … Mixed bag, because not linkable 18:40:59 lm: Linkability of native apps is the problem then 18:41:14 noah: Big part of what we mean by "web app".. phonegap useful but different 18:42:10 s/[missed]/fills some of these gaps/ 18:42:16 Mobile Web Initiative Activity 18:42:24 (attempt to untangle w3 activity situation) 18:42:37 Proposed response: Only insofar as we included a high-level list in our note to you. We believe the Mobile Web Initiative Activity is tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed. 18:43:02 rb: Don't sepcifically mention MWA? 18:43:07 s/sep/spe/ 18:43:28 replace "Mobile Web Initiative Activity is" with "people in charge of groups relating to mobile Web applications are" 18:43:38 I don't "believe MWI is tracking these things in detail" since I have no idea what they're doing 18:43:49 MWI *should* be tracking these things in detail 18:44:23 And if I don't know who the "people in charge .." are, how can I have a belief about what they're doing? 18:44:24 well, it's more the "Ubiquitous Web Applications Activity" that should be tracking things in details in that area 18:44:39 as the topic is really... Web Applications 18:45:16 Proposed response: Only insofar as we included a high-level list in our note to you. We believe the people in charge of groups relating to mobile Web applications are tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed. 18:45:39 s/are tracking/should be tracking/ 18:45:51 they report to Jeff, he can make sure they're doing what they should be doing 18:46:16 Remove -> and they have more domain expertise than we do 18:46:16 +1 18:46:41 Proposed response: Only insofar as we included a high-level list in our note to you. We believe the people in charge of groups relating to mobile Web applications are tracking these things in detail. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed. 18:47:17 AGREED WITHOUT OBJECTION 18:47:41 Relating to distributed extensibility and vendor prefixes, Jeff wrote: 18:47:46 "Did the TAG discuss solutions? My instincts is that there is an 18:47:46 opportunity to address this by speeding up the pace of standardization. If 18:47:46 everyone is using the same approach - why should everyone call it "webkit", 18:47:46 why can't we just agree?" 18:47:57 Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. The TAG is not discussing more general solutions, and it's not clear that there is some generic approach that would be broadly applicable. 18:48:05 +1 18:49:12 There isn't only webkit, every implementation has its own selection of features 18:49:23 rb: Most mobile browsers are webkit-based… webkit- prefix is hurting other browsers who are trying to gain ground 18:49:44 This is part of the versioning/distributed extensibility mess 18:49:58 noah: Jeff is saying, why not just drop the prefix? 18:50:24 a vendor prefix is a kind of 'version number' 18:50:36 rb: The prefix thing is rather borken. Would be nice if CSS WG sorted this out. Not sure we (TAG) need to dive into this 18:50:41 s/bork/brok/ 18:50:55 Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.) The TAG is not discussing more general solutions, and it's not clear that there 18:51:00 http://www.w3.org/2001/tag/2011/12/evolution/Identifiers.html has a section on vendor prefixes 18:51:14 The TAG is not discussing more general solutions, and it's not clear that there is some generic approach that would be broadly applicable. 18:52:17 lm: Count vendor prefix as part of topic we've been working on (but not now) - think there might be a general approach, we're just not working on it now 18:52:44 lm: Too broad for us to take on right now 18:53:02 I'm putting my bets on PhiloWeb at WWW 2012 as a venue for making progress on the fundamentals. 18:53:06 jt: It would be more accurate to [missed] 18:53:22 s/[missed]/say that the TAG's focus is currently on other things/ 18:53:36 vendor prefix is not so different from a namespace 18:53:38 Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.) The TAG has at times started work in related areas, so far we have not succeede 18:53:57 yves: media types, HTTP headers… it's not really technical but social, how to deploy, market share, experimental feature how to move to standard,… bigger topic than just vendor prefix 18:54:15 lm: How different from an XML namespace? 18:54:32 this is related to the issues around "x-" and the difficulties of putting metadata in names 18:54:37 noah: Details of implementation, environment. Easier to have redundant properties in CSS, than redundant NSes in XML 18:54:56 rb: You could have it in XML, and it would show the same problems. Attributes, elements 18:55:07 Part 1: Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.) 18:55:14 Part 2: The TAG has at times started work in related areas, so far we have not succeeded in finding a focused conclusion that would be of value to the community. 18:55:26 rb: If you allow people to add extensions in other namespaces, you end up with the same mess 18:55:40 this is related to http://www.w3.org/2001/tag/doc/metaDataInURI-31.html use of metadata in URIs. in this case, the metadata is in the tag that the vendor prefix is metadata "this is only implemented by this vendor" 18:56:01 noah: Worse eith elements because in CSS you can specify both, but 3 elements remain different 18:56:09 this is a 'version number for forking' 18:56:20 noah: WOrkarounds maybe, but not same as CSS. E.g. XSL rules 18:56:25 because the backward compatibility requirements only work for a single "fork" 18:57:18 "The TAG has at times started work in related areas, but our current focus is not on this work." 18:58:09 "The TAG has at times started work in the general area of extensibility, but we are not currently pursuing this." 18:58:15 +1 18:58:18 +1 18:58:24 +1 18:58:41 lm: not focusing (instead of pursuing) 18:59:04 "we are not currently focusing on this" 18:59:06 … so we are pursuing, just not in foreground 18:59:34 "The TAG has at times started work in the general area of extensibility, but versioning and extensibility is a known hard problem in computer science, and right now we are not focusing on this." 18:59:44 s/this/it/ 19:00:13 ashok: 19:00:29 Part 1: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.) 19:00:37 Part 2: The TAG has at times started work in the general area of extensibility, but we are not currently pursuing this." 19:00:50 s/particalur/particular/ 19:01:27 Part 2: The TAG has at times started work in the general area of extensibility, but we are not currently focusing on this." 19:01:42 lm: not currently a priority item. 19:01:46 lm: ok 19:02:12 no objection 19:02:17 AGREED WITHOUT OBJECTION Part 1 and (the second) PART 2 19:02:49 noah: I will send a response 19:02:50 +1 19:02:52 +1 19:03:03 I think this dicussion was useful 19:03:23 ACTION: Noah to respond to Jeff Jaffe, on the public list, using the text agreed on the telcon of 16 Feb 2012 19:03:24 Created ACTION-671 - Respond to Jeff Jaffe, on the public list, using the text agreed on the telcon of 16 Feb 2012 [on Noah Mendelsohn - due 2012-02-23]. 19:03:53 ACTION-563? 19:03:53 ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due 2012-01-31 -- PENDINGREVIEW 19:03:53 http://www.w3.org/2001/tag/group/track/actions/563 19:04:55 ht: June is too soon for next one 19:05:14 ACTION-563? 19:05:14 ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due 2012-09-25 -- OPEN 19:05:14 http://www.w3.org/2001/tag/group/track/actions/563 19:05:38 topic: httpRange-14 19:05:45 q+ 19:05:47 Can we get links to pertinent documents for the minutes? 19:06:24 HT: I've given you feedback on the UDDP(?) document. Mostly you can respond later, but there was one typo you need to address before publishing 19:06:43 topic: httpRange-14 call for change proposal 19:06:46 http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html 19:07:03 q? 19:07:03 http://www.w3.org/2001/tag/doc/uddp/ 19:07:10 scribenick: noah 19:07:14 ack next 19:07:30 JAR will read HT's email on the subject 19:10:19 q+ to agree that it's time to move from bilateral discussion to something which gets the parties to engage on pain of being vulnerable to a "you had your chance" critique 19:11:11 q? 19:12:06 HT: I think this is the right next step in a judiciously planned process of trying to wind up in a better place than last time, I.e. to have more buy in. 19:12:09 ht: This is the next step in aj udiciously planned process to try to end up better off than we were last time 19:12:17 scribenick: jar 19:12:41 ht: time to move into a community process, I think that's appropriate 19:12:51 s/aj udiciously/a judiciously/ 19:13:03 ht: If it doesn't work, we jave a basis for creating a new effort , community group maybe 19:13:04 I heard Henry say that the time to move to a community process is >after< feedback is received from Jonathan's call 19:13:35 yes 19:13:45 Noah is correct 19:13:57 Step 1: Call for change proposals 19:14:39 Step 2: Use the result as the basis for moving to some form of community process, exact form TBD, emphasis on getting broad consensus 19:14:51 That's just my memory of what JAR already proposed 19:15:19 noah: Any objections to proceeding as planned? … Seems not. 19:15:22 IOW, I'm happy for JAR to go ahead and Call for Proposals 19:15:33 -ht 19:15:38 noah: JAR, go ahead and publish the call. 19:17:38 (discussion of agenda) 19:17:49 topic: Design of APIs for Web Applications 19:17:59 started 2nd Feb (see agenda) 19:18:04 Discussion on 2 February: http://www.w3.org/2001/tag/2012/02/02-minutes#item08 19:19:19 Proposal from Robin to expand the scope: http://www.w3.org/2001/tag/2012/02/02-minutes#item08 19:19:32 rb: Audience. People *currently* writing specs? 19:19:35 Proposal from Robin to expand the scope: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0021.html 19:19:54 q+ to encourage the TAG to let Robin work on this 19:19:54 Draft product page from robin: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 19:20:28 From the draft product page: 19:20:31 "This covers multiple related approaches to preserving users' privacy: 19:20:38 * User-mediated enumeration. 19:20:44 rb: The initial product page was focused on miniization. I broadened it slightly, not to boil ocean, but just to include fingerprinting. The two are hard to separate 19:21:00 * Device-triggered access. 19:21:07 … Min only looks at information you give away when returning from method call, as opposed to info you give away right at the start 19:21:07 * API minimisation 19:21:20 remember GeoLocation vs. GeoPriv controversy over API design that wasn't miniimization 19:21:35 q+ to remind about GeoLocation vs. GeoPriv 19:21:39 … There are 4 WGs looking at fingerprinting. I don't think it's a huge broadening, just more coherent, and more relevant 19:21:50 ack next 19:21:51 ht, you wanted to agree that it's time to move from bilateral discussion to something which gets the parties to engage on pain of being vulnerable to a "you had your chance" 19:21:51 ... critique 19:22:04 ack next 19:22:06 JeniT, you wanted to encourage the TAG to let Robin work on this 19:22:40 one of the question about SPDY and privacy was whether use of SSL improved ability to fingerprinting 19:22:41 jt: I wanted to say that this sounded useful, we can get somewhere when someone is enthusiastic on topics, so Robin needs to be encouraged 19:22:43 ack next 19:22:44 masinter, you wanted to remind about GeoLocation vs. GeoPriv 19:23:45 lm: There was a controversy between geolocation and geopriv. Policy re private data APIs saying duration and rights should always be included. Please add as a use case. 19:23:49 it's an API design issue 19:24:27 i'm not asking you to look at the issue all over again, but rather consider the use case where additional policy information in the API might be useful 19:24:29 rb: I want to steer clear of that, it's bait for flame throwing. Most of the proponents of geopriv have moved on to other solutions. CDT 19:25:11 lm: I didn't want to revisit, just to look at increasing API design is a precedent on API design advice (?)… don't revisit, just use as use case 19:25:17 q? 19:25:58 noah: SOunds like people are supportive of Robin's plan. Can we look at product page? 19:26:11 topics and products should be defined by their center rather than their boundaries 19:26:11 http://www.w3.org/2001/tag/products/apiminimization.html 19:26:54 Note that the success criteria don't erquire 'minimization' in the solution space 19:27:08 s/erquire/explicitly require/ 19:27:16 http://www.w3.org/2001/tag/doc/APIMinimization.html 19:27:16 http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 19:27:36 noah: We could treat this as a new document with new schedule 19:27:52 rb: Lots of good stuff in what Dan did. 19:28:17 noah: You're proposing a draft for the April F2F. 19:28:47 i'm willing to review other people's documents 19:29:20 s/to review/to do early review of/ 19:29:39 noah: Propose to adopt RB's draft 19:29:59 . PROPOSED RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 19:30:21 RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 19:30:25 Agreed without dissent 19:30:37 http://www.w3.org/2001/tag/products/ 19:31:14 noah: Increase priority after seeing next draft? 19:31:20 (maybe) 19:31:28 NM: We will keep this as "Other Active Project" for this round, hope to move it up. 19:31:36 -Ashok 19:31:56 ADJOURNED 19:32:01 -darobin 19:32:03 -noah 19:32:04 -Yves 19:32:06 -Masinter 19:32:06 -JeniT 19:32:08 -plinss 19:32:09 rrsagent, pointer 19:32:09 See http://www.w3.org/2012/02/16-tagmem-irc#T19-32-09 19:32:12 Robin, you still here? 19:32:24 noah: for a few minutes yes 19:32:34 Suggest you clean up the product page, and when the content is right, let me know and I'll point it from the main page, make sure all dated URIs are right, etc. 19:32:40 OK? 19:33:15 agenda: http://www.w3.org/2001/tag/2012/02/16-agenda 19:33:16 If it's ready to go now, just say so (e.g. we can take out the orange text?) 19:33:52 noah: yes, that sounds good 19:34:05 we can take out the orange text, it was from the existing version 19:34:22 I don't think that we need to define "privacy characteristics" better at this point 19:34:52 I mean it would be nice to have firm metrics on privacy, but that's a broadening of the scope that could swallow up the entire TAG for a decade or two :) 19:35:07 want me to kill the orange? 19:37:09 disconnecting the lone participant, Jonathan_Rees, in TAG_Weekly()1:00PM 19:37:12 TAG_Weekly()1:00PM has ended 19:37:12 Attendees were Masinter, plinss, Ashok, noah, Jonathan_Rees, Yves, ht, darobin, JeniT 19:37:38 noah: I've committed a slightly cleaned up version 19:38:15 OK, I've also just cleaned up entry in http://www.w3.org/2001/tag/products/ Is it OK I hope? 19:38:21 I have to head out now — don't hesitate to email me if I can help 19:38:32 LGTM! 19:38:58 OK 19:39:03 Same URI? 19:39:21 yeah, let's make it one of those cool URIs I've heard about 19:40:01 OK, I'll check in the undated copy. 19:40:05 thanks a lot 19:40:13 timbl has joined #tagmem 19:40:14 I hope the music wasn't too disruptive 19:40:26 one of the great things with this office is that it's lively 19:40:27 dibe 19:40:30 done 19:40:42 http://www.w3.org/2001/tag/products/apiminimization.html 19:40:50 but this does indeed occasionally entail that a wine tasting event takes place during a TAG call 19:41:04 Hmm, some funky css in the sizing of the dated links at the top. OK, you can bring the wine to the F2F. 19:41:18 looks good 19:41:25 mmm, yes, CSS issue 19:41:33 I'm afraid they will drink it all 19:42:18 lemme fix the CSS 19:49:27 argh... NO! 19:49:33 I got it, but we're getting merge conflicts. 19:49:46 Just let me do it, as I've got a verison that's like all the others. Thanks. 19:50:34 Done, take a look 20:16:18 masinter has joined #tagmem 21:45:48 Zakim has left #tagmem 23:33:08 jar has joined #tagmem