18:00:06 RRSAgent has joined #tagmem 18:00:06 logging to http://www.w3.org/2010/12/16-tagmem-irc 18:00:37 Larry has joined #tagmem 18:01:24 zakim, who is here? 18:01:24 sorry, noah, I don't know what conference this is 18:01:26 On IRC I see Larry, RRSAgent, Zakim, jrees, Ashok, noah, Norm, plinss_, plinss, trackbot, Yves 18:01:59 scribe: larry 18:02:06 trackbot, start telcon 18:02:08 scribenick: larry 18:02:08 RRSAgent, make logs public 18:02:10 Zakim, this will be TAG 18:02:10 ok, trackbot, I see TAG_Weekly()1:00PM already started 18:02:11 Meeting: Technical Architecture Group Teleconference 18:02:11 Date: 16 December 2010 18:03:01 +Jonathan_Rees 18:03:09 +Yves 18:03:20 zakim, who is here? 18:03:20 On the phone I see Masinter, Noah_Mendelsohn, plinss_, Jonathan_Rees, Yves 18:03:22 On IRC I see Larry, RRSAgent, Zakim, jrees, Ashok, noah, Norm, plinss_, plinss, trackbot, Yves 18:03:23 +Ashok_Malhotra 18:04:05 agenda: http://www.w3.org/2001/tag/tag-weekly.html 18:04:24 jar has joined #tagmem 18:04:29 zakim, who is here? 18:04:29 On the phone I see Masinter, Noah_Mendelsohn, plinss_, Jonathan_Rees, Yves, Ashok_Malhotra 18:04:31 On IRC I see jar, Larry, RRSAgent, Zakim, jrees, Ashok, noah, Norm, plinss_, plinss, trackbot, Yves 18:04:52 regrets: dana 18:05:07 regrets: johnk 18:05:16 topic: approval of minutes? 18:05:32 resolved: minutes of 2 Dec approved 18:05:49 topic: call on 23 December? 18:06:55 noah: inclination to cancel, go through agenda today & see 18:07:01 topic: privacy workshop 18:07:09 action-506? 18:07:09 ACTION-506 -- Noah Mendelsohn to noah to bring proposed W3C Actions on Privacy before the TAG - TLR to report back to IETF -- due 2010-12-16 -- OPEN 18:07:09 http://www.w3.org/2001/tag/group/track/actions/506 18:07:41 ht has joined #tagmem 18:08:28 noah: 2-day workshop, primarily IETF workshop, with help from W3C. Estimate 35 attendees, wide variety. 18:10:14 * Fingerprinting implications relating to W3C technologies <==== Want user agent to run in non-fingerprintable mode -- TOR guys want this TOR guy would like to collaborate 18:10:15 noah: toward end, create set of actions for IETF and W3C; TAG reps will carry back set of actions. List of actions will be published in full. 18:10:34 noah: (posting in IRC) 18:11:48 Is this a W3C issue? 18:12:41 +??P5 18:12:48 zakim, ? is me 18:12:48 +ht; got it 18:14:02 fingerprinting is also part of browser behaviour, not only http, but font installed, plugins etc... 18:14:12 "fingerprinting" would apply to non-W3C specs, Java, HTML, PDF 18:14:56 noah: W3C should be proactive in addressing these issues, whether or not they are only W3C specs 18:15:31 peters: there are several examples of this in CSS, list of installed fonts, etc. 18:16:02 noah: referer in HTTP spec 18:16:02 fingerprinting is part of the "eternal cookie" discussion 18:16:24 noah: last thing was non-browser user agents 18:16:45 Just to be clear, i'm not arguing W3C shouldn't work on this stuff, more that W3C might have to increase scope to work on it 18:17:27 timbl has joined #tagmem 18:17:46 Privacy workshop papers: http://www.iab.org/about/workshops/privacy/Privacy_Workshop_Papers.zip 18:18:52 (discussion of how W3C could address some of these issues) 18:19:44 q+ to ask how much, if at all, Hal Abelson's perspective was represented 18:19:49 ack ht 18:19:51 ht, you wanted to ask how much, if at all, Hal Abelson's perspective was represented 18:19:52 ack next 18:22:06 ht: summarizing, "Thinking of privacy as a subbranch of security was the wrong way to think about it -- what you want is accountability" 18:22:26 (discussion of borderline between security or privacy) 18:22:31 well, you may want both 18:22:41 noah: this was a major axis of the discussion 18:22:50 send not-exact data to protect privacy, and accountabiity on the other side 18:23:27 TAMI = transparent accountable datamining initiative http://dig.csail.mit.edu/TAMI/ 18:23:51 ht: compare "here are some things that are private" vs. "here are parts of my public persona that are usable for what" 18:24:17 ht: the higher level question of "what do we mean by privacy?" -- doesn't seem to have been on the agenda. 18:24:47 Weitzner, Abelson, Berners-Lee, Feigenbaum, Hendler, Sussman, Information Accountability 18:25:04 noah: "I need to warn you that when you do certain things that others will be able to do certain things" 18:25:23 warning user vs. preventing misuse 18:26:18 noah: when we get the official list... pick up this discusison next time... decide how to proceed? 18:26:50 I believe this is now public: http://www.w3.org/2010/policy-ws/slides/09-Abelson-MIT.pdf 18:27:15 i asking Noah's gut feeling: is this just a TAG action item? 18:28:21 noah: perhaps we should treat it as we treat security 18:28:40 q+ to talk about defining "privacy" 18:28:58 ack next 18:28:59 Larry, you wanted to talk about defining "privacy" 18:30:20 q+ 18:30:41 noah: surprised there was not implicit consensus about definition of privacy... compared to security, where people have a clear idea of what the problem framework is 18:31:09 s/clear idea/at least some common ideas/ 18:32:14 noah: example: let's say the browsers give a list of fonts; some intuition that using order of font names on disk might improve fingerprinting chances, vs. alphabetizing fonts 18:32:25 q? 18:32:37 ack next 18:33:41 ashok: what actions might have been taken? 18:34:06 noah: TLR is outside contact for W3C 18:34:54 ACTION: Dan with Noah to suggest next steps for TAG on privacy 18:34:54 Created ACTION-507 - With Noah to suggest next steps for TAG on privacy [on Daniel Appelquist - due 2010-12-23]. 18:35:19 ACTION-507 Due 2011-01-03 18:35:19 ACTION-507 With Noah to suggest next steps for TAG on privacy due date now 2011-01-03 18:36:31 Topic: HashInURI 18:36:39 http://www.w3.org/2001/tag/2010/11/HashInURI 18:36:59 zakim, who is here? 18:36:59 On the phone I see Masinter, Noah_Mendelsohn, plinss_, Jonathan_Rees, Yves, Ashok_Malhotra, ht (muted) 18:37:01 On IRC I see timbl, ht, jar, Larry, RRSAgent, Zakim, jrees, Ashok, noah, Norm, plinss_, plinss, trackbot, Yves 18:37:40 http://lists.w3.org/Archives/Public/www-tag/2010Dec/0016.html 18:37:41 Comments from Yves and Tim ... I can handle them. 18:38:30 q+ to respond to Yves on zoom level being identification information 18:38:58 Yves: The Google maps params have several parts with map, zoom, etc. 18:39:10 ... URI is server-side identification 18:39:11 ack next 18:39:12 noah, you wanted to respond to Yves on zoom level being identification information 18:40:15 noah: In a map store, didfferent types of maps are different documents 18:40:49 ... google maps is a documenty app ... the URIs identify different maps 18:41:26 q+ to talk about documents, parc map browser, URIs as constructed vs. discovered 18:41:27 there are also lots of overlays options, is each display option a new map? I agree that it is the case for scale and type (sat/terrain) 18:42:43 q? 18:43:59 http://www2.parc.com/istl/projects/www94/mapviewer.html 18:44:14 Noah: Some AJAX apps identify a document 18:44:50 ... the Google maps URI identify a document 18:45:16 ack next 18:45:17 Larry, you wanted to talk about documents, parc map browser, URIs as constructed vs. discovered 18:45:38 That's Xerox PARC, I presume? 18:46:17 q+ to consider that URIs have corresponding interfaces/contracts 18:46:45 Larry: Every URI in this app did identify a distinct document 18:47:11 Noah: so what I think is interesting, is this is an AJAX app that feels like a REST app; I can email you the URI for any map document (zoom level, etc.), you deref the link and you barely know it's AJAX, you get what looks the the representation. I think that's very nice. 18:48:10 LM: There are other design patterns, in which AJAX apps can keep their state in all sorts of non-URI based ways. But, we want the apps to "imitate the old behavior" 18:48:33 Laary: We want apps to imitate the older archaic behaviour ... creating URI that poin to documents 18:48:47 s/Laary/Larry/ 18:49:07 q- jar 18:49:49 "Most World-Wide Web information servers provide simple browsing access to collections of static text or hypertext files. This paper describes some interactive World-Wide Web servers that produce information displays and documents dynamically rather than just providing access to static files." 18:50:53 noah: doesn't break nearly as much as video... 18:51:13 noah: people send down javascript with URIs, if you ran it in a non-JS environment, it would just do the wrong thing 18:52:02 q? 18:52:04 noah: there are examples of javascript sites where the fragment identifiers which have no meaning outside of that particular app 18:52:07 ack next 18:52:59 Yves: video example, the player is a 'heavy thing', because it is using the fragment identifier to identify video stream & location, maybe there are multiple versions of player 18:53:25 Yves: In CNN case you can cache the player and change the string after the # 18:56:41 http://lists.w3.org/Archives/Public/www-tag/2010Nov/0105.html 18:58:00 ashok going over other items in email 18:58:18 Ashok: Yves raises the case where the HTML contains the same fragment as the client 18:59:21 noah: we need the specs to match recommended practice; we need to say "dont' do that" or get specs changed 18:59:33 same as rdfa issue, noah. 19:00:06 noah: situation: I do HTTP request, what comes back is text/html. text/html MIME type defines fragment identifier. But these URIs don't work like the spec says they should. 19:00:45 I would note that there is a onhashchange event... 19:00:46 Sounds like this is a bug in the HTML spec. 19:01:10 noah: so, we either need to discourage this sort of behavior, or change the specs. Not sure which is better course. 19:01:17 HTML spec defines text/html MIME type and should define authoritative behavior of handling of fragment identifiers 19:01:44 noah: tend to feel that what the AJAX apps are doing should be discouraged if it conflicts with the normative specs as they now exist 19:02:09 http://www.w3.org/TR/html5/iana.html#text-html 19:02:29 q? 19:02:56 larry: either browsers need to change behavior to match spec, or spec needs to change behavior to match browsers. The latter seems to be the sentiment of community. 19:03:04 HTML5 draft text/html registration says nothing about fragment ids at all 19:03:28 oops... not so... 19:03:39 jar, see http://dev.w3.org/html5/spec/Overview.html#scroll-to-fragid (but not in the text/html reg) 19:03:42 "Fragment identifiers used with text/html resources refer to the indicated part of the document." 19:05:13 noah: this could be handled with new media type, text/html-with-javascript, that wouldn't break webarch 19:05:50 noah: but of course it would break all of our deployed code that expects text/html 19:05:54 q+ to suggest action 19:07:02 jar: we have a lot of problems with fragment identifiers ... pointing out similar issue with RDFa specs, and also with content negotiation 19:07:29 jar: WebArch wants consistency 19:08:16 ack next 19:08:17 Larry, you wanted to suggest action 19:08:49 Larry: I think problems with fragids are separable. I'm not as uncomfortable with conneg, which I think was resolved. 19:09:26 Larry: I think this is an issue with a single document, labeled text/html, for which URIs resolve differently according to whether javascript is turned on. 19:09:45 Larry: we can resolve separately for each media type, and should push back to the owners of the respective specs. 19:09:52 q+ to respond to Larry 19:09:55 ack next 19:09:56 noah, you wanted to respond to Larry 19:10:48 JAR pointed to the place in the spec which doesn't match behavior of software that claims to implement the spec 19:11:36 LM: Document doesn't match behavior. Fix one or the other. 19:13:00 Noah: There is in either RFC 3986 or RFC 2616 the statement that the Content-type identified media type registration determines the interpretation. I think it's a TAG question whether that still holds. 19:13:07 ack next 19:13:40 YL: It's the same for all media types the allow embedding of program logic that manipulates URIs. 19:13:43 PDF embeds scripting but this isn't a problem for application/pdf 19:14:27 I proposed an action 19:14:34 q+ to note i proposed an action 19:15:53 RFC 3887 defines fragment identifiers for application/pdf, there is scripting in PDF but PDF doesn't pass fragIDs to scripts so this isn't an issue with it. I think this is an HTML issue. Maybe it's also an SVG issue, but it's the individual media type definitions and implementations that are the problem. 19:16:34 q? 19:17:20 q+ to suggest that # has to do with resolution relative to content, not server/client 19:17:32 noah: discussing Ashok's draft, that ?xxxx is identified as server-side identification and #xxxx as client side identification. That what goes on the forward & back queue 19:17:52 jar, yes, and it also has implication on caching 19:18:03 noah: (argument that ? is also used client-side) 19:18:23 and agree with Noah that ? is not only used server-side 19:18:28 ack next 19:18:29 Larry, you wanted to note i proposed an action 19:18:32 noah: want to tell that story, can't if Ashok's document identifies ... 19:18:33 ack next 19:18:35 jar, you wanted to suggest that # has to do with resolution relative to content, not server/client 19:19:04 Exactly, but with one exception. It is true, as I said in my email, that fragids aren't sent to the server. 19:19:08 Otherwise, they're as you say. 19:19:15 Clients and servers can mess with ?. 19:21:09 noah: these are a lot more symmetric with respect to client/server... in only one case with a fragid... .... 19:21:48 (missed details of Noah's remarks, hope details will be forthcoming) 19:22:03 A#B means B as interpreted relative to what document A says. nothing to do with client vs. server 19:22:05 Ashok: I will think about this and will work on revised draft 19:22:17 +1 to jar 19:22:27 in some future protocol succeeding HTTP, one might have the #B transmitted to some "server" 19:22:48 jar, this was my comment about sub-resource/view as well 19:23:12 LM: There are other media types with active content that don't have this problem, so this is a problem with certain scriptable media types. Should be resolved per-type. 19:25:10 . ACTION: Larry to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 19:25:32 JAR: Ashok, do you want to talk about the RDFa situation? 19:25:42 Ashok: Tell me more, but yes. 19:25:53 JAR: In my pending review action, we'll get to it. 19:26:04 ACTION: Larry to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 19:26:04 Created ACTION-508 - Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 [on Larry Masinter - due 2010-12-23]. 19:26:19 ACTION-500 Due 2011-01-03 19:26:19 ACTION-500 Coordinate with Alexey about a possible presentation introducing IETF to TAG work on Web Apps & report to TAG due date now 2011-01-03 19:27:25 ACTION-508 Due 2011-01-03 19:27:25 ACTION-508 Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 due date now 2011-01-03 19:28:57 zakim, pointer? 19:28:57 I don't understand your question, Ashok. 19:28:57 Calls on the 23rd and the 30th are hereby cancelled 19:29:03 We are adjourned 19:29:19 zakim pointer 19:29:22 -Masinter 19:29:23 -Yves 19:29:24 -Jonathan_Rees 19:29:26 -plinss_ 19:29:26 -Noah_Mendelsohn 19:29:27 zakim, pointer 19:29:27 I don't understand 'pointer', jar 19:29:34 rrsagent, pointer 19:29:34 See http://www.w3.org/2010/12/16-tagmem-irc#T19-29-34 19:29:41 -Ashok_Malhotra 19:30:07 Thanks, Jonathan :-) 19:30:14 -ht 19:30:15 TAG_Weekly()1:00PM has ended 19:30:16 Attendees were Masinter, Noah_Mendelsohn, plinss_, Jonathan_Rees, Yves, Ashok_Malhotra, ht 19:30:36 ht has left #tagmem 21:49:11 Zakim has left #tagmem