14:04:25 RRSAgent has joined #tagmem 14:04:25 logging to http://www.w3.org/2011/02/08-tagmem-irc 14:04:41 scribe: Jonathan Rees 14:04:46 scribenick: jar 14:04:52 chair: Noah Mendelsohn 14:06:11 agenda: http://www.w3.org/2001/tag/2011/02/08-agenda 14:06:43 zakim, this is tag 14:06:43 ok, jar; that matches TAG_f2f()8:30AM 14:10:11 Not convened yet, awaiting arrivals 14:11:11 Convened 14:12:02 intros 14:12:08 jar: (intro) 14:12:45 ht: (intro) sgml, xml , more recently status of uris in webarch 14:13:49 dka: (intro) mobile web, privacy, social web 14:14:36 Ashok has joined #tagmem 14:14:40 timbl: (intro) DIG, privacy, policy, semweb UI 14:15:23 ashok: (intro) standards, oasis, etc, rdb to rdf 14:16:49 plinss: (intro) css, gecko, print as 1st-class citizen on web 14:19:21 ... pre-css: object based editor on nextstep, design model. Digital Style Websuite 14:21:39 noah: agenda review 14:23:06 ... norm w is planning to spend all of wed. with us 14:23:16 Noah, is this the number you used: email: LMM@acm.org (personal) masinter@adobe.com (company) 14:23:16 tel: +1 408 536-3024 14:30:13 noah: (re priorities session on thu) we had identified 3 areas, larry has created a 4th area of core technologies (mime, sniffing, etc) 14:31:11 ... please think about tradeoffs 14:31:15 zakim, who is here? 14:31:15 On the phone I see W3C 14:31:16 On IRC I see Ashok, RRSAgent, Zakim, jar, noah, plinss, DKA, timbl, ht, trackbot, Yves 14:33:23 topic: Design of APIs for Web Applications 14:33:56 DAP privacy requirements: http://www.w3.org/TR/dap-privacy-reqs/#privacy-notice 14:34:52 dka: Looking at DAP group's document on requirements 14:35:21 ... javascript apis that access things containing sensitive information - just about anyting 14:36:07 ... camera, address book, calendar, orientation, velocity 14:36:48 (pointing at table 'how each element is covered' with notice, consent, minimization, etc. rows) 14:38:54 dka: what might the tag do to help promote privacy [control] on web? 14:39:49 dka: set of small, targeted docs that build on work of others (DAP, UCB, others)? 14:41:19 dks: look at existing docs, amplifying, put in specific web contexts. e.g. (for instance) Hannis (sp?) doc is general, DAP specific to DAP, connect them. 14:41:26 s/dks:/dka:/ 14:43:22 projecting the API minimization note [URI in agenda] 14:43:53 dka: come up with several examples of this idea in action 14:45:30 ... want to sidestep Ashok's issue - about the Abelson et al. paper pointing out that user dialogs are silly, since they can't assess consequences 14:46:23 Ashok: Abelson et al suggests to consider legal accountability as alternative 14:47:20 dka: Vodafone privacy counsel said (at workshop) things are coming together on that front 14:47:22 q? 14:47:51 ... Minimization is not about this. 14:48:44 timbl: Need global change in ethos regarding data use, independent of how they got it 14:48:58 ... All these [tactics] need to be in the list 14:49:38 dka: Looking for technical [tactics] that TAG might be able to say something about. 14:50:15 ... image metadata capturing privacy intent? 14:50:37 ... If you keep asking people about this, good results are unlikely 14:51:42 timbl: What if you say: I want my friends to see my pictures. would be nice if software kept track of how/why friend got them, as reminder 14:52:32 dka: Problem - technical jargon in dialog boxes ('GPS coordinates' ...) 14:53:18 noah: You're saying the apps should be able to say: I don't need more info than xxx. 14:53:25 ... What about malicious apps. 14:55:05 dka: Remember this philosophical approach. We tend to get distracted. Need to find particular points to focus on. 14:55:26 dka: [Solve one problem at a time.] 14:55:54 noah: ... But my experience is that most of the problems have to do with attackers 14:56:27 ... and exploiters 14:57:41 dka: Problem comes with attacker exploiting well-intended app. What to do to well-intended to make it less vulnerable to exploitation 14:58:29 dka: We need to be clear that even if you do [any particular thing], you won't have a privacy solution 14:59:10 noah: Problem is interacting with untrusted services that I need to use. 15:00:47 dka: The aggregate amount of info open to abuse is lower if you minimize. So several docs to chip away at specific things, not to provide comprehensive solution 15:01:12 q+ to support DKA wrt NM's use case 15:01:38 http://www.cs.virginia.edu/~evans/cs551/saltzer/ 15:01:50 is what JR is talking about 15:03:37 LM and JK join the meeting at this point 15:04:13 jar: security is just one way to support privacy... and need to do lots to get security. least privilege just one. 15:05:30 ht: Dan's answer did address Noah's point. By specifying an approach that the platforms subscribe, you bound the damage that the bad guys can do. If they have less info, they can do less. 15:06:21 ht: You can reduce the bandwidth of any particular API call. This raises the barrier. 15:07:36 dka: If the app only needs city location, but has to request fine grained location, ... is the right question being asked [or user, developer, app...?] 15:07:51 noah: Document needs an intro that sets expectations 15:08:35 masinter: Framing = it's warfare, we're minimizing the attack surface 15:09:09 There is a HF/UI design/human engineering issue here which won't go away, but micro-capabilities do create a real opportunity to reduce your exposure, much as they make me tear my hair out as an implementor 15:09:26 masinter: To say there's a way around a defense, is not an argument against the defense 15:09:30 I also wanted to make the point that: dealing with access control (or legal means) that will prevent malicious apps from getting info they shouldn't have is crucial -- even if none of the solutions we have now have been shown to work very well (e.g. because users say "yes" to everything) 15:09:42 q+ to give the Mark Logic API parallel 15:10:01 ack next 15:10:02 ht, you wanted to support DKA wrt NM's use case and to give the Mark Logic API parallel 15:10:13 q? 15:10:53 ht: I use two different xml database systems... the 'open' one has unix style object protection - file x RW 15:11:39 ... the commercial one has about 60-70 capabilities. almost 1-1 on API calls, file x cap 15:12:01 ... bigger effort to manage for both users and developers. 15:12:03 johnk has joined #tagmem 15:12:40 q+ to mention the FB API model 15:13:16 ... you get high degree of control. Compare minimization. You have to get informed consent, but if it's granular enough you get questions that are specific enough to make sense 15:14:22 dka: Resistance to normative requirements to UI design, esp. re privacy 15:14:30 s/to UI/for UI/ 15:15:48 dka: The minimization approach doesn't impose specific UI requirements. This might enable creative UI design 15:15:58 zakim, close the queue 15:15:58 ok, noah, the speaker queue is closed 15:16:39 johnk: There's always a useability tradeoff in security. E.g. facebook has tons of knobs 15:17:05 ... but underneath there's a simple set of access control privs 15:17:18 ... e.g. app needs to do something special to get email address 15:17:35 ... This is a usability issue, a tradeoff 15:18:44 dka: Re minimization, the approach stands, since it says nothing about the user interaction. [API and UI needn't slavishly correspond] 15:18:56 q+ to talk about globbing together as a good UI for apps - data - groups of people 15:19:01 zakim, open the queue 15:19:01 ok, noah, the speaker queue is open 15:19:12 q+ to talk about globbing together as a good UI for apps - data - groups of people 15:19:25 q- 15:19:28 ack next 15:19:29 johnk, you wanted to mention the FB API model 15:19:43 masinter has joined #tagmem 15:19:47 noah: Proposal? 15:19:59 q+ to talk about participating in larger discussion 15:20:14 I'm asking: what do you propose we do that will have real, useful impact for the community? 15:20:44 dka: Useful output might be: Umbrella document. Privacy and webarch. Subdocuments, e.g. minimization. 15:21:59 scribes - Tue JR / DA, Wed AM / ?, Th HT / ? 15:22:41 masinter: Big discussion on privacy in larger community. Our schedule should coordinate with external events 15:23:11 q+ to make a specific proposal 15:23:23 ack next 15:23:24 masinter, you wanted to talk about participating in larger discussion 15:24:48 masinter: What does API minimization have to do with HTTP? 15:25:15 jar (under breath): there are HTTP APIs 15:25:55 my point is that if we're trying to decide what to do with some work that was focused in one group to generalize the principle in a way that it applies to all W3C work and not just to the work of one committee 15:26:12 noah: DKA, can we get together and make a straw-man product proposal? 15:28:35 masinter: E.g. can be a problem sending info in Accept: headers when it's not needed in order for server to do its job 15:29:28 masinter: Trying to suggest how to expand this from a DAP point to a TAG point 15:29:54 timbl: (masinter, you missed the beginning of the session) 15:30:25 (break) 15:45:58 johnk has joined #tagmem 15:48:30 topic: Web Applications: Security 15:48:43 http://www.w3.org/2001/tag/2011/02/security-web.html 15:50:14 jk: I was asked to frame section 7 of the webarch report on apps 15:50:32 jk: Wanted to echo [style of] Larry's MIME writeup 15:51:05 ... If you start with browser/server/protocol, and trace history of the three with a security focus... 15:51:24 ... start with just getting a doc. 15:52:03 ... then more support in http. history in doc is well known but worth reviewing 15:52:33 ... NN2 introduced cookies, and cookies needed origin 15:53:09 http://tools.ietf.org/html/draft-ietf-websec-origin 15:53:21 ... Related to lost of security issues. State in protocol. Origin and document not linked securely. 15:54:11 ... Why should you trust the DNS? 15:55:27 timbl: It assumes there's a social connection between - and -. There was a trust model, it just wasn't cryptographically secure 15:55:58 jk: These are layered protocols, that makes security harder. eg. DNSsec isn't bound to higher protocols 15:56:34 ht: scripts?? 15:56:49 jk: Dynamically loaded scripts not subject to SOP 15:57:59 noah: XML and JSON is good example - the weaker language was subject to tighter security controls - dumb 15:58:50 ht: script with a source tag predates JSON. it was never subject to SOP ?? 15:59:49 http://en.wikipedia.org/wiki/HTTP_cookie 15:59:53 timbl: Suddenly all these APIs have this extra parameter, the calling function ... 16:00:09 the function to be called by the injkected script tag 16:00:22 jk: Cookies were easiest way to do session indicator. shopping carts and so on. 16:00:34 ... AJAX was other driver 16:01:16 ... XHR does use SOP, but using JSONP you can circumvent it 16:01:40 ... apps send cookies from one place to another 16:02:08 jk: Trying to abstract away, to find security issues as opposed to implementation bugs. What issues are architectural in these examples 16:02:37 ... One is, when doc contains multiple parts, contributed from different security domains 16:03:52 noah: (When did we stop using the term 'representation'?) 16:04:19 jk: If you don't mediate the interaction, e.g. using sandbox, bad things happen. 16:04:29 ... e.g. runaway cpu time 16:05:15 ... Silent redirects. Malicious site forwards, cookies sent to 2nd site -> clickjacking 16:06:37 ... Authentication based on Referer: (i.e. referrer) header 16:07:12 ... Servers depend on client to do the right thing, in particular proper origin processing 16:07:50 ... Specs are difficult read, so there can be broken user agents. 16:09:01 ... My advice: Server should not trust user agents. What are circumstances in which you can server can align with user 16:09:32 timbl: We need to preserve the role of the user-agent as the agent of the (human) user. 16:10:18 johnk: Yes, but we need to be a bit more nuanced. There shouldn't be inordinate trust in a class of agents. One should only need to trust an agent to a certain degree. 16:11:05 noah: Users don't understand UAs well enough to be able to discriminate.. 16:11:11 masinter has joined #tagmem 16:11:53 somehow I want to bring in http://www.schneier.com/book-sandl.html' 16:12:14 timbl: That doesn't diminish the responsibility of UAs 16:12:33 q+ 16:13:06 timbl: One of the the things the TAG does is to ascribe blame 16:13:22 johnk: Who's responsible for a clickjacking attack? Software was behaving per spec 16:13:41 masinter: Users are presented choices that they don't understand 16:14:21 johnk: Not much you can do about that - 16:15:01 masinter: don't require users to make decisions that they don't understand. design principle. 16:17:02 ... optimize a match between what user wants and what happens. doesn't matter whether choices are simple or complex 16:17:48 pl: You said simplicity might be better - maybe so at user level, not nec. across the system 16:19:34 complex choices are less likely to be understood, but simple choices might be a problem 16:20:06 (scribe notes that henry suggested just the opposite. see above) 16:21:24 jk: Cache poisoning might mean no link between IP and domain name... in fact no way to guarantee domain name ownership 16:21:33 want to talk about TAG work in context with http://datatracker.ietf.org/wg/websec/charter/ 16:21:53 16:21:53 Oct 2010 Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item. -- don't see that document 16:22:00 ssl... data not encrypted on hotspot 16:22:08 s/ssl/jk: ssl/ 16:23:10 timbl: Firefox 'get me out of here' 16:24:07 jk: When you run web content, the content starts being rendered immediately - there is no install step. It just starts running 16:24:54 ht: I've been manually virus checking every downloaded app. Can't do this with pages 16:25:07 masinter: antivirus sw modifies the stack 16:26:19 noah: Also you lose the ability to make sticky decisions. Nextbus is an example of non-installed app but that you come back to repeatedly 16:26:51 ... you keep getting asked for permssion to use location. annoying 16:27:55 timbl: But most browsers do this well ? 16:28:12 s/antivirus/some antivirus/ 16:28:18 s/the stack/the HTTP stack/ 16:28:18 jk: Lack of tie-in between host naming and where you access the doc (where published) 16:28:56 ... who is responsible for the content of the document? Nonrepudiation. 16:30:03 timbl: You can sign the document until you're blue in the face ... 16:30:23 noah: Doc is written by an expert, would be helpful if some of the examples were spelled out in more detail 16:31:03 masinter: Security WG calls for a [...] document. Is what we're doing related to their work item? 16:31:25 ... They have a bunch of specific documents, but nothing at this level 16:31:50 jk: Their docs are very narrow 16:31:56 masinter: No, look at their charter 16:33:05 Oct 2010 Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item. 16:33:41 masinter: Isn't this what we're doing? 16:35:30 jk: The issue of mime sniffing. It became a good idea for the browser to ignore media type... problem is guessing user intent 16:36:52 (slight aside) 16:37:12 jk: So what would be desirable properties of security webarch? (reviewing doc) 16:37:57 noah: please clarify use of 'web agent' 16:39:23 noah: 'tie' isn't evocative - what constitutes success? what system properties are we after? 16:40:15 timbl: E.g. maybe avoid separation of authentication and authorization 16:41:18 jk: App layer with signed piece of content, same key should be used in both levels of protocol stack (or at least related) 16:41:31 timbl: WebID people have expereienced this need - converting keys between apps / layers - PGP to log in using ssh etc. 16:42:45 ht: I'm having to use Kerberos - very inconvenient - when I ssh from laptop home I need a kerberos principal... way too much work... [so unification cuts both ways?] 16:42:56 timbl: but kerberos isn't public-key 16:43:39 timbl: The thing about connecting the two parts together is valuable 16:45:00 jk: WebID is a case where it can't be done. User generates a cert, puts it in foaf file. Impossible to tie foaf description of me with me the person. 16:46:03 masinter: can show 1 person wrote 2 things 16:46:31 noah: Same issue as in PGP - you have to be careful when first picking up the key 16:46:42 jk: what's the purpose of encrypting the assertion?... 16:46:58 s/?/ (in webid)?/ 16:48:15 jk: 3rd bullet in properties section: We should be able to do what the original web design wanted us to do 16:50:49 timbl: But doesn't CORS do this for us? 16:51:04 jar: Controversial. 16:54:24 W3C TAG should be a participant in overall work on web security, including other work in IETF and W3C 16:55:36 ACTION-417? 16:55:59 action-417? 16:55:59 ACTION-417 -- John Kemp to frame section 7, security -- due 2011-01-25 -- OPEN 16:55:59 http://www.w3.org/2001/tag/group/track/actions/417 16:56:11 ACTION-417? 16:56:11 ACTION-417 -- John Kemp to frame section 7, security -- due 2011-01-25 -- OPEN 16:56:11 http://www.w3.org/2001/tag/group/track/actions/417 16:56:13 masinter: There's ongoing work. We should review it regularly and be seen as a participant. The way to do that is to publish a note, and announce, repeat. But be clear that we're not trying to take the lead. 16:57:01 noah: But the action was to frame a section of our document... 16:57:47 The W3C chapter on security on the web could identify that there are some issues and point at other groups that are working on the problems 16:58:37 W3C TAG should have input on W3C activities decisions, and this should be a W3C activity, on "security and privacy" 16:59:02 ashok: Let's close 417, start another one to write a note. If that becomes bigger/better, fine. 16:59:32 masinter: In general the TAG should be more involved in setting up W3C activities. 17:00:08 timbl: So far it's just been a series of workshops, not an activity 17:01:52 ashok: Privacy at w3 is morphing 17:03:47 masinter: Would like to see a note out before Prague meeting (end of March) 17:04:03 noah: any objection to a proposal to close ACTION-417, and have John publish what he's got, slightly cleaned up, as a note with no formal status, but at a stable URI. Noah will help. 17:04:44 Larry will help too, and would like this done in time for IETF in Prague. 17:04:55 PROPOSAL: close ACTION-417, and have John publish what he's got, slightly cleaned up, as a note with no formal status, but at a stable URI. Noah will help. 17:05:03 No objections. 17:05:07 close ACTION-417 17:05:08 ACTION-417 Frame section 7, security closed 17:05:54 action John to publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07 17:05:54 Sorry, couldn't find user - John 17:06:25 action Larry (as trackbot proxy for John) who will publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07 17:06:25 Created ACTION-515 - (as trackbot proxy for John) who will publish http://www.w3.org/2001/tag/2011/02/security-web.html, slightly cleaned up, with help from Noah and Larry Due: 2011-03-07 [on Larry Masinter - due 2011-02-15]. 17:08:36 ACTION: Noah to talk with Thomas Roessler about organizing W3C architecture work on security 17:08:36 Created ACTION-516 - Talk with Thomas Roessler about organizing W3C architecture work on security [on Noah Mendelsohn - due 2011-02-15]. 17:53:27 noah has joined #tagmem 17:54:33 ht has joined #tagmem 17:58:28 johnk has joined #tagmem 17:58:32 timbl has joined #tagmem 18:03:02 jar has joined #tagmem 18:06:06 ted has joined #tagmem 18:08:47 plinss has joined #tagmem 18:10:05 masinter` has joined #tagmem 18:19:09 DKA has joined #tagmem 18:19:54 Scribe: Dan 18:19:57 ScribeNick: DKA 18:20:03 [roll call] 18:20:11 Noah: Ted is joining us. 18:20:20 timbl_ has joined #tagmem 18:20:36 Topic: scalabilityOfURIAccess-58: Scalability of URI Access to Resources 18:21:06 Noah: [background] there are certain resources w3c publishes on its website - e.g. dtds... 18:21:18 ... certain organizations were [fetching] these resources a lot. 18:22:03 -> http://lists.w3.org/Archives/Public/www-tag/2011Feb/0016.html summary Yves wrote of actions taken by W3C 18:22:03 ... practical question: what can be done? Architectural question: what can be fixed in the architecture? 18:22:05 -> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic article on DTD traffic 18:22:38 timbl_ has joined #tagmem 18:23:02 ... one angle proposed is : what would be the role of a catalog? You could tell people that certain resources won't change or won't change any time soon so they could build [their products] not to fetch these resources. 18:23:17 ... Anything else from Ted? 18:24:15 Ted: We've employed some different techniques - for certain patterns we've given http 503 after reaching a threashold. At peaks, we see half a billion a day. Starts to become a problem. Sometimes this has resulted in blocking organizations. 18:24:30 ... if it's an organization that is a member then we pursue through the AC rep... 18:24:46 ... this doesn't scale well. 18:25:19 ... there are several big libraries - eg. msxml - they've put a fix in which has led to a sharp decline. 18:25:37 ... Norm Walsh came up with a URI resolver in Java that would implement a caching catalog solution but this never made its way into Sun JDK. 18:26:07 ... Sun has been bought by Oracle so now we are talking to Oracle engineers and they have been responsive. Trying to see if we can get something into next JDK. 18:26:22 ... We had a fast response from Python. 18:26:38 Noah: Do you ask these people to implement caching or a catalog? 18:27:10 Ted: We suggest either. I like the caching catalog solution [from Norm]. 18:28:05 ... we educate, we block, we have a high-volume proxy front-end that distinguishes traffic... 18:28:05 ... when we explain to people that this is not good architecture - receiving the same thing over the network 100000's times a day - they agree. 18:28:21 ... we probably should be in the business of packaging and promoting the catalog. Henry has done some work on this. 18:28:55 Ashok has joined #tagmem 18:29:21 ... the idea we came up with - find the most popular ones based on traffic and we routinely package these up, have RSS feeds to alert to catalog changes, talk to Oracle, Microsoft, Python, etc... get some of the bigger customers out there to adopt the catalog. 18:29:45 q+ to wonder about RSS feeds fro updates to things with distant expiry dates. 18:30:38 ... meta-topic (that the TAG is concerned with) is the scalability of URIs in general. There is a lack of directives to do rate limiting, to set boundaries, how to scale URIs... Could be useful in dealing with DDOS attacks. 18:30:44 q- noah 18:31:04 q? 18:31:08 ack next 18:31:09 ack next 18:31:10 timbl, you wanted to wonder about RSS feeds fro updates to things with distant expiry dates. 18:31:22 masinter has joined #tagmem 18:31:33 q+ to talk about what's required vs. what's desirable 18:32:01 who's here? 18:32:19 Tim: We don't have real push technology available (apart from Email) but supposing we make a package [a catalog] and we send them out. Then an erratum comes in for something that has a 12 month expiry date. Do we need a revocation mechanism? 18:32:30 zakim, who is here? 18:32:30 On the phone I see W3C 18:32:31 On IRC I see masinter, Ashok, timbl, DKA, plinss, ted, jar, johnk, ht, noah, RRSAgent, Zakim, trackbot, Yves 18:32:45 q? 18:33:21 Henry: I think there's an 80/20 point. Speaking as a user, I'm grateful for the shift from the 503s to the tarpitting. 18:33:33 q+ to mention HTTP automatically morphing to P2P when under stress 18:33:42 ... the delay of 30 seconds helps people to remind people to get the catalog. 18:34:13 masinter` has joined #tagmem 18:34:52 ... so that's a step forward. In response to Tim: the HTML DTDs are close to 80% of the problem, and they are legacy, they are not changing. If there were turn-key solutions for the tools that legitimately need those DTDs to validate - that made it easy for SAs to install the catalog that would cause the tools to find them, then I don't think there's an expiry problem. 18:34:58 q? 18:35:06 q+ 18:35:18 Tim: We have to consider the new and the old separately. 18:35:43 ... new systems could be designed differently. The total load on the server from the HTML dtd will go down over time. 18:35:50 masinter has joined #tagmem 18:36:50 masinter has joined #tagmem 18:37:48 Tim: My proposal - the old is finite damage, in the future we can issue different systems. This connects to an alternative to catalogs - promote a version of http that is much more robust, which could help Ted and could also help with other situations where someone has been disconnected from the net (e.g. the recent situation in Egyot). The new http version could use a number of different algorithms (e.g. P2P) to find the resource you are after. 18:37:53 q? 18:37:58 q+ to wonder if it's "http" or if it's some other "new http" = "http" 18:38:08 ... so that the chance of finding a copy locally (of a DTD) would be quite high. 18:38:23 ... after the Egypt situation, there's been a lot of interest in this. 18:38:30 ... I'd love to have the TAG push that forward. 18:38:39 ack timbl 18:38:39 timbl, you wanted to mention HTTP automatically morphing to P2P when under stress 18:38:41 q? 18:38:44 ack next 18:38:45 noah, you wanted to talk about what's required vs. what's desirable 18:39:02 q+ to speak up for the user 18:39:06 q? 18:39:12 q- 18:41:02 Noah: I think the role for the TAG is to talk about the problem that is not specific to particular resources like the html dtd. In previous times I've come across this problem, the response from some has been "well you should be running a proxy" - is that correct? And in some cases it is actually cheaper to make multiple http requests... 18:41:27 ... so: we could clarify the responsibilities that people have to cache or to not cache. 18:41:58 ... should we change the normative specs? 18:42:04 ... [some will push bacl] 18:42:59 ack next 18:43:07 ... for long term - we could break open this protocol http version 2. 18:43:52 Ted: Looking over the rfc-2616, the language is "should" around caching of http. 18:44:12 ... it's optional and treated as such. 18:44:20 q+ to give strawman: specs were wrong, so asking people to run a proxy is really only to compensate for our failures 18:44:26 ... lighter-weight implementations tend to be very barebones. 18:44:49 ... I think promoting catalogs is the way to go - and we should work to get major libraries to include it, ship it, and have it enabled by default. 18:45:05 ... I think the focus for the TAG should be in the meta problem. How to make URIs and web sites scale. 18:45:50 ... Sites do get overwhelmed. There is no way to let consumers of this data know what is acceptable behaviour besides sending back a 503. 18:46:01 should also note that HTML itself has gotten rid of DTDs. But isn't main problem giving out "http:" URIs in the first place? 18:46:05 ... we see lots of sites experiencing similar problems. 18:46:17 q? 18:46:19 ack next 18:46:20 ht, you wanted to speak up for the user 18:46:21 Noah: I read it as a MAY in rfc-2616 18:46:38 From RFC-2616 section 13.2.1: 18:46:52 The primary mechanism for avoiding 18:46:52 requests is for an origin server to provide an explicit expiration 18:46:52 time in the future, indicating that a response MAY be used to satisfy 18:46:52 subsequent requests. 18:47:00 So, it's a MAY not a SHOULD. 18:47:07 Henry: I'm concerned about the message we're sending to students "you should produce valid html, valid XML, etc..." and yet when they try to validate their documents they have to wait 30 seconds. 18:47:14 q+ to note that waiting 30 seconds should be to encourage alternate behaviour 18:47:40 ... because the web page has the public identifier. 18:47:46 Tim: Why does the validator not cache it? 18:48:23 Henry: Because the number of validators out there is quite large, and the free ones (while they support catalogs) but they don't distribute the catalog of DTS as part of their install. 18:48:27 [libxml from the beginning shipped w a catalog] 18:48:53 valid HTML no longer has a doctype http://www.w3.org/html/wg/tracker/issues/4 18:49:10 Tim: That can be fixed relatively easily - the DTDs can be wired into the code for things that aren't going to change any more. 18:49:48 Henry: The crucial people you need to convince are the open source implementers. 18:50:42 Noah: in many cases, when you dig into what needs to be fixed, it is not straightforward to change all the implementations... 18:51:11 Henry: I am more worried about the people [students] who are the future of the Web. The people who use off-the-shelf free validator tools and get burned. 18:51:56 q? 18:51:59 ack next 18:52:00 masinter, you wanted to give strawman: specs were wrong, so asking people to run a proxy is really only to compensate for our failures 18:52:01 Noah: should we undertake any work to help ted and/or ongoing work. 18:52:37 Larry: I think it was a serious design mistake to put a URL in a document that you didn't want anyone to retrieve and not tell them that. 18:53:11 ... all of these proxies are compensating for someone else's mistake. 18:53:13 q+ to ask: is it a mistake? 18:54:02 ... I'm worried it was a mistake in more than one way. The presumption was that if I send you a message with a pointer to a DTD there is some expectation that you'll get the same DTD that I meant you to get. But the lifetime of the message can be longer than the lifetime of the DTD. 18:54:05 ack next 18:54:06 johnk, you wanted to note that waiting 30 seconds should be to encourage alternate behaviour 18:54:43 ... We should think of the architectural design flaw here and make sure we don't do this again. 18:55:38 "there are no cool URLs, everything changes eventually" 18:55:42 John: Pragmatically, tarpitting requests that are overwhelming your server seems like the right way to deal with it [counterpoint to Henry's statement]. They should learn that they are doing something wrong. 18:55:46 "the URL is already broken" 18:56:10 ack next 18:56:12 noah, you wanted to ask: is it a mistake? 18:56:20 ... I'm worried we're going to overthink this, when education plus pragmatic tarpitting could be the right response. 18:56:31 q+ to long tail 18:57:10 Noah: My inclination is close to John's. This is a big distributed file system. [The system should cope with this.] 18:57:59 We have to design for the scale free web an we should be able to have specific designs tailored to make the extreme case of the most popular document/DTD/etc work, but we should not let that blind us to the general needs o fthe long tail. 18:58:13 ... what's implicit in what John is saying - these things are there to be dereferenced, in principle, you can look at these DTDs whenever you need to. The burden should be on the infrastructure to gracefully degrade and provide fair service. Tarpitting is a fine, proposed recommendation of best practice here. 18:58:16 masinter` has joined #tagmem 18:58:23 q? 18:58:26 ack next 18:58:27 timbl, you wanted to long tail 19:00:32 Tim: There are lots of DTD-like things out there. We need to be able to copy with various different scaling. We could provide some specific tailored response for these w3c issues. There may be similar things with some libraries... 19:01:16 Noah: Let's say there 100,000 ontologies, getting a lot of traffic. Let's say if I work my way through 100,000 ontologies in a loop. Should I also be tarpitted? 19:01:21 Tim: No. 19:01:33 masinter has joined #tagmem 19:02:03 q+ 19:02:05 Tim: I won't want to mess up the fact that in general you should be able to dereference a dtd if you want to. 19:02:14 q? 19:03:12 Jonathan: I'd like to hear more from Tim about the economics. [Analogy:] there's a popular library book. A library buys a copy. There's a lot of demand for i so you have to get in line to get it. For physical goods there is an infrastructure to support this. 19:03:12 masinter has joined #tagmem 19:03:32 q? 19:03:36 ... Publishers can take care of it. 19:04:03 Tim: For the case of harry potter, the book industry operates differently, because it's a different scale of usage. 19:05:16 Jonathan: Transaction costs [on the web] are so much lower. Inexpensive social expectations. 19:05:26 q+ 19:05:33 One downside of using URIs for things other than href@a and img@src is that these scale issues arise. This has been an architectural principle, to use http: URIs for things that you don't really intend to be referenced. it's not the only downside 19:05:58 I guess I just disagree that they should not be derefenced 19:06:04 ... it's a question of economics in relation to social expectations. ... who pays for what. 19:06:28 On the contrary, we've said that when you make things like namespaces, we want you to use http-scheme URIs precisely so that you CAN dereference them. 19:07:31 Larry, these DTD references are like img src -- each of the references is from an HTML document. 19:07:56 Larry: there has been an architectural principle for using URIs other than for HREFs and IMG SRC .. that architectural encouragement has some downsides. One of which is a scaling issue. You expect an IMG SRC to get as many retrievals as the document. And HREF to get as many requests as people clicking on it. So you can scale appropriately. DTDs, namespaces, ontologoes don't follow that model. 19:07:58 q+ to disagree with Larry 19:08:03 q- later 19:08:05 ack next 19:08:20 ... The mismatch has led to a couple of problems. 19:08:23 ack next 19:08:24 noah, you wanted to disagree with Larry 19:08:35 .. let's acknowledge the problem. 19:09:31 Noah: [disagreeing on the different scaling model between DTDs and IMG SRC...] 19:10:00 q? 19:10:02 ack next 19:10:43 Ted: To Tim's point: a software engineer comes up with a brand new ontology, puts it on his web site, it becomes popular - he will have the same headaches and hassles as we do. 19:11:19 Noah: If apache came pre-configured to handle the load would you be happy? 19:12:01 Ted: Yes, for example, if apache told search engines "I'm busy right now please come back later" then that would be good. You can't express in http your pain threshold. 19:12:37 Tim: TCP works really well because you stuff in as much as you can. It was designed at 300 baud times and it works at 300 gigabit times. 19:12:41 q+ to say that the problem was the W3C published a STANDARD that pointed to a http URI rather than something more permanent 19:12:58 Tim: You want to have negotiated quality of service. 19:13:15 speaking of Van Jacobson, http://en.wikipedia.org/wiki/Content-centric_networking 19:13:16 q? 19:13:36 q+ 19:13:47 ack next 19:13:49 masinter, you wanted to say that the problem was the W3C published a STANDARD that pointed to a http URI rather than something more permanent and to 19:14:26 Larry: Van Jacobson - has an interesting project on content-centric networks that we might want to look into. 19:15:16 [debate on whether DTDs are intended to be retrieved or not] 19:15:25 Noah: Next steps... 19:15:30 ACTION-390? 19:15:30 ACTION-390 -- Daniel Appelquist to review ISSUE-58 and suggest next steps -- due 2011-03-01 -- OPEN 19:15:30 http://www.w3.org/2001/tag/group/track/actions/390 19:16:35 Dan: I don't have an answer... 19:16:57 ted: the # (2-3?) of connection limit per ip gets in the way of user experiences as well, making CDN more popular. as administrator i would like to improve a user's browser experience (faster load time) and allow in some cases more concurrent connections 19:17:05 Noah: The simple answer is to [keep this on the back burner]. I need a proposal on what we should do and who does it. 19:17:07 ted: i also want to encourage search engines to crawl me and do so efficiently when convenient for me 19:17:27 ... I think we need a short finding on what people's responsibilities are regarding caching. 19:17:40 Norm has joined #tagmem 19:17:45 Henry: I will reach out to [authors of XML parsers]. 19:17:55 s/ted: i also/[i also 19:18:05 Tim: We should write what we want clients to do. 19:18:30 wonder if Henry could write up what he's asking and what they say or do? 19:18:32 Henry: A good idea is - what Ted mentioned - an adaptive caching mechanism. 19:19:09 Noah: We could talk about turing the MAY in rfc-2616 to a SHOULD. 19:19:18 Larry: I am against that. I think it's the wrong place. 19:19:41 Noah: When you have a piece of software that is in a position to detect repeated requests, you should cache. 19:19:56 [if caching was less optional and more widely deployed on net popular resources would scale better and performance would be better] 19:20:04 John: [supporting tarpitting] 19:20:13 q+ to put that on rec 19:20:49 John: I think it should be cached in the open source code level... 19:20:49 (a) I don't think we can quickly come to a conclusion, but (b) Henry has agreed to ask tool authors to do something, (c) think we could endorse what Henry asks if the tool authors are willing to go along with it 19:20:57 q+ to suggest Henry write that up 19:22:18 Norm has written about this; http://nwalsh.com/docs/articles/xml2003/ 19:22:28 [discussion of caching catalog and whether or not it's a catalog] 19:22:52 for example, "clear my cache" for privacy reasons might not clear the catalog 19:22:57 Henry: the OASIS catalog is just a string-to-string matcher, matching HTTP URIs to loca disk copies. 19:23:21 Larry: for privacy reasons you might want to say "clear my cache" but that wouldn't clear my catalog. 19:23:28 Ashok has joined #tagmem 19:23:44 Noah: What's implicit in john's proposal: separation of concerns. 19:24:13 Tim: I hope you wouldn't expect clients to spot that tcp connection is going slowly... 19:25:03 there are several places to intercept this problem. The first is the choice of the URI scheme for DTD or namespace or ontology. Second is choice of server and server infrastructure for serving, when the URI scheme is "http". Third is design of client software, fourth is operation of client. 19:25:28 Noah: the server is creating a network that is robust against traffic access pattern. Different clients will make different choices. A client might not need to change anything [in the case of e.g. tarpitting]. [if you are not time sensitive] 19:27:04 masinter` has joined #tagmem 19:27:14 Larry: Henry - I would like you to document what you tell [the implementors] and report back what they say. 19:28:21 Dan: on the p2p topic - should we be doing something here? 19:28:43 Henry: I don't know enough the next gen internet... 19:28:58 Tim: I don't think that internet2 is reinventing http. 19:29:03 s/http/tcp/ 19:29:08 [p2p has too much overhead (startup time to connect to peers) imho to be worthwhile for small resources. yves makes that point as well in his email] 19:30:17 Noah: This seems like an area where if we succeed it will take a third of our bandwidth. Rather than inviting people from the p2p community, we should either back off and do small things OR get one or 2 people on the tag to do a survey of what's out there and report back at the next f2f. 19:30:25 ... but we need people who want to put time into that. 19:31:30 q+ 19:31:34 Henry: over the next 2-3 years we better start thinking about how much of webarch is going to survive [with the next gen internet]. The interface between the tcp/ip layer and the http layer has thus-far been very clean. There's no guarantee that will be true 10-15 years from now. The TAG needs to start thinking about how we (the We 19:31:45 I wonder if this should be part of the TAG/IETF discussion 19:31:49 ... web) is going to survive. 19:32:20 Henry: [clarifying] as the future becomes clearer, we need to start tracking it ... 19:32:25 q? 19:32:51 ack next 19:32:52 ted, you wanted to put that on rec 19:32:52 Noah: I want to focus this on next steps. 19:33:01 ted: ^^ comment on merits of caching. in practice as we've heard from noah the costs of maintaining caching proxies too high compared to bandwidth. 19:33:01 ted: glad to hear larry's comment. get library developers to implement what ht suggests. i heard ht (and others) liked norm's caching catalog. would oracle implement it in jdk? 19:33:02 masinter, you wanted to suggest Henry write that up 19:33:35 masinter has joined #tagmem 19:33:54 q+ to remind people that just because there is a next-gen or internet2 activity doesn't mean that will be the future of the internet. :) 19:33:54 q? 19:33:54 test 19:34:49 Ted: [ speaking in support of the caching catalog approach ] 19:35:10 q? 19:35:18 q- 19:35:28 ack timbl 19:35:33 ack next 19:35:34 DKA, you wanted to remind people that just because there is a next-gen or internet2 activity doesn't mean that will be the future of the internet. :) 19:36:33 NM: Ted, anything hi priorty you want the TAG to do? 19:36:59 TG: Day by day, we're getting by. The catalog work would be helpful. What seems really useful is for the TAG to tackle the meta-issue. 19:37:45 TG: Directives are potentially useful; peer-to-peer seems most applicable for large things. 19:37:50 NM: Large or high volume? 19:38:02 TG: P2P startup times are typically significant, so large resources. 19:38:52 [and p2p could be intersting failover for http] 19:39:11 NM: Floor is open for volunteers 19:39:35 ACTION: Larry to help us figure out whether to say anything about scalability of access at IETF panel 19:39:35 Created ACTION-517 - Help us figure out whether to say anything about scalability of access at IETF panel [on Larry Masinter - due 2011-02-15]. 19:40:33 trackbot, status? 19:41:37 Ashok has joined #tagmem 19:41:58 ACTION: Henry S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools 19:41:59 Created ACTION-518 - S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools [on Henry S. Thompson - due 2011-02-15]. 19:41:59 . ACTION Peter to frame architectural opportunities relating to scalability of resource access 19:42:13 trackbot, action-518 due 2011-07-15 19:42:13 ACTION-518 S. to report back on efforts to get undertakings from open-source tool authors to ship pre-provisioned catalogs configured into their tools due date now 2011-07-15 19:42:40 ACTION Peter to frame architectural opportunities relating to scalability of resource access Due: 2011-03-15 19:42:40 Created ACTION-519 - Frame architectural opportunities relating to scalability of resource access Due: 2011-03-15 [on Peter Linss - due 2011-02-15]. 19:43:02 close ACTION-390 19:43:02 ACTION-390 Review ISSUE-58 and suggest next steps closed 19:43:19 Topic: Web Applications: Client-side state 19:45:45 ACTION-514 Due 2011-03-01 19:45:45 ACTION-514 Draft finding on API minimization Due: 2011-02-01 due date now 2011-03-01 19:45:52 (that should have been fixed this morning) 19:46:00 ted has left #tagmem 19:46:33 http://www.w3.org/2001/tag/2011/02/HashInURI-20110208.html 19:46:49 Noah: I think this draft needs to make a few key points... 19:47:02 Ashok: there is at the end a section on recommendations... 19:47:41 ... sections 4, 5 and 6 are the heart of it. 19:47:57 Noah: Can it be abstracted into a one or 2 sentence best practice? 19:48:23 [ looking through section 4 and picking out BP statements ] 19:48:26 I'm seeing as potential recommendations: 19:48:27 As the state of the resource and the display changes, the fragment identifier can be changed to keep track of the state. 19:48:34 I think the wording would be better if recast a bit 19:48:36 ...and... 19:48:37 if the URI is sent to someone else the fragment identifier can be used to recreate the state. 19:49:00 "the application can be designed so that the fragment identifier 'identifies' the state" 19:49:02 NM: What about "?" vs. "# 19:49:10 Ashok: I have added one paragraph - in the google maps case which I think talks about that. 19:49:12 AM: I added a para about that. 19:49:33 "the application can be designed so that the fragment identifier identifies or encodes the relevant transferable parts of the state" 19:50:30 Jonathan: Isn't this a special case of "use URIs to name things"? There are things that happen when you click or do a manipulation in your UI. You can name that action with a URI (a hyperlink) or you can not name it with a URI. If you use a URI then you have a control you can move out of the page. 19:50:34 Ashok: Yes. 19:50:37 q? 19:50:59 Larry: the application can be designed so that the fragment identifier identifies or encodes the relevant transferable parts of the state 19:51:09 Ashok: Yes. 19:52:03 Larry: in the case of a map application with a lot of state, then you want the app to be designed so that the URI contains the [part of the state that you want to be transferred to another client] 19:52:34 Larry: You can design the app so that the frag ig identifies or encodes the state you want uniformly erferenced 19:53:04 ... the part that you want to have uniformly referenced. 19:54:08 Noah: let's suspend disbelief and assume that google maps used hash signs. The question is: state of what? [demonstrates using google maps] 19:54:08 Ashok: What [gmaps 19:55:10 Noah: there are a lot of http interactions under the covers... 19:55:10 ... let's be careful about what is the transferable part of the resource... 19:55:12 ... originally, [in the case of gmaps] an http request was made for the generic http://maps.google.com document. 19:55:28 ... scrolling through this map feels like scrolling through an http document. 19:55:36 s/http/html/ 19:56:06 ... the question I want to raise: for this class of apps, you emphasise that there is a virtual document that is the map... 19:57:10 Ashok: [points to text in: http://www.w3.org/2001/tag/2011/02/HashInURI-20110208.html#InteractionState] 19:57:14 Ashok: we can work on this wording... 19:58:11 Tim: When you're looking at the map... It's interesting that you don't use the hash as you drive around... They do not use the hash, but they could... 19:58:45 Ashok: the question mark tells you what to bring from the server. the has would not tell you that. 19:58:52 Tim: they both would... 19:59:19 Ashok: I disagree it could be done with the hash. 19:59:58 Tim: What comes back on the response is a piece of javascript. The javascript then starts pulling in all the tiles. 20:00:29 Ashok: if the only thing that comes back is javascript on the first get... [then it could be hash...] 20:01:18 Noah: I think one of the attractions of this - is you don't have to do the distribution in the same way in all cases. If I use the hash sign and I us it in an email reader, the typical email client [wouldn't handle it correctly]. 20:02:04 Noah: [disables javascript and reloads the map from google maps; it works] 20:02:14 Noah: You couldn't do that with the hash sign. 20:04:35 Ashok: Your first access gets you the app plus some javascript... 20:07:15 Noah: where does the word representation apply. In the case of gmaps, is it a representation when it is generated with javascript, client side? 20:08:00 Tim: yes, it's a representation. 20:08:11 Tim: lots and lots of web pages are filled in with javascript. 20:08:45 Noah: Ok - it would be good to tell that story. Many web pages do this. There may be other ajax apps where you get different behavior. 20:09:09 Ashok: I'll ask TV if he can tell us what goes on under the covers [of google maps]. 20:12:44 example 3 talks about client URI generation - http://www.w3.org/2001/tag/2010/10/interaction-examples.html 20:13:12 Tim: History manipulation - to be able to change the behavior of the back button and change what's in the location bar - is in firefox 4. 20:13:52 Ashok: [talking through section 6] 20:14:12 Ashok: Do these or don't these violate specs and what do / should we do? 20:14:44 ... frag ids for html and xml... many media types don't define usage of frag ids.. 20:14:53 Larry: But we are specifically talking about http and html... 20:15:25 Ashok: [last paragraph] - "active content" 20:15:56 Larry: When you talk about URIs do you mean URIs in general, or just http URIs...? 20:16:05 ... [you need to be specific.] 20:16:41 Tim: I think we should make feel bad about using hash in this way. We should change the specs. 20:16:48 Larry: We should fix the specs to match. 20:17:13 Henry: I'm happier with doing this if we can say "because it's not incompatible" with the speced story. 20:17:43 Larry: originally content was static. Fragment ids were pointers to static pointers. Now content is active... 20:18:10 Henry: the interpretation of stuff after the hash should be client side... 20:18:15 [broad agreement] 20:20:23 Larry: it would be great if URIs worked [interoperated] between google maps and yahoo maps... 20:20:57 AndroUser has joined #tagmem 20:21:09 Henry: Historically the spec told you that all you needed to know was the media type of the response, now it's more tightly coupled. 20:21:48 The page tells you what the fragId is used for 20:22:21 Tim: what's interesting about the maps space - it would be great if the user has independent control over what happens when you get a GEO URI... what service you want to use... 20:22:58 John: Lat and Long have meaning in the real world. You also have the position on a map, which is different from the real space. The third part is the panning and zooming. 20:23:13 Tim: all you need is the lat - lon. 20:23:29 ... the user [should] just see lat, long. 20:23:46 There has been a real change in where the responsibility for determining the meaning of the post-# strings lies 20:23:59 Per the existing specs, it's global, and lies in the media type registration 20:24:40 Per the practice under discussion, it lies with the [transitive closure of] the representation retrieved for the pre-# URI 20:26:09 This is parallel to where the code comes from the _implements_ the semantics: for the existing spec. story, it's in the UA from the beginning, because it's known at UA-creation time, because it comes from the media type spec. 20:26:29 whereas for the new usage, it's in the retrieved representation itself 20:27:09 John: I think this goes back to the coupling issue. 20:27:09 Ashok: [back to the document] Section 7 - I didn't do anything with it - Yves says take it out... 20:28:14 Noah: It feels like we haven't nailed the good practices and recommendation. There are some interesting bits here. I'd like to see them in support of some news [some concrete recommendations]. Then we could see what other groups we need to coordinate with. 20:28:14 [back up to section 4] 20:28:31 Ashok has joined #tagmem 20:29:02 Noah: Not happy with the word "operate" in section 4. 20:29:18 [discussion on the wording] 20:29:27 Noah: I think it's more like: the JavaScript uses the fragment identifier as well as other information to render the representation(?) of the resource. 20:29:44 Noah: I think it's more like: the JavaScript uses the fragment identifier as well as other information to render and support interaction with the representation(?) of the resource. 20:30:27 Noah: On "As the state of the resource and the display changes, the fragment identifier can be changed to keep track of the state." Yes, but we need to get clear on pros and cons of ? vs. # 20:32:30 Dan: do you need to assume programmatic access to the history/address bar? 20:33:39 TBL: The key point on # vs ? is that when you update the address bar, the page >will< reload. In the case of #, well, the right document is already loaded. In the case of ?, the tendency would be to reload the page. 20:33:58 TBL: Right, and when the GET happens, you lose state. 20:35:08 noah has joined #tagmem 20:37:04 jar has joined #tagmem 20:37:32 DKA has joined #tagmem 20:37:36 johnk has joined #tagmem 20:37:42 plinss has joined #tagmem 20:37:42 timbl has joined #tagmem 20:38:40 timbl_ has joined #tagmem 20:39:39 Noah: This finding has been slowly evolving. Need to hear from the TAG : we need to focus on it, get it to where people are happy and move ahead. 20:39:56 +1 on its usefulness. 20:40:52 Jonathan: I am not worked up about it. My focus tends to be on what does the stuff mean, independent on the protocols. 20:41:04 masinter has joined #tagmem 20:41:20 ... I can't figure out who it would help or who would pay attention. 20:42:04 Henry: The thing that caused me to wake up: the two people who have the most invested in the history saying "yes we should change the spec." [Larry and Tim] So the way we should change this spec is to have a set of guidelines and suggestions on what specs should change, how they should change and why it's OK. 20:43:05 Larry: the media type registration needs to say (for active content) when and how those parameters are passed to the active content. We are extending something originally designed for passive content to change for active content. 20:43:33 Henry: So this should be a story about how we think about media type registration in the space [active content] that we are now living in. 20:44:10 Larry: ..make the frag identifiers useful for the potion of the state that you are interested in [uniformly referencing]. 20:45:03 Larry: We could start with the current document as a note and use that as a basis to add something to the mime-web document and maybe another document. 20:45:48 Noah: the document either has to cut the advice out, or it needs to give advice in close to the style that we've done in findings. "Good practice: xxx , explanation"... 20:45:55 ... or describe use cases. 20:46:09 ... Ashok I think that work needs to be done before publishing it as a note. 20:46:41 Larry: I'm OK with it. The context is a discovery... 20:48:07 Dan: I think that sounds like the right approach - reformatting / expanding some of the recommendations and publishing it as a note. 20:48:21 John: I think it makes sense to document things we'd like to see happen. 20:48:50 ... highlighting that kind of usage is good. But I worry that it's getting a bit wooly. 20:49:20 ... I told Raman when I reviewed this document that he could pull out 2 things - the same things referenced in section 4 of the current document. 20:49:45 Ashok: I think we can make this [section 4] better. 20:50:21 ... If people think that after that we can publish this as a note, great. Following that, if you want something smaller - one page, about spec recommendations, then we can pull that out. 20:50:34 Noah: that could be as simple as giving someone an action... 20:52:12 action-508? 20:52:12 ACTION-508 -- Larry Masinter to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 -- due 2011-02-12 -- OPEN 20:52:12 http://www.w3.org/2001/tag/group/track/actions/508 20:52:47 action-500? 20:52:47 ACTION-500 -- Larry Masinter to coordinate about TAG participation in IETF/IAB panel at March 2011 IETF -- due 2011-02-15 -- OPEN 20:52:47 http://www.w3.org/2001/tag/group/track/actions/500 20:52:48 Leave ACTION-481 as is 20:53:48 ACTION-508? 20:53:48 ACTION-508 -- Larry Masinter to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 -- due 2011-02-12 -- OPEN 20:53:48 http://www.w3.org/2001/tag/group/track/actions/508 20:53:59 LM: Ashok's document should be a stable reference. 20:54:35 ACTION-508 Due 2011-02-22 20:54:35 ACTION-508 Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 due date now 2011-02-22 20:55:00 action-508 should say that the problem is that #XXXX are parameters to acdtive content 21:00:13 timbl_ has joined #tagmem 21:01:27 timbl has joined #tagmem 21:13:46 timbl_ has joined #tagmem 21:15:08 Topic: the IETF presentation... 21:15:16 timbl__ has joined #tagmem 21:16:06 Larry: What is the boundary between "the web" and the "rest of the Internet"? 21:16:21 ISSUE-500? 21:16:21 ISSUE-500 does not exist 21:16:29 Ashok has joined #tagmem 21:16:42 issue-500? 21:16:42 ISSUE-500 does not exist 21:16:47 action-500? 21:16:47 ACTION-500 -- Larry Masinter to coordinate about TAG participation in IETF/IAB panel at March 2011 IETF -- due 2011-02-15 -- OPEN 21:16:47 http://www.w3.org/2001/tag/group/track/actions/500 21:19:53 [re: Ashok's document on fragments, I'll send further comments/help working on it] 21:20:09 [debate on what is implied by the quote from the IAB] 21:20:38 Thanks, Yves! 21:26:15 Noah: The TAG has decided to say yes to participating on the IETF panel in Prague. 21:27:24 Topic: Admin 21:27:34 Noah: Once again, welcome to Peter. 21:27:47 Noah: Minutes of the 20th - approved? 21:27:54 Minutes of the 20th are approved. 21:28:03 Noah: Note that TPAC is happening November in Santa Clara. 21:29:09 Noah: we would normally meet sometime in may timeframe. there is an ac meeting in bilbao, spain in may. 21:30:07 ... so - open to suggestions. 21:30:21 ... we could meet in Cambridge again... 21:30:41 Tim: 11-12-13 of May in London...? 21:30:45 Noah: Doesn't work for me. 21:31:17 Noah: Who else is going to the ac meeting? 21:31:29 Noah: 9-11 in the UK? 21:31:46 Larry: Week of the 9th I am completely booked. 21:32:49 Noah: Week after the AC? 21:33:00 [week of the 23rd] 21:33:39 [not good for Tim] 21:35:15 Noah: Week of June 6? 21:38:03 Noah: 7-8-9 of June? 21:38:17 Tim: Yes could do it - would have to be in Cambridge. 21:39:51 Noah: Formal proposal - 7-9 June in cambridge Mass for next TAG f2f meeting. 21:39:55 +1 21:40:24 Noah: Should we talk about September? 21:40:39 Henry: I would be happy to host. 21:41:56 +1 to edinburgh in September. 21:49:12 ACTION: Settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 21:49:12 Sorry, couldn't find user - Settle 21:49:46 RESOLUTION: The TAG will meet at MIT 7-9 June 21:50:47 ACTION: Noah to settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 21:50:47 Created ACTION-520 - Settle London vs. Edinburgh for Sept. 13-15 F2F Due 2011-05-31 [on Noah Mendelsohn - due 2011-02-15]. 21:51:25 RESOLUTION: The TAG will meet in the UK 13-15 Sept, either Edinburgh or London, TBD see ACTION-520 21:52:10 RRSAgent, make minutes 21:52:10 I have made the request to generate http://www.w3.org/2011/02/08-tagmem-minutes.html DKA 21:52:18 rrsagent, make logs public 21:52:30 rrsagent, pointer 21:52:30 See http://www.w3.org/2011/02/08-tagmem-irc#T21-52-30 22:00:38 -W3C 22:00:40 TAG_f2f()8:30AM has ended 22:00:40 Attendees were W3C 22:03:10 Draft minutes available here: http://www.w3.org/2001/tag/2011/02/08-minutes.html 22:11:13 ndw has joined #tagmem 22:19:12 Zakim has left #tagmem 22:43:17 rrsagent, make logs public 23:11:20 jar has joined #tagmem 23:19:08 Norm has joined #tagmem 23:29:31 ht has joined #tagmem