13:08:34 RRSAgent has joined #tagmem 13:08:34 logging to http://www.w3.org/2012/06/12-tagmem-irc 13:08:36 RRSAgent, make logs public 13:08:36 Zakim has joined #tagmem 13:08:38 Zakim, this will be TAG 13:08:38 ok, trackbot, I see TAG_f2f()8:00AM already started 13:08:39 Meeting: Technical Architecture Group Teleconference 13:08:39 Date: 12 June 2012 13:11:30 Meeting: TAG f2f 13:11:37 ScribeNick: ht 13:11:42 Scribe: Henry S. Thompson 13:11:48 Chair: Noah Mendelsohn 13:12:00 Agenda: http://www.w3.org/2001/tag/2012/06/12-agenda 13:12:05 zakim, who's here? 13:12:05 On the phone I see +1.617.715.aaaa 13:12:11 On IRC I see RRSAgent, noah, Ashok, masinter, ht, jar, JeniT, darobin, trackbot, Yves, plinss 13:12:48 +Yves 13:13:19 RRSAgent, log? 13:13:19 I'm logging. Sorry, nothing found for 'log' 13:14:58 timbl has joined #tagmem 13:16:25 + +33.1.43.14.aabb 13:17:00 Zakim, aabb is me 13:17:00 +darobin; got it 13:21:36 Norm has joined #tagmem 13:23:06 noah? 13:23:50 Yes. Let's say I can do that and I'll try to get something ready by then 13:23:52 darobin has joined #tagmem 13:24:05 NM: Minutes of 24/5? 13:24:08 I'll try to send some sort of summary today, though I'm in a tight spot work wise 13:24:41 Sure thing, JeniT. Sorry I can't be there with you all. 13:25:22 NM: RESOLUTION: Minutes of 24/5 at http://www.w3.org/2001/tag/2012/05/24-minutes approved 13:25:33 I did. I'll get some Rum at duty free in LHR and make them at Summer School, ok? 13:26:01 Topic: Privacy by Design in APIs for Web Applications 13:26:10 Work plan not approved: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 13:26:17 NM: I believe we do not yet have an approved workplan for this 13:26:46 RB: Correct 13:26:53 RB: Not sure that's the latest draft 13:27:00 http://www.w3.org/2001/tag/products/apiminimization.html 13:27:14 that one isn't dated 13:27:23 oh it is at bottom kind of 13:28:14 RB: I'll walk us through the changes 13:28:30 ... since Nice f2f 13:28:50 http://darobin.github.com/api-design-privacy/api-design-privacy.html 13:29:27 http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-06-06.html 13:29:41 http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html has been updated 13:30:12 RB: Feedback at f2f and from others have led to changes 13:30:23 http://tools.ietf.org/id/draft-iab-privacy-terminology-01.html is latest draft 13:30:29 ... It is trying to address two communities which is tricky 13:30:45 ... The privacy c'ty and the API creators 13:31:01 RB: A lot of the feedback was on providing more background 13:31:26 ... So I've reworked the intro wrt scope, also added a section on that specifically 13:31:45 ... To be clear about the _small_ part of the privacy space we are targetting 13:32:10 RB: This is in contrast to a lot of other privacy work which IMO has too large a scope 13:32:32 RB: So _just_ APIs, and _just_ privacy perspective on APIs 13:32:42 q? 13:32:53 darobin has joined #tagmem 13:33:20 AM: When you talk about apps later on, you talk about how _apps_ ought to be written -- that's not quite just APIs, is it? It's about how you write the app so as not to access stuff you shouldn't 13:33:40 ... Aren't you going to get the response "I'll write my app the way I want to" 13:33:50 RB: Not sure I understand the distinction 13:33:54 there is another design pattern for APIs which is that APIs which communicate information that's personal should include a redistribution policy (3rd-party usable? timeouts?) 13:34:19 RB: In the other document . . . 13:34:32 AM: No, in this one, at the end 13:34:50 perhaps there are other design patterns, like origin, which creates sandboxes 13:34:56 RB: This doc. is only aimed at API designers, not app authors. 13:35:30 q+ jar to unpack "malicious" 13:35:53 NM: Maybe the same point? When you mentioned Saltser & Schroeder, I thought I understood -- they say the API strictly limits what non-privileged apps, but tells you how you can do a lot non-the-less. 13:36:09 NM: But in their case they assume that those limits are enforced. 13:36:44 DNT is a policy-transmission API 13:36:59 ... Whereas in what you've written you focus on partitioning the API into individual pieces, w/o talking (much?) about access control _to_ those pieces 13:37:03 I'm taking the view that 'API' and 'network protocol' isn't that different 13:37:17 q? 13:37:40 RB: Granularity is only one part of the overall approach 13:37:49 ... That's in the minimization section 13:38:11 RB: In the other parts, there is dicussion about privilege separation 13:38:40 ... So e.g. in the vibration API, it fails w/o saying that's because there is none, so not exposing that information 13:38:53 My concern is mainly about the minimization part, and the Schroeder reference in that context 13:38:58 RB: Granularity allows easy exposure to the user of what's being accessed/required/used 13:39:09 http://tools.ietf.org/html/draft-iab-privacy-considerations-02 should be background, why is this document so different a context? 13:39:25 q? 13:39:28 I'm saying you need to make clearer that if the app asks for lots of information, the user >will< be told that it's happening and have a chance to say no 13:39:38 design APIs so that it's hard to write buggy apps 13:39:51 q+ 13:39:51 ... If the app asks for every part of a contacts DB, then the user knows some serious problem might be there, whereas if it only asks for first-name and email address, that sounds like a reasonable request 13:40:03 ack next 13:40:05 jar, you wanted to unpack "malicious" 13:40:12 q+ to give feedback 13:40:34 JAR: I have said this before and heard no pushback -- there's a difference between security and privacy 13:40:58 ... The purpose of minimization is not to provide a security mechanism 13:41:06 ... But to reduce temptation 13:41:23 q? 13:41:30 ... It's not that I don't trust you, but if I give you too much information you may be tempted to use more than you need 13:41:46 ... Removing possible sources of temptation 13:42:01 I hear JAR saying that enforcing access controls is a security mechansim only, not privacy. I'm not convinced that's the best use of terminology. 13:42:04 TBL: Temptation or attack 13:42:12 s/attack/attack?/ 13:42:36 If I'm enforcing the limit to protect someone's privacy, then it's a privacy mechanism. If I'm doing it to preserve the integrity of the OS (e.g. not disclosing the root password), then it's a security mechanism. 13:42:57 http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5 13:42:58 JAR: If you ask if you can borrow a book, and lay the book on the table and put a $20 next to it, is it an attack if you take the $20? 13:43:02 q? 13:43:26 JAR: policy, "nothing there to protect" [scribe missed] 13:43:41 Now I sort of get it a bit, but I think minimization affects privacy too, e.g. to minimize risk of unintentional loss. 13:43:57 ack next 13:44:13 JAR: The word "malicious" appears in the document, which puts people in the security mindset, and that's not appropriate for this document or its goals 13:44:18 q+ to ask that we not do the privacy/security debate all over again 13:45:13 AM: Section 4.1, example, "discover lots of stuff about each mouse" -- what are we going to _do_ about this 13:45:19 the risk is of unintended use of information that is provided for a particular purpose. I wouldn't call that an "attack" - connotations are wrong - it's "yielding to temptation" 13:45:42 AM: Where in the API can anything prevent/signal/call attention to this 13:45:52 s/this/this?/ 13:46:22 RB: This is an anti-pattern -- don't do this -- it's appeared in lots of apps in various ways 13:47:03 ... Recent e.g. mouse APIs have been designed so that this isn't possible anymore 13:47:57 RB: Even if an app needs info about how many e.g. game controllers you have, you have to be using them for them to be exposed/counted 13:48:27 AM: So the API won't support getAllMice()? 13:48:29 I have three points: background & terminology; protocol and APIs equivalence; missing design patterns 13:48:34 q? 13:48:40 ack next 13:48:41 RB: That information won't be available if the API is designed right 13:48:42 masinter, you wanted to give feedback 13:49:20 There's a new version of http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html 13:49:30 LM: I do see a reference to Hannes's document -- there's a newer version, which is now an IAB [???] 13:49:33 s/There/Larry says there/ 13:50:41 RB: I spoke with Christine ??, and then with Hannes and others, and they said they are actively developing it, with terminology changes, so I'm waiting to hear from them about when it stabilizes, and then I'll reference it and adopt the terms 13:50:45 http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5 13:51:21 LM: There's also a draft about privacy considerations more generally 13:51:23 (Fascnating: http://tools.ietf.org/html/draft-iab-privacy-considerations-99 redirects to http://tools.ietf.org/html/draft-iab-privacy-considerations-02 !) 13:52:04 q+ to point out that I think there's a logical jump in Larry's protocol <-> API idea 13:52:12 LM: I think there's a near-equivalence between privacy wrt protocols and privacy wrt APIs, so minimization, which is discussed in that draft 13:52:47 LM: Also, I note that this doc talks about threats and attacks, both wrt privacy and wrt security 13:53:12 the terminology uses "threat" and "attack" but in different context 13:53:42 NM: I heard Larry say that the IAB? document talks about attacks against system security, and attacks on users' privacy. That seems exactly right to me. 13:54:09 q+ to point out that DNT is orthogonal to API design, and that GeoPriv led to a catastrophic failure in communication between parties 13:54:09 LM: Given that framework, there are various design pattern -- GeoPriv e.g. increases the API to _include_ policy information, particulary regarding redistribution 13:54:31 LM: Similarly the Do Not Track header is a policy statement 13:54:37 terminology quibble I guess: I would put defense against technical attacks under the "security" banner, and reserve "privacy" for non-security-related concerns. making sure information is *unavailable* to an attacker is a security issue (a particular kind of privacy issue, sometimes) 13:55:09 q? 13:55:12 LM: [earlier] The protocol/API parallel reminds us that what you _do_ with what you get is part of the equation 13:55:25 ack next 13:55:27 darobin, you wanted to ask that we not do the privacy/security debate all over again and to point out that I think there's a logical jump in Larry's protocol <-> API idea and to 13:55:27 ... point out that DNT is orthogonal to API design, and that GeoPriv led to a catastrophic failure in communication between parties 13:57:01 RB: Wrt JAR's comments about privacy/security and vocabulary, e.g. "threat" -- we used to argue this in a section that talked about the commonality, when bad things may happen to the user 13:57:30 ... but people argued about that, and said we needed references, so we took it out 13:58:02 LM: I at least pushed back on the use of a common vocabulary, not that they were compleetely separate 13:58:30 I think there's a Venn diagram, with bins (1) privacy not security, (2) privacy and security, (3) security not privacy 13:58:31 NM: I heard you try to avoid making that distinction and focus on the doc. 13:59:03 RB: I agree there's an issue, and an ongoing discussion, but for _this_ document we're clearly in the intersection, so the problem doesn't arise 13:59:29 LM: My argument is about vocabulary, not about scope 13:59:54 LM: I don't mind limiting the scope, but I do care that we don't invent new vocabulary 14:00:07 ... We should use "threat", which is what the IAB use 14:00:19 RB: I just don't want to do that until they stabilize 14:00:46 ... They've already said changes are coming 14:00:48 LM: OK 14:01:03 NM: JAR, does that address your problem? 14:01:35 sandboxing 14:01:37 JAR: If you are talking about privacy, and you are _not_ talking about policy, that seems odd, but maybe you just need to change the title/make this clear 14:01:40 q+ 14:01:49 http://www.w3.org/2012/05/sysapps-wg-charter.html 14:01:54 JAR: And the other think that's odd is the absence of discussion about secure Javascript 14:01:55 policy and sandboxing are missing 14:02:37 RB: Yes, of course if you have a security hole privacy attacks may be enabled, but that doesn't affect API design 14:03:05 ... That is, I won't expect any change to an API if you were worried about security attacks 14:03:11 s/attackes/holes/ 14:03:17 JAR: Not clear to me that's true 14:03:19 Robin, could you say who on IAB told you that we shouldn't reference the IAB documents for terminology and privacy considerations? 14:03:33 I'd like to follow up 14:03:58 JAR: Imagine someone wanting to learn about privacy by design in Javascript APIs, and thinks this document will tell them what they need -- that would be wrong 14:04:07 NM: Change scope, or title? 14:04:29 JAR: Title, I think, plus some references to what else they need to know 14:05:17 JAR: I need to review the Scope section 14:05:22 Is PING coming up with their own terminology document? 14:05:44 NM: Would you, RB, be able to add some pointers? 14:05:57 RB: Not sure I understand what's wanted well enough, no 14:06:12 q? 14:06:13 q? 14:06:14 q+ 14:06:26 RB: But if JAR can help, I'm happy to work to improve things in that area 14:06:33 ack Yves 14:07:23 YL: The focus on unwanted data access is both privacy and security, w/o claiming that that's all of either topic 14:07:58 YL: But the fingerprinting part isn't part of API design I don't think 14:08:31 q+ my identity is *also* information I don't want to give access to 14:08:36 YL: So I'd like the document to focus only on the not exposing unwanted-to-be-exposed data 14:08:38 q+ to say my identity is *also* information I don't want to give access to 14:08:42 q- Ashok 14:08:46 if the document is how to design APIs with security characteristics that support privacy goals, then there ought to be a hint in the title that this is the case; or, alternatively, a pointer in the intro that say "if you want to learn about other aspects of privacy by design, read X" 14:08:47 the "privacy considerations" document is more than terminology, and also applicable. 14:09:36 AM: We thrashed on privacy for a while and only agreed to tackle this at all when DA proposed this very narrow topic 14:09:37 if this is a topic for PING, should the TAG wait until IAB and PING converge? 14:09:59 AM: So I'm worried that JAR's concerns are widening things again 14:10:16 and what about other design patterns not covered? 14:10:30 robin, if you want to stop fingerprinting, you probably need more than api minization, but more policies, and that is not the same scope 14:10:34 AM: I liked the old "Data Minimization" title 14:10:41 actually the previous version of the product page that broadened the scope was approved IIRC 14:11:06 NM: But when RB took on the document, he did so on the basis of expanding the scope a bit 14:11:21 ... and that title reflects that 14:11:46 http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-4.1 is "Data Minimization" 14:11:46 Yves, yes, you can't use just section 4.4 — you mostly need sections 4.1-4.3 ;) 14:12:09 Data minimization is comprised of a number of mutually exclusive sub-goals: 14:12:09 14:12:28 AB: I would recommend going back to the original scope, because then we can publish more quickly 14:12:35 q? 14:12:38 q? 14:12:52 darobin: not only 14:13:41 Yves, what else do you need when designing new APIs (I'm not talking about handling the existing mess) 14:13:52 noah has joined #tagmem 14:13:53 LM: [summarizes IAB doc't on DM] 14:14:05 LM: I think we should collaborate with this 14:14:06 I mean that you might fingerprint by merely using multiple apis 14:14:20 LM: If they're not ready to collaborate, we should wait until they are 14:14:39 IF policy transmission is the only non-security privacy-by-design technique we know of, then it would suffice to just add a short section on policy transmission. then the title would match the scope… 14:14:59 AM: But we, and they, having been working for a long time 14:15:15 jar, how does policy transmission affect API design? 14:15:23 so you need specific policies to avoid mixing that information to generate accurate identifiers 14:15:26 LM: They are talking about protocols, we are talking about APIs, so there's a difference 14:15:58 to transmit a policy, the API has to provide a way to transmit it (as a parameter). you already talk about this in the document 14:16:07 Yves, if individual APIs do not yield identifying information, having more of them won't help identify more I would think 14:16:18 q? 14:16:24 ack masinter 14:16:45 jar, that's known as the GeoPriv anti-pattern :) 14:16:51 darobin, it depends on the level of fuzziness ;) 14:16:54 LM: There is a trust difference, certainly -- I might trust an app, and install it, more than I trust "the net" and thus not want stuff to go over the web that I would let an app see on my machine 14:17:22 LM: But then of course things such as Kindle Fire muddy the water 14:17:23 fine if it's an anti-pattern. discussion of it is in the scope implied by the title. even if you want to argue against it 14:17:42 s/water/waters/ 14:17:44 jar, well, the primary argument against it is that politically it won't happen 14:17:57 but it's true that I could include a section on antipatterns 14:18:06 q? 14:18:17 but it *is* happening - as DNT 14:18:36 which is 100% orthogonal to API design — not the pattern you describe 14:18:56 disagree. it's policy transmission. 14:19:02 NM: Should we add something to the draft about this connection, at least to signal it exists and aim for cooperation 14:19:04 LM: Yes 14:19:12 antipatterns would be a good idea indeed 14:19:22 jar, it changes *nothing* to how you design the API 14:19:26 RB: That sounds good to me, yes 14:20:03 any API that's involved in implementing DNT policy will have to have a way to transmit the DNT policy 14:20:22 jar, JS APIs won't even touch DNT 14:20:22 ack me 14:20:22 darobin, you wanted to say my identity is *also* information I don't want to give access to 14:20:45 NN: LM said "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward" 14:21:06 ACTION: Robin to incorporate into Privacy document "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward" 14:21:06 Created ACTION-713 - Incorporate into Privacy document "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward" [on Robin Berjon - due 2012-06-19]. 14:21:07 s/NN/NM/ 14:21:14 isn't DNT binding on ajax? 14:21:23 Ajax isn't an JS API 14:21:25 it's network 14:21:37 XHR 14:21:37 It's not just "we are working on", it's "this document focusses primarily on APIs, they are working on protocols, we intend to collaborate with them on points of overlap" 14:21:43 AM: This will never finish if we do this 14:22:21 NM: We're only talking about trying to be consistent, not trying to have a jointly agreed outcome 14:22:28 LM: Who is Christine? 14:22:49 We are, IMO, not committing to wait for any particular progress from those doing protocols, just saying we will attempt to coordinate, and we'll see where that leads on both content and schedules. 14:23:37 Christine Runnegar 14:23:39 RB: I've been emailing with Hannes T and Alicia ?, and Christine ?? who is co-chair of the Privacy Interest Group 14:23:46 q+ to ask about whether this should be done by PING? 14:23:59 s/Alicia/Alissa/ 14:24:22 RB: That's the W3C Privacy IG, and Alissa is on that group, so that seems like a good place to have this discussion 14:24:28 s/Hannes T/Hannes Tschofenig/ 14:24:30 jar, XHR is something you use to talk to something else on the network — and the JS certainly won't be allowed to set DNT 14:25:05 NM: So I'd like to turn to the process by which we get this published as a PWD 14:25:27 LM: Shouldn't this be being produced by the Privacy IG? 14:25:42 AM: They're an IG, and they have 1 call per month 14:26:04 RB: It's early days for them, they aren't ready to take this one 14:26:52 HST: If they ever fork a WG, maybe we park our WD based on calling it input into their work 14:27:41 LM: Could NM at least officially tell them we are doing this 14:27:51 NM: Sure, if we agree to go ahead 14:28:02 s/tell them/ask them if it is ok that/ 14:28:21 APIs and protocols are very similar, and over time become more and more so. e.g. in SES they're hard to distinguish. people designing one will always eventually design the other. historical experience is that they always converge. … in any case if you're right, it would help me to find an argument in a document called "privacy by design in javascript APIs", or a reference. it's in the scope set by the title 14:28:51 i don't think the TAG should take this on if there's a working group chartered to do this 14:28:55 q+ 14:28:57 q? 14:29:05 .ACTION: NM to email Christine ? that we are about to publish this doc't and offering to coordinate with them on who does what 14:29:30 LM: I don't think we should be doing this 14:29:44 ... I think a group dedicated to working on privacy should do this 14:29:59 ... I'm willing for the TAG to work on it until there is such a group 14:30:06 ... but only until then 14:30:46 q- masinter 14:31:00 this is a small part of "how to design for privacy" 14:31:38 [if the TAG were to drop this document, it would likely get published in DAP in cooperation with PING] 14:31:54 LM: The W3C needs to do the whole thing, not just this 14:32:06 prefixing the title with the word "some" might address my concern 14:32:06 ... The whole thing is _very_ big 14:32:17 the tag can't do the whole thing 14:32:30 i think this is something we can START on 14:32:37 q? 14:32:50 q+ jar to suggest "some" 14:32:58 AM: I thought we needed a victory in this space, so when we found a nice well-delimited task, we agreed to go ahead on it -- it's a step forward 14:33:06 maybe publish as a NOTE saying that we looked at a little piece of the space and more should be done, because our intent isn't to take on the whole thing. 14:33:36 q? 14:33:39 q- jar 14:34:17 jar, I am not aware of a single "patterns" document that claims to cover all patterns? 14:34:18 JAR: If we changed the title to "Some Patterns for Privacy. . .", that would help me -- LM? 14:34:39 LM: Yes, along with a preface about where this fits, as a Note 14:34:54 +1 to Jeni! 14:35:18 JT: More important to publish now than discuss where it fits indefinitely 14:35:20 +1 14:35:43 leadership is the skill of getting people to follow. i'm trying to figure out how the TAG can lead. Not even 'getting it right' 14:35:52 NM: LM you surprised me 14:36:18 LM: The TAG should lead, which means getting others to follow 14:36:39 i don't think what we have is a complete set of design patterns for privacy 14:36:52 NM: Is this publish and quit, or are we aiming for a good job, which we will edit in response to feedback 14:37:38 LM: What we have doesn't cover all the things in might, including sandboxing, secure Javascript and policy transmission 14:38:04 ... so we don't claim it's exhaustive 14:38:29 NM: OK, so do we publish it to get feedback and promise to revise, etc. 14:38:47 ... or do we expect to just hand it off and stop there? 14:39:38 NM: Personally, I agree to bound and label the scope, but publish as a PWD because we want to get feedback and improve as a result. 14:40:12 FWIW, I think that there are only two options forward: FPWD and keep going, or pass it to another group 14:41:05 i have a low barrier for FPWD as long as the disclaimer 14:42:11 NM: Title change, e.g. "Some Patterns. . .", so additional material about relation with protocols, FPWD, starting down REC track -- is that what we are saying? 14:42:59 LM: Yes, but conditional on a) IAB ref; b) not all of privacy; c) belongs elsewhere. 14:44:05 to be useful, this has to be only one of a suite of documents about privacy 14:44:56 NM: We have pulled things off REC track, but that sends at best a mixed message, I don't want to go ahead without a commitment that our best guess is that we want to take this to REC if we can 14:45:01 masinter, that's true, but we don't get to do a suite of documents without starting somewhere 14:46:06 HST: I don't agree with LM's caveat (c) -- we are committing to do this 14:46:39 PL: I think there should be a WG producing RECs on privacy. If there was, they should be doing this. But there isn't. So we should. 14:47:04 [especially since this document is not at all about building privacy aware applications at all] 14:47:09 LM: A world in which this is the only W3C doc't on Privacy in apps would not be a good one. 14:47:48 NM: Agreed, but not by putting that language in this document. 14:48:28 LM: So where _do_ we say we think there should be "a WG producing RECs on privacy". 14:48:38 s/"./"?/ 14:49:46 NM: We can talk about how to take this forward elsewhere, can we just publish the document? 14:50:06 PL: Can we put this on the product page 14:50:07 Poposal: ACTION noah contact JJ to pass on the message that the TAG thnks that W3C should have a working group working on Privacy 14:50:28 darobin has joined #tagmem 14:51:25 this is an argument over what gets written in the 'status' section, right? 14:51:29 ack Yves 14:53:57 NM: So the product page will only track the narrow document, I will take an action to communicate the larger need 14:54:21 . RESOLUTION: the TAG thnks that W3C should have a working group working on Privacy 14:54:45 which should take on as one of its work product to take on this document 14:54:55 note that I think the reason there is an IG on Privacy is so that we can figure out what a WG on Privacy would do (or several) 14:54:58 note that having a WG working on the topic doesn't preclude to publish document that might act (or not) as a seed document 14:57:15 . RESOLUTION: The TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG 14:57:26 +1 14:57:47 RESOLUTION: The TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG 14:57:51 Passes without dissent 14:58:18 ACTION Noah to communicate that tThe TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG 14:58:18 Passes without dissent 14:58:19 Created ACTION-714 - Communicate that tThe TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG [on Noah Mendelsohn - due 2012-06-19]. 14:59:00 timbl_ has joined #tagmem 14:59:10 NM: Objections to moving forward with the document? 14:59:12 [none] 14:59:27 NM: Objections to FPWD on the Web track? 14:59:29 [none] 14:59:31 FPWD, doesn't need to say "rec trac" 14:59:43 s/Web track/Rec track/ 15:00:17 +1 to adding word 'some' to title 15:00:20 NM: Add the word "Some"? 15:00:24 [no objections] 15:00:24 Accepted without objection: add "some" to the title 15:00:35 http://www.w3.org/2001/tag/products/apiminimization.html 15:00:42 http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html 15:00:48 http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html 15:01:20 I still wonder if anyone has ever seen a patterns document claiming to exhaustively document all patterns but *shrug*, won't bikeshed :) 15:01:33 why ever not? 15:02:23 JeniT, they're all about "some patterns" :) 15:02:38 HT: Propose replacing "TBD: an approved TAG finding on API Privacy by Design" with disjunction: 15:02:40 Either: 15:02:49 jenit, but hey, I think a slightly brighter shade of pink might catch the light better 15:02:56 * We publish a document (could be finding, rec, note TBD) -or- 15:03:04 * This gets handed over to new privacy group 15:03:25 should the product page make the assumption that a new privacy group will be chartered? 15:03:37 question for product page to include liaison with IAB and PING 15:03:41 might be chartered 15:04:29 Yves, Dan, Robin — who can tell the difference between those frenchmen 15:04:40 HT: Prefer not to get into details of handing over and to whom in the product page 15:04:59 LM: Adding something about liaison helps clarify our goals 15:05:24 LM: We will be commited to trying to resolve any disagreements 15:05:58 s/commited/committed/ 15:07:22 close ACTION-684 15:07:22 ACTION-684 Update Privacy by Design in APIs closed 15:07:48 here's the same document as a FPWD :) http://darobin.github.com/api-design-privacy/api-design-privacy.html?specStatus=FPWD 15:08:03 ACTION: Robin to prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published - Due 2012-06-26 15:08:04 Created ACTION-715 - prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published [on Robin Berjon - due 2012-06-26]. 15:08:24 NM: Need an action on the PP 15:08:28 "patterns for X" to me has the implicature of "all the patterns we know about, or at least a pretty dense sampling". "some patterns for X" doesn't 15:09:25 I really have to leave — sorry 15:09:45 please just give me actions! 15:09:49 -darobin 15:11:39 NM: Is a goal that we initiate further W3C work? 15:11:41 LM: Yes 15:11:45 NM: Objections? 15:11:48 . ACTION: Noah to update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy 15:12:01 [none] 15:12:13 ACTION: Noah to update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy - Due: 2012-07-31 15:12:13 Created ACTION-716 - Update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy - Due: 2012-07-31 [on Noah Mendelsohn - due 2012-06-19]. 15:12:31 ACTION-650? 15:12:31 ACTION-650 -- Jonathan Rees to review what provenance WG is doing with an eye to application to privacy issues -- due 2012-08-01 -- OPEN 15:12:31 http://www.w3.org/2001/tag/group/track/actions/650 15:12:58 JAR: no need for attention now. 15:24:50 Ashok has joined #tagmem 15:27:27 Topic: ACTION-563: Periodic TAG key issues reports to Jeff Jaffe 15:28:13 NM: We will owe an issue update in the autumn to JJ 15:29:12 q? 15:29:32 LM: Things we the TAG have struggled with: 15:30:07 ... XML and HTML are on divergent tracks, and they are both important to the W3C 15:30:55 Distributed Extensibility 15:31:53 apps vs. web 15:32:02 JAR: How do we frame this for JJ? Our previous message got the response: OK, so what do we do about it? 15:32:03 for mobile 15:32:29 NM: We should remember to revisit our last list before we do a new one. . . 15:32:57 AM: What if we work back from "What does the W3C want to accomplish?" 15:33:03 boundary between 'web' and 'non-web' for apps? 15:33:22 AM: For example, getting more uptake for the Semantic Web 15:33:41 semantic web is a means to an end… what's the end? 15:33:58 NM: JJ asked for alerts about things happening "out there" that he should be aware of 15:34:35 NM: Net neutrality? Installing servers "near the edges" 15:35:34 q+ to mention aging/companions/communities 15:35:51 TBL: Pushing it, or defining it? 15:36:16 q+ to raise distributed web applications (eg unhosted) 15:36:18 NM: Things which undermine the equality of access on the Web happen all the time 15:36:22 TBL: That's a given 15:36:46 q? 15:36:49 ack ht 15:36:49 ht, you wanted to mention aging/companions/communities 15:36:50 q? 15:37:40 HT: Help me get this right... trying to use technology, in some cases Web technology, to deal with changing age demographics in the "developed" world 15:38:12 HT: Using Web technology, in particular social Web technology, to address problems especially of older people learning alone. 15:38:36 HT: Story about study in UK that death rates could be cut dramatically if those at risk check their feet everyday. 15:38:55 HT: Relates to gangreen and diabetes. Old people can't easily see their feet. 15:39:07 q+ jar to webp2p , http://cyber.law.harvard.edu/node/5136 15:39:40 HT: I'm thinking of communities that are housebound 15:40:05 distance ed 15:40:07 video 15:40:34 TBL: Judy has some funding in this area. It's not a new idea, but it is important. 15:40:39 gamification 15:41:02 globalization 15:41:09 i18n isn't good enough 15:41:17 ack next 15:41:18 JeniT, you wanted to raise distributed web applications (eg unhosted) 15:41:20 game-ificaiton 15:43:23 JT: Distributed web apps means e.g. getting your app code from one server, but your data from one or more _other_ servers -- known as "unhosted" apps -- so you aren't dependent on any one silo/walled-garden for your data 15:43:53 AM: Linked Data Platform (LDP) is _not_ about unhosted data 15:44:10 ... There target is extending REST to Linked Data 15:44:16 http://unhosted.org/ 15:44:27 TBL: Aren't they talking about separating app from data? 15:44:45 q? 15:44:53 ... decoupling provision of stores from provision of apps 15:44:54 q+ to ask Jeni a question 15:45:09 q+ to raise the remote join question 15:45:44 ack noah 15:45:44 noah, you wanted to ask Jeni a question 15:45:52 unhosted is analogous to patient-controlled EHRs 15:46:09 NM: Is unhosted like AJAX, a way of thinking about your app? 15:46:56 JT: Yes, but also a concrete implementation, which you can import to give access to multiple sources of (encrypted) data 15:47:11 NM: So it is AJAX like, with some concrete JS support 15:47:36 ack next 15:47:37 jar, you wanted to webp2p , http://cyber.law.harvard.edu/node/5136 15:48:01 JT: Different from mashups is that e.g. Craigs List and google supplied the data for them, 15:48:05 q? 15:48:11 ... whereas unhosted means _you_ supply the data 15:48:36 AM: So when you start an app, do you spell out which sources of data to access? 15:48:42 JT: I think so, but not sure 15:49:40 TBL: So I imagine this as e.g. a version of Doodle which asks you "which [of your data] space do you want this meeting to use?" 15:49:51 http://www.mendeley.com/research/indivo-x-developing-fully-substitutable-personally-controlled-health-record-platform/ 15:50:02 spaces? 15:50:17 ... So that we can choose stores for different data parts based on the properties, e.g. privacy, they provide 15:50:27 q+ to give some new topics, disruption of higher ed 15:50:28 ack jar 15:50:46 JAR: I keep coming back to peer-to-peer -- has it heated up enough? 15:50:48 facebook, identity, "social" 15:50:59 from unhosted.org: "The web is not as open as it used to be: monopoly platforms formed new proprietary layers on top of it. But we create a better architecture for the web. We break the package deal »you get our app, we get your data« with remoteStorage, a cross-origin storage protocol separating application servers from people's documents." 15:51:11 JAR: There's a web-p-to-p mailing list, which has been sort of quiet lately 15:51:26 ack next 15:51:28 ht, you wanted to raise the remote join question 15:51:35 JAR: My fantasy is of p-to-p as a backup for the Web when the servers stop working 15:51:43 or DNS 15:52:20 http://www.w3.org/TR/sparql11-federated-query/ 15:52:39 does webrtc/rtcweb change skype / connect / webex ? 15:52:50 HT: Every 6-18 months I ask... Preamble: I don't want to load all your triples, or sparql to one source...want remote join 15:53:38 "web of video" "hypervideo" ? 15:53:44 just brainstorming 15:54:08 ...general sense...probably not now 15:54:14 impact / likelihood of action / timeliness 15:54:33 ht: Is there anything important happening in this space, that it should get attention? 15:54:53 vertical application spaces with near-term web impact 15:55:11 http://tesla.lcs.mit.edu/publications/Papers/sheldon.pdf 15:55:26 http://www.khanacademy.org/ 15:55:36 TBL: My goal is to have a SPARQL query, as such, and on that basis diagnoses based on a bunch of indices what data sources need to be accessed to get an answer 15:55:45 note "ni:" scheme discussion 15:55:47 ... and then uses those source to do the remote joing 15:56:07 TBL: The second part has been well studied, but the first has not 15:56:18 q? 15:56:42 http://tools.ietf.org/html/draft-farrell-decade-ni 15:56:44 comment on my scribed comment above re webp2p: the list isn't quiet; rather it's nascent, mostly introductions now, some interesting discussion 15:57:11 ack masinter 15:57:11 masinter, you wanted to give some new topics, disruption of higher ed 15:57:13 ack next 15:57:39 LM: Verticals with possible disruptive near-term impact: healthcare and higher education 15:57:58 ... Some threshhold wrt higher education on the web seems to be being crossed 15:58:17 ... Maybe healthcare 15:58:45 LM: RTC Web -- peer-to-peer video is another potential problem area 15:59:01 HST: IETF work isn't adequate? 15:59:11 LM: I think some things are maybe falling in the gaps. . . 15:59:34 ... IETF is doing protocols, W3C the APIS, but I'm not sure it's all covered 15:59:47 another p2p thing to be aware of might be the ietf decade wg… possible evidence of foment? 15:59:48 move of more things from text => video mean hypervideo 16:00:13 HT: What about identity (of people) 16:00:19 JAR: W3C hired someone 16:00:30 = Wendy 16:01:08 - +1.617.715.aaaa 16:01:11 one question is whether there is coordination between browserid & webid… but i'd be surprised if there weren't 16:01:16 NM: Adjourned until 1345 16:01:34 -Yves 16:01:35 TAG_f2f()8:00AM has ended 16:01:35 Attendees were +1.617.715.aaaa, Yves, +33.1.43.14.aabb, darobin 16:05:38 Thread on acct: URI scheme: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05957.html 16:49:36 jar has joined #tagmem 16:50:12 JeniT has joined #tagmem 16:52:15 timbl has joined #tagmem 17:09:21 ht has joined #tagmem 17:09:43 jar, jenit - where are you? 17:09:50 8th floor 17:10:11 coming 17:47:45 masinter has joined #tagmem 17:48:57 Ashok has joined #tagmem 17:49:20 noah has joined #tagmem 17:50:09 Scribe: JeniT 17:51:26 Topic: Quick report from lunchtime ISSUE-57 breakout group 17:51:35 jar: plan for Thursday's session on ISSUE-57 17:51:49 ... two problems: technical and procedural 17:52:13 ... jar, ht, JeniT & timbl have been exchanging emails behind the scenes 17:52:19 ... we have a rough consensus 17:52:34 ... technical part is to present "parallel properties" idea 17:52:58 ... has been around for 10 years, in some form or another 17:53:21 ... we have thoughts in terms of how to present or sell it, to see it differently 17:53:47 ... procedurally, first is to report back to the community about change proposals 17:53:59 ... then to prepare a document presenting "parallel properties" idea 17:54:04 ... then spin up a community group 17:54:26 Ashok: if we spin up a CG, is the TAG off the hook 17:54:35 jar: that's part of the question, it depends on the purpose of the CG 17:54:50 ... if the purpose is to solve the problem, it would require the TAG to have some level of commitment to the group 17:55:05 ... required for continuity for what we've been doing over last couple of months 17:55:12 ... take the draft as a starting point 17:55:31 ... the matrix would be an input to the CG 17:55:46 noah: what about the other documents you produced? are they still useful points of reference? 17:56:07 jar: if someone has questions about why particular options were discarded, then yes, but more for that historical purpose 17:56:29 ... easiest thing is to give CG a bibliography, harder to provide an orientation document 17:56:40 ... let the group start meeting, and see if they need it 17:56:56 noah: we worked hard on them, wondering whether they have proven useful 17:57:10 jar: if the CG is on board with the proposal, then they won't need it 17:57:51 masinter: I'm happy you're making progress, and I like the parallel properties proposal 17:58:00 ... like that it's not tightly linked to HTTP 17:58:06 ... that servers don't have to exist 17:58:16 noah: is there anything we should read? 17:59:37 jar, jenit: don't think so right now 17:59:51 if you want to say "the copyright of A is C", and A is a JPEG impage of mickey mouse, you can talk about the JPEG encoding, the particular image, the drawing the image was scanned from, or the very idea of mickey. 18:00:49 … and if you want to talk about all four at the same time?… e.g. how they relate to one another?... 18:01:37 scribenicK: jar 18:01:59 topic: Fragment Identifiers and Mime Types 18:02:09 noah: Objective is to get to FPWG 18:02:17 s/FPWG/FPWD/ 18:03:11 jt: Context: We're trying to tackle: fragment ids are defined in different specs, e.g. media fragments and the +xml media type(s) registration 18:03:26 … How to resolve conflicts between these 18:03:27 Zakim has joined #tagmem 18:04:11 … We've been talking to Chris re 3023bis (+xml), with RDFa WG, and IETF media type reg process RFC draft 18:04:21 tools.ietf.org/html/draft-ietf-appsawg-media-type-regs 18:04:26 http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs 18:05:03 … The present document is best practices for 4 groups of people: (see TOC) 18:06:17 … those writing media type regs; those writing +xxx regs; those writing generic fragid semantics specs; people preparing documents [& sw that prepares] 18:07:08 noah: Has anyone read this particular version? 18:08:01 jt: I'll try to talk through the main points that the BP draft makes 18:08:23 jt: 1. People writing media type regs. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html#registrations 18:09:10 jt: You're subject to constraints. These come from several places. Other media types, scripting, etc. What to do? 18:09:34 Coined term 'fragment identifier structures' 18:09:41 s/Coined/jt: Coined/ 18:11:52 jt: If there are two kinds of generic processor that might apply to the documents, then the media type reg should reconcile … if there's a conflict, make a choice 18:12:11 lm: The dependent clause is not determinable - whether there's a conflict is unknowable. Remove 2nd sentence? 18:13:07 jt: You would drop the structure syntax by removing the +xxx in the media type name 18:13:43 lm: If they're in conflict, you're better off not using the structure syntax (this isn't exactly a BP) 18:14:23 noah: The doc uses both uppercase and lowercase 'should'… no mention of 2119 18:14:50 … the mix was murky to me… SHOULD is normative 18:15:17 lm: How about just explaining that uppercase (2119) is used in the BP notes (i.e. not outside them) 18:15:50 noah: 'Best practice' has strong connotations.. maybe say 'good practice' instead? 18:16:57 lm: The status of the IETF document could note that this document is in progress. If there's a durable URI we should be able to get them to mention in it 18:17:26 noah: Important that the BPs are linkable. 18:18:27 … (individually) 18:19:28 The document that I'd like to reference this is called a "BCP" "Best Current Practice" 18:21:53 jt: BP #2. Conflicts betwen app-specific fragid structures that apply to the media type: explain how to resolve 18:22:14 does "special internal syntax" mean "punctuation" ? What about CamelCase identifiers? Or are some puncutation marks OK? What about names with spaces which are then %20 escaped? 18:22:36 noah: There should be no syntactic overlap? 18:23:24 q+ to offer that everything we're talking about are quibbles and we could FPWD this version without any changes 18:23:57 jt: There are fragids that are brought about generically, because of the 'supertype' of the media type. Then there are fragids that come about because of specific applications. BP #2 is between instances of the latter 18:24:46 put parentheses around "as in the music notation example above" between BP1 and BP2 18:24:54 noah: If you're a +xml and there's an xpointer, it's xpointer, full stop. 18:26:00 timbl: What about rdf+xml? 18:26:06 jt: Hang on, that comes later 18:26:16 q? 18:27:41 noah: I read this differently 18:28:39 jt: Don't land-grab on barenames. Currently +xml specifies both xpointer and barenames; it would be better if only said xpointer 18:29:28 noah: Problem regarding evolution of the xpointer spec- a future version might claim more syntactic space 18:31:16 lm: I'd be happy with this as fpwd as is. For BP#3, what about new formats not based on XML, e.g. json-based. No barenames anywhere? Is that bad practice? What is justification for singling out barenames [?]? Maybe I have multiple kinds of things named by authors. 18:31:57 jt: In XML schema you have types named by authors and elements named by authors 18:32:09 noah: a bit hard to read. 18:32:35 lm: Perhaps this is about worst practices, not best practices 18:33:41 timbl: bare names are common to many languages, including future ones. original architecture was for local identifiers, defined using definition mechanism of any language 18:34:25 jt: Authors want to put anchors in documents… places they can get at 18:35:25 timbl: With a bit of effort we can make it much more interesting, e.g. javascript variable names. Don't use id in your language for anything other than global names 18:35:57 lm: The names aren't generated by author always, sometimes by the authoring tool. Plain names are more like local ids and less about syntactic structures. 18:36:24 … Can it have spaces? Can it use dots? dashes? those are syntactic structures 18:37:41 "should be used to address" => "should be reserved for addressing" 18:37:50 timbl: It's been frustrating that N3 is C-like, no minus signs. Then RDF people use dashes because they work in XML. Don't serialize nicely in N3. Turtle gave in because of XML pressure. Personal practice: no punctuation in bare names, even if your favorite language likes them 18:38:47 lm: In the context of media types, you're not talking about addressing, but reserving a style for the purpose of addressing 18:40:41 jt: BP#4: Media type regs should talk about scripts. Maybe reserve part of namespace for use by scripts. 18:41:18 sentence 1 of para before BP#4 is a definition of "active content" 18:41:36 s/likes/allows/ 18:42:02 and "scripts" is "user provided", where the scripts are part of what is downloaded 18:42:04 noah: Add a new tag to XML? Oh that's a circle, I can fake that using a canvas tag. Scripts operate on document content too. The fragid isn't always just a parameter to the script 18:42:39 … There are times when scripts are tempted to squat on parts of the address space that might be in use for something else 18:42:41 "the developers of scripts should ensure" seems misplaced 18:44:22 s/them/them (JSON for example doesn't have - or . in local names, and so names imported from XML will break if they have punctuation within them. So a good practice is to avoid punctuation characters characters in localids.)/ 18:45:37 noah: Misread that BP. First talk about how tags are interpreted when the scripts don't run… then say scripts shouldn't conflict with that 18:45:53 not sure "scripts" is the right word -- does this work for java applets? 18:45:57 ashok: Should specify how scripts use fragment identifiers 18:46:18 jt: Maybe this is two separate practices 18:46:21 "scripts" => "active content" everywhere? 18:47:21 jt: #5: If you're going to define a fragid structure, do it in a separate document so people can reference it separately. 18:47:52 ashok: Didn't we say the reg should define …? 18:47:56 for ...? for reusability? for consistency? 18:48:18 for modularity? 18:48:26 jt: The reg should list the applicable structures, usually with references to independent specs 18:48:42 ht: It's a 'should' only because sometimes the independent spec doesn't exist 18:49:04 … if the spec exists maybe the reg MUST reference it? 18:49:52 noah: Suppose I have a need for specialized fragids, are you saying I should provide it in a separate spec? 18:50:32 … Consider factoring the spec, or looking to see if there's already a factored spec 18:50:49 noah: The sentence has multiple parses 18:51:11 … if they exist, vs. creating them as necessary 18:51:25 lm: If the justifications are modularity and reuse, the previous paragraph should say so 18:52:24 jt: #6: Should say what happens if a fragid is undefined - either it's outside syntactic space, or it's not defined semantically 18:53:54 noah: Unresolved fragids comes up in parts of the architecture… where are you going with that? 18:54:04 noah: if you're describing what fragment identifiers identify, then if things don't match, you don't say. Where is this going? 18:54:52 timbl: This is a funny area. There are lots of media types out there, … (missed) 18:55:31 jt: E.g. say that if there's no fragid defined in the HTML, then you should go to the top of the document… 18:56:38 timbl: Bad idea for the spec to say what the user application is supposed to do. Maybe browser is a special case, but in data processing in general, it all depends, and the spec shouldn't try to nail behavior down 18:57:10 timbl: Operational commitments, like what we find in XML and HTML, are not a good idea 18:58:37 noah: Identifiers resolve, or they don't. Or you could say that since all ids seem to appear something in the document (usually)… (missed) 18:58:52 noah: Better to say less. E.g. just say that some ids don't resolve. 19:00:26 noah: The behavior when the pre-# part resolves but the fragid doesn't is best specified by the consuming application 19:01:03 … disagree that #6 is a best practice 19:01:31 jt: What if it's invalid syntactically? 19:01:47 noah: I wouldn't expect much commonality between consumers 19:02:39 jt: Section 3, re things like +xml and +json 19:05:08 jt: It was trying avoid the +xml case where it said that all fragments had to be interpreted as xpointer, leaving no room for the specific media type registration. 19:06:34 timbl: Needs to be crisper. If you're talking about media types adopting a variety of structures. Was this deliberate? Or it ended up being covered by a suffix? You could make a structure that simultaneously matches two specs, or do you decide which syntax it is and choose which structure applies? 19:08:29 … you must not use any other registration that overlaps with my syntax because it has the bugs you say. but if it's not overlapping, supporting both shouldn't be precluded 19:09:30 timbl: You're trying to say, use up a small part of the syntactic space 19:10:27 jt: #7 is saying that if it's not covered in +, then it devolves to the specific media type 19:11:42 jt: #8 says that + registrations shouldn't cover bare names 19:11:58 ht: If Chris does what we asked them before, it will contradict this advice 19:12:12 jt: We discussed this in Antibes 19:12:54 ht: #8 and #9 conflict for XML. The xpointer framework includes barenames 19:13:06 jt: +xml doesn't need to adopt it in its entirety 19:13:54 ht: if 3023bis doesn't say that it adopts xpointer, we have trouble 19:14:35 lm: The conclusion is that the +xml definition is not best practice. 19:16:12 (going meta) 19:20:02 masinter` has joined #tagmem 19:20:30 ht: (Reading resolution passed in Antibes re 3023bis) 19:20:53 ht: It's on a case by case basis, not a syntactic category basis 19:21:23 ht: This was at the end of a long discussion, and everyone agreed 19:21:48 I read from these minutes: http://www.w3.org/2001/tag/2012/04/04-minutes#item02 19:22:04 the appsawg documents are not on http://datatracker.ietf.org/iesg/agenda/documents/ 19:22:36 The relevant bit is in red many pages down from that link, in practice easier to reach a few pages _up_ from http://www.w3.org/2001/tag/2012/04/04-minutes#item03 19:22:37 noah: Right. There's precedent for saying that some identifiers resolve and others don't, and the ones that don't get their semantics elsewhere 19:23:02 jt: "… but if they do, they should at least leave the ones that don't resolve to …" 19:23:14 noah: They apply to any potentially overlapping syntax 19:23:51 ht: We didn't leave it to bare names, it was for any overlapping syntax 19:24:29 noah: Action at a distance risk 19:24:33 ht: That's why it's a should 19:25:17 noah: Explain the tradeoff. This advice was given for xml because... 19:25:39 ht: This doc goes back on what we worked hard on in Antibes… problem 19:26:12 my reading of IESG tracker http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ is that today vs thursday doesn't matter. 19:26:56 ht: Last draft published 6 days ago. 19:27:31 lm: Draft is not on their agenda for the next couple of weeks. But I can give editors a heads-up 19:29:40 scheduling 19:33:01 Adjourned until tomorrow. 19:33:10 rrsagent, pointer 19:33:10 See http://www.w3.org/2012/06/12-tagmem-irc#T19-33-10 20:31:46 ht has joined #tagmem 20:36:06 Zakim has left #tagmem 21:15:45 Norm has joined #tagmem 21:16:57 Norm has joined #tagmem 22:45:14 Norm has joined #tagmem